Merge branch 'u-boot/master'

Conflicts:
	drivers/net/Makefile

(trivial merge)

10 files changed, 499 insertions, 37 deletions

diff --git a/doc/DocBook/.gitignore b/doc/DocBook/.gitignore
index 720f245ceb..7ebd5465d9 100644
--- a/doc/DocBook/.gitignore
+++ b/doc/DocBook/.gitignore
@@ -10,5 +10,6 @@
 *.out
 *.png
 *.gif
+*.svg
 media-indices.tmpl
 media-entities.tmpl
diff --git a/doc/DocBook/Makefile b/doc/DocBook/Makefile
index 9b4a9b6762..593237f04a 100644
--- a/doc/DocBook/Makefile
+++ b/doc/DocBook/Makefile
@@ -26,6 +26,7 @@ PS_METHOD	= $(prefer-db2x)
 # The targets that may be used.
 PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
 
+targets += $(DOCBOOKS)
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
 xmldocs: $(BOOKS)
 sgmldocs: xmldocs
@@ -44,17 +45,18 @@ htmldocs: $(HTML)
 
 MAN := $(patsubst %.xml, %.9, $(BOOKS))
 mandocs: $(MAN)
+	$(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
 
 installmandocs: mandocs
 	mkdir -p /usr/local/man/man9/
-	install doc/DocBook/man/*.9.gz /usr/local/man/man9/
+	install $(obj)/man/*.9.gz /usr/local/man/man9/
 
 ###
 #External programs used
 KERNELDOC = $(srctree)/scripts/kernel-doc
 DOCPROC   = $(objtree)/scripts/docproc
 
-XMLTOFLAGS = -m $(srctree)/doc/DocBook/stylesheet.xsl
+XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
 
 ###
@@ -76,21 +78,9 @@ define rule_docproc
         ) > $(dir $@).$(notdir $@).cmd
 endef
 
-%.xml: %.tmpl FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
 	$(call if_changed_rule,docproc)
 
-###
-#Read in all saved dependency files
-cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
-
-ifneq ($(cmd_files),)
-  include $(cmd_files)
-endif
-
-###
-# Changes in kernel-doc force a rebuild of all documentation
-$(BOOKS): $(KERNELDOC)
-
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 
@@ -128,16 +118,16 @@ quiet_cmd_db2pdf = PDF     $@
 
 
 index = index.html
-main_idx = doc/DocBook/$(index)
+main_idx = $(obj)/$(index)
 build_main_index = rm -rf $(main_idx); \
 		   echo '<h1>U-Boot Bootloader HTML Documentation</h1>' >> $(main_idx) && \
 		   echo '<h2>U-Boot Version: $(UBOOTVERSION)</h2>' >> $(main_idx) && \
 		   cat $(HTML) >> $(main_idx)
 
 quiet_cmd_db2html = HTML    $@
-      cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
+      cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
-        $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+		$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
 
 %.html:	%.xml
 	@(which xmlto > /dev/null 2>&1) || \
@@ -149,7 +139,7 @@ quiet_cmd_db2html = HTML    $@
             cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
 
 quiet_cmd_db2man = MAN     $@
-      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
+      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
 %.9 : %.xml
 	@(which xmlto > /dev/null 2>&1) || \
 	 (echo "*** You need to install xmlto ***"; \
diff --git a/doc/README.b4860qds b/doc/README.b4860qds
index 3da77d9f0f..eada0c7dd8 100644
--- a/doc/README.b4860qds
+++ b/doc/README.b4860qds
@@ -328,3 +328,39 @@ The below commands apply to both B4860QDS and B4420QDS.
    On Linux the interfaces are renamed as:
 	. eth2 -> fm1-gb2
 	. eth3 -> fm1-gb3
+
+NAND boot with 2 Stage boot loader
+----------------------------------
+PBL initialise the internal SRAM and copy SPL(160KB) in SRAM.
+SPL further initialise DDR using SPD and environment variables and copy
+u-boot(768 KB) from flash to DDR.
+Finally SPL transer control to u-boot for futher booting.
+
+SPL has following features:
+ - Executes within 256K
+ - No relocation required
+
+ Run time view of SPL framework during  boot :-
+ -----------------------------------------------
+ Area        | Address                         |
+-----------------------------------------------
+ Secure boot | 0xFFFC0000 (32KB)               |
+ headers     |                                 |
+ -----------------------------------------------
+ GD, BD      | 0xFFFC8000 (4KB)                |
+ -----------------------------------------------
+ ENV         | 0xFFFC9000 (8KB)                |
+ -----------------------------------------------
+ HEAP        | 0xFFFCB000 (30KB)               |
+ -----------------------------------------------
+ STACK       | 0xFFFD8000 (22KB)               |
+ -----------------------------------------------
+ U-boot SPL  | 0xFFFD8000 (160KB)              |
+ -----------------------------------------------
+
+NAND Flash memory Map on B4860 and B4420QDS
+------------------------------------------
+ Start		 End		Definition			Size
+0x000000	0x0FFFFF	u-boot                          1MB
+0x140000	0x15FFFF	u-boot env                      128KB
+0x1A0000	0x1BFFFF	FMAN Ucode                      128KB
diff --git a/doc/README.console b/doc/README.console
index c9ef59e9a5..aadf596a8a 100644
--- a/doc/README.console
+++ b/doc/README.console
@@ -25,7 +25,7 @@ stdout or stderr) to any device you see in that list simply by
 assigning its name to the corresponding environment variable. For
 example:
 
-    setenv stdin wl_kbd		<- To use the wireless keyboard
+    setenv stdin serial		<- To use the serial input
     setenv stdout video		<- To use the video console
 
 Do a simple "saveenv" to save the console settings in the environment
@@ -99,4 +99,3 @@ The driver has been tested with the following configurations (see
 CREDITS for other contact informations):
 
 - MPC823FADS with AD7176 on a PAL TV (YCbYCr)	- arsenio@tin.it
-- GENIETV    with AD7177 on a PAL TV (YCbYCr)	- arsenio@tin.it
diff --git a/doc/README.generic-board b/doc/README.generic-board
new file mode 100644
index 0000000000..50d3a26849
--- /dev/null
+++ b/doc/README.generic-board
@@ -0,0 +1,189 @@
+#
+# (C) Copyright 2014 Google, Inc
+# Simon Glass <sjg@chromium.org>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+DEPRECATION NOTICE FOR arch/<arch>/lib/board.c
+
+For board maintainers: Please submit patches for boards you maintain before
+July 2014, to make them use generic board.
+
+For architecture maintainers: Please submit patches to remove your
+architecture-specific board.c file before October 2014.
+
+
+Background
+----------
+
+U-Boot has tranditionally had a board.c file for each architecture. This has
+introduced quite a lot of duplication, with each architecture tending to do
+initialisation slightly differently. To address this, a new 'generic board
+init' feature was introduced a year ago in March 2013 (further motivation is
+provided in the cover letter below).
+
+
+What has changed?
+-----------------
+
+The main change is that the arch/<arch>/lib/board.c file is being removed in
+favour of common/board_f.c (for pre-relocation init) and common/board_r.c
+(for post-relocation init).
+
+Related to this, the global_data and bd_t structures now have a core set of
+fields which are common to all architectures. Architecture-specific fields
+have been moved to separate structures.
+
+
+Supported Arcthitectures
+------------------------
+
+If you are unlucky then your architecture may not support generic board.
+The following architectures are supported at the time of writing:
+
+   arc
+   arm
+   powerpc
+   sandbox
+   x86
+
+If your architecture is not supported, you need to adjust your
+arch/<arch>/config.mk file to include:
+
+   __HAVE_ARCH_GENERIC_BOARD := y
+
+and test it with a suitable board, as follows.
+
+
+Adding Support for your Board
+-----------------------------
+
+To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in
+your board config header file.
+
+Test that U-Boot still functions correctly on your board, and fix any
+problems you find. Don't be surprised if there are no problems - generic
+board has had a reasonable amount of testing with common boards.
+
+
+DeadLine
+--------
+
+Please don't take this the wrong way - there is no intent to make your life
+miserable, and we have the greatest respect and admiration for U-Boot users.
+However, with any migration there has to be a period where the old way is
+deprecated and removed. Every patch to the deprecated code introduces a
+potential breakage in the new unused code. Therefore:
+
+Boards or architectures not converted over to general board by the
+end of 2014 may be forcibly changed over (potentially causing run-time
+breakage) or removed.
+
+
+
+Further Background
+------------------
+
+The full text of the original generic board series is reproduced below.
+
+--8<-------------
+
+This series creates a generic board.c implementation which contains
+the essential functions of the major arch/xxx/lib/board.c files.
+
+What is the motivation for this change?
+
+1. There is a lot of repeated code in the board.c files. Any change to
+things like setting up the baud rate requires a change in 10 separate
+places.
+
+2. Since there are 10 separate files, adding a new feature which requires
+initialisation is painful since it must be independently added in 10
+places.
+
+3. As time goes by the architectures naturely diverge since there is limited
+pressure to compare features or even CONFIG options against simiilar things
+in other board.c files.
+
+4. New architectures must implement all the features all over again, and
+sometimes in subtley different ways. This places an unfair burden on getting
+a new architecture fully functional and running with U-Boot.
+
+5. While it is a bit of a tricky change, I believe it is worthwhile and
+achievable. There is no requirement that all code be common, only that
+the code that is common should be located in common/board.c rather than
+arch/xxx/lib/board.c.
+
+All the functions of board_init_f() and board_init_r() are broken into
+separate function calls so that they can easily be included or excluded
+for a particular architecture. It also makes it easier to adopt Graeme's
+initcall proposal when it is ready.
+
+http://lists.denx.de/pipermail/u-boot/2012-January/114499.html
+
+This series removes the dependency on generic relocation. So relocation
+happens as one big chunk and is still completely arch-specific. See the
+relocation series for a proposed solution to this for ARM:
+
+http://lists.denx.de/pipermail/u-boot/2011-December/112928.html
+
+or Graeme's recent x86 series v2:
+
+http://lists.denx.de/pipermail/u-boot/2012-January/114467.html
+
+Instead of moving over a whole architecture, this series takes the approach
+of simply enabling generic board support for an architecture. It is then up
+to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board
+config file. If this is not done, then the code will be generated as
+before. This allows both sets of code to co-exist until we are comfortable
+with the generic approach, and enough boards run.
+
+ARM is a relatively large board.c file and one which I can test, therefore
+I think it is a good target for this series. On the other hand, x86 is
+relatively small and simple, but different enough that it introduces a
+few issues to be solved. So I have chosen both ARM and x86 for this series.
+After a suggestion from Wolfgang I have added PPC also. This is the
+largest and most feature-full board, so hopefully we have all bases
+covered in this RFC.
+
+A generic global_data structure is also required. This might upset a few
+people. Here is my basic reasoning: most fields are the same, all
+architectures include and need it, most global_data.h files already have
+#ifdefs to select fields for a particular SOC, so it is hard to
+see why architecures are different in this area. We can perhaps add a
+way to put architecture-specific fields into a separate header file, but
+for now I have judged that to be counter-productive.
+
+Similarly we need a generic bd_info structure, since generic code will
+be accessing it. I have done this in the same way as global_data and the
+same comments apply.
+
+There was dicussion on the list about passing gd_t around as a parameter
+to pre-relocation init functions. I think this makes sense, but it can
+be done as a separate change, and this series does not require it.
+
+While this series needs to stand on its own (as with the link script
+cleanup series and the generic relocation series) the goal is the
+unification of the board init code. So I hope we can address issues with
+this in mind, rather than focusing too narrowly on particular ARM, x86 or
+PPC issues.
+
+I have run-tested ARM on Tegra Seaboard only. To try it out, define
+CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on
+x86 and PPC at least it will hang, but if you are lucky it will print
+something first :-)
+
+I have run this though MAKEALL with CONFIG_SYS_GENERIC_BOARD on for all
+ARM, PPC and x86 boards. There are a few failures due to errors in
+the board config, which I have sent patches for. The main issue is
+just the difference between __bss_end and __bss_end__.
+
+Note: the first group of commits are required for this series to build,
+but could be separated out if required. I have included them here for
+convenience.
+
+------------->8--
+
+Simon Glass, sjg@chromium.org
+March 2014
diff --git a/doc/README.power-framework b/doc/README.power-framework
new file mode 100644
index 0000000000..1f6fd43203
--- /dev/null
+++ b/doc/README.power-framework
@@ -0,0 +1,166 @@
+#
+# (C) Copyright 2014 Samsung Electronics
+# Lukasz Majewski <l.majewski@samsung.com>
+#
+# SPDX-License-Identifier:      GPL-2.0+
+#
+
+Introduction
+------------
+
+This document describes the second version of the u-boot's PMIC (Power
+Management IC) framework. As a reference boards please consider Samsungs' Trats
+and Trats2.
+
+Background
+----------
+
+Boards supported by u-boot are getting increasingly complex. Developers and
+designers strive to cut down power consumption. Hence several different types of
+devices are now available on the board - namely power managers (PMIC), fuel
+gauges (FG), micro USB interface controllers (MUIC), batteries, multi-function
+devices (MFD).
+
+Explanation of key design decisions
+-----------------------------------
+
+One package can integrate PMIC and MUIC with different addresses on the I2C bus.
+The same device - e.g. MAX8997 uses two different I2C busses and addresses.
+
+Power devices use not only I2C for communication, but SPI as well. Additionally
+different ICs use different endianess. For this reason struct pmic holds
+information about I2C/SPI transmission, which is used with generic
+pmic_req_write() function.
+
+The "flat" hierarchy for power devices works well when each device performs only
+one operation - e.g. PMIC enables LDO.
+
+The problem emerges when we have a device (battery) which conceptually shall be
+the master and uses methods exported by other devices. We need to control MUIC
+to start charging the battery, use PMIC to reduce board's overall power
+consumption (by disabling not needed LDOs, BUCKs) and get current state of
+energy on the battery from FG.
+Up till now u-boot doesn't support device model, so a simple one had to be
+added.
+
+The directory hierarchy has following structure:
+./include/power/<device_name>_<device_function>.h
+e.g. ./include/power/max8997_pmic.h
+
+./drivers/power/pmic/power_{core files}.c
+e.g. ./drivers/power/pmic/power_core.c
+
+./drivers/power/pmic/<device_function>/<device_function>_<device_name>.c
+e.g. ./drivers/power/pmic/pmic_max8997.c
+e.g. ./drivers/power/battery/trats/bat_trats.c
+e.g. ./drivers/power/fuel_gauge/fg_max17042.c
+
+The framework classifies devices by their function - separate directories should
+be maintained for different classes of devices.
+
+Current design
+--------------
+
+Everything is a power device described by struct pmic. Even battery is
+considered as a valid power device. This helps for better management of those
+devices.
+
+- Block diagram of the hierarchy:
+			-----------------
+		--------| BAT           |------------
+		|       |               |           |
+		|       -----------------           |
+		|               |                   |
+	       \|/             \|/                 \|/
+	-----------     -----------------       ---------
+	|FG       |     |MUIC           |       |CHRG   |
+	|         |     |               |       |       |
+	-----------     -----------------       ---------
+
+
+1. When hierarchy is not needed (no complex battery charge):
+
+Definition of the struct pmic is only required with proper name and parameters
+for communication. This is enough to use the "pmic" command in the u-boot
+prompt to change values of device's register (enable/disable LDO, BUCK).
+
+The PG, MUIC and CHRG above are regarded to be in the same level in the
+hierarchy.
+
+2. Complex battery charging.
+
+To charge a battery, information from several "abstract" power devices is
+needed (defined at ./include/power/pmic.h):
+- FG device (struct power_fg):
+	     -- *fg_battery_check - check if battery is not above its limits
+	     -- *fg_battery_update - update the pmic framework with current
+				     battery state(voltage and current capacity)
+
+- Charger device (struct power_chrq):
+	     -- *chrg_type - type/capacity of the charger (including information
+			     about USB cable disconnection)
+	     -- *chrg_bat_present - detection if battery to be charged is
+				    present
+	     -- *chrg_state - status of the charger - if it is enabled or
+			      disabled
+
+- Battery device (struct power_battery):
+	     -- *battery_init - assign proper callbacks to be used by top
+				hierarchy battery device
+	     -- *battery_charge - called from "pmic" command, responsible
+				  for performing the charging
+
+Now two batteries are supported; trats and trats2 [*]. Those differ in the way
+how they handle the exact charging. Trats uses polling (MAX8997) and trats2
+relies on the PMIC/MUIC HW completely (MAX77693).
+
+__Example for trats (this can be very different for other board):__
+	     -- *fg_battery_check       -> FG device (fg_max17042.c)
+	     -- *fg_battery_update      -> FG device (fg_max17042.c)
+	     -- *chrg_type              -> MUIC device (muic_max8997.c)
+	     -- *chrg_bat_present       -> PMIC device (pmic_max8997.c)
+	     -- *chrg_state             -> PMIC device (pmic_max8997.c)
+	     -- *battery_init           -> BAT device (bat_trats.c)
+	     -- *battery_charge         -> BAT device (bat_trats.c)
+
+Also the struct pmic holds method (*low_power_mode) for reducing board's
+power consumption when one calls "pmic BAT_TRATS bat charge" command.
+
+How to add a new power device
+-----------------------------
+
+1. Simple device should be added with creation of file
+<pmic_function>_<pmic_name>.c, <pmic_name>_<pmic_function>.h  according to the
+proposed and described above scheme.
+
+Then "pmic" command supports reading/writing/dump of device's internal
+registers.
+
+2. Charging battery with hierarchy
+Define devices as listed at 1.
+
+Define battery file (bat_<board>.c). Please also note that one might need a
+corresponding battery model description for FG.
+
+For points 1 and 2 use a generic function power_init_board() to initialise the
+power framework on your board.
+
+For reference, please look into the trats/trats2 boards.
+
+TO DO list (for PMICv3) - up till v2014.04
+------------------------------------------
+
+1. Description of the devices related to power via device tree is not available.
+This is the main problem when a developer tries to build a multi-boot u-boot
+binary. The best would be to parse the DTS from Linux kernel.
+
+2. To support many instances of the same IC, like two MAX8997, one needs to
+copy the corresponding pmic_max8997.c file with changed name to "MAX8997_PMICX",
+where X is the device number. This problem will be addressed when extended
+pmic_core.c will support storing available devices in a list.
+
+3. Definition of batteries [*] (for trats/trats2) should be excluded from the
+code responsible for charging them and since it in fact describes the charging
+profile it should be put to a separate file.
+
+4. Adjust the framework to work with the device model.
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index 7d670339dd..f9742e7d49 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -11,8 +11,17 @@ easily if here is something they might want to dig for...
 
 Board            Arch        CPU            Commit      Removed     Last known maintainer/contact
 =================================================================================================
-idmr             m68k        mcf52x2        -           2014-01-28
-M5271EVB         m68k        mcf52x2        -           2014-01-28
+lubbock          arm         pxa            -           2014-04-04  Kyle Harris <kharris@nexus-tech.net>
+MOUSSE           powerpc     mpc824x        -           2014-04-04
+rsdproto         powerpc     mpc8260        -           2014-04-04
+RPXsuper         powerpc     mpc8260        -           2014-04-04
+RPXClassic       powerpc     mpc8xx         -           2014-04-04
+RPXlite          powerpc     mpc8xx         -           2014-04-04
+genietv          powerpc     mpc8xx         -           2014-04-04
+mbx8xx           powerpc     mpc8xx         -           2014-04-04
+nx823            powerpc     mpc8xx         -           2014-04-04
+idmr             m68k        mcf52x2        ba650e9b    2014-01-28
+M5271EVB         m68k        mcf52x2        ba650e9b    2014-01-28
 dvl_host         arm         ixp            e317de6b    2014-01-28  Michael Schwingen <michael@schwingen.org>
 actux4           arm         ixp            6ff7aafa    2014-01-28  Michael Schwingen <michael@schwingen.org>
 actux3           arm         ixp            38da33f3    2014-01-28  Michael Schwingen <michael@schwingen.org>
@@ -26,11 +35,15 @@ pdnb3            arm         ixp            304db0b     2013-09-24  Stefan Roese
 scpu             arm         ixp            304db0b     2013-09-24  Stefan Roese <sr@denx.de>
 omap1510inn      arm         arm925t        0610a16     2013-09-23  Kshitij Gupta <kshitij@ti.com>
 CANBT            powerpc     405CR          fb8f4fd     2013-08-07  Matthias Fuchs <matthias.fuchs@esd.eu>
+omap2420h4       arm         omap24xx       7f5eef9     2013-06-04  Richard Woodruff <r-woodruff2@ti.com>
 Alaska8220       powerpc     mpc8220        d6ed322     2013-05-11
 Yukon8220        powerpc     mpc8220        d6ed322     2013-05-11
 sorcery          powerpc     mpc8220        d6ed322     2013-05-11
 smdk6400         arm         arm1176        52587f1     2013-04-12  Zhong Hongbo <bocui107@gmail.com>
 ns9750dev        arm         arm926ejs      4cfc611     2013-02-28  Markus Pietrek <mpietrek@fsforth.de>
+eNET             x86         x86            7e8c53d     2013-02-14  Graeme Russ <graeme.russ@gmail.com>
+PCIPPC2          powerpc     MPC740/MPC750  7c9e89b     2013-02-07  Wolfgang Denk <wd@denx.de>
+PCIPPC6          powerpc     MPC740/MPC750  7c9e89b     2013-02-07  Wolfgang Denk <wd@denx.de>
 AMX860           powerpc     mpc860         1b0757e     2012-10-28  Wolfgang Denk <wd@denx.de>
 c2mon            powerpc     mpc855         1b0757e     2012-10-28  Wolfgang Denk <wd@denx.de>
 EP88x            powerpc     mpc885         1b0757e     2012-10-28
@@ -40,15 +53,17 @@ LANTEC           powerpc     mpc850         1b0757e     2012-10-28  Wolfgang Den
 SCM              powerpc     mpc8260        1b0757e     2012-10-28  Wolfgang Grandegger <wg@denx.de>
 SX1              arm         arm925t        53c4154     2012-10-26
 TQM85xx          powerpc     MPC85xx        d923a5d     2012-10-04  Stefan Roese <sr@denx.de>
+ADCIOP           powerpc     ppc4xx         99bcad1     2012-09-19  Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+DASA_SIM         powerpc     ppc4xx         99bcad1     2012-09-19  Matthias Fuchs <matthias.fuchs@esd-electronics.com>
 apollon          arm         omap24xx       535c74f     2012-09-18  Kyungmin Park <kyungmin.park@samsung.com>
 tb0229           mips        mips32         3f3110d     2011-12-12
 rmu              powerpc     MPC850         fb82fd7     2011-12-07  Wolfgang Denk <wd@denx.de>
 OXC              powerpc     MPC8240        309a292     2011-12-07
 BAB7xx           powerpc     MPC740/MPC750  c53043b     2011-12-07  Frank Gottschling <fgottschling@eltec.de>
-xm250            arm         pxa            c746cdd     2011-25-11
-pleb2            arm         pxa            b185a1c     2011-25-11
-cradle           arm         pxa            4e24f8a     2011-25-11  Kyle Harris <kharris@nexus-tech.net>
-cerf250          arm         pxa            a3f1241     2011-25-11  Prakash Kumar <prakash@embedx.com>
+xm250            arm         pxa            c477d72     2011-11-25
+pleb2            arm         pxa            d299173     2011-11-25
+cradle           arm         pxa            00c4aca     2011-11-25  Kyle Harris <kharris@nexus-tech.net>
+cerf250          arm         pxa            f13eba6     2011-11-25  Prakash Kumar <prakash@embedx.com>
 mpq101           powerpc     mpc85xx        e877fab     2011-10-23  Alex Dubov <oakad@yahoo.com>
 ixdpg425         arm         ixp            0ca8eb7     2011-09-22  Stefan Roese <sr@denx.de>
 ixdp425          arm         ixp            0ca8eb7     2011-09-22  Kyle Harris <kharris@nexus-tech.net>
@@ -87,13 +102,13 @@ B2               arm         s3c44b0        5dcf536     2011-07-16  Andrea Scian
 armadillo        arm         arm720t        be28857     2011-07-16  Rowel Atienza <rowel@diwalabs.com>
 assabet          arm         sa1100         c91e90d     2011-07-16  George G. Davis <gdavis@mvista.com>
 trab             arm         S3C2400        566e5cf     2011-05-01  Gary Jennejohn <garyj@denx.de>
-xsengine         ARM         PXA2xx         4262a7c     2010-10-20
-wepep250         ARM         PXA2xx         7369478     2010-10-20  Peter Figuli <peposh@etc.sk>
-delta            ARM         PXA2xx         75e2035     2010-10-20
 mp2usb           ARM         AT91RM2900     ee986e2     2011-01-25  Eric Bénard <eric@eukrea.com>
 barco            powerpc     MPC8245        afaa27b     2010-11-23  Marc Leeman <marc.leeman@barco.com>
 ERIC             powerpc     405GP          d9ba451     2010-11-21  Swen Anderson <sand@peppercon.de>
 VoVPN-GW_100MHz  powerpc     MPC8260        26fe3d2     2010-10-24  Juergen Selent <j.selent@elmeg.de>
+xsengine         ARM         PXA2xx         4262a7c     2010-10-20
+wepep250         ARM         PXA2xx         7369478     2010-10-20  Peter Figuli <peposh@etc.sk>
+delta            ARM         PXA2xx         75e2035     2010-10-20
 NC650            powerpc     MPC852         333d86d     2010-10-19  Wolfgang Denk <wd@denx.de>
 CP850            powerpc     MPC852         333d86d     2010-10-19  Wolfgang Denk <wd@denx.de>
 logodl           ARM         PXA2xx         059e778     2010-10-18  August Hoeraendl <august.hoerandl@gmx.at>
@@ -110,7 +125,4 @@ MVS1             powerpc     MPC823         306620b     2008-08-26  Andre Schwar
 adsvix           ARM         PXA27x         7610db1     2008-07-30  Adrian Filipi <adrian.filipi@eurotech.com>
 R5200            ColdFire    -              48ead7a     2008-03-31  Zachary P. Landau <zachary.landau@labxtechnologies.com>
 CPCI440          powerpc     440GP          b568fd2     2007-12-27  Matthias Fuchs <matthias.fuchs@esd-electronics.com>
-PCIPPC2          powerpc     MPC740/MPC750  7c9e89b     2013-02-07  Wolfgang Denk <wd@denx.de>
-PCIPPC6          powerpc     MPC740/MPC750  -           -           Wolfgang Denk <wd@denx.de>
-omap2420h4       arm         omap24xx       -           2013-06-04  Richard Woodruff <r-woodruff2@ti.com>
-eNET             x86         x86            7e8c53d     2013-02-14  Graeme Russ <graeme.russ@gmail.com>
+incaip           mips        mips32         -           2014-04-17  Wolfgang Denk <wd@denx.de>
diff --git a/doc/README.t4240qds b/doc/README.t4240qds
index a9841fb5f7..ef8c75f3b2 100644
--- a/doc/README.t4240qds
+++ b/doc/README.t4240qds
@@ -120,3 +120,56 @@ The override voltage takes effect when booting.
 Note: voltage adjustment needs to be done step by step. Changing voltage too
 rapidly may cause current surge. The voltage stepping is done by software.
 Users can set the final voltage directly.
+
+2-stage NAND/SD boot loader
+-------------------------------
+PBL initializes the internal SRAM and copy SPL(160K) in SRAM.
+SPL further initialise DDR using SPD and environment variables
+and copy u-boot(768 KB) from NAND/SD device to DDR.
+Finally SPL transers control to u-boot for futher booting.
+
+SPL has following features:
+ - Executes within 256K
+ - No relocation required
+
+Run time view of SPL framework
+-------------------------------------------------
+|Area		| Address			|
+-------------------------------------------------
+|SecureBoot header | 0xFFFC0000	(32KB)		|
+-------------------------------------------------
+|GD, BD		| 0xFFFC8000	(4KB)		|
+-------------------------------------------------
+|ENV		| 0xFFFC9000	(8KB)		|
+-------------------------------------------------
+|HEAP		| 0xFFFCB000	(50KB)		|
+-------------------------------------------------
+|STACK		| 0xFFFD8000	(22KB)		|
+-------------------------------------------------
+|U-boot SPL	| 0xFFFD8000 	(160KB)		|
+-------------------------------------------------
+
+NAND Flash memory Map on T4QDS
+--------------------------------------------------------------
+Start		End		Definition	Size
+0x000000	0x0FFFFF	u-boot img	1MB
+0x140000	0x15FFFF	u-boot env      128KB
+0x160000	0x17FFFF	FMAN Ucode      128KB
+
+Micro SD Card memory Map on T4QDS
+----------------------------------------------------
+Block		#blocks		Definition	Size
+0x008		2048		u-boot img	1MB
+0x800		0016		u-boot env	8KB
+0x820		0128		FMAN ucode	64KB
+
+Switch Settings: (ON is 1, OFF is 0)
+===============
+NAND boot SW setting:
+SW1[1:8] = 10000010
+SW2[1.1] = 0
+SW6[1:4] = 1001
+
+SD boot SW setting:
+SW1[1:8] = 00100000
+SW2[1.1] = 0
diff --git a/doc/README.video b/doc/README.video
index f09d5f9f6b..dadbfcd2fd 100644
--- a/doc/README.video
+++ b/doc/README.video
@@ -11,8 +11,6 @@ U-Boot MPC8xx video controller driver
 The driver has been tested with the following configurations:
 
 - MPC823FADS with AD7176 on a PAL TV (YCbYCr)	- arsenio@tin.it
-- GENIETV    with AD7177 on a PAL TV (YCbYCr)	- arsenio@tin.it
-
 
 "video-mode" environment variable
 ===============================
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index bc9f3fa6e1..9502037705 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -346,7 +346,9 @@ Simple Verified Boot Test
 
 Please see doc/uImage.FIT/verified-boot.txt for more information
 
+/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
 Build keys
+do sha1 test
 Build FIT with signed images
 Test Verified Boot Run: unsigned signatures:: OK
 Sign images
@@ -355,10 +357,26 @@ Build FIT with signed configuration
 Test Verified Boot Run: unsigned config: OK
 Sign images
 Test Verified Boot Run: signed config: OK
+check signed config on the host
+OK
+Test Verified Boot Run: signed config: OK
+Test Verified Boot Run: signed config with bad hash: OK
+do sha256 test
+Build FIT with signed images
+Test Verified Boot Run: unsigned signatures:: OK
+Sign images
+Test Verified Boot Run: signed images: OK
+Build FIT with signed configuration
+Test Verified Boot Run: unsigned config: OK
+Sign images
+Test Verified Boot Run: signed config: OK
+check signed config on the host
+OK
+Test Verified Boot Run: signed config: OK
+Test Verified Boot Run: signed config with bad hash: OK
 
 Test passed
 
-
 Future Work
 -----------
 - Roll-back protection using a TPM is done using the tpm command. This can