added boot script files to repository

161 files changed, 18236 insertions, 0 deletions

diff --git a/u-boot/doc/I2C_Edge_Conditions b/u-boot/doc/I2C_Edge_Conditions
new file mode 100644
index 0000000..f4a9968
--- /dev/null
+++ b/u-boot/doc/I2C_Edge_Conditions
@@ -0,0 +1,46 @@
+I2C Edge Conditions:
+====================
+
+    I2C devices may be left in a write state if a read was occuring
+    and the CPU was reset. This may result in EEPROM data corruption.
+
+    The edge condition is as follows:
+	1) A read operation begins.
+	2) I2C controller issues a start command.
+	3) The I2C writes the device address.
+	4) The CPU is reset at this point.
+
+    Once the CPU reinitializes and the read is tried again:
+	1) The I2C controller issues a start command.
+	2) The I2C controller writes the device address.
+	3) The I2C controller writes the offset.
+
+    The EEPROM sees:
+	1) START
+	2) device address
+	3) START "this start is ignored by most EEPROMs"
+	4) device address "EEPROM interprets this as offset"
+	5) Offset in device, "EEPROM interprets this as data to write"
+
+    The device will interpret this sequence as a WRITE command and
+    write rubbish into itself, i.e. the "offset" will be interpreted
+    as data to be written in location "device address".
+
+Notes
+-----
+!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A AMCC 4xx BUG!!!
+
+This reset edge condition could possibly be present in every I2C
+controller and device available. For boards where a I2C bus reset
+function can be implemented a i2c_init_board() function should be
+provided and enabled by #define'ing CONFIG_SYS_I2C_INIT_BOARD in your
+board's config file. Note that this is NOT necessary when using the
+bit-banging I2C driver (common/soft_i2c.c) as this already includes
+the I2C bus reset sequence.
+
+
+Many thanks to Bill Hunter for finding this serious BUG.
+email to: <williamhunter@attbi.com>
+
+Erik Theisen <etheisen@mindspring.com>
+Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET)
diff --git a/u-boot/doc/README-i386 b/u-boot/doc/README-i386
new file mode 100644
index 0000000..c560d22
--- /dev/null
+++ b/u-boot/doc/README-i386
@@ -0,0 +1,74 @@
+This is my attempt to port U-Boot to the i386 platform. This
+work was sponsored by my emplyer, Omicron Ceti AB. http://www.omicron.se
+
+It is currently capable of booting a linux bzImage from flash on
+the AMD SC520 CDP platform.
+
+It was originally based on PPCBoot taken from the CVS October 28 2002.
+
+To compile:
+
+1) Unpack the source tree, either from the complete tarball or
+   from the virgin snapshot + the patch
+
+2) Configure the source
+   $ make sc520_cdp_comfig
+   $ make
+
+To use this code on the CDP:
+1) Make a suitable kernel, I used 2.4.19 with the mtd-support updated
+   from the MTD CVS and a patch to allow root=/dev/mtdblock1 which I
+   included at the end of this file.
+   The following options in the MTD section might be useful:
+
+   CONFIG_MTD_PHYSMAP=y
+   CONFIG_MTD_PHYSMAP_START=38100000
+   CONFIG_MTD_PHYSMAP_LEN=7a0000
+   CONFIG_MTD_PHYSMAP_BUSWIDTH=2
+
+
+2) Program it in to the CDP flashbank with remon
+   u-boot.bin should be programmed att offset 0x7e000 and the kernel at
+   offset 0. If you want to use a jffs2 root file system (not included here),
+   it should be  programmed to offset 0x100000.
+
+   remon> z
+   remon> yi
+   remon> ns u-boot.bin 7e0000
+   remon> ns bzImage 0
+   remon> ns image.jffs2 100000
+
+3) Connect a terminal to the 25pin serial port at 9600bps, and start the CDP.
+
+   remon> z
+   remon> g
+
+4) U-Boot should output some message and a prompt on the terminal, to
+   start the kernel issue the following command:
+
+   BOOT> bootm
+
+5) The kernel should boot, and mount the root filesystem if present.
+
+We hope you find this stuff useful
+Daniel Engström, Omicron Ceti AB, daniel@omicron.se
+
+
+--- linux-2.4.19-orig/init/do_mounts.c	Sat Aug  3 02:39:46 2002
++++ linux-2.4.19/init/do_mounts.c	Mon Sep 23 16:21:33 2002
+@@ -224,6 +224,14 @@
+	{ "ftlc", 0x2c10 },
+	{ "ftld", 0x2c18 },
+	{ "mtdblock", 0x1f00 },
++	{ "mtdblock0", 0x1f00 },
++	{ "mtdblock1", 0x1f01 },
++	{ "mtdblock2", 0x1f02 },
++	{ "mtdblock3", 0x1f03 },
++	{ "mtdblock4", 0x1f04 },
++	{ "mtdblock5", 0x1f05 },
++	{ "mtdblock6", 0x1f06 },
++	{ "mtdblock7", 0x1f07 },
+	{ NULL, 0 }
+ };
+
+-------------------
diff --git a/u-boot/doc/README-integrator b/u-boot/doc/README-integrator
new file mode 100644
index 0000000..5a0e934
--- /dev/null
+++ b/u-boot/doc/README-integrator
@@ -0,0 +1,110 @@
+
+		U-Boot for ARM Integrator Development Platforms
+
+			Peter Pearse, ARM Ltd.
+			peter.pearse@arm.com
+			     www.arm.com
+
+Manuals available from :-
+http://www.arm.com/products/DevTools/Hardware_Platforms.html
+
+Overview :
+--------
+There are two Integrator variants - Integrator/AP and Integrator/CP.
+Each may be fitted with a variety of core modules (CMs).
+Each CM consists of a ARM processor core and associated hardware e.g
+	FPGA implementing various controllers and/or register
+	SSRAM
+	SDRAM
+	RAM controllers
+	clock generators etc.
+CMs may be fitted with varying amounts of SDRAM using a DIMM socket.
+
+Boot Methods :
+------------
+Integrator platforms can be configured to use U-Boot in at least three ways :-
+a) Run ARM boot monitor, manually run U-Boot image from flash
+b) Run ARM boot monitor, automatically run U-Boot image from flash
+c) Run U-Boot image direct from flash.
+
+In cases a) and b) the ARM boot monitor will have configured the CM and mapped
+writeable memory to 0x00000000 in the Integrator address space.
+U-Boot has to carry out minimal configration before standard code is run.
+
+In case c) it may be necessary for U-Boot to perform CM dependent initialization.
+
+Configuring U-Boot :
+------------------
+	The makefile contains targets for Integrator platforms of both types
+fitted with all current variants of CM. If these targets are to be used with
+boot process c) above then CONFIG_INIT_CRITICAL may need to be defined to ensure
+that the CM is correctly configured.
+
+	There are also targets independent of CM. These may not be suitable for
+boot process c) above. They have been preserved for backward compatibility with
+existing build processes.
+
+Code Hierarchy Applied :
+----------------------
+Code specific to initialization of a particular ARM processor has been placed in
+cpu/arm<>/start.S so that it may be used by other boards.
+
+However, to avoid duplicating code through all processor files, a generic core
+for ARM Integrator CMs has been added
+
+	arch/arm/cpu/arm_intcm
+
+Otherwise. for example,  the standard CM reset via the CM control register would
+need placing in each CM processor file......
+
+Code specific to the initialization of the CM, rather than the cpu, and initialization
+of the Integrator board itself, has been placed in
+
+	board/integrator<>/platform.S
+	board/integrator<>/integrator<>.c
+
+Targets
+=======
+The U-Boot make targets map to the available core modules as below.
+
+Integrator/AP is no longer available from ARM.
+Core modules marked ** are also no longer available.
+
+ap720t_config		** CM720T
+ap920t_config		** CM920T
+ap926ejs_config	Integrator Core Module for ARM926EJ-STM
+ap946es_config		Integrator Core Module for ARM946E-STM
+cp920t_config		** CM920T
+cp926ejs_config	Integrator Core Module for ARM926EJ-STM
+cp946es_config		Integrator Core Module for ARM946E-STM
+cp1136_config		Integrator Core Module ARM1136JF-S  TM
+
+The final groups of targets are for core modules where no explicit cpu
+code has yet been added to U-Boot i.e. they all use the same U-Boot binary
+using the generic "arm_intcm" core:
+
+ap966_config			Integrator Core Module for ARM966E-S TM
+ap922_config			Integrator Core Module for ARM922T TM with ETM
+ap922_XA10_config		Integrator Core Module for ARM922T using Altera Excalibur
+ap7_config			** CM7TDMI
+integratorap_config
+ap_config
+
+
+cp966_config			Integrator Core Module for ARM966E-S TM
+cp922_config			Integrator Core Module for ARM922T TM with ETM
+cp922_XA10_config		Integrator Core Module for ARM922T using Altera Excalibur
+cp1026_config			Integrator Core Module ARM1026EJ-S TM
+integratorcp_config
+cp_config
+
+The Makefile targets call board/integrator<>/split_by_variant.sh
+to configure various defines in include/configs/integrator<>.h
+to indicate the core module & core configuration and ensure that
+board/integrator<>/u-boot.lds loads the cpu object first in the U-Boot image.
+
+*********************************
+Because of this mechanism
+> make clean
+must be run before each change in configuration
+*********************************
diff --git a/u-boot/doc/README.440-DDR-performance b/u-boot/doc/README.440-DDR-performance
new file mode 100644
index 0000000..17bc747
--- /dev/null
+++ b/u-boot/doc/README.440-DDR-performance
@@ -0,0 +1,90 @@
+AMCC suggested to set the PMU bit to 0 for best performace on the
+PPC440 DDR controller. The 440er common DDR setup files (sdram.c &
+spd_sdram.c) are changed accordingly. So all 440er boards using
+these setup routines will automatically receive this performance
+increase.
+
+Please see below some benchmarks done by AMCC to demonstrate this
+performance changes:
+
+
+----------------------------------------
+SDRAM0_CFG0[PMU] = 1 (U-boot default for Bamboo, Yosemite and Yellowstone)
+----------------------------------------
+Stream benchmark results
+-------------------------------------------------------------
+This system uses 8 bytes per DOUBLE PRECISION word.
+-------------------------------------------------------------
+Array size = 2000000, Offset = 0
+Total memory required = 45.8 MB.
+Each test is run 10 times, but only
+the *best* time for each is used.
+-------------------------------------------------------------
+Your clock granularity/precision appears to be 1 microseconds.
+Each test below will take on the order of 112345 microseconds.
+   (= 112345 clock ticks)
+Increase the size of the arrays if this shows that you are not getting
+at least 20 clock ticks per test.
+-------------------------------------------------------------
+WARNING -- The above is only a rough guideline.
+For best results, please be sure you know the precision of your system
+timer.
+-------------------------------------------------------------
+Function      Rate (MB/s)   RMS time     Min time     Max time
+Copy:         256.7683       0.1248       0.1246       0.1250
+Scale:        246.0157       0.1302       0.1301       0.1302
+Add:          255.0316       0.1883       0.1882       0.1885
+Triad:        253.1245       0.1897       0.1896       0.1899
+
+
+TTCP Benchmark Results
+ttcp-t: socket
+ttcp-t: connect
+ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
+localhost
+ttcp-t: 16777216 bytes in 0.28 real seconds = 454.29 Mbit/sec +++
+ttcp-t: 2048 I/O calls, msec/call = 0.14, calls/sec = 7268.57
+ttcp-t: 0.0user 0.1sys 0:00real 60% 0i+0d 0maxrss 0+2pf 3+1506csw
+
+----------------------------------------
+SDRAM0_CFG0[PMU] = 0 (Suggested modification)
+Setting PMU = 0 provides a noticeable performance improvement *2% to
+5% improvement in memory performance.
+*Improves the Mbit/sec for TTCP benchmark by almost 76%.
+----------------------------------------
+Stream benchmark results
+-------------------------------------------------------------
+This system uses 8 bytes per DOUBLE PRECISION word.
+-------------------------------------------------------------
+Array size = 2000000, Offset = 0
+Total memory required = 45.8 MB.
+Each test is run 10 times, but only
+the *best* time for each is used.
+-------------------------------------------------------------
+Your clock granularity/precision appears to be 1 microseconds.
+Each test below will take on the order of 120066 microseconds.
+   (= 120066 clock ticks)
+Increase the size of the arrays if this shows that you are not getting
+at least 20 clock ticks per test.
+-------------------------------------------------------------
+WARNING -- The above is only a rough guideline.
+For best results, please be sure you know the precision of your system
+timer.
+-------------------------------------------------------------
+Function      Rate (MB/s)   RMS time     Min time     Max time
+Copy:         262.5167       0.1221       0.1219       0.1223
+Scale:        258.4856       0.1238       0.1238       0.1240
+Add:          262.5404       0.1829       0.1828       0.1831
+Triad:        266.8594       0.1800       0.1799       0.1802
+
+TTCP Benchmark Results
+ttcp-t: socket
+ttcp-t: connect
+ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5000  tcp  ->
+localhost
+ttcp-t: 16777216 bytes in 0.16 real seconds = 804.06 Mbit/sec +++
+ttcp-t: 2048 I/O calls, msec/call = 0.08, calls/sec = 12864.89
+ttcp-t: 0.0user 0.0sys 0:00real 46% 0i+0d 0maxrss 0+2pf 120+1csw
+
+
+2006-07-28, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/README.AMCC-eval-boards-cleanup b/u-boot/doc/README.AMCC-eval-boards-cleanup
new file mode 100644
index 0000000..901bd87
--- /dev/null
+++ b/u-boot/doc/README.AMCC-eval-boards-cleanup
@@ -0,0 +1,31 @@
+---------------------------------------------------------------------
+Cleanup of AMCC eval boards (Walnut/Sycamore, Bubinga, Ebony, Ocotea)
+---------------------------------------------------------------------
+
+Changes to all AMCC eval boards:
+--------------------------------
+
+o Changed u-boot image size to 256 kBytes instead of 512 kBytes on most
+  boards.
+
+o Use 115200 baud as default console baudrate.
+
+o Added config option to use redundant environment in flash. This is also
+  the default setting. Option for environment in nvram is still available
+  for backward compatibility.
+
+o Merged board specific flash drivers to common flash driver:
+  board/amcc/common/flash.c
+
+
+Sycamore/Walnut (one port supporting both eval boards):
+-------------------------------------------------------
+
+o Cleanup to allow easier "cloning" for different (custom) boards:
+
+  o Moved EBC configuration from board specific asm-file "init.S"
+    using defines in board configuration file. No board specific
+    asm file needed anymore.
+
+
+August 01 2005, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/README.ARM-SoC b/u-boot/doc/README.ARM-SoC
new file mode 100644
index 0000000..d6bd624
--- /dev/null
+++ b/u-boot/doc/README.ARM-SoC
@@ -0,0 +1,31 @@
+[By Steven Scholz <steven.scholz@imc-berlin.de>, 16 Aug 2004]
+
+Since the cpu/ directory gets clobbered with peripheral driver code I
+started cleaning up arch/arm/cpu/arm920t.
+
+I introduced the concept of Soc (system on a chip) into the ./cpu
+directory. That means that code that is cpu (i.e. core) specific
+resides in
+
+	$(CPUDIR)/
+
+and code that is specific to some SoC (i.e. vendor specific
+peripherals around the core) is moved into
+
+	$(CPUDIR)/$(SOC)/
+
+Thus a library/archive "$(CPUDIR)/$(SOC)/lib$(SOC).a" will be build
+and linked. Examples will be
+
+	arch/arm/cpu/arm920t/imx/
+	arch/arm/cpu/arm920t/s3c24x0
+
+One can select an SoC by passing the name of it to ./mkconfig just
+like
+
+	@./mkconfig $(@:_config=) arm arm920t vcma9 mpl s3c24x0
+
+If there's no VENDOR field (like "mpl" in the above line) one has to
+pass NULL instead:
+
+	@./mkconfig $(@:_config=) arm arm920t mx1ads NULL imx
diff --git a/u-boot/doc/README.ARM-memory-map b/u-boot/doc/README.ARM-memory-map
new file mode 100644
index 0000000..1b120ac
--- /dev/null
+++ b/u-boot/doc/README.ARM-memory-map
@@ -0,0 +1,17 @@
+Subject: Re: [PATCH][CFT] bring ARM memory layout in line with the documented behaviour
+From: "Anders Larsen" <alarsen@rea.de>
+Date: Thu, 18 Sep 2003 14:15:21 +0200
+To: Wolfgang Denk <wd@denx.de>
+
+...
+>I still see  references  to  _armboot_start,  _armboot_end_data,  and
+>_armboot_end - which role do these play now? Can we get rid of them?
+>
+>How are they (should they be) set in your memory map above?
+
+_armboot_start contains the value of CONFIG_SYS_TEXT_BASE (0xA07E0000); it seems
+CONFIG_SYS_TEXT_BASE and _armboot_start are both used for the same purpose in
+different parts of the (ARM) code.
+Furthermore, the startup code (cpu/<arm>/start.S) internally uses
+another variable (_TEXT_BASE) with the same content as _armboot_start.
+I agree that this mess should be cleaned up.
diff --git a/u-boot/doc/README.AVR32 b/u-boot/doc/README.AVR32
new file mode 100644
index 0000000..632cc05
--- /dev/null
+++ b/u-boot/doc/README.AVR32
@@ -0,0 +1,25 @@
+AVR32 is a new high-performance 32-bit RISC microprocessor core,
+designed for cost-sensitive embedded applications, with particular
+emphasis on low power consumption and high code density. The AVR32
+architecture is not binary compatible with earlier 8-bit AVR
+architectures.
+
+The AVR32 architecture, including the instruction set, is described
+by the AVR32 Architecture Manual, available from
+
+http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf
+
+A GNU toolchain with support for AVR32, along with non-GNU programming
+and debugging support, can be downloaded from
+
+http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
+
+A full set of u-boot, kernel and filesystem images can be built using
+buildroot. This will also produce a working toolchain which can be
+used instead of the official GNU toolchain above. A customized version
+of buildroot for AVR32 can be downloaded here:
+
+http://www.atmel.no/buildroot/
+
+The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and
+other associated software are actively supported by Atmel Corporation.
diff --git a/u-boot/doc/README.AVR32-port-muxing b/u-boot/doc/README.AVR32-port-muxing
new file mode 100644
index 0000000..b53799d
--- /dev/null
+++ b/u-boot/doc/README.AVR32-port-muxing
@@ -0,0 +1,208 @@
+AVR32 Port multiplexer configuration
+====================================
+
+On AVR32 chips, most external I/O pins are routed through a port
+multiplexer. There are currently two kinds of port multiplexer
+hardware around with different register interfaces:
+
+  * PIO (AT32AP700x; this is also used on ARM AT91 chips)
+  * GPIO (all other AVR32 chips)
+
+The "PIO" variant supports multiplexing up to two peripherals per pin
+in addition to GPIO (software control). Each pin has configurable
+pull-up, glitch filter, interrupt and multi-drive capabilities.
+
+The "GPIO" variant supports multiplexing up to four peripherals per
+pin in addition to GPIO. Each pin has configurable
+pull-up/pull-down/buskeeper, glitch filter, interrupt, open-drain and
+schmitt-trigger capabilities, as well as configurable drive strength
+and slew rate control.
+
+Both controllers are configured using the same API, but the functions
+may accept different values for some parameters depending on the
+actual portmux implementation, and some parameters may be ignored by
+one of the implementation (e.g. the "PIO" implementation will ignore
+the drive strength flags since the hardware doesn't support
+configurable drive strength.)
+
+Selecting the portmux implementation
+------------------------------------
+Since u-boot is lacking a Kconfig-style configuration engine, the
+portmux implementation must be selected manually by defining one of
+the following symbols:
+
+	CONFIG_PORTMUX_PIO
+	CONFIG_PORTMUX_GPIO
+
+depending on which implementation the chip in question uses.
+
+Identifying pins
+----------------
+The portmux configuration functions described below identify the pins
+to act on based on two parameters: A "port" (i.e. a block of pins
+that somehow belong together) and a pin mask. Both are defined in an
+implementation-specific manner.
+
+The available ports are defined on the form
+
+  #define PORTMUX_PORT_A	(something)
+
+where "A" matches the identifier given in the chip's data sheet, and
+"something" is whatever the portmux implementation needs to identify
+the port (usually a memory address).
+
+The pin mask is a bitmask where each '1' bit indicates a pin to apply
+the current operation to. The width of the bitmask may vary from port
+to port, but it is never wider than 32 bits (which is the width of
+'unsigned long' on avr32).
+
+Selecting functions
+-------------------
+Each pin can either be assigned to one of a predefined set of on-chip
+peripherals, or it can be set up to be controlled by software. For the
+former case, the portmux implementation defines an enum containing all
+the possible peripheral functions that can be selected. For example,
+the PIO implementation, which allows multiplexing two peripherals per
+pin, defines it like this:
+
+	enum portmux_function {
+		PORTMUX_FUNC_A,
+		PORTMUX_FUNC_B,
+	};
+
+To configure a set of pins to be connected to a given peripheral
+function, the following function is used.
+
+	void portmux_select_peripheral(void *port, unsigned long pin_mask,
+			enum portmux_function func, unsigned long flags);
+
+To configure a set of pins to be controlled by software (GPIO), the
+following function is used. In this case, no "function" argument is
+required since "GPIO" is a function in its own right.
+
+	void portmux_select_gpio(void *port, unsigned int pin_mask,
+			unsigned long flags);
+
+Both of these functions take a "flags" parameter which may be used to
+alter the default configuration of the pin. This is a bitmask of
+various flags defined in an implementation-specific way, but the names
+of the flags are the same on all implementations.
+
+	PORTMUX_DIR_OUTPUT
+	PORTMUX_DIR_INPUT
+
+These mutually-exlusive flags configure the initial direction of the
+pins. PORTMUX_DIR_OUTPUT means that the pins are driven by the CPU,
+while PORTMUX_DIR_INPUT means that the pins are tristated by the CPU.
+These flags are ignored by portmux_select_peripheral().
+
+	PORTMUX_INIT_HIGH
+	PORTMUX_INIT_LOW
+
+These mutually-exclusive flags configure the initial state of the
+pins: High (Vdd) or low (Vss). They are only effective when
+portmux_select_gpio() is called with the PORTMUX_DIR_OUTPUT flag set.
+
+	PORTMUX_PULL_UP
+	PORTMUX_PULL_DOWN
+	PORTMUX_BUSKEEPER
+
+These mutually-exclusive flags are used to enable any on-chip CMOS
+resistors connected to the pins. PORTMUX_PULL_UP causes the pins to be
+pulled up to Vdd, PORTMUX_PULL_DOWN causes the pins to be pulled down
+to Vss, and PORTMUX_BUSKEEPER will keep the pins in whatever state
+they were left in by whatever was driving them last. If none of the
+flags are specified, the pins are left floating if no one are driving
+them; this is only recommended for always-output pins (e.g. extern
+address and control lines driven by the CPU.)
+
+Note that the "PIO" implementation will silently ignore the
+PORTMUX_PULL_DOWN flag and interpret PORTMUX_BUSKEEPER as
+PORTMUX_PULL_UP.
+
+	PORTMUX_DRIVE_MIN
+	PORTMUX_DRIVE_LOW
+	PORTMUX_DRIVE_HIGH
+	PORTMUX_DRIVE_MAX
+
+These mutually-exlusive flags determine the drive strength of the
+pins. PORTMUX_DRIVE_MIN will give low power-consumption, but may cause
+corruption of high-speed signals. PORTMUX_DRIVE_MAX will give high
+power-consumption, but may be necessary on pins toggling at very high
+speeds. PORTMUX_DRIVE_LOW and PORTMUX_DRIVE_HIGH specify something in
+between the other two.
+
+Note that setting the drive strength too high may cause excessive
+overshoot and EMI problems, which may in turn cause signal corruption.
+Also note that the "PIO" implementation will silently ignore these
+flags.
+
+	PORTMUX_OPEN_DRAIN
+
+This flag will configure the pins as "open drain", i.e. setting the
+pin state to 0 will drive it low, while setting it to 1 will leave it
+floating (or, in most cases, let it be pulled high by an internal or
+external pull-up resistor.) In the data sheet for chips using the
+"PIO" variant, this mode is called "multi-driver".
+
+Enabling specific peripherals
+-----------------------------
+In addition to the above functions, each chip provides a set of
+functions for setting up the port multiplexer to use a given
+peripheral. The following are some of the functions available.
+
+All the functions below take a "drive_strength" parameter, which must
+be one of the PORTMUX_DRIVE_x flags specified above.  Any other
+portmux flags will be silently filtered out.
+
+To set up the External Bus Interface (EBI), call
+
+	void portmux_enable_ebi(unsigned int bus_width,
+			unsigned long flags, unsigned long drive_strength)
+
+where "bus_width" must be either 16 or 32. "flags" can be any
+combination of the following flags.
+
+	PORTMUX_EBI_CS(x)	/* Enable chip select x */
+	PORTMUX_EBI_NAND	/* Enable NAND flash interface */
+	PORTMUX_EBI_CF(x)	/* Enable CompactFlash interface x */
+	PORTMUX_EBI_NWAIT	/* Enable NWAIT signal */
+
+To set up a USART, call
+
+	void portmux_enable_usartX(unsigned long drive_strength);
+
+where X is replaced by the USART instance to be configured.
+
+To set up an ethernet MAC:
+
+	void portmux_enable_macbX(unsigned long flags,
+			unsigned long drive_strength);
+
+where X is replaced by the MACB instance to be configured. "flags" can
+be any combination of the following flags.
+
+	PORTMUX_MACB_RMII	/* Just set up the RMII interface */
+	PORTMUX_MACB_MII	/* Set up full MII interface */
+	PORTMUX_MACB_SPEED	/* Enable the SPEED pin */
+
+To set up the MMC controller:
+
+	void portmux_enable_mmci(unsigned long slot, unsigned long flags
+			unsigned long drive_strength);
+
+where "slot" identifies which of the alternative SD card slots to
+enable. "flags" can be any combination of the following flags:
+
+	PORTMUX_MMCI_4BIT	/* Enable 4-bit SD card interface */
+	PORTMUX_MMCI_8BIT	/* Enable 8-bit MMC+ interface */
+	PORTMUX_MMCI_EXT_PULLUP	/* Board has external pull-ups */
+
+To set up a SPI controller:
+
+	void portmux_enable_spiX(unsigned long cs_mask,
+			unsigned long drive_strength);
+
+where X is replaced by the SPI instance to be configured. "cs_mask" is
+a 4-bit bitmask specifying which of the four standard chip select
+lines to set up as GPIOs.
diff --git a/u-boot/doc/README.COBRA5272 b/u-boot/doc/README.COBRA5272
new file mode 100644
index 0000000..ae0f148
--- /dev/null
+++ b/u-boot/doc/README.COBRA5272
@@ -0,0 +1,156 @@
+File:		README.COBRA5272
+Author:		Florian Schlote for Sentec elektronik (linux@sentec-elektronik.de)
+Contents:	This is the README of u-boot (Universal bootloader) for our
+		COBRA5272 board.
+Version:	v01.00
+Date:		Tue Mar 30 00:28:33 CEST 2004
+License:	This document is published under the GNU GPL
+______________________________________________________________________
+
+CHANGES
+040330   v01.00 Creation
+
+______________________________________________________________________
+
+
+CONFIGURING
+-----------
+
+1. Modify include/configs/cobra5272.h acc. to your prefs
+
+2. If necessary, modify board/cobra5272/config.mk (see below)
+
+3.
+
+> make cobra5272_config
+
+> make
+
+
+Please refer to u-boot README (general info, u-boot-x-x-x/README),
+to u-boot-x-x-x/doc/README.COBRA5272 and
+to the comments in u-boot-x-x-x/include/configs/cobra5272.h
+
+Configuring u-boot is done by commenting/uncommenting preprocessor defines.
+
+Default configuration is
+
+	FLASH version (for further info see subsection below)
+	link address 0xffe00000
+
+	16 MB RAM
+
+	network enabled
+	no default IP address for target, host set, no MACaddress set
+
+	bootdelay for autoboot 5 sec.
+	autoboot disabled
+
+
+#-----------------------------------
+# u-boot FLASH version & RAM version
+#-----------------------------------
+
+The u-boot bootloader for Coldfire processors can be configured
+
+	1. as a standalone bootloader residing in flash & relocating itself to RAM on
+	startup automatically => "FLASH version"
+
+	2. as a RAM version which will not load from flash automatically as it needs a
+	prestage bootloader ("chainloading") & is running only from the RAM address it
+	is linked to => "RAM version"
+
+	This version may be very helpful when installing u-boot for the first time
+	since it can be used to make available s. th. like a "bootstrap
+	mechanism".
+
+
+How to build the different images:
+
+------------------------------
+Flash version
+------------------------------
+
+Compile u-boot
+
+in dir ./u-boot-x-x-x/
+
+please first check:
+
+	in ./include/configs/cobra5272.h
+
+		CONFIG_MONITOR_IS_IN_RAM has to be undefined, e. g. as follows:
+
+		#if 0
+			#define CONFIG_MONITOR_IS_IN_RAM
+			/* define if monitor is started from a pre-loader */
+		#endif
+
+	=> u-boot as single bootloader starting from flash
+
+
+	in board/cobra5272/config.mk CONFIG_SYS_TEXT_BASE should be
+
+		CONFIG_SYS_TEXT_BASE = 0xffe00000
+
+	=> linking address for u-boot as single bootloader stored in flash
+
+then:
+
+	host> make cobra5272_config
+		rm -f include/config.h include/config.mk
+		Configuring for cobra5272 board...
+	host> make
+		[...]
+
+	host> cp u-boot.bin /tftpboot/u-boot_flash.bin
+
+
+------------------------------
+RAM version
+------------------------------
+
+in dir ./u-boot-x-x-x/
+
+	host> make distclean
+
+please modify the settings:
+
+	in ./include/configs/cobra5272.h
+
+		CONFIG_MONITOR_IS_IN_RAM now has to be defined, e. g. as follows:
+
+		#if 1
+			#define CONFIG_MONITOR_IS_IN_RAM
+			/*define if monitor is started from a pre-loader */
+		#endif
+
+	=> u-boot as RAM version, chainloaded by another bootloader or using bdm cable
+
+
+	in board/cobra5272/config.mk CONFIG_SYS_TEXT_BASE should be
+
+		CONFIG_SYS_TEXT_BASE = 0x00020000
+
+	=> target linking address for RAM
+
+
+then:
+
+	host> make cobra5272_config
+		rm -f include/config.h include/config.mk
+		Configuring for cobra5272 board...
+	host> make
+		[...]
+
+	host> cp u-boot.bin /tftpboot/u-boot_ram.bin
+
+
+----
+HINT
+----
+
+If the m68k-elf-toolchain & the m68k-bdm-gdb is installed you can run the RAM
+version by typing (in dir ./u-boot-x-x-x/)
+"board/cobra5272/bdm/load-cobra_uboot" ,
+in ./u-boot-x-x-x/ the RAM version u-boot (elf format) has to be available.
diff --git a/u-boot/doc/README.EVB-64260-750CX b/u-boot/doc/README.EVB-64260-750CX
new file mode 100644
index 0000000..5ea38ea
--- /dev/null
+++ b/u-boot/doc/README.EVB-64260-750CX
@@ -0,0 +1,7 @@
+The EVB-64260-750CX is quite similar to the EVB-64260-BP already
+supported except the following differences:
+* It has an IBM-750CXe soldiered on board instead of the slot-1 in the
+   BP.
+* It has a single PCI male connector instead of the 4 PCI female
+   connectors on the BP. It also gets power trough the PCI connector.
+* It has only a single DIMM slot instead of the 2 slots in the BP.
diff --git a/u-boot/doc/README.INCA-IP b/u-boot/doc/README.INCA-IP
new file mode 100644
index 0000000..1329152
--- /dev/null
+++ b/u-boot/doc/README.INCA-IP
@@ -0,0 +1,57 @@
+
+Flash programming on the INCA-IP board is complicated because of the
+EBU swapping unit. A BDI2000 can be used for flash programming only
+if the EBU swapping unit is enabled; otherwise it will not detect the
+flash memory. But the EBU swapping unit is disadbled after reset, so
+if you program some code to flash with the swapping unit on, it will
+not be runnable with the swapping unit off.
+
+The consequence is that you have to write a pre-swapped image to
+flash using the BDI2000. A simple host-side tool "inca-swap-bytes" is
+provided in the "tools/" directory. Use it as follows:
+
+	bash$ ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+Note that the current BDI config file _disables_ the EBU swapping
+unit for the flash bank 0. To enable it, (this is required for the
+BDI flash commands to work) uncomment the following line in the
+config file:
+
+	;WM32   0xb8000260      0x404161ff ; Swapping unit enabled
+
+and comment out
+
+	WM32    0xb8000260      0x004161ff ; Swapping unit disabled
+
+Alternatively, you can use "mm 0xb8000260 <value>" commands to
+enable/disable the swapping unit manually.
+
+Just for reference, here is the complete sequence of actions we took
+to install a U-Boot image into flash.
+
+    1. ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+    2. From BDI:
+
+	mm 0xb8000260  0x404161ff
+	erase 0xb0000000
+	erase 0xb0010000
+	prog 0xb0000000 /tftpboot/INCA/u-boot.bin.swp bin
+	mm 0xb8000260 0x004161ff
+	go 0xb0000000
+
+
+Ethernet autonegotiation needs some time to complete. Instead of
+delaying the boot process in all cases, we just start the
+autonegotiation process when U-Boot comes up and that is all. Most
+likely, it will complete by the time the network transfer is
+attempted for the first time. In the worst case, if a transfer is
+attempted before the autonegotiation is complete, just a single
+packet would be lost resulting in a single timeout error, and then
+the transfer would proceed normally. So the time that we would have
+lost unconditionally waiting for the autonegotiation to complete, we
+have to wait only if the file transfer is started immediately after
+reset. We've verified that this works for all the clock
+configurations.
+
+(C) 2003 Wolfgang Denk
diff --git a/u-boot/doc/README.IPHASE4539 b/u-boot/doc/README.IPHASE4539
new file mode 100644
index 0000000..c5146d9
--- /dev/null
+++ b/u-boot/doc/README.IPHASE4539
@@ -0,0 +1,358 @@
+
+This file contains basic information on the port of U-Boot to IPHASE4539
+(Interphase 4539 T1/E1/J1 PMC Communications Controller).
+All the changes fit in the common U-Boot infrastructure, providing a new
+IPHASE4539-specific entry in makefiles. To build U-Boot for IPHASE4539,
+type "make IPHASE4539_config", edit the "include/config_IPHASE4539.h"
+file if necessary, then type "make".
+
+
+Common file modifications:
+--------------------------
+
+The following common files have been modified by this project:
+(starting from the ppcboot-1.1.5/ directory)
+
+MAKEALL				- IPHASE4539 entry added
+Makefile			- IPHASE4539_config entry added
+
+
+New files:
+----------
+
+The following new files have been added by this project:
+(starting from the ppcboot-1.1.5/ directory)
+
+board/iphase4539/		- board-specific directory
+board/iphase4539/Makefile	- board-specific makefile
+board/iphase4539/config.mk	- config file
+board/iphase4539/flash.c	- flash driver (for AM29LV033C)
+board/iphase4539/ppcboot.lds	- linker script
+board/iphase4539/iphase4539.c	- ioport and memory initialization
+include/config_IPHASE4539.h	- main configuration file
+
+
+New configuration options:
+--------------------------
+
+CONFIG_IPHASE4539
+
+	Main board-specific option (should be defined for IPHASE4539).
+
+
+Acceptance criteria tests:
+--------------------------
+
+The following tests have been conducted to validate the port of U-Boot
+to IPHASE4539:
+
+1. Operation on serial console:
+
+With SMC1 defined as console in the main configuration file, the U-Boot
+output appeared on the serial terminal connected to the 2.5mm stereo jack
+connector as follows:
+
+------------------------------------------------------------------------------
+=> help
+base    - print or set address offset
+bdinfo  - print Board Info structure
+bootm   - boot application image from memory
+bootp   - boot image via network using BootP/TFTP protocol
+bootd   - boot default, i.e., run 'bootcmd'
+cmp     - memory compare
+coninfo - print console devices and informations
+cp      - memory copy
+crc32   - checksum calculation
+dcache  - enable or disable data cache
+echo    - echo args to console
+erase   - erase FLASH memory
+flinfo  - print FLASH memory information
+go      - start application at address 'addr'
+help    - print online help
+icache  - enable or disable instruction cache
+iminfo  - print header information for application image
+loadb   - load binary file over serial line (kermit mode)
+loads   - load S-Record file over serial line
+loop    - infinite loop on address range
+md      - memory display
+mm      - memory modify (auto-incrementing)
+mtest   - simple RAM test
+mw      - memory write (fill)
+nm      - memory modify (constant address)
+printenv- print environment variables
+protect - enable or disable FLASH write protection
+rarpboot- boot image via network using RARP/TFTP protocol
+reset   - Perform RESET of the CPU
+run     - run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv  - set environment variables
+sleep   - delay execution for some time
+source  - run script from memory
+tftpboot- boot image via network using TFTP protocol
+	       and env variables ipaddr and serverip
+version - print monitor version
+?       - alias for 'help'
+=>
+------------------------------------------------------------------------------
+
+
+2. Flash driver operation
+
+The following sequence was performed to test the "flinfo" command:
+
+------------------------------------------------------------------------------
+=> flinfo
+
+Bank # 1: AMD AM29LV033C (32 Mbit, uniform sectors)
+  Size: 4 MB in 64 Sectors
+  Sector Start Addresses:
+    FF800000 (RO) FF810000 (RO) FF820000      FF830000      FF840000
+    FF850000      FF860000      FF870000      FF880000      FF890000
+    FF8A0000      FF8B0000      FF8C0000      FF8D0000      FF8E0000
+    FF8F0000      FF900000      FF910000      FF920000      FF930000
+    FF940000      FF950000      FF960000      FF970000      FF980000
+    FF990000      FF9A0000      FF9B0000      FF9C0000      FF9D0000
+    FF9E0000      FF9F0000      FFA00000      FFA10000      FFA20000
+    FFA30000      FFA40000      FFA50000      FFA60000      FFA70000
+    FFA80000      FFA90000      FFAA0000      FFAB0000      FFAC0000
+    FFAD0000      FFAE0000      FFAF0000      FFB00000 (RO) FFB10000 (RO)
+    FFB20000 (RO) FFB30000 (RO) FFB40000      FFB50000      FFB60000
+    FFB70000      FFB80000      FFB90000      FFBA0000      FFBB0000
+    FFBC0000      FFBD0000      FFBE0000      FFBF0000
+------------------------------------------------------------------------------
+
+Note: the Hardware Configuration Word (HWC) of the 8260 is on the
+first sector of the flash and should not be touched. The U-Boot
+environment variables are stored on second sector and U-Boot
+starts at the address 0xFFB00000.
+
+
+The following sequence was performed to test the erase command:
+
+------------------------------------------------------------------------------
+=> cp 0 ff880000 10
+Copy to Flash... done
+=> md ff880000 20
+ff880000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+ff880020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+ff880030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> erase ff880000 ff88ffff
+Erase Flash from 0xff880000 to 0xff88ffff
+.. done
+Erased 1 sectors
+=> md ff880000
+ff880000: ffffffff ffffffff ffffffff ffffffff    ................
+ff880010: ffffffff ffffffff ffffffff ffffffff    ................
+ff880020: ffffffff ffffffff ffffffff ffffffff    ................
+ff880030: ffffffff ffffffff ffffffff ffffffff    ................
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> cp 0 ff880000 10
+Copy to Flash... done
+=> md ff880000 20
+ff880000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+ff880020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+ff880030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> erase 1:8
+Erase Flash Sectors 8-8 in Bank # 1
+.. done
+=> md ff880000 20
+ff880000: ffffffff ffffffff ffffffff ffffffff    ................
+ff880010: ffffffff ffffffff ffffffff ffffffff    ................
+ff880020: ffffffff ffffffff ffffffff ffffffff    ................
+ff880030: ffffffff ffffffff ffffffff ffffffff    ................
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> cp 0 ff880000 10
+Copy to Flash... done
+=> cp 0 ff890000 10
+=> md ff880000 20
+ff880000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+ff880020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+ff880030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> md ff890000
+ff890000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+ff890010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+ff890020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+ff890030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+ff890040: ffffffff ffffffff ffffffff ffffffff    ................
+ff890050: ffffffff ffffffff ffffffff ffffffff    ................
+ff890060: ffffffff ffffffff ffffffff ffffffff    ................
+ff890070: ffffffff ffffffff ffffffff ffffffff    ................
+=> erase 1:8-9
+Erase Flash Sectors 8-9 in Bank # 1
+.... done
+=> md ff880000 20
+ff880000: ffffffff ffffffff ffffffff ffffffff    ................
+ff880010: ffffffff ffffffff ffffffff ffffffff    ................
+ff880020: ffffffff ffffffff ffffffff ffffffff    ................
+ff880030: ffffffff ffffffff ffffffff ffffffff    ................
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=> md ff890000
+ff890000: ffffffff ffffffff ffffffff ffffffff    ................
+ff890010: ffffffff ffffffff ffffffff ffffffff    ................
+ff890020: ffffffff ffffffff ffffffff ffffffff    ................
+ff890030: ffffffff ffffffff ffffffff ffffffff    ................
+ff890040: ffffffff ffffffff ffffffff ffffffff    ................
+ff890050: ffffffff ffffffff ffffffff ffffffff    ................
+ff890060: ffffffff ffffffff ffffffff ffffffff    ................
+ff890070: ffffffff ffffffff ffffffff ffffffff    ................
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test the Flash programming commands:
+
+------------------------------------------------------------------------------
+=> erase ff880000 ff88ffff
+Erase Flash from 0xff880000 to 0xff88ffff
+.. done
+Erased 1 sectors
+=> cp 0 ff880000 10
+Copy to Flash... done
+=> md 0 20
+00000000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+00000010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+00000020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+00000030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+00000040: 3c83c000 2c040000 40823378 7c0000a6    <...,...@.3x|...
+00000050: 60000030 7c1b03a6 3c00c000 600035ec    `..0|...<...`.5.
+00000060: 7c1a03a6 4c000064 00000000 00000000    |...L..d........
+00000070: 00000000 00000000 00000000 00000000    ................
+=> md ff880000 20
+ff880000: ff000000 60000000 60000000 7c7f1b78    ....`...`...|..x
+ff880010: 7c9e2378 7cbd2b78 7cdc3378 7cfb3b78    |.#x|.+x|.3x|.;x
+ff880020: 3b000000 4811e0f5 48003719 480036a5    ;...H...H.7.H.6.
+ff880030: 480036f9 48003731 48005c5d 7c7a1b78    H.6.H.71H.\]|z.x
+ff880040: ffffffff ffffffff ffffffff ffffffff    ................
+ff880050: ffffffff ffffffff ffffffff ffffffff    ................
+ff880060: ffffffff ffffffff ffffffff ffffffff    ................
+ff880070: ffffffff ffffffff ffffffff ffffffff    ................
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test storage of the environment
+variables in Flash:
+
+------------------------------------------------------------------------------
+=> setenv foo bar
+=> saveenv
+Un-Protected 1 sectors
+Erasing Flash...
+.. done
+Erased 1 sectors
+Saving Environment to Flash...
+Protected 1 sectors
+=> reset
+...
+=> printenv
+...
+foo=bar
+...
+Environment size: 339/65532 bytes
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test image download and run over
+Ethernet interface (both interfaces were tested):
+
+------------------------------------------------------------------------------
+=> tftpboot 40000 hello_world.bin
+ARP broadcast 1
+TFTP from server 10.0.0.1; our IP address is 10.0.0.8
+Filename 'hello_world.bin'.
+Load address: 0x40000
+Loading: #############
+done
+Bytes transferred = 65932 (1018c hex)
+=> go 40004
+## Starting application at 0x00040004 ...
+Hello World
+argc = 1
+argv[0] = "40004"
+argv[1] = "<NULL>"
+Hit any key to exit ...
+
+## Application terminated, rc = 0x0
+=>
+------------------------------------------------------------------------------
+
+
+3. Known Problems
+
+None for the moment.
+
+
+----------------------------------------------------------------------------
+U-Boot and Linux for Interphase 4539 T1/E1/J1 PMC Communications Controller
+----------------------------------------------------------------------------
+
+U-Boot:
+
+	Configure and make U-Boot:
+
+	$ cd <path>/u-boot
+	$ make IPHASE4539_config
+	$ make dep
+	$ make
+	$ cp -p u-boot.bin /tftpboot
+
+	Load u-boot.bin into the Flash memory at 0xffb00000.
+
+
+Linux:
+
+	Configure and make Linux:
+
+	$ cd <patch>/linux-2.4
+	$ make IPHASE4539_config
+	$ make oldconfig
+	$ make dep
+	$ make uImage
+	$ cp -p arch/powerpc/mbxboot/uImage /tftpboot
+
+	Load uImage via tftp and boot it.
+
+
+Flash organisation:
+
+	The following preliminary layout of the Flash memory
+	is defined:
+
+	0xff800000 (   0    -   64 kB): Hardware Configuration Word.
+	0xff810000 (  64 kB -  128 kB): U-Boot Environment.
+	0xff820000 ( 128 kB -    3 MB): RAMdisk.
+	0xffb00000 (   3 MB - 3328 kB): U-Boot.
+	0xffb40000 (3328 KB -    4 MB): Linux Kernel.
+
+
+For further information concerning U-Boot and Linux please consult
+the "DENX U-Boot and Linux Guide".
+
+
+(C) 2002 Wolfgang Grandegger, DENX Software Engineering, wg@denx.de
+===================================================================
diff --git a/u-boot/doc/README.IceCube b/u-boot/doc/README.IceCube
new file mode 100644
index 0000000..5252bc9
--- /dev/null
+++ b/u-boot/doc/README.IceCube
@@ -0,0 +1,13 @@
+---------------------------------------------------------------------------
+Build target                Flash address | BDI "go" command | Reset Vector
+---------------------------------------------------------------------------
+Lite5200                     0xFFF00000   |    0xFFF00100    |   0xFFF00100
+Lite5200_LOWBOOT             0xFF000000   |    0xFF000100    |   0x00000100
+Lite5200_LOWBOOT08           0xFF800000   |    0xFF800100    |   0x00000100
+icecube_5200                 0xFFF00000   |    0xFFF00100    |   0xFFF00100
+icecube_5200_LOWBOOT         0xFF000000   |    0xFF000100    |   0x00000100
+icecube_5200_LOWBOOT08       0xFF800000   |    0xFF800100    |   0x00000100
+icecube_5200_DDR             0xFFF00000   |    0xFFF00100    |   0xFFF00100
+icecube_5200_DDR_LOWBOOT     0xFF800000   |    0xFF800100    |   0x00000100
+icecube_5200_DDR_LOWBOOT08   0xFF800000   |    0xFF800100    |   0x00000100
+---------------------------------------------------------------------------
diff --git a/u-boot/doc/README.JFFS2 b/u-boot/doc/README.JFFS2
new file mode 100644
index 0000000..f0e9bc1
--- /dev/null
+++ b/u-boot/doc/README.JFFS2
@@ -0,0 +1,74 @@
+JFFS2 options and usage.
+-----------------------
+
+JFFS2 in U-Boot is a read only implementation of the file system in
+Linux with the same name. To use JFFS2 define CONFIG_CMD_JFFS2.
+
+The module adds three new commands.
+fsload  - load binary file from a file system image
+fsinfo  - print information about file systems
+ls      - list files in a directory
+chpart  - change active partition
+
+If you boot from a partition which is mounted writable, and you
+update your boot environment by replacing single files on that
+partition, you should also define CONFIG_SYS_JFFS2_SORT_FRAGMENTS. Scanning
+the JFFS2 filesystem takes *much* longer with this feature, though.
+Sorting is done while inserting into the fragment list, which is
+more or less a bubble sort. That algorithm is known to be O(n^2),
+thus you should really consider if you can avoid it!
+
+
+There is two ways for JFFS2 to find the disk. The default way uses
+the flash_info structure to find the start of a JFFS2 disk (called
+partition in the code) and you can change where the partition is with
+two defines.
+
+CONFIG_SYS_JFFS2_FIRST_BANK
+	defined the first flash bank to use
+
+CONFIG_SYS_JFFS2_FIRST_SECTOR
+	defines the first sector to use
+
+
+The second way is to define CONFIG_SYS_JFFS_CUSTOM_PART and implement the
+jffs2_part_info(int part_num) function in your board specific files.
+In this mode CONFIG_SYS_JFFS2_FIRST_BANK and CONFIG_SYS_JFFS2_FIRST_SECTOR is not
+used.
+
+The input is a partition number starting with 0.
+Return a pointer to struct part_info or NULL for error;
+
+Ex jffs2_part_info() for one partition.
+---
+#if defined CONFIG_SYS_JFFS_CUSTOM_PART
+#include <jffs2/jffs2.h>
+
+static struct part_info part;
+
+struct part_info*
+jffs2_part_info(int part_num)
+{
+	if(part_num==0){
+		if(part.usr_priv==(void*)1)
+			return &part;
+
+		memset(&part, 0, sizeof(part));
+		part.offset=(char*)0xFF800000;
+		part.size=1024*1024*8;
+
+		/* Mark the struct as ready */
+		part.usr_priv=(void*)1;
+
+		return &part;
+	}
+	return 0;
+}
+#endif
+---
+
+TODO.
+
+	Remove the assumption that JFFS can dereference a pointer
+	into the disk. The current code do not work with memory holes
+	or hardware with a sliding window (PCMCIA).
diff --git a/u-boot/doc/README.JFFS2_NAND b/u-boot/doc/README.JFFS2_NAND
new file mode 100644
index 0000000..5018ae8
--- /dev/null
+++ b/u-boot/doc/README.JFFS2_NAND
@@ -0,0 +1,24 @@
+JFFS2 NAND support:
+
+To ebable, use the following #define in the board configuration file:
+
+#define CONFIG_JFFS2_NAND 1
+
+Configuration of partitions is similar to how this is done in  U-Boot
+for  JFFS2  on top NOR flash. If a single partition is used, it can be
+configured using the following #defines in the configuration file:
+
+#define CONFIG_JFFS2_NAND_DEV 0			/* nand device jffs2 lives on */
+#define CONFIG_JFFS2_NAND_OFF 0			/* start of jffs2 partition */
+#define CONFIG_JFFS2_NAND_SIZE 2*1024*1024	/* size of jffs2 partition */
+
+If more than a single partition is desired, the user can define a
+CONFIG_SYS_JFFS_CUSTOM_PART macro and implement a
+
+	struct part_info* jffs2_part_info(int part_num)
+
+function in a board-specific module. An example of such function is
+available in common/cmd_jffs2.c
+
+The default configuration for the DAVE board has a single JFFS2
+partition of 2 MB size.
diff --git a/u-boot/doc/README.LED b/u-boot/doc/README.LED
new file mode 100644
index 0000000..c3bcb3a
--- /dev/null
+++ b/u-boot/doc/README.LED
@@ -0,0 +1,78 @@
+Status LED
+========================================
+
+This README describes the status LED API.
+
+The API is defined by the include file include/status_led.h
+
+The first step is to define CONFIG_STATUS_LED in the board config file.
+
+If the LED support is only for a single board, define CONFIG_BOARD_SPECIFIC_LED
+in the board config file.
+
+At a minimum, these macros must be defined at
+STATUS_LED_BIT
+STATUS_LED_STATE
+STATUS_LED_PERIOD
+
+If there are multiple status LED's define
+STATUS_LED_BIT<n>
+STATUS_LED_STATE<n>
+STATUS_LED_PERIOD<n>
+
+Where <n> can a integer 1 through 3.
+
+STATUS_LED_BIT is passed into the __led_* functions to identify which LED is
+being acted on.  As such, the value choose must be unique with with respect to
+the other STATUS_LED_BIT's.  Mapping the value to a physical LED is the
+reponsiblity of the __led_* function.
+
+STATUS_LED_STATE is the initial state of the LED. It should be set to one of
+these values: STATUS_LED_OFF or STATUS_LED_ON.
+
+STATUS_LED_PERIOD is how long is the LED blink period.  This usually set to
+(CONFIG_SYS_HZ / <N>) where <N> is the frequency of the blink. Typical values
+range from 2 to 10.
+
+Some other LED macros
+
+STATUS_LED_BOOT is the LED to light when the board is booting.  This must be a
+valid STATUS_LED_BIT value.
+
+STATUS_LED_RED is the red LED.  It is used signal errors. This must be a valid
+STATUS_LED_BIT value. Other similar color LED's are STATUS_LED_YELLOW and
+STATUS_LED_BLUE.
+
+These board must define these functions
+
+__led_init is called once to initialize the LED to STATUS_LED_STATE. One time
+start up code should be placed here.
+
+__led_set is called to change the state of the LED.
+
+__led_toggle is called to toggle the current state of the LED.
+
+Colour LED
+========================================
+
+Colour LED's are at present only used by ARM.
+
+The functions names explain their purpose.
+
+coloured_LED_init
+red_LED_on
+red_LED_off
+green_LED_on
+green_LED_off
+yellow_LED_on
+yellow_LED_off
+blue_LED_on
+blue_LED_off
+
+These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define
+these functions in the board specific source.
+
+TBD : Describe older board dependent macros similar to what is done for
+CONFIG_TQM8xxL.
+
+TBD : Describe general support via asm/status_led.h
diff --git a/u-boot/doc/README.LED_display b/u-boot/doc/README.LED_display
new file mode 100644
index 0000000..19977ea
--- /dev/null
+++ b/u-boot/doc/README.LED_display
@@ -0,0 +1,26 @@
+LED display internal API
+=======================================
+
+This README describes the LED display API.
+
+The API is defined by the include file include/led-display.h
+
+The first step in to define CONFIG_CMD_DISPLAY in the board config file.
+Then you need to provide the following functions to access LED display:
+
+void display_set(int cmd);
+
+This function should control the state of the LED display. Argument is
+an ORed combination of the following values:
+ DISPLAY_CLEAR	-- clear the display
+ DISPLAY_HOME	-- set the position to the beginning of display
+
+int display_putc(char c);
+
+This function should display it's parameter on the LED display in the
+current position. Returns the displayed character on success or -1 in
+case of failure.
+
+With this functions defined 'display' command will display it's
+arguments on the LED display (or clear the display if called without
+arguments).
diff --git a/u-boot/doc/README.Lite5200B_low_power b/u-boot/doc/README.Lite5200B_low_power
new file mode 100644
index 0000000..5b04fbb
--- /dev/null
+++ b/u-boot/doc/README.Lite5200B_low_power
@@ -0,0 +1,22 @@
+Lite5200B wakeup from low-power mode (CONFIG_LITE5200B_PM)
+----------------------------------------------------------
+
+Low-power mode as described in Lite5200B User's Manual, means that
+with support of MC68HLC908QT1 microcontroller (refered to as QT),
+everything but the SDRAM can be powered down. This brings
+maximum power saving, while one can still restore previous state
+quickly.
+
+Quick overview where U-Boot comes into the picture:
+- OS saves device states
+- OS saves wakeup handler address to physical 0x0, puts SDRAM into
+  self-refresh and signals to QT, it should power down the board
+- / board is sleeping here /
+- someone presses SW4 (connected to QT)
+- U-Boot checks PSC2_4 pin, if QT drives it down, then we woke up,
+  so get SDRAM out of self-refresh and transfer control to OS
+  wakeup handler
+- OS restores device states
+
+This was tested on Linux with USB and Ethernet in use. Adding
+support for other devices is an OS issue.
diff --git a/u-boot/doc/README.MBX b/u-boot/doc/README.MBX
new file mode 100644
index 0000000..c889fe9
--- /dev/null
+++ b/u-boot/doc/README.MBX
@@ -0,0 +1,68 @@
+IMPORTANT NOTE - read before defining CONFIG_SYS_USE_OSCCLK in your board
+		 config file!!!
+
+
+WARNING: Wrong settings of this parameter have the potential to
+damage hardware by running the MBX's CPU at frequencies that exceed
+it's rating and/or overdriving the it's SPLL!
+
+
+Ramblings:
+1) Motorola offered 12 different variants of the MBX, 6 823s and 6 860s.
+2) Of these 12 variants, only 2 were entry level boards.
+3) I believe that the 2 entry level boards were the only ones that
+   used OSCM clocking. I can't be completely certain of this at this
+   point.
+4) Motorola never offered an MBX that ran faster than 50Mhz.
+5) The 10, non-entry level boards, ran at 40Mhz.
+6) The EXTCLK input has a minimum clock of 15Mhz for the 823/860.
+7) Motorola no longer sells MBXs.
+
+Based on this information, I can surmise that the default power-on
+reset clocking was one of the following three options.
+
+Multiplier       SPLL Options
+------------------------------------
+513              OSCM is SPLL input
+5                OSCM is SPLL input
+1                EXTCLK is SPLL input
+
+The forth option:
+
+5                EXTCLK is SPLL input
+
+is not possible on MBXs. This is because the minimum EXTCLK input
+frequency is 15Mhz. 5 * 15Mhz = 75 Mhz. There was no variant that ran
+above 50 Mhz.
+
+The board I have borrowed definitely uses a multiplier of 1 for
+EXTCLK and runs at 40Mhz. I even went so far as to put a scope on it.
+
+One of the two default OSCM modes are most likely what was used on
+the entry level boards to cheapen them by eliminating the external
+crystal oscillator.
+
+To add insult to injury, the stupid 860 PLPRCR register retains it's
+multiplication factor through hard resets. You can't clear it out
+because it is battery backed and once it is set wrong, it stays
+wrong. The only way to reset it, so that it takes on it's default
+multiplier is to disconnect all power including external, batteries,
+as well discharging caps on the board. This precludes the fact that
+your 860 may be quite DEAD by this time!
+
+If you don't setup the multiplication factor for boards that use the
+OSCM input, they won't run correctly, but at least they won't be
+dead.
+
+Addtionally, there is no good way to determine the clock input source
+from CPU register data. The only way to deal with this is either hard
+code it, determine the correct value with some rather NASTY timing
+loops, or try to grok it from external data sources. Motorola
+firmware opts for the NASTY timing loops, but needs to configure the
+serial ports to do so.
+
+
+You may have a legitimate need to define CONFIG_SYS_USE_OSCCLK if your
+MBX8xx board is using the OSCM clocking mode.
+
+You better know what you are doing here.
diff --git a/u-boot/doc/README.MPC866 b/u-boot/doc/README.MPC866
new file mode 100644
index 0000000..4707cb7
--- /dev/null
+++ b/u-boot/doc/README.MPC866
@@ -0,0 +1,24 @@
+The current implementation allows the user to specify the desired CPU
+clock value, in MHz, via an environment variable "cpuclk".
+
+Four compile-time constants are used:
+
+	CONFIG_8xx_OSCLK          - input quartz clock
+	CONFIG_SYS_8xx_CPUCLK_MIN        - minimum allowed CPU clock
+	CONFIG_SYS_8xx_CPUCLK_MAX        - maximum allowed CPU clock
+	CONFIG_8xx_CPUCLK_DEFAULT - default CPU clock value
+
+If the "cpuclk" environment variable value is within the CPUCLK_MIN /
+CPUCLK_MAX limits, the specified value is used. Otherwise, the
+default CPU clock value is set.
+
+Please make sure you understand what you are doing, and understand
+the restrictions of your hardware (board, processor). For example,
+ethernet will stop working for CPU clock frequencies below 25 MHz.
+
+Please note that the new clock-handling code is enabled if
+CONFIG_8xx_CPUCLK_DEFAULT is defined. Since this mechanism supports
+only MPC866 and newer CPUs, this constant MUST NOT be defined for
+MPC823/850/860/862 series. The clock generation algorithm for older
+chips is different and has not been implemented yet. If you need it,
+your patch is welcome.
diff --git a/u-boot/doc/README.Modem b/u-boot/doc/README.Modem
new file mode 100644
index 0000000..1613c11
--- /dev/null
+++ b/u-boot/doc/README.Modem
@@ -0,0 +1,72 @@
+How to configure modem support in U-Boot :
+
+1. Define modem initialization strings:
+---------------------------------------
+
+The modem initialization strings have following format:
+
+	mdm_init1=<AT-command>
+	mdm_init2=<AT-command>
+	...
+
+Turning off modem verbose responses with ATV0 or ATQ1 is not allowed;
+U-Boot analyzes only verbose (not numeric) result codes. Modem local
+command echo can be turned off (ATE0).
+
+2. RTS/CTS hardware flow control:
+---------------------------------
+
+You may wish to enable RTS/CTS hardware flow control, if the board's
+UART driver supports it (see CONFIG_HWFLOW compile-time flag in
+config/<board>.h). This is controlled by the 'mdm_flow_control'
+environment variable:
+
+	'mdm_flow_control=rts/cts'  - to enable RTS/CTS flow control.
+	'mdm_flow_control=none '    - to disable.
+
+
+The following are the examples using a Rockwell OEM modem
+configuration:
+
+SAMSUNG # setenv mdm_init1 ATZ			- reset the modem to
+						  the factory defaults.
+SAMSUNG # setenv mdm_init2 ATS0=1               - set modem into
+						  answer mode.
+SAMSUNG # setenv mdm_flow_control rts/cts       - enable serial port
+						  flow control
+SAMSUNG # saveenv
+
+The example above initializes modem into answer mode to wait for the
+incoming call. RTS/CTS flow control is enabled for the serial port.
+(The RTS/CTS flow control is enabled by default on the modem).
+
+
+SAMSUNG # setenv mdm_init1 ATZ
+SAMSUNG # setenv mdm_init2 ATS39=0+IFC=0,0	- disable modem
+						  RTS/CTS flow control
+SAMSUNG # setenv mdm_init3 ATDT1643973         -  dial out the number
+SAMSUNG # setenv mdm_flow_control none
+SAMSUNG # saveenv
+
+The example above initializes modem to dial-up connection on the
+number 1643973. Flow control is disabled.
+
+Note that flow control must be turned both off or both on for the
+board serial port and for the modem.
+
+
+If the connection was set up successfully, the U-Boot prompt appears
+on the terminal console. If not (U-Boot modem was configured for
+originating the call and connection was not established) - the board
+should be reset for another dial-up try.
+
+
+Note on the SMDK2400 board:
+---------------------------
+
+Since the board serial ports does not have DTR signal wired, modem
+should be told to ignore port DTR setting prior to connection to the
+SMDK board, and this setting should be stored in modem NVRAM. For the
+Rockwell OEM modem this can to be done with the following command:
+
+AT&D0&W
diff --git a/u-boot/doc/README.NetConsole b/u-boot/doc/README.NetConsole
new file mode 100644
index 0000000..c8bcb90
--- /dev/null
+++ b/u-boot/doc/README.NetConsole
@@ -0,0 +1,92 @@
+
+In U-Boot, we implemented the networked console via the standard
+"devices" mechanism, which means that you can switch between the
+serial and network input/output devices by adjusting the 'stdin' and
+'stdout' environment variables. To switch to the networked console,
+set either of these variables to "nc". Input and output can be
+switched independently.
+
+We use an environment variable 'ncip' to set the IP address and the
+port of the destination. The format is <ip_addr>:<port>. If <port> is
+omitted, the value of 6666 is used. If the env var doesn't exist, the
+broadcast address and port 6666 are used. If it is set to an IP
+address of 0 (or 0.0.0.0) then no messages are sent to the network.
+
+For example, if your server IP is 192.168.1.1, you could use:
+
+	=> setenv nc 'setenv stdout nc;setenv stdin nc'
+	=> setenv ncip 192.168.1.1
+	=> saveenv
+	=> run nc
+
+
+On the host side, please use this script to access the console:
+
+	tools/netconsole <ip> [port]
+
+The script uses netcat to talk to the board over UDP.  It requires you to
+specify the target IP address (or host name, assuming DNS is working). The
+script can be interrupted by pressing ^T (CTRL-T).
+
+Be aware that in some distributives (Fedora Core 5 at least)
+usage of nc has been changed and -l and -p options are considered
+as mutually exclusive. If nc complains about options provided,
+you can just remove the -p option from the script.
+
+It turns out that 'netcat' cannot be used to listen to broadcast
+packets. We developed our own tool 'ncb' (see tools directory) that
+listens to broadcast packets on a given port and dumps them to the
+standard output.  It will be built when compiling for a board which
+has CONFIG_NETCONSOLE defined.  If the netconsole script can find it
+in PATH or in the same directory, it will be used instead.
+
+For Linux, the network-based console needs special configuration.
+Minimally, the host IP address needs to be specified. This can be
+done either via the kernel command line, or by passing parameters
+while loading the netconsole.o module (when used in a loadable module
+configuration). Please refer to Documentation/networking/logging.txt
+file for the original Ingo Molnar's documentation on how to pass
+parameters to the loadable module.
+
+The format of the kernel command line parameter (for the static
+configuration) is as follows:
+
+  netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
+
+where
+
+  src-port	source for UDP packets
+		(defaults to 6665)
+  src-ip	source IP to use
+		(defaults to the interface's address)
+  dev		network interface
+		(defaults to eth0)
+  tgt-port	port for logging agent
+		(defaults to 6666)
+  tgt-ip	IP address for logging agent
+		(this is the required parameter)
+  tgt-macaddr	ethernet MAC address for logging agent
+		(defaults to broadcast)
+
+Examples:
+
+  netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
+
+or
+
+  netconsole=@/,@192.168.3.1/
+
+Please note that for the Linux networked console to work, the
+ethernet interface has to be up by the time the netconsole driver is
+initialized. This means that in case of static kernel configuration,
+the respective Ethernet interface has to be brought up using the "IP
+Autoconfiguration" kernel feature, which is usually done by defaults
+in the ELDK-NFS-based environment.
+
+To browse the Linux network console output, use the 'netcat' tool invoked
+as follows:
+
+	nc -u -l -p 6666
+
+Note that unlike the U-Boot implementation the Linux netconsole is
+unidirectional, i. e. you have console output only in Linux.
diff --git a/u-boot/doc/README.OFT b/u-boot/doc/README.OFT
new file mode 100644
index 0000000..dd1c632
--- /dev/null
+++ b/u-boot/doc/README.OFT
@@ -0,0 +1,28 @@
+Open Firmware Flat Tree and usage.
+----------------------------------
+
+As part of the ongoing cleanup of the Linux PPC trees, the preferred
+way to pass bootloader and board setup information is the open
+firmware flat tree.
+
+Please take a look at the following email discussion for some
+background.
+
+  http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019408.html
+  http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019362.html
+
+The generated tree is part static and part dynamic.
+
+There is a static part which is compiled in with DTC and a dynamic
+part which is programmatically appended.
+
+You'll need a fairly recent DTC tool, which is available by git at
+
+  rsync://ozlabs.org/dtc/dtc.git
+
+The xxd binary dumper is needed too which I got from
+
+  ftp://ftp.uni-erlangen.de/pub/utilities/etc/xxd-1.10.tar.gz
+
+
+Pantelis Antoniou, 13 Oct 2005
diff --git a/u-boot/doc/README.OXC b/u-boot/doc/README.OXC
new file mode 100644
index 0000000..c5db5f8
--- /dev/null
+++ b/u-boot/doc/README.OXC
@@ -0,0 +1,24 @@
+This document contains different information about the port
+of U-Boot for the OXC board designed by Lucent Technologies,
+Inc.
+
+1. Showing activity
+
+U-Boot for the OXC board can show its current status using
+the Active LED. This feature is configured by the following
+options:
+
+CONFIG_SHOW_ACTIVITY
+
+  When this option is on, the Active LED is blinking fast
+when U-Boot runs in the idle loop (i.e. waits for user
+commands from serial console) and blinking slow when it
+downloads an image over network. When U-Boot loads an image
+over serial line the Active LED does not blink and its state
+is random (i.e. either constant on or constant off).
+
+CONFIG_SHOW_BOOT_PROGRESS
+
+  When this option is on, U-Boot switches the Active LED
+off before booting an image and switches it on if booting
+failed due to some reasons.
diff --git a/u-boot/doc/README.PIP405 b/u-boot/doc/README.PIP405
new file mode 100644
index 0000000..012db1c
--- /dev/null
+++ b/u-boot/doc/README.PIP405
@@ -0,0 +1,375 @@
+U-Boot Changes due to PIP405 Port:
+===================================
+
+Changed files:
+==============
+- MAKEALL			added PIP405
+- makefile			added PIP405
+- common/Makefile		added Floppy disk and SCSI support
+- common/board.c		added PIP405, SCSI support, get_PCI_freq()
+- common/bootm.c		added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
+- common/cmd_i2c.c		added "defined(CONFIG_PIP405)"
+- common/cmd_ide.c		changed div. functions to work with block device
+				description
+				added ATAPI support
+- common/command.c		added SCSI and Floppy support
+- common/console.c		replaced // with /* comments
+				added console settings from environment
+- common/devices.c		added ISA keyboard init
+- common/main.c			corrected the read of bootdelay
+- arch/powerpc/cpu/ppc4xx/405gp_pci.c	excluded file from PIP405
+- arch/powerpc/cpu/ppc4xx/i2c.c		added 16bit read write I2C support
+				added page write
+- arch/powerpc/cpu/ppc4xx/speed.c		added get_PCI_freq
+- arch/powerpc/cpu/ppc4xx/start.S		added CONFIG_IDENT_STRING
+- disk/Makefile			added part_iso for CD support
+- disk/part.c			changed to work with block device description
+				added ISO CD support
+				added dev_print (was ide_print in cmd_ide.c)
+- disk/part_dos.c		changed to work with block device description
+- disk/part_mac.c		changed to work with block device description
+- include/ata.h			added ATAPI commands
+- include/cmd_bsp.h		added PIP405 commands definitions
+- include/cmd_condefs.h		added Floppy and SCSI support
+- include/cmd_disk.h		changed to work with block device description
+- include/config_LANTEC.h	excluded CONFIG_CMD_FDC and CONFIG_CMD_SCSI
+- include/config_hymod.h	excluded CONFIG_CMD_FDC and CONFIG_CMD_SCSI
+- include/flash.h		added INTEL_ID_28F320C3T  0x88C488C4
+- include/i2c.h			added "defined(CONFIG_PIP405)"
+- include/image.h		added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
+- include/u-boot.h		moved partitions functions definitions to part.h
+				added "defined(CONFIG_PIP405)"
+				added get_PCI_freq() definition
+- rtc/Makefile			added MC146818 RTC support
+- tools/mkimage.c		added IH_OS_U_BOOT, IH_TYPE_FIRMWARE
+
+Added files:
+============
+- board/pip405			directory for PIP405
+- board/pip405/cmd_pip405.c	board specific commands
+- board/pip405/config.mk	config make
+- board/pip405/flash.c		flash support
+- board/pip405/init.s		start-up
+- board/pip405/kbd.c		keyboard support
+- board/pip405/kbd.h		keyboard support
+- board/pip405/Makefile		Makefile
+- board/pip405/pci_piix4.h	southbridge definitions
+- board/pip405/pci_pip405.c	PCI support for PIP405
+- board/pip405/pci_pip405.h	PCI support for PIP405
+- board/pip405/pip405.c		PIP405 board init
+- board/pip405/pip405.h		PIP405 board init
+- board/pip405/pip405_isa.c	ISA support
+- board/pip405/pip405_isa.h	ISA support
+- board/pip405/u-boot.lds	Linker description
+- board/pip405/u-boot.lds.debugLinker description debug
+- board/pip405/sym53c8xx.c	SYM53C810A support
+- board/pip405/sym53c8xx_defs.h SYM53C810A definitions
+- board/pip405/vga_table.h	definitions of tables for VGA
+- board/pip405/video.c		CT69000 support
+- board/pip405/video.h		CT69000 support
+- common/cmd_fdc.c		Floppy disk support
+- common/cmd_scsi.c		SCSI support
+- disk/part_iso.c		ISO CD ROM support
+- disk/part_iso.h		ISO CD ROM support
+- include/cmd_fdc.h		command forFloppy disk support
+- include/cmd_scsi.h		command for SCSI support
+- include/part.h		partitions functions definitions
+				(was part of u-boot.h)
+- include/scsi.h		SCSI support
+- rtc/mc146818.c		MC146818 RTC support
+
+
+New Config Switches:
+====================
+For detailed description, refer to the corresponding paragraph in the
+section "Changes".
+
+New Commands:
+-------------
+CONFIG_CMD_SCSI	SCSI Support
+CONFIG_CMF_FDC	Floppy disk support
+
+IDE additions:
+--------------
+CONFIG_IDE_RESET_ROUTINE	defines that instead of a reset Pin,
+				the routine ide_set_reset(int idereset) is used.
+ATAPI support (experimental)
+----------------------------
+CONFIG_ATAPI	enables ATAPI Support
+
+SCSI support (experimental) only SYM53C8xx supported
+----------------------------------------------------
+CONFIG_SCSI_SYM53C8XX		type of SCSI controller
+CONFIG_SYS_SCSI_MAX_LUN	8	number of supported LUNs
+CONFIG_SYS_SCSI_MAX_SCSI_ID	7	maximum SCSI ID (0..6)
+CONFIG_SYS_SCSI_MAX_DEVICE	CONFIG_SYS_SCSI_MAX_SCSI_ID * CONFIG_SYS_SCSI_MAX_LUN
+				maximum of Target devices (multiple LUN support
+				for boot)
+
+ISO (CD-Boot) partition support (Experimental)
+----------------------------------------------
+CONFIG_ISO_PARTITION		CD-boot support
+
+RTC
+----
+CONFIG_RTC_MC146818		MC146818 RTC support
+
+Keyboard:
+---------
+CONFIG_ISA_KEYBOARD		Standard (PC-Style) Keyboard support
+
+Video:
+------
+CONFIG_VIDEO_CT69000		Enable Chips & Technologies 69000 Video chip
+				CONFIG_VIDEO must be defined also
+
+External peripheral base address:
+---------------------------------
+CONFIG_SYS_ISA_IO_BASE_ADDRESS		address of all ISA-bus related parts
+				_must_ be defined for ISA-bus parts
+
+Identify:
+---------
+CONFIG_IDENT_STRING		added to the U_BOOT_VERSION String
+
+Environment / Console:
+----------------------
+
+CONFIG_SYS_CONSOLE_IS_IN_ENV		if defined, stdin, stdout and stderr used from
+				the values stored in the evironment.
+
+CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE	if defined, console_overwrite() decides if the
+				values stored in the environment or the standard
+				serial in/out put should be assigned to the console.
+
+CONFIG_SYS_CONSOLE_ENV_OVERWRITE	if defined, the start-up console switching
+				are stored in the environment.
+
+PIP405 specific:
+----------------
+CONFIG_PORT_ADDR		address used to read boot configuration
+MULTI_PURPOSE_SOCKET_ADDR	address of the multi purpose socked
+SDRAM_EEPROM_WRITE_ADDRESS	addresses of the serial presence detect
+SDRAM_EEPROM_READ_ADDRESS	EEPROM on the SDRAM module.
+
+
+Changes:
+========
+
+Added Devices:
+==============
+
+Floppy support:
+---------------
+Support of a standard floppy disk controller at address CONFIG_SYS_ISA_IO_BASE_ADDRESS
++ 0x3F0. Enabled with define CONFIG_CMD_FDC. Reads a unformated floppy disk
+with a image header (see: mkimage). No interrupts and no DMA are used for this.
+Added files:
+- common/cmd_fdc.c
+- include/cmd_fdc.h
+
+SCSI support:
+-------------
+Support for Symbios SYM53C810A chip. Implemented as follows:
+- without disconnect
+- only asynchrounous
+- multiple LUN support (caution, needs a lot of RAM. define CONFIG_SYS_SCSI_MAX_LUN 1 to
+  save RAM)
+- multiple SCSI ID support
+- no write support
+- analyses the MAC, DOS and ISO pratition similar to the IDE support
+- allows booting from SCSI devices similar to the IDE support.
+The device numbers are not assigned like they are within the IDE support. The first
+device found will get the number 0, the next 1 etc. If all SCSI IDs (0..6) and all
+LUNs (8) are enabled, 56 boot devices are possible. This uses a lot of RAM since the
+device descriptors are not yet dynamically allocated. 56 boot devices are overkill
+anyway. Please refer to the section "Todo" chapter "block device support enhancement".
+The SYM53C810A uses 1 Interrupt and must be able of mastering the PCI bus.
+Added files:
+- common/cmd_scsi.c
+- common/board.c
+- include/cmd_scsi.h
+- include/scsi.h
+- board/pip405/sym53c8xx.c
+- board/pip405/sym53c8xx_defs.h
+
+ATAPI support (IDE changes):
+----------------------------
+Added ATAPI support (with CONFIG_ATAPI) in the file cmd_ide.c.
+To support a hardreset, when the IDE reset pin is not connected to the
+CONFIG_SYS_PC_IDE_RESET pin, the switch CONFIG_IDE_RESET_ROUTINE has been added. When
+this switch is enabled the routine void ide_set_reset(int idereset) must be
+within the board specific files.
+Only read from ATAPI devices are supported.
+Found out that the function trim_trail cuts off the last character if the whole
+string is filled. Added function cpy_ident instead, which trims also leading
+spaces and copies the string in the buffer.
+Changed files:
+- common/cmd_ide.c
+- include/ata.h
+
+ISO partition support:
+----------------------
+Added CD boot support for El-Torito bootable ISO CDs. The bootfile image must contain
+the U-Boot image header. Since CDs do not have "partitions", the boot partition is 0.
+The bootcatalog feature has not been tested so far. CD Boot is supported for ATAPI
+("diskboot") and SCSI ("scsiboot") devices.
+Added files:
+- disk/iso_part.c
+- disk/iso_part.h
+
+Block device changes:
+---------------------
+To allow the use of dos_part.c, mac_part.c and iso_part.c, the parameter
+block_dev_desc will be used when accessing the functions in these files. The block
+device descriptor (block_dev_desc) contains a pointer to the read routine of the
+device, which will be used to read blocks from the device.
+Renamed function ide_print to dev_print and moved it to the file disk/part.c to use
+it for IDE ATAPI and SCSI devices.
+Please refer to the section "Todo" chapter "block device support enhancement".
+Added files:
+- include/part.h
+changed files:
+- disk/dos_part.c
+- disk/dos_part.h
+- disk/mac_part.c
+- disk/mac_part.h
+- disk/part.c
+- common/cmd_ide.c
+- include/u-boot.h
+
+
+MC146818 RTC support:
+---------------------
+Added support for MC146818 RTC with defining CONFIG_RTC_MC146818. The ISA bus IO
+base address must be defined with CONFIG_SYS_ISA_IO_BASE_ADDRESS.
+Added files:
+- rtc/mc146818.c
+
+Standard ISA bus Keyboard support:
+----------------------------------
+Added support for the standard PC kyeboard controller. For the PIP405 the superIO
+controller must be set up previously. The keyboard uses the standard ISA IRQ, so
+the ISA PIC must also be set up.
+Added files:
+- board/pip405/kbd.c
+- board/pip405/kbd.h
+- board/pip405/pip405_isa.c
+- board/pip405/pip405_isa.h
+
+Chips and Technologie 69000 VGA controller support:
+---------------------------------------------------
+Added support for the CT69000 VGA controller.
+Added files:
+- board/pip405/video.c
+- board/pip405/video.h
+- board/pip405/vga_table.h
+
+
+Changed Items:
+==============
+
+Identify:
+---------
+Added the config variable CONFIG_IDENT_STRING which will be added to the
+"U_BOOT_VERSION __TIME__ DATE___ " String, to allows to identify intermidiate
+and custom versions.
+Changed files:
+- arch/powerpc/cpu/ppc4xx/start.s
+
+Firmware Image:
+---------------
+Added IH_OS_U_BOOT and IH_TYPE_FIRMWARE to the image definitions to allows the
+U-Boot update with prior CRC check.
+Changed files:
+- include/image.h
+- tools/mkimage.c
+- common/cmd_bootm.c
+
+Correct PCI Frequency for PPC405:
+---------------------------------
+Added function (in arch/powerpc/cpu/ppc4xx/speed.c) to get the PCI frequency for PPC405 CPU.
+The PCI Frequency will now be set correct in the board description in common/board.c.
+(was set to the busfreq before).
+Changed files:
+- arch/powerpc/cpu/ppc4xx/speed.c
+- common/board.c
+
+I2C Stuff:
+----------
+Added defined(CONFIG_PIP405) at several points in common/cmd_i2c.c.
+Added 16bit read/write support for I2C (PPC405), and page write to
+I2C EEPROM if defined CONFIG_SYS_EEPROM_PAGE_WRITE_ENABLE.
+Changed files:
+- arch/powerpc/cpu/ppc4xx/i2c.c
+- common/cmd_i2c.c
+
+Environment / Console:
+----------------------
+Although in README.console described, the U-Boot has not assinged the values
+found in the environment to the console. Corrected this behavior, but only if
+CONFIG_SYS_CONSOLE_IS_IN_ENV is defined.
+If CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE is defined, console_overwrite() decides if the
+values stored in the environment or the standard serial in/output should be
+assigned to the console. This is useful if the environment values are not correct.
+If CONFIG_SYS_CONSOLE_ENV_OVERWRITE is defined the devices assigned to the console at
+start-up time will be written to the environment. This means that if the
+environment values are overwritten by the overwrite_console() routine, they will be
+stored in the environment.
+Changed files:
+- common/console.c
+
+Correct bootdelay intepretation:
+--------------------------------
+Changed bootdelay read from the environment from simple_strtoul (unsigned) to
+simple_strtol (signed), to be able to get a bootdelay of -1.
+Changed files:
+- common/main.c
+
+Todo:
+=====
+
+Block device support enhancement:
+---------------------------------
+Consider to unify the block device handling. Instead of using diskboot for IDE,
+scsiboot for SCSI and fdcboot for floppy disks, it would make sense to use only
+one command ("devboot" ???) with a parameter of the desired device ("hda1", "sda1",
+"fd0" ???) to boot from. The other ide commands can be handled in the same way
+("dev hda read.." instead of "ide read.." or "dev sda read.." instead of
+"scsi read..."). Todo this, a common way of assign a block device to its name
+(first found ide device = hda, second found hdb etc., or hda is device 0 on bus 0,
+hdb is device 1 on bus 0 etc.) as well as the names (hdx for ide, sdx for scsi, fx for
+floppy ???) must be defined.
+Maybe there are better ideas to do this.
+
+Console assingment:
+-------------------
+Consider to initialize and assign the console stdin, stdout and stderr as soon as
+possible to see the boot messages also on an other console than serial.
+
+
+Todo for PIP405:
+================
+
+LCD support for VGA:
+--------------------
+Add LCD support for the CT69000
+
+Default environment:
+--------------------
+Consider to write a default environment to the OTP part of the EEPROM and use it
+if the normal environment is not valid. Useful for serial# and ethaddr values.
+
+Watchdog:
+---------
+Implement Watchdog.
+
+Files clean-up:
+---------------
+Following files needs to be cleaned up:
+- cmd_pip405.c
+- flash.c
+- pci_pip405.c
+- pip405.c
+- pip405_isa.c
+Consider to split up the files in their functions.
diff --git a/u-boot/doc/README.POST b/u-boot/doc/README.POST
new file mode 100644
index 0000000..6815d49
--- /dev/null
+++ b/u-boot/doc/README.POST
@@ -0,0 +1,743 @@
+Power-On-Self-Test support in U-Boot
+------------------------------------
+
+This project is to support Power-On-Self-Test (POST) in U-Boot.
+
+1. High-level requirements
+
+The key requirements for this project are as follows:
+
+1) The project shall develop a flexible framework for implementing
+   and running Power-On-Self-Test in U-Boot. This framework shall
+   possess the following features:
+
+   o) Extensibility
+
+      The framework shall allow adding/removing/replacing POST tests.
+      Also, standalone POST tests shall be supported.
+
+   o) Configurability
+
+      The framework shall allow run-time configuration of the lists
+      of tests running on normal/power-fail booting.
+
+   o) Controllability
+
+      The framework shall support manual running of the POST tests.
+
+2) The results of tests shall be saved so that it will be possible to
+   retrieve them from Linux.
+
+3) The following POST tests shall be developed for MPC823E-based
+   boards:
+
+   o) CPU test
+   o) Cache test
+   o) Memory test
+   o) Ethernet test
+   o) Serial channels test
+   o) Watchdog timer test
+   o) RTC test
+   o) I2C test
+   o) SPI test
+   o) USB test
+
+4) The LWMON board shall be used for reference.
+
+2. Design
+
+This section details the key points of the design for the project.
+The whole project can be divided into two independent tasks:
+enhancing U-Boot/Linux to provide a common framework for running POST
+tests and developing such tests for particular hardware.
+
+2.1. Hardware-independent POST layer
+
+A new optional module will be added to U-Boot, which will run POST
+tests and collect their results at boot time. Also, U-Boot will
+support running POST tests manually at any time by executing a
+special command from the system console.
+
+The list of available POST tests will be configured at U-Boot build
+time. The POST layer will allow the developer to add any custom POST
+tests. All POST tests will be divided into the following groups:
+
+  1) Tests running on power-on booting only
+
+     This group will contain those tests that run only once on
+     power-on reset (e.g. watchdog test)
+
+  2) Tests running on normal booting only
+
+     This group will contain those tests that do not take much
+     time and can be run on the regular basis (e.g. CPU test)
+
+  3) Tests running in special "slow test mode" only
+
+     This group will contain POST tests that consume much time
+     and cannot be run regularly (e.g. strong memory test, I2C test)
+
+  4) Manually executed tests
+
+     This group will contain those tests that can be run manually.
+
+If necessary, some tests may belong to several groups simultaneously.
+For example, SDRAM test may run in both normal and "slow test" mode.
+In normal mode, SDRAM test may perform a fast superficial memory test
+only, while running in slow test mode it may perform a full memory
+check-up.
+
+Also, all tests will be discriminated by the moment they run at.
+Specifically, the following groups will be singled out:
+
+  1) Tests running before relocating to RAM
+
+     These tests will run immediately after initializing RAM
+     as to enable modifying it without taking care of its
+     contents. Basically, this group will contain memory tests
+     only.
+
+  2) Tests running after relocating to RAM
+
+     These tests will run immediately before entering the main
+     loop as to guarantee full hardware initialization.
+
+The POST layer will also distinguish a special group of tests that
+may cause system rebooting (e.g. watchdog test). For such tests, the
+layer will automatically detect rebooting and will notify the test
+about it.
+
+2.1.1. POST layer interfaces
+
+This section details the interfaces between the POST layer and the
+rest of U-Boot.
+
+The following flags will be defined:
+
+#define POST_POWERON		0x01	/* test runs on power-on booting */
+#define POST_NORMAL		0x02	/* test runs on normal booting */
+#define POST_SLOWTEST		0x04	/* test is slow, enabled by key press */
+#define POST_POWERTEST		0x08	/* test runs after watchdog reset */
+#define POST_ROM		0x100	/* test runs in ROM */
+#define POST_RAM		0x200	/* test runs in RAM */
+#define POST_MANUAL		0x400	/* test can be executed manually */
+#define POST_REBOOT		0x800	/* test may cause rebooting */
+#define POST_PREREL             0x1000  /* test runs before relocation */
+
+The POST layer will export the following interface routines:
+
+  o) int post_run(bd_t *bd, char *name, int flags);
+
+     This routine will run the test (or the group of tests) specified
+     by the name and flag arguments. More specifically, if the name
+     argument is not NULL, the test with this name will be performed,
+     otherwise all tests running in ROM/RAM (depending on the flag
+     argument) will be executed. This routine will be called at least
+     twice with name set to NULL, once from board_init_f() and once
+     from board_init_r(). The flags argument will also specify the
+     mode the test is executed in (power-on, normal, power-fail,
+     manual).
+
+  o) void post_reloc(ulong offset);
+
+     This routine will be called from board_init_r() and will
+     relocate the POST test table.
+
+  o) int post_info(char *name);
+
+     This routine will print the list of all POST tests that can be
+     executed manually if name is NULL, and the description of a
+     particular test if name is not NULL.
+
+  o) int post_log(char *format, ...);
+
+     This routine will be called from POST tests to log their
+     results. Basically, this routine will print the results to
+     stderr. The format of the arguments and the return value
+     will be identical to the printf() routine.
+
+Also, the following board-specific routines will be called from the
+U-Boot common code:
+
+  o) int board_power_mode(void)
+
+     This routine will return the mode the system is running in
+     (POST_POWERON, POST_NORMAL or POST_SHUTDOWN).
+
+  o) void board_poweroff(void)
+
+     This routine will turn off the power supply of the board. It
+     will be called on power-fail booting after running all POST
+     tests.
+
+  o) int post_hotkeys_pressed(gd_t *gd)
+
+     This routine will scan the keyboard to detect if a magic key
+     combination has been pressed, or otherwise detect if the
+     power-on long-running tests shall be executed or not ("normal"
+     versus "slow" test mode).
+
+The list of available POST tests be kept in the post_tests array
+filled at U-Boot build time. The format of entry in this array will
+be as follows:
+
+struct post_test {
+    char *name;
+    char *cmd;
+    char *desc;
+    int flags;
+    int (*test)(bd_t *bd, int flags);
+};
+
+  o) name
+
+     This field will contain a short name of the test, which will be
+     used in logs and on listing POST tests (e.g. CPU test).
+
+  o) cmd
+
+     This field will keep a name for identifying the test on manual
+     testing (e.g. cpu). For more information, refer to section
+     "Command line interface".
+
+  o) desc
+
+     This field will contain a detailed description of the test,
+     which will be printed on user request. For more information, see
+     section "Command line interface".
+
+  o) flags
+
+     This field will contain a combination of the bit flags described
+     above, which will specify the mode the test is running in
+     (power-on, normal, power-fail or manual mode), the moment it
+     should be run at (before or after relocating to RAM), whether it
+     can cause system rebooting or not.
+
+  o) test
+
+     This field will contain a pointer to the routine that will
+     perform the test, which will take 2 arguments. The first
+     argument will be a pointer to the board info structure, while
+     the second will be a combination of bit flags specifying the
+     mode the test is running in (POST_POWERON, POST_NORMAL,
+     POST_SLOWTEST, POST_MANUAL) and whether the last execution of
+     the test caused system rebooting (POST_REBOOT). The routine will
+     return 0 on successful execution of the test, and 1 if the test
+     failed.
+
+The lists of the POST tests that should be run at power-on/normal/
+power-fail booting will be kept in the environment. Namely, the
+following environment variables will be used: post_poweron,
+powet_normal, post_slowtest.
+
+2.1.2. Test results
+
+The results of tests will be collected by the POST layer. The POST
+log will have the following format:
+
+...
+--------------------------------------------
+START <name>
+<test-specific output>
+[PASSED|FAILED]
+--------------------------------------------
+...
+
+Basically, the results of tests will be printed to stderr. This
+feature may be enhanced in future to spool the log to a serial line,
+save it in non-volatile RAM (NVRAM), transfer it to a dedicated
+storage server and etc.
+
+2.1.3. Integration issues
+
+All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
+This macro will be defined in the config_<board>.h file for those
+boards that need POST. The CONFIG_POST macro will contain the list of
+POST tests for the board. The macro will have the format of array
+composed of post_test structures:
+
+#define CONFIG_POST \
+	{
+		"On-board peripherals test", "board", \
+		"  This test performs full check-up of the " \
+		"on-board hardware.", \
+		POST_RAM | POST_SLOWTEST, \
+		&board_post_test \
+	}
+
+A new file, post.h, will be created in the include/ directory. This
+file will contain common POST declarations and will define a set of
+macros that will be reused for defining CONFIG_POST. As an example,
+the following macro may be defined:
+
+#define POST_CACHE \
+	{
+		"Cache test", "cache", \
+		"  This test verifies the CPU cache operation.", \
+		POST_RAM | POST_NORMAL, \
+		&cache_post_test \
+	}
+
+A new subdirectory will be created in the U-Boot root directory. It
+will contain the source code of the POST layer and most of POST
+tests. Each POST test in this directory will be placed into a
+separate file (it will be needed for building standalone tests). Some
+POST tests (mainly those for testing peripheral devices) will be
+located in the source files of the drivers for those devices. This
+way will be used only if the test subtantially uses the driver.
+
+2.1.4. Standalone tests
+
+The POST framework will allow to develop and run standalone tests. A
+user-space library will be developed to provide the POST interface
+functions to standalone tests.
+
+2.1.5. Command line interface
+
+A new command, diag, will be added to U-Boot. This command will be
+used for listing all available hardware tests, getting detailed
+descriptions of them and running these tests.
+
+More specifically, being run without any arguments, this command will
+print the list of all available hardware tests:
+
+=> diag
+Available hardware tests:
+  cache             - cache test
+  cpu               - CPU test
+  enet              - SCC/FCC ethernet test
+Use 'diag [<test1> [<test2>]] ... ' to get more info.
+Use 'diag run [<test1> [<test2>]] ... ' to run tests.
+=>
+
+If the first argument to the diag command is not 'run', detailed
+descriptions of the specified tests will be printed:
+
+=> diag cpu cache
+cpu - CPU test
+  This test verifies the arithmetic logic unit of CPU.
+cache - cache test
+  This test verifies the CPU cache operation.
+=>
+
+If the first argument to diag is 'run', the specified tests will be
+executed. If no tests are specified, all available tests will be
+executed.
+
+It will be prohibited to execute tests running in ROM manually. The
+'diag' command will not display such tests and/or run them.
+
+2.1.6. Power failure handling
+
+The Linux kernel will be modified to detect power failures and
+automatically reboot the system in such cases. It will be assumed
+that the power failure causes a system interrupt.
+
+To perform correct system shutdown, the kernel will register a
+handler of the power-fail IRQ on booting. Being called, the handler
+will run /sbin/reboot using the call_usermodehelper() routine.
+/sbin/reboot will automatically bring the system down in a secure
+way. This feature will be configured in/out from the kernel
+configuration file.
+
+The POST layer of U-Boot will check whether the system runs in
+power-fail mode. If it does, the system will be powered off after
+executing all hardware tests.
+
+2.1.7. Hazardous tests
+
+Some tests may cause system rebooting during their execution. For
+some tests, this will indicate a failure, while for the Watchdog
+test, this means successful operation of the timer.
+
+In order to support such tests, the following scheme will be
+implemented. All the tests that may cause system rebooting will have
+the POST_REBOOT bit flag set in the flag field of the correspondent
+post_test structure. Before starting tests marked with this bit flag,
+the POST layer will store an identification number of the test in a
+location in IMMR. On booting, the POST layer will check the value of
+this variable and if it is set will skip over the tests preceding the
+failed one. On second execution of the failed test, the POST_REBOOT
+bit flag will be set in the flag argument to the test routine. This
+will allow to detect system rebooting on the previous iteration. For
+example, the watchdog timer test may have the following
+declaration/body:
+
+...
+#define POST_WATCHDOG \
+	{
+		"Watchdog timer test", "watchdog", \
+		"  This test checks the watchdog timer.", \
+		POST_RAM | POST_POWERON | POST_REBOOT, \
+		&watchdog_post_test \
+	}
+...
+
+...
+int watchdog_post_test(bd_t *bd, int flags)
+{
+	unsigned long start_time;
+
+	if (flags & POST_REBOOT) {
+		/* Test passed */
+		return 0;
+	} else {
+		/* disable interrupts */
+		disable_interrupts();
+		/* 10-second delay */
+		...
+		/* if we've reached this, the watchdog timer does not work */
+		enable_interrupts();
+		return 1;
+	}
+}
+...
+
+2.2. Hardware-specific details
+
+This project will also develop a set of POST tests for MPC8xx- based
+systems. This section provides technical details of how it will be
+done.
+
+2.2.1. Generic PPC tests
+
+The following generic POST tests will be developed:
+
+  o) CPU test
+
+     This test will check the arithmetic logic unit (ALU) of CPU. The
+     test will take several milliseconds and will run on normal
+     booting.
+
+  o) Cache test
+
+     This test will verify the CPU cache (L1 cache). The test will
+     run on normal booting.
+
+  o) Memory test
+
+     This test will examine RAM and check it for errors. The test
+     will always run on booting. On normal booting, only a limited
+     amount of RAM will be checked. On power-fail booting a fool
+     memory check-up will be performed.
+
+2.2.1.1. CPU test
+
+This test will verify the following ALU instructions:
+
+  o) Condition register istructions
+
+     This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
+     cror, crorc, crxor, crnand, crnor, creqv, mcrf.
+
+     The mtcrf/mfcr instructions will be tested by loading different
+     values into the condition register (mtcrf), moving its value to
+     a general-purpose register (mfcr) and comparing this value with
+     the expected one. The mcrxr instruction will be tested by
+     loading a fixed value into the XER register (mtspr), moving XER
+     value to the condition register (mcrxr), moving it to a
+     general-purpose register (mfcr) and comparing the value of this
+     register with the expected one. The rest of instructions will be
+     tested by loading a fixed value into the condition register
+     (mtcrf), executing each instruction several times to modify all
+     4-bit condition fields, moving the value of the conditional
+     register to a general-purpose register (mfcr) and comparing it
+     with the expected one.
+
+  o) Integer compare instructions
+
+     This group will contain: cmp, cmpi, cmpl, cmpli.
+
+     To verify these instructions the test will run them with
+     different combinations of operands, read the condition register
+     value and compare it with the expected one. More specifically,
+     the test will contain a pre-built table containing the
+     description of each test case: the instruction, the values of
+     the operands, the condition field to save the result in and the
+     expected result.
+
+  o) Arithmetic instructions
+
+     This group will contain: add, addc, adde, addme, addze, subf,
+     subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu,
+     extsb, extsh.
+
+     The test will contain a pre-built table of instructions,
+     operands, expected results and expected states of the condition
+     register. For each table entry, the test will cyclically use
+     different sets of operand registers and result registers. For
+     example, for instructions that use 3 registers on the first
+     iteration r0/r1 will be used as operands and r2 for result. On
+     the second iteration, r1/r2 will be used as operands and r3 as
+     for result and so on. This will enable to verify all
+     general-purpose registers.
+
+  o) Logic instructions
+
+     This group will contain: and, andc, andi, andis, or, orc, ori,
+     oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw.
+
+     The test scheme will be identical to that from the previous
+     point.
+
+  o) Shift instructions
+
+     This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
+     rlwimi
+
+     The test scheme will be identical to that from the previous
+     point.
+
+  o) Branch instructions
+
+     This group will contain: b, bl, bc.
+
+     The first 2 instructions (b, bl) will be verified by jumping to
+     a fixed address and checking whether control was transfered to
+     that very point. For the bl instruction the value of the link
+     register will be checked as well (using mfspr). To verify the bc
+     instruction various combinations of the BI/BO fields, the CTR
+     and the condition register values will be checked. The list of
+     such combinations will be pre-built and linked in U-Boot at
+     build time.
+
+  o) Load/store instructions
+
+     This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
+     lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u).
+
+     All operations will be performed on a 16-byte array. The array
+     will be 4-byte aligned. The base register will point to offset
+     8. The immediate offset (index register) will range in [-8 ...
+     +7]. The test cases will be composed so that they will not cause
+     alignment exceptions. The test will contain a pre-built table
+     describing all test cases. For store instructions, the table
+     entry will contain: the instruction opcode, the value of the
+     index register and the value of the source register. After
+     executing the instruction, the test will verify the contents of
+     the array and the value of the base register (it must change for
+     "store with update" instructions). For load instructions, the
+     table entry will contain: the instruction opcode, the array
+     contents, the value of the index register and the expected value
+     of the destination register. After executing the instruction,
+     the test will verify the value of the destination register and
+     the value of the base register (it must change for "load with
+     update" instructions).
+
+  o) Load/store multiple/string instructions
+
+
+The CPU test will run in RAM in order to allow run-time modification
+of the code to reduce the memory footprint.
+
+2.2.1.2 Special-Purpose Registers Tests
+
+TBD.
+
+2.2.1.3. Cache test
+
+To verify the data cache operation the following test scenarios will
+be used:
+
+  1) Basic test #1
+
+    - turn on the data cache
+    - switch the data cache to write-back or write-through mode
+    - invalidate the data cache
+    - write the negative pattern to a cached area
+    - read the area
+
+    The negative pattern must be read at the last step
+
+  2) Basic test #2
+
+    - turn on the data cache
+    - switch the data cache to write-back or write-through mode
+    - invalidate the data cache
+    - write the zero pattern to a cached area
+    - turn off the data cache
+    - write the negative pattern to the area
+    - turn on the data cache
+    - read the area
+
+    The negative pattern must be read at the last step
+
+  3) Write-through mode test
+
+    - turn on the data cache
+    - switch the data cache to write-through mode
+    - invalidate the data cache
+    - write the zero pattern to a cached area
+    - flush the data cache
+    - write the negative pattern to the area
+    - turn off the data cache
+    - read the area
+
+    The negative pattern must be read at the last step
+
+  4) Write-back mode test
+
+    - turn on the data cache
+    - switch the data cache to write-back mode
+    - invalidate the data cache
+    - write the negative pattern to a cached area
+    - flush the data cache
+    - write the zero pattern to the area
+    - invalidate the data cache
+    - read the area
+
+    The negative pattern must be read at the last step
+
+To verify the instruction cache operation the following test
+scenarios will be used:
+
+  1) Basic test #1
+
+    - turn on the instruction cache
+    - unlock the entire instruction cache
+    - invalidate the instruction cache
+    - lock a branch instruction in the instruction cache
+    - replace the branch instruction with "nop"
+    - jump to the branch instruction
+    - check that the branch instruction was executed
+
+  2) Basic test #2
+
+    - turn on the instruction cache
+    - unlock the entire instruction cache
+    - invalidate the instruction cache
+    - jump to a branch instruction
+    - check that the branch instruction was executed
+    - replace the branch instruction with "nop"
+    - invalidate the instruction cache
+    - jump to the branch instruction
+    - check that the "nop" instruction was executed
+
+The CPU test will run in RAM in order to allow run-time modification
+of the code.
+
+2.2.1.4. Memory test
+
+The memory test will verify RAM using sequential writes and reads
+to/from RAM. Specifically, there will be several test cases that will
+use different patterns to verify RAM. Each test case will first fill
+a region of RAM with one pattern and then read the region back and
+compare its contents with the pattern. The following patterns will be
+used:
+
+ 1) zero pattern (0x00000000)
+ 2) negative pattern (0xffffffff)
+ 3) checkerboard pattern (0x55555555, 0xaaaaaaaa)
+ 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
+ 5) address pattern (offset, ~offset)
+
+Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
+be used to detect adherent bits, i.e. bits whose state may randomly
+change if adjacent bits are modified. The last pattern will be used
+to detect far-located errors, i.e. situations when writing to one
+location modifies an area located far from it. Also, usage of the
+last pattern will help to detect memory controller misconfigurations
+when RAM represents a cyclically repeated portion of a smaller size.
+
+Being run in normal mode, the test will verify only small 4Kb regions
+of RAM around each 1Mb boundary. For example, for 64Mb RAM the
+following areas will be verified: 0x00000000-0x00000800,
+0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
+0x04000000. If the test is run in power-fail mode, it will verify the
+whole RAM.
+
+The memory test will run in ROM before relocating U-Boot to RAM in
+order to allow RAM modification without saving its contents.
+
+2.2.2. Common tests
+
+This section describes tests that are not based on any hardware
+peculiarities and use common U-Boot interfaces only. These tests do
+not need any modifications for porting them to another board/CPU.
+
+2.2.2.1. I2C test
+
+For verifying the I2C bus, a full I2C bus scanning will be performed
+using the i2c_probe() routine. If a board defines
+CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
+listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
+devices are detected.  If CONFIG_SYS_POST_I2C_ADDRS is not defined
+the test will pass if any I2C device is found.
+
+The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C
+devices which may or may not be present when using
+CONFIG_SYS_POST_I2C_ADDRS.  The I2C POST test will pass regardless
+if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not.
+This is useful in cases when I2C devices are optional (eg on a
+daughtercard that may or may not be present) or not critical
+to board operation.
+
+2.2.2.2. Watchdog timer test
+
+To test the watchdog timer the scheme mentioned above (refer to
+section "Hazardous tests") will be used. Namely, this test will be
+marked with the POST_REBOOT bit flag. On the first iteration, the
+test routine will make a 10-second delay. If the system does not
+reboot during this delay, the watchdog timer is not operational and
+the test fails. If the system reboots, on the second iteration the
+POST_REBOOT bit will be set in the flag argument to the test routine.
+The test routine will check this bit and report a success if it is
+set.
+
+2.2.2.3. RTC test
+
+The RTC test will use the rtc_get()/rtc_set() routines. The following
+features will be verified:
+
+  o) Time uniformity
+
+     This will be verified by reading RTC in polling within a short
+     period of time (5-10 seconds).
+
+  o) Passing month boundaries
+
+     This will be checked by setting RTC to a second before a month
+     boundary and reading it after its passing the boundary. The test
+     will be performed for both leap- and nonleap-years.
+
+2.2.3. MPC8xx peripherals tests
+
+This project will develop a set of tests verifying the peripheral
+units of MPC8xx processors. Namely, the following controllers of the
+MPC8xx communication processor module (CPM) will be tested:
+
+  o) Serial Management Controllers (SMC)
+
+  o) Serial Communication Controllers (SCC)
+
+2.2.3.1. Ethernet tests (SCC)
+
+The internal (local) loopback mode will be used to test SCC. To do
+that the controllers will be configured accordingly and several
+packets will be transmitted. These tests may be enhanced in future to
+use external loopback for testing. That will need appropriate
+reconfiguration of the physical interface chip.
+
+The test routines for the SCC ethernet tests will be located in
+arch/powerpc/cpu/mpc8xx/scc.c.
+
+2.2.3.2. UART tests (SMC/SCC)
+
+To perform these tests the internal (local) loopback mode will be
+used. The SMC/SCC controllers will be configured to connect the
+transmitter output to the receiver input. After that, several bytes
+will be transmitted. These tests may be enhanced to make to perform
+"external" loopback test using a loopback cable. In this case, the
+test will be executed manually.
+
+The test routine for the SMC/SCC UART tests will be located in
+arch/powerpc/cpu/mpc8xx/serial.c.
+
+2.2.3.3. USB test
+
+TBD
+
+2.2.3.4. SPI test
+
+TBD
diff --git a/u-boot/doc/README.PXA_CF b/u-boot/doc/README.PXA_CF
new file mode 100644
index 0000000..1d76b32
--- /dev/null
+++ b/u-boot/doc/README.PXA_CF
@@ -0,0 +1,56 @@
+
+These are brief instructions on how to add support for CF adapters to
+custom designed  PXA boards. You need to set the parameters in the
+config file. This should work for most implementations especially if you
+follow the connections of the standard lubbock. Anyway just the block
+marked memory configuration should be touched since the other parameters
+are imposed by the PXA architecture.
+
+EDIT 2010-07-01: in common/cmd_ide.c, having CONFIG_PXA_PCMCIA defined
+would cause looping on inw()/outw() rather than using insw()/outsw(),
+thus making sure IDE / ATA bytes are properly swapped. This behaviour
+is now controlled by CONFIG_IDE_SWAP_IO, therefore PXA boards with
+PCMCIA should #define CONFIG_IDE_SWAP_IO.
+
+#define CONFIG_IDE_SWAP_IO
+
+#define CONFIG_PXA_PCMCIA 1
+#define CONFIG_PXA_IDE 1
+
+#define CONFIG_PCMCIA_SLOT_A 1
+/* just to keep build system happy  */
+
+#define CONFIG_SYS_PCMCIA_MEM_ADDR     0x28000000
+#define CONFIG_SYS_PCMCIA_MEM_SIZE     0x10000000
+
+#define CONFIG_SYS_MECR_VAL		0x00000000
+#define CONFIG_SYS_MCMEM0_VAL		0x00004204
+#define CONFIG_SYS_MCMEM1_VAL		0x00000000
+#define CONFIG_SYS_MCATT0_VAL		0x00010504
+#define CONFIG_SYS_MCATT1_VAL		0x00000000
+#define CONFIG_SYS_MCIO0_VAL		0x00008407
+#define CONFIG_SYS_MCIO1_VAL		0x00000000
+/* memory configuration */
+
+#define CONFIG_SYS_IDE_MAXBUS		1
+/* max. 1 IDE bus		*/
+#define CONFIG_SYS_IDE_MAXDEVICE	1
+/* max. 1 drive per IDE bus	*/
+
+#define CONFIG_SYS_ATA_IDE0_OFFSET	0x0000
+
+#define CONFIG_SYS_ATA_BASE_ADDR	0x20000000
+
+/* Offset for data I/O			*/
+#define CONFIG_SYS_ATA_DATA_OFFSET	0x1f0
+
+/* Offset for normal register accesses	*/
+#define CONFIG_SYS_ATA_REG_OFFSET	0x1f0
+
+/* Offset for alternate registers	*/
+#define CONFIG_SYS_ATA_ALT_OFFSET	0x3f0
+
+
+Another important point is that maybe you have to power the pcmcia
+subsystem. This is very board specific, for an example on how to
+do it please search for CONFIG_EXADRON1 in cmd_pcmcia.c
diff --git a/u-boot/doc/README.PlanetCore b/u-boot/doc/README.PlanetCore
new file mode 100644
index 0000000..b73c5f5
--- /dev/null
+++ b/u-boot/doc/README.PlanetCore
@@ -0,0 +1,163 @@
+After several heart-struck failure, I got one workable way to program
+each other in FLASH between PlanetCore and U-Boot.
+
+Hardware Platform : RPXlite DW(EP 823 H1 DW)
+
+1. From U-Boot to PlanetCore
+
+Utilities : PlanetCore Boot Loader - PCL200.mot
+
+[root@sam tftpboot]# ppc_8xx-objcopy -O ppcboot
+PCL200.mot pcl200.bin
+
+[Target Operation]
+u-boot>t 100000 pcl200.bin
+u-boot>go 0x100000
+## Starting application at 0x00100000 ...
+
+MPC8xx PlanetCore Flash Burner v2.00
+Copyright 2001 Embedded Planet.  All rights reserved.
+
+Construct Flash Device.....done.
+
+
+Program MPC8xx PlanetCore Boot Loader v2.00
+Built Sep 19, 2001 at 14:34:42
+Image located from FC000000 to FC01B5D1.
+(Skipping an image, only loading low boot image)
+
+Low boot board detected, skipping high boot image.
+Erasing, programming and verifying will start in 20
+seconds
+Press P to start immediately or ESC to cancel
+Press Space or Enter for more options.
+..............
+
+Erasing
+Programming
+FLASH programmed successfully!
+Press R to induce a hard reset
+
+MPC8xx PlanetCore Boot Loader v2.00
+Copyright 2001 Embedded Planet.  All rights reserved.
+DRAM available size = 64 MB
+wvCV
+DRAM OK
+>
+
+2. From PlanetCore to U-Boot
+
+Utilities : PlanetCore FLASH Burner - PCB200.mot
+
+Use Flash Burner to finish the work:
+
+First, TFTP the U-Boot image file to RAM; For example,
+RPXlite_DW.bin to 0x400000
+Second, TFTP FLASH Burner to RAM; For example,
+0x100000
+Third, run the FLASH Burner and Program the U-Boot
+image into the correct location in FLASH.
+
+[Target Operation]
+MPC8xx PlanetCore Boot Loader v2.00
+Copyright 2001 Embedded Planet.  All rights reserved.
+DRAM available size = 64 MB
+wvCV
+DRAM OK
+>t
+Load using tftp via Ethernet
+Enter server IP address <172.16.115.6> :
+Enter server filename   <PCL200.mot> : RPXlite_DW.bin
+Enter (B)inary or (S)record input mode <S> : B
+Enter address offset  : <00400000 hex> :
+
+Total bytes = 120096 in 232184 uSecs
+Loaded addresses 00400000 through 0041D51F.
+Start address = 00400000
+>t
+Load using tftp via Ethernet
+Enter server IP address <172.16.115.6> :
+Enter server filename   <RPXlite_DW.bin> : PCB200.mot
+Enter (B)inary or (S)record input mode <B> : S
+Enter address offset  : <00000000 hex> :
+.512.1024..2048....4096.....
+Total bytes = 326280 in 2570249 uSecs
+Loaded addresses 00100000 through 0011BB51.
+Start address = 00100000
+>go
+[Go 00100000]
+
+MPC8xx PlanetCore Flash Burner v2.00
+Copyright 2001 Embedded Planet.  All rights reserved.
+
+Construct Flash Device.....done.
+
+Bad start address
+Start = 0xFFFFFFFF, target = 0xFFFFFFFF, length =
+0xFFFFFFFF
+Forcing Menu Interface
+
+h[elp]     Show commands.
+c[ode]     Show information on code to be loaded.
+di[splay]  Display all flash sections.
+du[mp]     Dump memory. d ? for more info.
+e[rase]    Erase flash sections.
+f[ill]     Fill flash sections.
+im[age]    Toggle load high, low, or both flash
+images.
+in[fo]     Show flash information.
+ma[p]      Show memory map.
+mo[dify]   Modify memory.  m ? for more info.
+p[rogram]  Erase, program, and verify now.
+reset      Restart the loader.
+s[how]     Show flash sections to erase and program.
+t[est]     Test flash sections.
+q[uit]     Quit without programming.
+#program 400000 ff000000 1D51F
+doProgram( 400000 ff000000 1D51F )
+
+Start = 0x00400000, target = 0xFF000000, length =
+0x0001D51F
+Erasing sector 0xFF000000, length 0x008000.
+Erasing sector 0xFF008000, length 0x008000.
+Erasing sector 0xFF010000, length 0x008000.
+Erasing sector 0xFF018000, length 0x008000.
+Programming FF000000 through FF01D51E
+FLASH programmed successfully!
+Press R to induce a hard reset
+
+Forcing Hard Reset by MachineCheck and
+ResetOnCheckstop...
+
+U-Boot 1.1.2 (Aug 29 2004 - 15:11:27)
+
+CPU:   PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
+D-Cache
+Board: RPXlite_DW
+DRAM:  64 MB
+FLASH: 16 MB
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   SCC ETHERNET
+u-boot>
+
+-------------------------------------------------
+
+Well, sometimes network function of PlanetCore couldn't work when
+switching from U-Boot to PlanetCore. For example, you couldn't
+download a file from HOST PC via TFTP. Don't worry, just restart your
+HOST PC and everything would work as smooth as clockwork. I don't
+know the reason WHY:-)
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Merry Christmas and Happy New Year!
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+=====
+Best regards,
+
+Sam
diff --git a/u-boot/doc/README.Purple b/u-boot/doc/README.Purple
new file mode 100644
index 0000000..0098e26
--- /dev/null
+++ b/u-boot/doc/README.Purple
@@ -0,0 +1,84 @@
+Installation Instructions:
+--------------------------
+
+1. Put the s2 switch into the following position:
+
+	Off On
+	------
+	|x   |
+	|   x|
+	|x   |
+	|   X|
+	------
+
+   Put the s3 switch into the following position:
+
+	Off On
+	------
+	| x  |
+	| x  |
+	|   x|
+	|   x|
+	------
+
+   Put the s4 switch into the following position:
+
+	Off On
+	------
+	|x   |
+	|x   |
+	|x   |
+	|x   |
+	|x   |
+	|   x|
+	|   x|
+	|x   |
+	------
+
+2. Connect to the serial console and to the BDI. Power on. On the
+   serial line, you should see:
+
+	PURPLE@1.2>
+
+3. Type '8'. No echo will be displayed. In response, you should get:
+
+	7A(pass)
+
+4. From BDI, enter command:
+
+	mmw 0xb800d860 0x0042c7ff
+
+5. Then, from BDI:
+
+	erase 0xB0000000
+	erase 0xB0008000
+	erase 0xB000C000
+	erase 0xB0010000
+	erase 0xB0020000
+
+	prog 0xB0000000 <u-boot.bin> bin
+
+6. Power off. Restore the original S2 switch position:
+
+	Off On
+	------
+	|   x|
+	|   x|
+	|x   |
+	|   X|
+	------
+
+   Power on.  U-Boot should come up.
+
+
+Implementation Notes:
+---------------------
+
+Due to the RAM/flash bus arbitration problem the suggested workaround
+had to be implemented. It works okay. On the downside is that you
+can't really check whether 'erase' is complete by polling flash as it
+is usually done. Instead, the flash driver simply waits for a given
+time and assumes that erase then has passed. This behaviour is
+identical to what the VxWorks driver does; also, the same timeout (6
+seconds) was chosen. Note that this timeout applies for each erase
+operation, i. e. per erased sector.
diff --git a/u-boot/doc/README.RPXClassic b/u-boot/doc/README.RPXClassic
new file mode 100644
index 0000000..5344cc6
--- /dev/null
+++ b/u-boot/doc/README.RPXClassic
@@ -0,0 +1,19 @@
+# Porting U-Boot onto RPXClassic LF_BW31 board
+# Written by Pierre AUBERT
+# E-Mail  p.aubert@staubli.com
+# Stäubli Faverges - <www.staubli.com>
+#
+# Sept. 20 2001
+#
+# Cross compile: Montavista Hardhat ported on HP-UX 10.20
+#
+
+Flash memories : AM29DL323B (2 banks flash memories) 16 Mb from 0xff000000
+DRAM : 16 Mb from 0
+NVRAM : 512 kb from 0xfa000000
+
+
+- environment is stored in NVRAM
+- Mac address is read from EEPROM
+- ethernet on SCC1 or fast ethernet on FEC are running (depending on the
+  configuration flag CONFIG_FEC_ENET)
diff --git a/u-boot/doc/README.RPXlite b/u-boot/doc/README.RPXlite
new file mode 100644
index 0000000..3ca6711
--- /dev/null
+++ b/u-boot/doc/README.RPXlite
@@ -0,0 +1,877 @@
+# Porting U-Boot onto RPXlite board
+# Written by Yoo. Jonghoon
+# E-Mail : yooth@ipone.co.kr
+# IP ONE Inc.
+
+# Since 2001. 1. 29
+
+# Shell : bash
+# Cross-compile tools : Montavista Hardhat
+# Debugging tools : Windriver VisionProbe (PowerPC BDM)
+# ppcboot ver. : ppcboot-0.8.1
+
+###############################################################
+#	1. Hardware setting
+###############################################################
+
+1.1. Board, BDM settings
+	Install board, BDM, connect each other
+
+1.2. Save Register value
+	Boot with board-on monitor program and save the
+	register values with BDM.
+
+1.3. Configure flash programmer
+	Check flash memory area in the memory map.
+	0xFFC00000 - 0xFFFFFFFF
+
+	Boot monitor program is at
+	0xFFF00000
+
+	You can program on-board flash memory with VisionClick
+	flash programmer. Set the target flash device as:
+
+	29DL800B
+
+	(?) The flash memory device in the board *is* 29LV800B,
+		but I cannot program it with '29LV800B' option.
+		(in VisionClick flash programming tools)
+		I don't know why...
+
+1.4. Save boot monitor program *IMPORTANT*
+	Upload boot monitor program from board to file.
+	boot monitor program starts at 0xFFF00000
+
+1.5. Test flash memory programming
+	Try to erase boot program in the flash memory,
+	and re-write them.
+	*WARNING* YOU MUST SAVE BOOT PROGRAM TO FILE
+		BEFORE ERASING FLASH
+
+###############################################################
+#	2. U-Boot setting
+###############################################################
+
+2.1. Download U-Boot tarball at
+	ftp://ftp.denx.de
+	(The latest version is ppcboot-0.8.1.tar.bz2)
+
+	To extract the archive use the following syntax :
+	> bzip2 -cd ppcboot-0.8.1.tar.bz2 | tar xf -
+
+2.2. Add the following lines in '.profile'
+	export PATH=$PATH:/opt/hardhat/devkit/ppc/8xx/bin
+
+2.3. Make board specific config, for example:
+	> cd ppcboot-0.8.1
+	> make TQM860L_config
+
+	Now we can build ppcboot bin files.
+	After make all, you must see these files in your
+	ppcboot root directory.
+
+	ppcboot
+	ppcboot.bin
+	ppcboot.srec
+	ppcboot.map
+
+2.4. Make your own board directory into the
+	ppcboot-0.8.1/board
+	and make your board-specific files here.
+
+	For exmanple, tqm8xx files are composed of
+	.depend : Nothing
+	Makefile : To make config file
+	config.mk : Sets base address
+	flash.c : Flash memory control files
+	ppcboot.lds : linker(ld) script? (I don't know this yet)
+	tqm8xx.c : DRAM control and board check routines
+
+	And, add your board config lines in the
+	ppcboot-0.8.1/Makefile
+
+	Finally, add config_(your board).h file in the
+	ppcboot-0.8.1/include/
+
+	I've made board/rpxlite directory, and just copied
+	tqm8xx settings for now.
+
+	Rebuild ppcboot for rpxlite board:
+	> make rpxlite_config
+	> make
+
+###############################################################
+#	3. U-Boot porting
+###############################################################
+
+3.1. My RPXlite files are based on tqm8xx board files.
+	> cd board
+	> cp -r tqm8xx RPXLITE
+	> cd RPXLITE
+	> mv tqm8xx.c RPXLITE.c
+	> cd ../../include
+	> cp config_tqm8xx.h config_RPXLITE.h
+
+3.2. Modified files are:
+	board/RPXLITE/RPXLITE.c		/* DRAM-related routines */
+	board/RPXLITE/flash.c		/* flash-related routines */
+	board/RPXLITE/config.mk		/* set text base address */
+	arch/powerpc/cpu/mpc8xx/serial.c /* board specific register setting */
+	include/config_RPXLITE.h	/* board specific registers */
+
+	See 'reg_config.txt' for register values in detail.
+
+###############################################################
+#	4. Running Linux
+###############################################################
+
+
+###############################################################
+#	Misc Information
+###############################################################
+
+mem_config.txt:
+===============
+
+Flash memory device : AM29LV800BB (1Mx8Bit) x 4 device
+manufacturer id : 01     (AMD)
+device id       : 5B     (AM29LV800B)
+size            : 4Mbyte
+sector #        : 19
+
+Sector information :
+
+number   start addr.     size
+00       FFC0_0000       64
+01       FFC1_0000       32
+02       FFC1_8000       32
+03       FFC2_0000       128
+04       FFC4_0000       256
+05       FFC8_0000       256
+06       FFCC_0000       256
+07       FFD0_0000       256
+08       FFD4_0000       256
+09       FFD8_0000       256
+10       FFDC_0000       256
+11       FFE0_0000       256
+12       FFE4_0000       256
+13       FFE8_0000       256
+14       FFEC_0000       256
+15       FFF0_0000       256
+16       FFF4_0000       256
+17       FFF8_0000       256
+18       FFFC_0000       256
+
+
+reg_config.txt:
+===============
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	SIU (System Interface Unit) */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+
+
+/*### IMMR */
+/*### Internal Memory Map Register */
+/*### Chap. 11.4.1 */
+
+	ISB		= 0xFA20		/* Set the Immap base = 0xFA20 0000 */
+	PARTNUM = 0x21
+	MASKNUM = 0x00
+
+	=> 0xFA20 2100
+
+---------------------------------------------------------------------
+
+/*### SIUMCR */
+/*### SIU Module Configuration Register */
+/*### Chap. 11.4.2 */
+/*### Offset : 0x0000 0000 */
+
+	EARB	= 0
+	EARP	= 0
+	DSHW	= 0
+	DBGC	= 0
+	DBPC	= 0
+	FRC		= 0
+	DLK		= 0
+	OPAR	= 0
+	PNCS	= 0
+	DPC		= 0
+	MPRE	= 0
+	MLRC	= 10		/* ~KR/~RETRY/~IRQ4/SPKROUT functions as ~KR/~TRTRY */
+	AEME	= 0
+	SEME	= 0
+	BSC		= 0
+	GB5E	= 0
+	B2DD	= 0
+	B3DD	= 0
+
+	=> 0x0000 0800
+
+---------------------------------------------------------------------
+
+/*### SYPCR */
+/*### System Protection Control Register */
+/*### Chap. 11.4.3 */
+/*### Offset : 0x0000 0004 */
+
+	SWTC	= 0xFFFF	/* SW watchdog timer count = 0xFFFF */
+	BMT		= 0x06		/* BUS monitoring timing */
+	BME		= 1			/* BUS monitor enable */
+	SWF		= 1
+	SWE		= 0			/* SW watchdog disable */
+	SWRI	= 0
+	SWP		= 1
+
+	=> 0xFFFF 0689
+
+---------------------------------------------------------------------
+
+/*### TESR */
+/*### Transfer Error Status Register */
+/*### Chap. 11.4.4 */
+/*### Offset : 0x0000 0020 */
+
+	IEXT	= 0
+	ITMT	= 0
+	IPB		= 0000
+	DEXT	= 0
+	DTMT	= 0
+	DPB		= 0000
+
+	=> 0x0000 0000
+
+---------------------------------------------------------------------
+
+/*### SIPEND */
+/*### SIU Interrupt Pending Register */
+/*### Chap. 11.5.4.1 */
+/*### Offset : 0x0000 0010 */
+
+	IRQ0~IRQ7 = 0
+	LVL0~LVL7 = 0
+
+	=> 0x0000 0000
+
+---------------------------------------------------------------------
+
+/*### SIMASK */
+/*### SIU Interrupt Mask Register */
+/*### Chap. 11.5.4.2 */
+/*### Offset : 0x0000 0014 */
+
+	IRM0~IRM7 = 0		/* Mask all interrupts */
+	LVL0~LVL7 = 0
+
+	=> 0x0000 0000
+
+---------------------------------------------------------------------
+
+/*### SIEL */
+/*### SIU Interrupt Edge/Level Register */
+/*### Chap. 11.5.4.3 */
+/*### Offset : 0x0000 0018 */
+
+	ED0~ED7 = 0			/* Low level triggered */
+	WMn0~WMn7 = 0		/* Not allowed to exit from low-power mode */
+
+	=> 0x0000 0000
+
+---------------------------------------------------------------------
+
+/*### SIVEC */
+/*### SIU Interrupt Vector Register */
+/*### Chap. 11.5.4.4 */
+/*### Offset : 0x0000 001C */
+
+	INTC = 3C		/* The lowest interrupt is pending..(?) */
+
+	=> 0x3C00 0000
+
+---------------------------------------------------------------------
+
+/*### SWSR */
+/*### Software Service Register */
+/*### Chap. 11.7.1 */
+/*### Offset : 0x0000 001E */
+
+	SEQ = 0
+
+	=> 0x0000
+
+---------------------------------------------------------------------
+
+/*### SDCR */
+/*### SDMA Configuration Register */
+/*### Chap. 20.2.1 */
+/*### Offset : 0x0000 0032 */
+
+	FRZ = 0
+	RAID = 01	/* Priority level 5 (BR5) (normal operation) */
+
+	=> 0x0000 0001
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	UPMA (User Programmable Machine A) */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+
+/*### Chap. 16.6.4.1 */
+/*### Offset = 0x0000 017c */
+
+	T0  = CFFF CC24		/* Single Read */
+	T1  = 0FFF CC04
+	T2  = 0CAF CC04
+	T3  = 03AF CC08
+	T4  = 3FBF CC27		/* last */
+	T5  = FFFF CC25
+	T6  = FFFF CC25
+	T7  = FFFF CC25
+	T8  = CFFF CC24		/* Burst Read */
+	T9  = 0FFF CC04
+	T10 = 0CAF CC84
+	T11 = 03AF CC88
+	T12 = 3FBF CC27		/* last */
+	T13 = FFFF CC25
+	T14 = FFFF CC25
+	T15 = FFFF CC25
+	T16 = FFFF CC25
+	T17 = FFFF CC25
+	T18 = FFFF CC25
+	T19 = FFFF CC25
+	T20 = FFFF CC25
+	T21 = FFFF CC25
+	T22 = FFFF CC25
+	T23 = FFFF CC25
+	T24 = CFFF CC24		/* Single Write */
+	T25 = 0FFF CC04
+	T26 = 0CFF CC04
+	T27 = 03FF CC00
+	T28 = 3FFF CC27		/* last */
+	T29 = FFFF CC25
+	T30 = FFFF CC25
+	T31 = FFFF CC25
+	T32 = CFFF CC24		/* Burst Write */
+	T33 = 0FFF CC04
+	T34 = 0CFF CC80
+	T35 = 03FF CC8C
+	T36 = 0CFF CC00
+	T37 = 33FF CC27		/* last */
+	T38 = FFFF CC25
+	T39 = FFFF CC25
+	T40 = FFFF CC25
+	T41 = FFFF CC25
+	T42 = FFFF CC25
+	T43 = FFFF CC25
+	T44 = FFFF CC25
+	T45 = FFFF CC25
+	T46 = FFFF CC25
+	T47 = FFFF CC25
+	T48 = C0FF CC24		/* Refresh */
+	T49 = 03FF CC24
+	T50 = 0FFF CC24
+	T51 = 0FFF CC24
+	T52 = 3FFF CC27		/* last */
+	T53 = FFFF CC25
+	T54 = FFFF CC25
+	T55 = FFFF CC25
+	T56 = FFFF CC25
+	T57 = FFFF CC25
+	T58 = FFFF CC25
+	T59 = FFFF CC25
+	T60 = FFFF CC25		/* Exception */
+	T61 = FFFF CC25
+	T62 = FFFF CC25
+	T63 = FFFF CC25
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	UPMB */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+---------------------------------------------------------------------
+
+/*### Chap. 16.6.4.1 */
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	MEMC */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+---------------------------------------------------------------------
+
+/*### BR0 & OR0 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR0(0x0000 0100) & OR0(0x0000 0104) */
+/*### Flash memory */
+
+	BA   = 1111 1110 0000 0000 0	/* Base addr = 0xFE00 0000 */
+	AT   = 000
+	PS   = 00
+	PARE = 0
+	WP   = 0
+	MS   = 0				/* GPCM */
+	V    = 1				/* Valid */
+
+	=> 0xFE00 0001
+
+	AM            = 1111 1110 0000 0000 0	/* 32MBytes */
+	ATM           = 000
+	CSNT/SAM      = 0
+	ACS/G5LA,G5LS = 00
+	BIH           = 1			/* Burst inhibited */
+	SCY           = 0100		/* cycle length = 4 */
+	SETA          = 0
+	TRLX          = 0
+	EHTR          = 0
+
+	=> 0xFE00 0140
+
+/*### BR1 & OR1 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR1(0x0000 0108) & OR1(0x0000 010C) */
+/*### SDRAM */
+
+	BA   = 0000 0000 0000 0000 0	/* Base addr = 0x0000 0000 */
+	AT   = 000
+	PS   = 00
+	PARE = 0
+	WP   = 0
+	MS   = 1				/* UPMA */
+	V    = 1				/* Valid */
+
+	=> 0x0000 0081
+
+	AM            = 1111 1110 0000 0000	/* 32MBytes */
+	ATM           = 000
+	CSNT/SAM      = 1
+	ACS/G5LA,G5LS = 11
+	BIH           = 0
+	SCY           = 0000		/* cycle length = 0 */
+	SETA          = 0
+	TRLX          = 0
+	EHTR          = 0
+
+	=> 0xFE00 0E00
+
+/*### BR2 & OR2 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR2(0x0000 0110) & OR2(0x0000 0114) */
+
+	BR2 & OR2 = 0x0000 0000		/* Not used */
+
+/*### BR3 & OR3 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR3(0x0000 0118) & OR3(0x0000 011C) */
+/*### BCSR */
+
+	BA   = 1111 1010 0100 0000 0	/* Base addr = 0xFA40 0000 */
+	AT   = 000
+	PS   = 00
+	PARE = 0
+	WP   = 0
+	MS   = 0				/* GPCM */
+	V    = 1				/* Valid */
+
+	=> 0xFA40 0001
+
+	AM            = 1111 1111 0111 1111 1	/* (?) */
+	ATM           = 000
+	CSNT/SAM      = 1
+	ACS/G5LA,G5LS = 00
+	BIH           = 1			/* Burst inhibited */
+	SCY           = 0001		/* cycle length = 1 */
+	SETA          = 0
+	TRLX          = 0
+
+	=> 0xFF7F 8910
+
+/*### BR4 & OR4 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR4(0x0000 0120) & OR4(0x0000 0124) */
+/*### NVRAM & SRAM */
+
+	BA   = 1111 1010 0000 0000 0	/* Base addr = 0xFA00 0000 */
+	AT   = 000
+	PS   = 01
+	PARE = 0
+	WP   = 0
+	MS   = 0				/* GPCM */
+	V    = 1				/* Valid */
+
+	=> 0xFA00 0401
+
+	AM            = 1111 1111 1111 1000 0	/* 8MByte */
+	ATM           = 000
+	CSNT/SAM      = 1
+	ACS/G5LA,G5LS = 00
+	BIH           = 1			/* Burst inhibited */
+	SCY           = 0111		/* cycle length = 7 */
+	SETA          = 0
+	TRLX          = 0
+
+	=> 0xFFF8 0970
+
+/*### BR5 & OR5 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR2(0x0000 0128) & OR2(0x0000 012C) */
+
+	BR5 & OR5 = 0x0000 0000		/* Not used */
+
+/*### BR6 & OR6 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR2(0x0000 0130) & OR2(0x0000 0134) */
+
+	BR6 & OR6 = 0x0000 0000		/* Not used */
+
+/*### BR7 & OR7 */
+/*### Base Registers & Option Registers */
+/*### Chap. 16.4.1 & 16.4.2 */
+/*### Offset : BR7(0x0000 0138) & OR7(0x0000 013C) */
+
+	BR7 & OR7 = 0x0000 0000		/* Not used */
+
+/*### MAR */
+/*### Memory Address Register */
+/*### Chap. 16.4.7 */
+/*### Offset : 0x0000 0164 */
+
+	MA = External memory address
+
+/*### MCR */
+/*### Memory Command Register */
+/*### Chap. 16.4.5 */
+/*### Offset : 0x0000 0168 */
+
+	OP   = xx			/* Command op code */
+	UM   = 1			/* Select UPMA */
+	MB   = 001			/* Select CS1 */
+	MCLF = xxxx			/* Loop times */
+	MAD  = xx xxxx		/* Memory array index */
+
+/*### MAMR */
+/*### Machine A Mode Register */
+/*### Chap. 16.4.4 */
+/*### Offset : 0x0000 0170 */
+
+	PTA = 0101 1000
+	PTAE = 1			/* Periodic timer A enabled */
+	AMA = 010
+	DSA = 00
+	G0CLA = 000
+	GPLA4DIS = 1
+	RLFA = 0100
+	WLFA = 0011
+	TLFA = 0000
+
+	=> 0x58A0 1430
+
+/*### MBMR */
+/*### Machine B Mode Register */
+/*### Chap. 16.4.4 */
+/*### Offset : 0x0000 0174 */
+
+	PTA = 0100 1110
+	PTAE = 0			/* Periodic timer B disabled */
+	AMA = 000
+	DSA = 00
+	G0CLA = 000
+	GPLA4DIS = 1
+	RLFA = 0000
+	WLFA = 0000
+	TLFA = 0000
+
+	=> 0x4E00 1000
+
+/*### MSTAT */
+/*### Memory Status Register */
+/*### Chap. 16.4.3 */
+/*### Offset : 0x0000 0178 */
+
+	PER0~PER7 = Parity error
+	WPER      = Write protection error
+
+	=> 0x0000
+
+/*### MPTPR */
+/*### Memory Periodic Timer Prescaler Register */
+/*### Chap. 16.4.8 */
+/*### Offset : 0x0000 017A */
+
+	PTP = 0000 1000		/* Divide by 8 */
+
+	=> 0x0800
+
+/*### MDR */
+/*### Memory Data Register */
+/*### Chap. 16.4.6 */
+/*### Offset : 0x0000 017C */
+
+	MD = Memory data contains the RAM array word
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	TIMERS */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+---------------------------------------------------------------------
+
+/*### TBREFx */
+/*### Timebase Reference Registers */
+/*### Chap. 11.9.2 */
+/*### Offset : TBREFF0(0x0000 0204)/TBREFF1(0x0000 0208) */
+/*### (Locked) */
+
+	TBREFF0 = 0xFFFF FFFF
+	TBREFF1 = 0xFFFF FFFF
+
+---------------------------------------------------------------------
+
+/*### TBSCR */
+/*### Timebase Status and Control Registers */
+/*### Chap. 11.9.3 */
+/*### Offset : 0x0000 0200 */
+/*### (Locked) */
+
+	TBIRQ = 00000000
+	REF0  = 0
+	REF1  = 0
+	REFE0 = 0			/* Reference interrupt disable */
+	REFE1 = 0
+	TBF   = 1
+	TBE   = 1			/* Timebase enable */
+
+	=> 0x0003
+
+---------------------------------------------------------------------
+
+/*### RTCSC */
+/*### Real-Time Clock Status and Control Registers */
+/*### Chap. 11.10.1 */
+/*### Offset : 0x0000 0220 */
+/*### (Locked) */
+
+	RTCIRQ = 00000000
+	SEC = 1
+	ALR = 0
+	38K = 0				/* PITRTCLK is driven by 32.768KHz */
+	SIE = 0
+	ALE = 0
+	RTF = 0
+	RTE = 1				/* Real-Time clock enabled */
+
+	=> 0x0081
+
+---------------------------------------------------------------------
+
+/*### RTC */
+/*### Real-Time Clock Registers */
+/*### Chap. 11.10.2 */
+/*### Offset : 0x0000 0224 */
+/*### (Locked) */
+
+	RTC = Real time clock measured in second
+
+---------------------------------------------------------------------
+
+/*### RTCAL */
+/*### Real-Time Clock Alarm Registers */
+/*### Chap. 11.10.3 */
+/*### Offset : 0x0000 022C */
+/*### (Locked) */
+
+	ALARM = 0xFFFF FFFF
+
+---------------------------------------------------------------------
+
+/*### RTSEC */
+/*### Real-Time Clock Alarm Second Registers */
+/*### Chap. 11.10.4 */
+/*### Offset : 0x0000 0228 */
+/*### (Locked) */
+
+	COUNTER = Counter bits(fraction of a second)
+
+---------------------------------------------------------------------
+
+/*### PISCR */
+/*### Periodic Interrupt Status and Control Register */
+/*### Chap. 11.11.1 */
+/*### Offset : 0x0000 0240 */
+/*### (Locked) */
+
+	PIRQ = 0
+	PS   = 0		/* Write 1 to clear */
+	PIE  = 0
+	PITF = 1
+	PTE  = 0		/* PIT disabled */
+
+---------------------------------------------------------------------
+
+/*### PITC */
+/*### PIT Count Register */
+/*### Chap. 11.11.2 */
+/*### Offset : 0x0000 0244 */
+/*### (Locked) */
+
+	PITC = PIT count
+
+---------------------------------------------------------------------
+
+/*### PITR */
+/*### PIT Register */
+/*### Chap. 11.11.3 */
+/*### Offset : 0x0000 0248 */
+/*### (Locked) */
+
+	PIT = PIT count		/* Read only */
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	CLOCKS */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+---------------------------------------------------------------------
+
+
+---------------------------------------------------------------------
+
+/*### SCCR */
+/*### System Clock and Reset Control Register */
+/*### Chap. 15.6.1 */
+/*### Offset : 0x0000 0280 */
+/*### (Locked) */
+
+	COM    = 11		/* Clock output disabled */
+	TBS    = 1		/* Timebase frequency source is GCLK2 divided by 16 */
+	RTDIV  = 0		/* The clock is divided by 4 */
+	RTSEL  = 0		/* OSCM(Crystal oscillator) is selected */
+	CRQEN  = 0
+	PRQEN  = 0
+	EBDF   = 00		/* CLKOUT is GCLK2 divided by 1 */
+	DFSYNC = 00		/* Divided by 1 (normal operation) */
+	DFBRG  = 00		/* Divided by 1 (normal operation) */
+	DFNL   = 000
+	DFNH   = 000
+
+	=> 0x6200 0000
+
+---------------------------------------------------------------------
+
+/*### PLPRCR */
+/*### PLL, Low-Power, and Reset Control Register */
+/*### Chap. 15.6.2 */
+/*### Offset : 0x0000 0284 */
+/*### (Locked) */
+
+	MF    = 0x005	/* 48MHz (?) (  = 8MHz * (MF+1) ) */
+	SPLSS = 0
+	TEXPS = 0
+	TMIST = 0
+	CSRC  = 0		/* The general system clock is generated by the DFNH field */
+	LPM   = 00		/* Normal high/normal low mode */
+	CSR   = 0
+	LOLRE = 0
+	FIOPD = 0
+
+	=> 0x0050 0000
+
+---------------------------------------------------------------------
+
+/*### RSR */
+/*### Reset Status Register */
+/*### Chap. 12.2 */
+/*### Offset : 0x0000 0288 */
+/*### (Locked) */
+
+	EHRS  = External hard reset
+	ESRS  = External soft reset
+	LLRS  = Loss-of-lock reset
+	SWRS  = Software watchdog reset
+	CSRS  = Check stop reset
+	DBHRS = Debug port hard reset
+	DBSRS = Debug port soft reset
+	JTRS  = JTAG reset
+
+
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+/*	DMA */
+/* */
+/*------------------------------------------------------------------- */
+/*------------------------------------------------------------------- */
+---------------------------------------------------------------------
+
+/*### SDSR */
+/*### SDMA Status Register */
+/*### Chap. 20.2.2 */
+/*### Offset : 0x0000 0908 */
+
+	SBER = 0	/* SDMA channel bus error */
+	DSP2 = 0	/* DSP chain2 (Tx) interrupt */
+	DSP1 = 0	/* DSP chain1 (Rx) interrupt */
+
+	=> 0x00
+
+/*### SDMR */
+/*### SDMA Mask Register */
+/*### Chap. 20.2.3 */
+/*### Offset : 0x0000 090C */
+
+	SBER = 0
+	DSP2 = 0
+	DSP1 = 0	/* All interrupts are masked */
+
+	=> 0x00
+
+/*### SDAR */
+/*### SDMA Address Register */
+/*### Chap. 20.2.4 */
+/*### Offset : 0x0000 0904 */
+
+	AR = 0xxxxx xxxx	/* current system address */
+
+	=> 0xFA20 23AC
+
+/*### IDSRx */
+/*### IDMA Status Register */
+/*### Chap. 20.3.3.2 */
+/*### Offset : IDSR1(0x0000 0910) & IDSR2(0x0000 0918) */
+
+	AD   = 0
+	DONE = 0
+	OB   = 0
+
+	=> 0x00
+
+/*### IDMRx */
+/*### IDMA Mask Register */
+/*### Chap. 20.3.3.3 */
+/*### Offset : IDMR1(0x0000 0914) & IDMR2(0x0000 091C) */
+
+	AD   = 0
+	DONE = 0
+	OB   = 0
diff --git a/u-boot/doc/README.SBC8560 b/u-boot/doc/README.SBC8560
new file mode 100644
index 0000000..c4b6422
--- /dev/null
+++ b/u-boot/doc/README.SBC8560
@@ -0,0 +1,57 @@
+The port was tested on Wind River System Sbc8560 board
+<www.windriver.com>. U-Boot was installed on the flash memory of the
+CPU card (no the SODIMM).
+
+NOTE: Please configure uboot compile to the proper PCI frequency and
+setup the appropriate DIP switch settings.
+
+SBC8560 board:
+
+Make sure boards switches are set to their appropriate conditions.
+Refer to the Engineering Reference Guide ERG-00300-002. Of particular
+importance are: 1) the settings for JP4 (JP4 1-3 and 2-4), which
+select the on-board FLASH device (Intel 28F128Jx); 2) The settings
+for the Clock SW9 (33 MHz or 66 MHz).
+
+	Note:	SW9 Settings: 66 MHz
+		4:1 ratio CCB clocks:SYSCLK
+		3:1 ration e500 Core:CCB
+		pos1 - on, pos2 - on, pos3 - off, pos4 - on, pos5 - off, pos6 - on
+	Note:	SW9 Settings: 33 MHz
+		8:1 ratio CCB clocks:SYSCLK
+		3:1 ration e500 Core:CCB
+		pos1 - on, pos2 - on, pos3 - on, pos4 - off, pos5 - off, pos6 - on
+
+
+Flashing the FLASH device with the "Wind River ICE":
+
+1) Properly connect and configure the Wind River ICE to the target
+   JTAG port. This includes running the SBC8560 register script. Make
+   sure target memory can be read and written.
+
+2) Build the u-boot image:
+	make distclean
+	make SBC8560_66_config or SBC8560_33_config
+	make CROSS_COMPILE=.../ELDK3.0/ppc_8xx-/ all
+
+   Note: reference is made to the ELDK3.0 compiler. Further, it seems
+	 the ppc_8xx compiler is required for the 85xx (no 85xx
+	 designated compiler in ELDK3.0)
+
+3) Convert the uboot (.elf) file to a uboot.bin file (using
+   visionClick converter). The bin file should be converted from
+   fffc0000 to ffffffff
+
+4) Setup the Flash Utility (tools menu) for:
+
+   Do a "dc clr" [visionClick] to load the default register settings
+   Determine the clock speed of the PCI bus and set SW9 accordingly
+	Note: the speed of the PCI bus defaults to the slowest PCI card
+   PlayBack the "default" register file for the SBC8560
+   Select the uboot.bin file with zero bias
+   Select the initialize Target prior to programming
+   Select the V28F640Jx (8192 x 8) 1 device FLASH Algorithm
+   Select the erase base address from FFFC0000 to FFFFFFFF
+   Select the start address from 0 with size of 4000
+
+5) Erase and Program
diff --git a/u-boot/doc/README.SNTP b/u-boot/doc/README.SNTP
new file mode 100644
index 0000000..9edc957
--- /dev/null
+++ b/u-boot/doc/README.SNTP
@@ -0,0 +1,17 @@
+To use SNTP support, add define CONFIG_CMD_SNTP to the
+configuration file of the board.
+
+The "sntp" command gets network time from NTP time server and
+syncronize RTC of the board. This command needs the command line
+parameter of server's IP address or environment variable
+"ntpserverip". The network time is sent as UTC. So if you want to
+set local time to RTC, set the offset in second from UTC to the
+enviroment variable "time offset".
+
+If the DHCP server provides time server's IP or time offset, you
+don't need to set the above environment variables yourself.
+
+Current limitations of SNTP support:
+1. The roundtrip time is ignored.
+2. Only the 1st NTP server IP, in the option ntp-servers of DHCP, will
+   be used.
diff --git a/u-boot/doc/README.Sandpoint8240 b/u-boot/doc/README.Sandpoint8240
new file mode 100644
index 0000000..a41b69a
--- /dev/null
+++ b/u-boot/doc/README.Sandpoint8240
@@ -0,0 +1,394 @@
+The port was tested on a Sandpoint 8240 X3 board, with U-Boot
+installed in the flash memory of the CPU card. Please use the
+following DIP switch settings:
+
+Motherboard:
+
+SW1.1: on	SW1.2: on	SW1.3: on	SW1.4: on
+SW1.5: on	SW1.6: on	SW1.7: on	SW1.8: on
+
+SW2.1: on	SW2.2: on	SW2.3: on	SW2.4: on
+SW2.5: on	SW2.6: on	SW2.7: on	SW2.8: on
+
+
+CPU Card:
+
+SW2.1: OFF	SW2.2: OFF	SW2.3: on	SW2.4: on
+SW2.5: OFF	SW2.6: OFF	SW2.7: OFF	SW2.8: OFF
+
+SW3.1: OFF	SW3.2: on	SW3.3: OFF	SW3.4: OFF
+SW3.5: on	SW3.6: OFF	SW3.7: OFF	SW3.8: on
+
+
+The followind detailed description of installation and initial steps
+with U-Boot and QNX was provided by Jim Sandoz <sandoz@lucent.com>:
+
+
+Directions for installing U-Boot on Sandpoint+Unity8240
+using the Abatron BDI2000 BDM/JTAG debugger ...
+
+Background and Reference info:
+http://u-boot.sourceforge.net/
+http://www.abatron.ch/
+http://www.abatron.ch/BDI/bdihw.html
+http://www.abatron.ch/DataSheets/BDI2000.pdf
+http://www.abatron.ch/Manuals/ManGdbCOP-2000C.pdf
+http://e-www.motorola.com/collateral/SPX3UM.pdf
+http://e-www.motorola.com/collateral/UNITYX4CONFIG.pdf
+
+
+Connection Diagram:
+					    ===========
+ ===                     =====             |-----      |
+|   | <---------------> |     |            |     |     |
+|PC |       rs232       | BDI |=============[]   |     |
+|   |                   |2000 |  BDM probe |     |     |
+|   | <---------------> |     |            |-----      |
+ ===       ethernet      =====             |           |
+					   |           |
+					    ===========
+					 Sandpoint X3 with
+					  Unity 8240 proc
+
+
+PART 1)
+  DIP Switch Settings:
+
+Sandpoint X3 8240 processor board DIP switch settings, with
+U-Boot to be installed in the flash memory of the CPU card:
+
+Motorola Sandpoint X3 Motherboard:
+SW1.1: on	SW1.2: on	SW1.3: on	SW1.4: on
+SW1.5: on	SW1.6: on	SW1.7: on	SW1.8: on
+SW2.1: on	SW2.2: on	SW2.3: on	SW2.4: on
+SW2.5: on	SW2.6: on	SW2.7: on	SW2.8: on
+
+Motorola Unity 8240 CPU Card:
+SW2.1: OFF	SW2.2: OFF	SW2.3: on	SW2.4: on
+SW2.5: OFF	SW2.6: OFF	SW2.7: OFF	SW2.8: OFF
+SW3.1: OFF	SW3.2: on	SW3.3: OFF	SW3.4: OFF
+SW3.5: on	SW3.6: OFF	SW3.7: OFF	SW3.8: on
+
+
+PART 2)
+  Connect the BDI2000 Cable to the Sandpoint/Unity 8240:
+
+BDM Pin 1 on the Unity 8240 processor board is towards the
+PCI PMC connectors, or away from the socketed SDRAM, i.e.:
+
+  ====================
+  | ---------------- |
+  | |    SDRAM     | |
+  | |              | |
+  | ---------------- |
+  | |~|              |
+  | |B|       ++++++ |
+  | |D|       + uP + |
+  | |M|       +8240+ |
+  |  ~ 1      ++++++ |
+  |                  |
+  |                  |
+  |                  |
+  | PMC conn ======  |
+  |   =====  ======  |
+  |                  |
+  ====================
+
+
+PART 3)
+  Setting up the BDI2000, and preparing for TCP/IP network comms:
+
+Connect the BDI2000 to the PC using the supplied serial cable.
+Download the BDI2000 software and install it using setup.exe.
+
+[Note: of course you  can  also  use  the  Linux  command  line  tool
+"bdisetup"  to  configure  your BDI2000 - the sources are included on
+the floppy disk that comes with your BDI2000. Just in case you  don't
+have any Windows PC's - like me :-)   -- wd ]
+
+Power up the BDI2000; then follow directions to assign the IP
+address and related network information.  Note that U-Boot
+will be loaded to the Sandpoint via tftp.  You need to either
+use the Abatron-provided tftp application or provide a tftp
+server (e.g. Linux/Solaris/*BSD) somewhere on your network.
+Once the IP address etc are assigned via the RS232 port,
+further communication with the BDI2000 will happen via the
+ethernet connection.
+
+PART 4)
+  Making a TCP/IP network connection to the Abatron BDI2000:
+
+Telnet to the Abatron BDI2000.  Assuming that all of the
+networking info was loaded via RS232 correctly, you will see
+the following (scrolling):
+
+- TARGET: waiting for target Vcc
+- TARGET: waiting for target Vcc
+
+
+PART 5)
+  Power up the target Sandpoint:
+If the BDM connections are correct, the following will now appear:
+
+- TARGET: waiting for target Vcc
+- TARGET: waiting for target Vcc
+- TARGET: processing power-up delay
+- TARGET: processing user reset request
+- BDI asserts HRESET
+- Reset JTAG controller passed
+- Bypass check: 0x55 => 0xAA
+- Bypass check: 0x55 => 0xAA
+- JTAG exists check passed
+- Target PVR is 0x00810101
+- COP status is 0x01
+- Check running state passed
+- BDI scans COP freeze command
+- BDI removes HRESET
+- COP status is 0x05
+- Check stopped state passed
+- Check LSRL length passed
+- BDI sets breakpoint at 0xFFF00100
+- BDI resumes program execution
+- Waiting for target stop passed
+- TARGET: Target PVR is 0x00810101
+- TARGET: reseting target passed
+- TARGET: processing target startup ....
+- TARGET: processing target startup passed
+BDI>
+
+
+PART 6)
+  Erase the current contents of the flash memory:
+
+BDI>era 0xFFF00000
+    Erasing flash at 0xfff00000
+    Erasing flash passed
+BDI>era 0xFFF04000
+    Erasing flash at 0xfff04000
+    Erasing flash passed
+BDI>era 0xFFF06000
+    Erasing flash at 0xfff06000
+    Erasing flash passed
+BDI>era 0xFFF08000
+    Erasing flash at 0xfff08000
+    Erasing flash passed
+BDI>era 0xFFF10000
+    Erasing flash at 0xfff10000
+    Erasing flash passed
+BDI>era 0xFFF20000
+    Erasing flash at 0xfff20000
+    Erasing flash passed
+
+
+PART 7)
+  Program the flash memory with the U-Boot image:
+
+BDI>prog 0xFFF00000 u-boot.bin bin
+    Programming u-boot.bin , please wait ....
+    Programming flash passed
+
+
+PART 8)
+  Connect PC to Sandpoint:
+Using a crossover serial cable, attach the PC serial port to the
+Sandpoint's COM1.  Set communications parameters to 8N1 / 9600 baud.
+
+
+PART 9)
+  Reset the Unity and begin U-Boot execution:
+
+BDI>reset
+- TARGET: processing user reset request
+- TARGET: Target PVR is 0x00810101
+- TARGET: reseting target passed
+- TARGET: processing target init list ....
+- TARGET: processing target init list passed
+
+BDI>go
+
+Now see output from U-Boot running, sent via serial port:
+
+U-Boot 1.1.4 (Jan 23 2002 - 18:29:19)
+
+CPU:   MPC8240 Revision 1.1 at 264 MHz: 16 kB I-Cache 16 kB D-Cache
+Board: Sandpoint 8240 Unity
+DRAM:  64 MB
+FLASH:  2 MB
+PCI:    scanning bus0 ...
+  bus dev fn venID devID class  rev MBAR0    MBAR1    IPIN ILINE
+  00  00  00 1057  0003  060000 13  00000008 00000000 01   00
+  00  0b  00 10ad  0565  060100 10  00000000 00000000 00   00
+  00  0f  00 8086  1229  020000 08  80000000 80000001 01   00
+In:    serial
+Out:   serial
+Err:   serial
+=>
+
+
+PART 10)
+  Set and save any required environmental variables, examples of some:
+
+=> setenv ethaddr 00:03:47:97:D0:79
+=> setenv bootfile your_qnx_image_here
+=> setenv hostname sandpointX
+=> setenv netmask 255.255.255.0
+=> setenv ipaddr 192.168.0.11
+=> setenv serverip 192.168.0.10
+=> setenv gatewayip=192.168.0.1
+=> saveenv
+Saving Enviroment to Flash...
+Un-Protected 1 sectors
+Erasing Flash...
+ done
+Erased 1 sectors
+Writing to Flash... done
+Protected 1 sectors
+=>
+
+**** Example environment: ****
+
+=> printenv
+baudrate=9600
+bootfile=telemetry
+hostname=sp1
+ethaddr=00:03:47:97:E4:6B
+load=tftp 100000 u-boot.bin
+update=protect off all;era FFF00000 FFF3FFFF;cp.b 100000 FFF00000 ${filesize};saveenv
+filesize=1f304
+gatewayip=145.17.228.1
+netmask=255.255.255.0
+ipaddr=145.17.228.42
+serverip=145.17.242.46
+stdin=serial
+stdout=serial
+stderr=serial
+
+Environment size: 332/8188 bytes
+=>
+
+here's some text useful stuff for cut-n-paste:
+setenv hostname sandpoint1
+setenv netmask 255.255.255.0
+setenv ipaddr 145.17.228.81
+setenv serverip 145.17.242.46
+setenv gatewayip 145.17.228.1
+saveenv
+
+PART 11)
+  Test U-Boot by tftp'ing new U-Boot, overwriting current:
+
+=> protect off all
+Un-Protect Flash Bank # 1
+=> tftp 100000 u-boot.bin
+eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
+ARP broadcast 1
+TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
+ gateway 145.17.228.1
+Filename 'u-boot.bin'.
+Load address: 0x100000
+Loading: #########################
+done
+Bytes transferred = 127628 (1f28c hex)
+=> era all
+Erase Flash Bank # 1
+ done
+Erase Flash Bank # 2 - missing
+=> cp.b 0x100000 FFF00000 1f28c
+Copy to Flash... done
+=> saveenv
+Saving Enviroment to Flash...
+Un-Protected 1 sectors
+Erasing Flash...
+ done
+Erased 1 sectors
+Writing to Flash... done
+Protected 1 sectors
+=> reset
+
+You can put these commands into some environment variables;
+
+=> setenv load tftp 100000 u-boot.bin
+=> setenv update protect off all\;era FFF00000 FFF3FFFF\;cp.b 100000 FFF00000 \${filesize}\;saveenv
+=> saveenv
+
+Then you just have to type "run load" then "run update"
+
+=> run load
+eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
+ARP broadcast 1
+TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
+ gateway 145.17.228.1
+Filename 'u-boot.bin'.
+Load address: 0x100000
+Loading: #########################
+done
+Bytes transferred = 127748 (1f304 hex)
+=> run update
+Un-Protect Flash Bank # 1
+Un-Protect Flash Bank # 2
+Erase Flash from 0xfff00000 to 0xfff3ffff
+ done
+Erased 7 sectors
+Copy to Flash... done
+Saving Enviroment to Flash...
+Un-Protected 1 sectors
+Erasing Flash...
+ done
+Erased 1 sectors
+Writing to Flash... done
+Protected 1 sectors
+=>
+
+
+PART 12)
+  Load OS image (ELF format) via U-Boot using tftp
+
+
+=> tftp 800000 sandpoint-simple.elf
+eth: Intel i82559 PCI EtherExpressPro @0x80000000(bus=0, device=15, func=0)
+ARP broadcast 1
+TFTP from server 145.17.242.46; our IP address is 145.17.228.42; sending through
+ gateway 145.17.228.1
+Filename 'sandpoint-simple.elf'.
+Load address: 0x800000
+Loading: #################################################################
+	 #################################################################
+	 #################################################################
+	 ########################
+done
+Bytes transferred = 1120284 (11181c hex)
+==>
+
+PART 13)
+  Begin OS image execution: (note that unless you have the
+serial parameters of your OS image set to 9600 (i.e. same as
+the U-Boot binary) you will get garbage here until you change
+the serial communications speed.
+
+=> bootelf 800000
+Loading  @ 0x001f0100 (1120028 bytes)
+## Starting application at 0x001f1d28 ...
+Replace init_hwinfo() with a board specific version
+
+Loading QNX6....
+
+Header size=0x0000009c, Total Size=0x000005c0, #Cpu=1, Type=1
+<...loader and kernel messages snipped...>
+
+Welcome to Neutrino on the Sandpoint
+#
+
+
+other information:
+
+CVS Retrieval Notes:
+
+U-Boot's SourceForge CVS repository can be checked out
+through anonymous (pserver) CVS with the following
+instruction set. The module you wish to check out must
+be specified as the modulename. When prompted for a
+password for anonymous, simply press the Enter key.
+
+cvs -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot login
+
+cvs -z6 -d:pserver:anonymous@cvs.u-boot.sourceforge.net:/cvsroot/u-boot co -P u-boot
diff --git a/u-boot/doc/README.TQM8260 b/u-boot/doc/README.TQM8260
new file mode 100644
index 0000000..93b5506
--- /dev/null
+++ b/u-boot/doc/README.TQM8260
@@ -0,0 +1,415 @@
+
+This file contains basic information on the port of U-Boot to TQM8260.
+All the changes fit in the common U-Boot infrastructure, providing a
+new TQM8260-specific entry in makefiles. To build U-Boot for TQM8260,
+type "make TQM8260_config", edit the "include/config_TQM8260.h" file
+if necessary, then type "make".
+
+
+Common file modifications:
+--------------------------
+
+The following common files have been modified by this project:
+(starting from the ppcboot-0.9.3/ directory)
+
+MAKEALL			- TQM8260 entry added
+Makefile		- TQM8260_config entry added
+arch/powerpc/cpu/mpc8260/Makefile	- soft_i2c.o module added
+arch/powerpc/cpu/mpc8260/ether_scc.c	- TQM8260-specific definitions added, an obvious
+			  bug fixed (fcr -> scr)
+arch/powerpc/cpu/mpc8260/ether_fcc.c	- TQM8260-specific definitions added
+include/flash.h		- added definitions for the AM29LV640D Flash chip
+
+
+New files:
+----------
+
+The following new files have been added by this project:
+(starting from the ppcboot-0.9.3/ directory)
+
+board/tqm8260/		  - board-specific directory
+board/tqm8260/Makefile	  - board-specific makefile
+board/tqm8260/config.mk	  - config file
+board/tqm8260/flash.c	  - flash driver (for AM29LV640D)
+board/tqm8260/ppcboot.lds - linker script
+board/tqm8260/tqm8260.c	  - ioport and memory initialization
+arch/powerpc/cpu/mpc8260/soft_i2c.c	  - software i2c EEPROM driver
+include/config_TQM8260.h  - main configuration file
+
+
+New configuration options:
+--------------------------
+
+CONFIG_TQM8260
+
+	Main board-specific option (should be defined for TQM8260).
+
+CONFIG_82xx_CONS_SMC1
+
+	If defined, SMC1 will be used as the console
+
+CONFIG_82xx_CONS_SMC2
+
+	If defined, SMC2 will be used as the console
+
+CONFIG_SYS_INIT_LOCAL_SDRAM
+
+	If defined, the SDRAM on the local bus will be initialized and
+	mapped at BR2.
+
+
+Acceptance criteria tests:
+--------------------------
+
+The following tests have been conducted to validate the port of U-Boot
+to TQM8260:
+
+1. Operation on serial console:
+
+With the CONFIG_82xx_CONS_SMC1 option defined in the main configuration file,
+the U-Boot output appeared on the serial terminal connected to COM1 as
+follows:
+
+------------------------------------------------------------------------------
+=> help
+go      - start application at address 'addr'
+run     - run commands in an environment variable
+bootm   - boot application image from memory
+bootp   - boot image via network using BootP/TFTP protocol
+tftpboot- boot image via network using TFTP protocol
+	       and env variables ipaddr and serverip
+rarpboot- boot image via network using RARP/TFTP protocol
+bootd   - boot default, i.e., run 'bootcmd'
+loads   - load S-Record file over serial line
+loadb   - load binary file over serial line (kermit mode)
+md      - memory display
+mm      - memory modify (auto-incrementing)
+nm      - memory modify (constant address)
+mw      - memory write (fill)
+cp      - memory copy
+cmp     - memory compare
+crc32   - checksum calculation
+base    - print or set address offset
+printenv- print environment variables
+setenv  - set environment variables
+saveenv - save environment variables to persistent storage
+protect - enable or disable FLASH write protection
+erase   - erase FLASH memory
+flinfo  - print FLASH memory information
+bdinfo  - print Board Info structure
+iminfo  - print header information for application image
+coninfo - print console devices and informations
+eeprom  - EEPROM sub-system
+loop    - infinite loop on address range
+mtest   - simple RAM test
+icache  - enable or disable instruction cache
+dcache  - enable or disable data cache
+reset   - Perform RESET of the CPU
+echo    - echo args to console
+version - print monitor version
+help    - print online help
+?       - alias for 'help'
+=>
+------------------------------------------------------------------------------
+
+
+2. Flash driver operation
+
+The following sequence was performed to test the "flinfo" command:
+
+------------------------------------------------------------------------------
+=> flinfo
+
+Bank # 1: AMD 29LV640D (64 M, uniform sector)
+  Size: 32 MB in 128 Sectors
+  Sector Start Addresses:
+    40000000      40040000 (RO) 40080000      400C0000      40100000
+    40140000      40180000      401C0000      40200000      40240000
+    40280000      402C0000      40300000      40340000      40380000
+    403C0000      40400000      40440000      40480000      404C0000
+    40500000      40540000      40580000      405C0000      40600000
+    40640000      40680000      406C0000      40700000      40740000
+    40780000      407C0000      40800000      40840000      40880000
+    408C0000      40900000      40940000      40980000      409C0000
+    40A00000      40A40000      40A80000      40AC0000      40B00000
+    40B40000      40B80000      40BC0000      40C00000      40C40000
+    40C80000      40CC0000      40D00000      40D40000      40D80000
+    40DC0000      40E00000      40E40000      40E80000      40EC0000
+    40F00000      40F40000      40F80000      40FC0000      41000000
+    41040000      41080000      410C0000      41100000      41140000
+    41180000      411C0000      41200000      41240000      41280000
+    412C0000      41300000      41340000      41380000      413C0000
+    41400000      41440000      41480000      414C0000      41500000
+    41540000      41580000      415C0000      41600000      41640000
+    41680000      416C0000      41700000      41740000      41780000
+    417C0000      41800000      41840000      41880000      418C0000
+    41900000      41940000      41980000      419C0000      41A00000
+    41A40000      41A80000      41AC0000      41B00000      41B40000
+    41B80000      41BC0000      41C00000      41C40000      41C80000
+    41CC0000      41D00000      41D40000      41D80000      41DC0000
+    41E00000      41E40000      41E80000      41EC0000      41F00000
+    41F40000      41F80000      41FC0000
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test the erase command:
+
+------------------------------------------------------------------------------
+=> cp 0 40080000 10
+Copy to Flash... done
+=> erase 40080000 400bffff
+Erase Flash from 0x40080000 to 0x400bffff
+.. done
+Erased 1 sectors
+=> md 40080000
+40080000: ffffffff ffffffff ffffffff ffffffff    ................
+40080010: ffffffff ffffffff ffffffff ffffffff    ................
+40080020: ffffffff ffffffff ffffffff ffffffff    ................
+40080030: ffffffff ffffffff ffffffff ffffffff    ................
+40080040: ffffffff ffffffff ffffffff ffffffff    ................
+40080050: ffffffff ffffffff ffffffff ffffffff    ................
+40080060: ffffffff ffffffff ffffffff ffffffff    ................
+40080070: ffffffff ffffffff ffffffff ffffffff    ................
+40080080: ffffffff ffffffff ffffffff ffffffff    ................
+40080090: ffffffff ffffffff ffffffff ffffffff    ................
+400800a0: ffffffff ffffffff ffffffff ffffffff    ................
+400800b0: ffffffff ffffffff ffffffff ffffffff    ................
+400800c0: ffffffff ffffffff ffffffff ffffffff    ................
+400800d0: ffffffff ffffffff ffffffff ffffffff    ................
+400800e0: ffffffff ffffffff ffffffff ffffffff    ................
+400800f0: ffffffff ffffffff ffffffff ffffffff    ................
+=> cp 0 40080000 10
+Copy to Flash... done
+=> erase 1:2
+Erase Flash Sectors 2-2 in Bank # 1
+.. done
+=> md 40080000
+40080000: ffffffff ffffffff ffffffff ffffffff    ................
+40080010: ffffffff ffffffff ffffffff ffffffff    ................
+40080020: ffffffff ffffffff ffffffff ffffffff    ................
+40080030: ffffffff ffffffff ffffffff ffffffff    ................
+40080040: ffffffff ffffffff ffffffff ffffffff    ................
+40080050: ffffffff ffffffff ffffffff ffffffff    ................
+40080060: ffffffff ffffffff ffffffff ffffffff    ................
+40080070: ffffffff ffffffff ffffffff ffffffff    ................
+40080080: ffffffff ffffffff ffffffff ffffffff    ................
+40080090: ffffffff ffffffff ffffffff ffffffff    ................
+400800a0: ffffffff ffffffff ffffffff ffffffff    ................
+400800b0: ffffffff ffffffff ffffffff ffffffff    ................
+400800c0: ffffffff ffffffff ffffffff ffffffff    ................
+400800d0: ffffffff ffffffff ffffffff ffffffff    ................
+400800e0: ffffffff ffffffff ffffffff ffffffff    ................
+400800f0: ffffffff ffffffff ffffffff ffffffff    ................
+=> cp 0 40080000 10
+Copy to Flash... done
+=> cp 0 400c0000 10
+Copy to Flash... done
+=> erase 1:2-3
+Erase Flash Sectors 2-3 in Bank # 1
+... done
+=> md 40080000
+40080000: ffffffff ffffffff ffffffff ffffffff    ................
+40080010: ffffffff ffffffff ffffffff ffffffff    ................
+40080020: ffffffff ffffffff ffffffff ffffffff    ................
+40080030: ffffffff ffffffff ffffffff ffffffff    ................
+40080040: ffffffff ffffffff ffffffff ffffffff    ................
+40080050: ffffffff ffffffff ffffffff ffffffff    ................
+40080060: ffffffff ffffffff ffffffff ffffffff    ................
+40080070: ffffffff ffffffff ffffffff ffffffff    ................
+40080080: ffffffff ffffffff ffffffff ffffffff    ................
+40080090: ffffffff ffffffff ffffffff ffffffff    ................
+400800a0: ffffffff ffffffff ffffffff ffffffff    ................
+400800b0: ffffffff ffffffff ffffffff ffffffff    ................
+400800c0: ffffffff ffffffff ffffffff ffffffff    ................
+400800d0: ffffffff ffffffff ffffffff ffffffff    ................
+400800e0: ffffffff ffffffff ffffffff ffffffff    ................
+400800f0: ffffffff ffffffff ffffffff ffffffff    ................
+=> md 400c0000
+400c0000: ffffffff ffffffff ffffffff ffffffff    ................
+400c0010: ffffffff ffffffff ffffffff ffffffff    ................
+400c0020: ffffffff ffffffff ffffffff ffffffff    ................
+400c0030: ffffffff ffffffff ffffffff ffffffff    ................
+400c0040: ffffffff ffffffff ffffffff ffffffff    ................
+400c0050: ffffffff ffffffff ffffffff ffffffff    ................
+400c0060: ffffffff ffffffff ffffffff ffffffff    ................
+400c0070: ffffffff ffffffff ffffffff ffffffff    ................
+400c0080: ffffffff ffffffff ffffffff ffffffff    ................
+400c0090: ffffffff ffffffff ffffffff ffffffff    ................
+400c00a0: ffffffff ffffffff ffffffff ffffffff    ................
+400c00b0: ffffffff ffffffff ffffffff ffffffff    ................
+400c00c0: ffffffff ffffffff ffffffff ffffffff    ................
+400c00d0: ffffffff ffffffff ffffffff ffffffff    ................
+400c00e0: ffffffff ffffffff ffffffff ffffffff    ................
+400c00f0: ffffffff ffffffff ffffffff ffffffff    ................
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test the Flash programming commands:
+
+------------------------------------------------------------------------------
+=> erase 40080000 400bffff
+Erase Flash from 0x40080000 to 0x400bffff
+.. done
+Erased 1 sectors
+=> cp 0 40080000 10
+Copy to Flash... done
+=> md 0
+00000000: 00000000 00000104 61100200 01000000    ........a.......
+00000010: 00000000 00000000 81140000 82000100    ................
+00000020: 01080000 00004000 22800000 00000600    ......@.".......
+00000030: 00200800 00000000 10000100 00008000    . ..............
+00000040: 00812000 00000200 00020000 80000000    .. .............
+00000050: 00028001 00001000 00040400 00000200    ................
+00000060: 20480000 00000000 20090000 00142000     H...... ..... .
+00000070: 00000000 00004000 24210000 10000000    ......@.$!......
+00000080: 02440002 10000000 00200008 00000000    .D....... ......
+00000090: 02440900 00000000 30a40000 00004400    .D......0.....D.
+000000a0: 04420800 00000000 00000040 00020000    .B.........@....
+000000b0: 05020000 00100000 00060000 00000000    ................
+000000c0: 00400000 00000000 00080000 00040000    .@..............
+000000d0: 10400000 00800004 00000000 00000200    .@..............
+000000e0: 80890000 00010004 00080000 00000020    ...............
+000000f0: 08000000 10000000 00010000 00000000    ................
+=> md 40080000
+40080000: 00000000 00000104 61100200 01000000    ........a.......
+40080010: 00000000 00000000 81140000 82000100    ................
+40080020: 01080000 00004000 22800000 00000600    ......@.".......
+40080030: 00200800 00000000 10000100 00008000    . ..............
+40080040: ffffffff ffffffff ffffffff ffffffff    ................
+40080050: ffffffff ffffffff ffffffff ffffffff    ................
+40080060: ffffffff ffffffff ffffffff ffffffff    ................
+40080070: ffffffff ffffffff ffffffff ffffffff    ................
+40080080: ffffffff ffffffff ffffffff ffffffff    ................
+40080090: ffffffff ffffffff ffffffff ffffffff    ................
+400800a0: ffffffff ffffffff ffffffff ffffffff    ................
+400800b0: ffffffff ffffffff ffffffff ffffffff    ................
+400800c0: ffffffff ffffffff ffffffff ffffffff    ................
+400800d0: ffffffff ffffffff ffffffff ffffffff    ................
+400800e0: ffffffff ffffffff ffffffff ffffffff    ................
+400800f0: ffffffff ffffffff ffffffff ffffffff    ................
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test storage of the environment
+variables in Flash:
+
+------------------------------------------------------------------------------
+=> setenv foo bar
+=> saveenv
+Un-Protected 1 sectors
+Erasing Flash...
+.. done
+Erased 1 sectors
+Saving Environment to Flash...
+Protected 1 sectors
+=> reset
+...
+=> printenv
+bootdelay=CONFIG_BOOTDELAY
+baudrate=9600
+ipaddr=192.168.4.7
+serverip=192.168.4.1
+ethaddr=66:55:44:33:22:11
+foo=bar
+stdin=serial
+stdout=serial
+stderr=serial
+
+Environment size: 170/262140 bytes
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test image download and run over
+Ethernet interface (both interfaces were tested):
+
+------------------------------------------------------------------------------
+=> tftpboot 40000 hello_world.bin
+ARP broadcast 1
+TFTP from server 192.168.2.2; our IP address is 192.168.2.7
+Filename 'hello_world.bin'.
+Load address: 0x40000
+Loading: #############
+done
+Bytes transferred = 65912 (10178 hex)
+=> go 40004
+## Starting application at 0x00040004 ...
+Hello World
+argc = 1
+argv[0] = "40004"
+argv[1] = "<NULL>"
+Hit any key to exit ...
+
+## Application terminated, rc = 0x0
+=>
+------------------------------------------------------------------------------
+
+
+The following sequence was performed to test eeprom read/write commands:
+
+------------------------------------------------------------------------------
+=> md 40000
+00040000: 00018148 9421ffe0 7c0802a6 bf61000c    ...H.!..|....a..
+00040010: 90010024 48000005 7fc802a6 801effe8    ...$H...........
+00040020: 7fc0f214 7c7f1b78 813f004c 7c9c2378    ....|..x.?.L|.#x
+00040030: 807e8000 7cbd2b78 80090010 3b600000    .~..|.+x....;`..
+00040040: 7c0803a6 4e800021 813f004c 7f84e378    |...N..!.?.L...x
+00040050: 807e8004 80090010 7c0803a6 4e800021    .~......|...N..!
+00040060: 7c1be000 4181003c 80bd0000 813f004c    |...A..<.....?.L
+00040070: 3bbd0004 2c050000 40820008 80be8008    ;...,...@.......
+00040080: 80090010 7f64db78 807e800c 3b7b0001    .....d.x.~..;{..
+00040090: 7c0803a6 4e800021 7c1be000 4081ffcc    |...N..!|...@...
+000400a0: 813f004c 807e8010 80090010 7c0803a6    .?.L.~......|...
+000400b0: 4e800021 813f004c 80090004 7c0803a6    N..!.?.L....|...
+000400c0: 4e800021 2c030000 4182ffec 813f004c    N..!,...A....?.L
+000400d0: 80090000 7c0803a6 4e800021 813f004c    ....|...N..!.?.L
+000400e0: 807e8014 80090010 7c0803a6 4e800021    .~......|...N..!
+000400f0: 38600000 80010024 7c0803a6 bb61000c    8`.....$|....a..
+=> eeprom write 40000 0 40
+
+EEPROM write: addr 00040000  off 0000  count 64 ... done
+=> mw 50000 0 1000
+=> eeprom read 50000 0 40
+
+EEPROM read: addr 00050000  off 0000  count 64 ... done
+=> md 50000
+00050000: 00018148 9421ffe0 7c0802a6 bf61000c    ...H.!..|....a..
+00050010: 90010024 48000005 7fc802a6 801effe8    ...$H...........
+00050020: 7fc0f214 7c7f1b78 813f004c 7c9c2378    ....|..x.?.L|.#x
+00050030: 807e8000 7cbd2b78 80090010 3b600000    .~..|.+x....;`..
+00050040: 00000000 00000000 00000000 00000000    ................
+00050050: 00000000 00000000 00000000 00000000    ................
+00050060: 00000000 00000000 00000000 00000000    ................
+00050070: 00000000 00000000 00000000 00000000    ................
+00050080: 00000000 00000000 00000000 00000000    ................
+00050090: 00000000 00000000 00000000 00000000    ................
+000500a0: 00000000 00000000 00000000 00000000    ................
+000500b0: 00000000 00000000 00000000 00000000    ................
+000500c0: 00000000 00000000 00000000 00000000    ................
+000500d0: 00000000 00000000 00000000 00000000    ................
+000500e0: 00000000 00000000 00000000 00000000    ................
+000500f0: 00000000 00000000 00000000 00000000    ................
+=>
+------------------------------------------------------------------------------
+
+
+Patch per Mon, 06 Aug 2001 17:57:27:
+
+- upgraded Flash support (added support for the following chips:
+  AM29LV800T/B, AM29LV160T/B, AM29DL322T/B, AM29DL323T/B)
+- BCR tweakage for the 8260 bus mode
+- SIUMCR tweakage enabling the MI interrupt (IRQ7)
+
+To simplify switching between the bus modes, a new configuration
+option (CONFIG_BUSMODE_60x) has been added to the "config_TQM8260.h"
+file. If it is defined, BCR will be configured for the 60x mode,
+otherwise - for the 8260 mode.
+
+Concerning the SIUMCR modification: it's hard to predict whether it
+will induce any problems on the other (60x mode) board. However, the
+problems (if they appear) should be easy to notice - if the board
+does not boot, it's most likely caused by the DPPC configuration in
+SIUMCR.
diff --git a/u-boot/doc/README.VLAN b/u-boot/doc/README.VLAN
new file mode 100644
index 0000000..4f86d55
--- /dev/null
+++ b/u-boot/doc/README.VLAN
@@ -0,0 +1,15 @@
+U-Boot has networking support for VLANs (802.1q), and CDP (Cisco
+Discovery Protocol).
+
+You control the sending/receiving of VLAN tagged packets with the
+"vlan" environmental variable. When not present no tagging is
+performed.
+
+CDP is used mainly to discover your device VLAN(s) when connected to
+a Cisco switch.
+
+Note: In order to enable CDP support a small change is needed in the
+networking driver. You have to enable reception of the
+01:00:0c:cc:cc:cc MAC address which is a multicast address.
+
+Various defines control CDP; see the README section.
diff --git a/u-boot/doc/README.alaska8220 b/u-boot/doc/README.alaska8220
new file mode 100644
index 0000000..3345073
--- /dev/null
+++ b/u-boot/doc/README.alaska8220
@@ -0,0 +1,482 @@
+Freescale Alaska MPC8220 board
+==============================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created 9/21/04
+===========================================
+
+
+Changed files:
+==============
+
+- Makefile		    added MPC8220 and Alaska8220_config
+- MAKEALL		    added MPC8220 and Alaska8220
+- README		    added CONFIG_MPC8220, Alaska8220_config
+
+- common/cmd_bdinfo.c	    added board information members for MPC8220
+- common/cmd_bootm.c	    added clocks for MPC8220 in do_bootm_linux()
+
+- include/common.h	    added CONFIG_MPC8220
+
+- include/asm-ppc/u-boot.h  added board information members for MPC8220
+- include/asm-ppc/global_data.h added global variables - inp_clk, pci_clk,
+			    vco_clk, pev_clk, flb_clk, and bExtUart
+
+- arch/powerpc/lib/board.c	    added CONFIG_MPC8220 support
+
+- net/eth.c		    added FEC support for MPC8220
+
+Added files:
+============
+- board/alaska		    directory for Alaska MPC8220
+- board/alaska/alaska.c	    Alaska dram and BATs setup
+- board/alaska/extserial.c  external serial (debug card serial) support
+- board/alaska/flash.c	    Socket (AMD) and Onboard (INTEL) flash support
+- board/alaska/serial.c	    to determine which int/ext serial to use
+- board/alaska/Makefile	    Makefile
+- board/alaska/config.mk    config make
+- board/alaska/u-boot.lds   Linker description
+
+- arch/powerpc/cpu/mpc8220/dma.h	    multi-channel dma header file
+- arch/powerpc/cpu/mpc8220/dramSetup.h   dram setup header file
+- arch/powerpc/cpu/mpc8220/fec.h	    MPC8220 FEC header file
+- arch/powerpc/cpu/mpc8220/cpu.c	    cpu specific code
+- arch/powerpc/cpu/mpc8220/cpu_init.c    Flexbus ChipSelect and Mux pins setup
+- arch/powerpc/cpu/mpc8220/dramSetup.c   MPC8220 DDR SDRAM setup
+- arch/powerpc/cpu/mpc8220/fec.c	    MPC8220 FEC driver
+- arch/powerpc/cpu/mpc8220/i2c.c	    MPC8220 I2C driver
+- arch/powerpc/cpu/mpc8220/interrupts.c  interrupt support (not enable)
+- arch/powerpc/cpu/mpc8220/loadtask.c    load dma
+- arch/powerpc/cpu/mpc8220/speed.c	    system, pci, flexbus, pev, and cpu clock
+- arch/powerpc/cpu/mpc8220/traps.c	    exception
+- arch/powerpc/cpu/mpc8220/uart.c	    MPC8220 UART driver
+- arch/powerpc/cpu/mpc8220/Makefile	    Makefile
+- arch/powerpc/cpu/mpc8220/config.mk	    config make
+- arch/powerpc/cpu/mpc8220/fec_dma_task.S MPC8220 FEC multi-channel dma program
+- arch/powerpc/cpu/mpc8220/io.S	    io functions
+- arch/powerpc/cpu/mpc8220/start.S	    start up
+
+- include/mpc8220.h
+
+- include/asm-ppc/immap_8220.h
+
+- include/configs/Alaska8220.h
+
+
+1. SWITCH SETTINGS
+==================
+1.1 SW1: 0 - Boot from Socket Flash (AMD) or 1 - Onboard Flash (INTEL)
+    SW2: 0 - Select MPC8220 UART or 1 - Debug Card UART
+    SW3: unsed
+    SW4: 0 - 1284 or 1 - FEC1
+    SW5: 0 - PEV or 1 - FEC2
+
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+     linux kernel, you can customize it based on your system requirements:
+      DDR:	    0x00000000-0x1fffffff (max 512MB)
+      MBAR:	    0xf0000000-0xf0027fff (128KB)
+      CPLD:	    0xf1000000-0xf103ffff (256KB)
+      FPGA:	    0xf2000000-0xf203ffff (256KB)
+      Flash:	    0xfe000000-0xffffffff (max 32MB)
+
+3. DEFINITIONS AND COMPILATION
+==============================
+3.1 Explanation on NEW definitions in include/configs/alaska8220.h
+    CONFIG_MPC8220	    MPC8220 specific
+    CONFIG_ALASKA8220	    Alaska board specific
+    CONFIG_SYS_MPC8220_CLKIN	    Define Alaska Input Clock
+    CONFIG_PSC_CONSOLE	    Enable MPC8220 UART
+    CONFIG_EXTUART_CONSOLE  Enable External 16552 UART
+    CONFIG_SYS_AMD_BOOT	    To determine the u-boot is booted from AMD or Intel
+    CONFIG_SYS_MBAR		    MBAR base address
+    CONFIG_SYS_DEFAULT_MBAR	    Reset MBAR base address
+
+3.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot-1-1-x
+   make distclean
+   make Alaska8220_config
+   make
+
+
+4. SCREEN DUMP
+==============
+4.1 Alaska MPC8220 board
+    Boot from AMD (NOTE: May not show exactly the same)
+
+U-Boot 1.1.1 (Sep 22 2004 - 22:14:41)
+
+CPU:   MPC8220 (JTAG ID 1640301d) at 300 MHz
+       Bus 120 MHz, CPU 300 MHz, PCI 30 MHz, VCO 480 MHz
+Board: Alaska MPC8220 Evaluation Board
+I2C:   93 kHz, ready
+DRAM:  256 MB
+Reserving 167k for U-Boot at: 0ffd6000
+FLASH: 16.5 MB
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   FEC ETHERNET
+=> flinfo
+
+Bank # 1: INTEL 28F128J3A
+  Size: 8 MB in 64 Sectors
+  Sector Start Addresses:
+    FE000000	  FE020000	FE040000      FE060000	    FE080000
+    FE0A0000	  FE0C0000	FE0E0000      FE100000	    FE120000
+    FE140000	  FE160000	FE180000      FE1A0000	    FE1C0000
+    FE1E0000	  FE200000	FE220000      FE240000	    FE260000
+    FE280000	  FE2A0000	FE2C0000      FE2E0000	    FE300000
+    FE320000	  FE340000	FE360000      FE380000	    FE3A0000
+    FE3C0000	  FE3E0000	FE400000      FE420000	    FE440000
+    FE460000	  FE480000	FE4A0000      FE4C0000	    FE4E0000
+    FE500000	  FE520000	FE540000      FE560000	    FE580000
+    FE5A0000	  FE5C0000	FE5E0000      FE600000	    FE620000
+    FE640000	  FE660000	FE680000      FE6A0000	    FE6C0000
+    FE6E0000	  FE700000	FE720000      FE740000	    FE760000
+    FE780000	  FE7A0000	FE7C0000      FE7E0000
+
+Bank # 2: INTEL 28F128J3A
+  Size: 8 MB in 64 Sectors
+  Sector Start Addresses:
+    FE800000	  FE820000	FE840000      FE860000	    FE880000
+    FE8A0000	  FE8C0000	FE8E0000      FE900000	    FE920000
+    FE940000	  FE960000	FE980000      FE9A0000	    FE9C0000
+    FE9E0000	  FEA00000	FEA20000      FEA40000	    FEA60000
+    FEA80000	  FEAA0000	FEAC0000      FEAE0000	    FEB00000
+    FEB20000	  FEB40000	FEB60000      FEB80000	    FEBA0000
+    FEBC0000	  FEBE0000	FEC00000      FEC20000	    FEC40000
+    FEC60000	  FEC80000	FECA0000      FECC0000	    FECE0000
+    FED00000	  FED20000	FED40000      FED60000	    FED80000
+    FEDA0000	  FEDC0000	FEDE0000      FEE00000	    FEE20000
+    FEE40000	  FEE60000	FEE80000      FEEA0000	    FEEC0000
+    FEEE0000	  FEF00000 (RO) FEF20000 (RO) FEF40000	    FEF60000
+    FEF80000	  FEFA0000	FEFC0000      FEFE0000 (RO)
+
+Bank # 3: AMD AMD29F040B
+  Size: 0 MB in 7 Sectors
+  Sector Start Addresses:
+    FFF00000 (RO) FFF10000 (RO) FFF20000 (RO) FFF30000	    FFF40000
+    FFF50000	  FFF60000
+
+Bank # 4: AMD AMD29F040B
+  Size: 0 MB in 1 Sectors
+  Sector Start Addresses:
+    FFF70000 (RO)
+=> bdinfo
+
+memstart    = 0xF0009800
+memsize	    = 0x10000000
+flashstart  = 0xFFF00000
+flashsize   = 0x01080000
+flashoffset = 0x00025000
+sramstart   = 0xF0020000
+sramsize    = 0x00008000
+bootflags   = 0x00000001
+intfreq	    =	 300 MHz
+busfreq	    =	 120 MHz
+inpfreq	    =	  30 MHz
+flbfreq	    =	  30 MHz
+pcifreq	    =	  30 MHz
+vcofreq	    =	 480 MHz
+pevfreq	    =	  81 MHz
+ethaddr	    = 00:E0:0C:BC:E0:60
+eth1addr    = 00:E0:0C:BC:E0:61
+IP addr	    = 192.162.1.2
+baudrate    = 115200 bps
+=> printenv
+bootargs=root=/dev/ram rw
+bootdelay=5
+baudrate=115200
+ethaddr=00:e0:0c:bc:e0:60
+eth1addr=00:e0:0c:bc:e0:61
+ipaddr=192.162.1.2
+serverip=192.162.1.1
+gatewayip=192.162.1.1
+netmask=255.255.255.0
+hostname=Alaska
+stdin=serial
+stdout=serial
+stderr=serial
+ethact=FEC ETHERNET
+
+Environment size: 268/65532 bytes
+=> setenv ipaddr 192.160.1.2
+=> setenv serverip 192.160.1.1
+=> setenv gatewayip 192.160.1.1
+=> saveenv
+Saving Environment to Flash...
+
+.
+Un-Protected 1 sectors
+Erasing Flash...
+Erasing sector	0 ...  done
+Erased 1 sectors
+Writing to Flash... done
+
+.
+Protected 1 sectors
+=> tftp 0x10000 linux.elf
+Using FEC ETHERNET device
+TFTP from server 192.160.1.1; our IP address is 192.160.1.2; sending through gateway 192.160.1.1
+Filename 'linux.elf'.
+Load address: 0x10000
+Loading: invalid RARP header
+#################################################################
+	 #################################################################
+	 #################################################################
+	 #################################################################
+	 #################################################################
+	 #################################################################
+	 #################################################################
+	 #################################################################
+	 ##################################################
+done
+Bytes transferred = 2917494 (2c8476 hex)
+=> bootelf
+Loading .text @ 0x00a00000 (23820 bytes)
+Loading .data @ 0x00a06000 (2752512 bytes)
+Clearing .bss @ 0x00ca6000 (12764 bytes)
+## Starting application at 0x00a00000 ...
+
+Collect some entropy from RAM........done
+loaded at:     00A00000 00CA91DC
+zimage at:     00A06A93 00AD7756
+initrd at:     00AD8000 00CA5565
+avail ram:     00CAA000 014AA000
+
+Linux/PPC load: ip=off console=ttyS0,115200
+Uncompressing Linux...done.
+Now booting the kernel
+Total memory in system: 256 MB
+Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
+Linux version 2.4.21-rc1 (r61688@bluesocks.sps.mot.com) (gcc version 3.3.1) #17 Wed Sep 8 11:49:16 CDT 2004
+Motorola Alaska port (C) 2003 Motorola, Inc.
+CPLD rev 3
+CPLD switches 0x1b
+Set Pin Mux for FEC1
+Set Pin Mux for FEC2
+Alaska Pin Multiplexing:
+Port Configuration Register 0 = 0
+Port Configuration Register 1 = 0
+Port Configuration Register 2 = 0
+Port Configuration Register 3 = 50000000
+Port Configuration Register 3 - PCI = 51400180
+Setup Alaska FPGA PIC:
+Interrupt Enable Register *(u32) = 0
+Interrupt Status Register = 2f0000
+Interrupt Enable Register in_be32 = 0
+Interrupt Status Register = 2f0000
+Interrupt Enable Register in_le32 = 0
+Interrupt Status Register = 2f00
+Interrupt Enable Register readl = 0
+Interrupt Status Register = 2f00
+Interrupt Enable Register = 0
+Interrupt Status Register = 2f0000
+Setup Alaska PCI Controller:
+On node 0 totalpages: 65536
+zone(0): 65536 pages.
+zone(1): 0 pages.
+zone(2): 0 pages.
+Kernel command line: ip=off console=ttyS0,115200
+Using XLB clock (120.00 MHz) to set up decrementer
+Calibrating delay loop... 199.88 BogoMIPS
+Memory: 254792k available (1476k kernel code, 708k data, 228k init, 0k highmem)
+Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
+Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
+Mount cache hash table entries: 512 (order: 0, 4096 bytes)
+Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
+Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
+POSIX conformance testing by UNIFIX
+PCI: Probing PCI hardware
+PCI: (pcibios_init) Global-Hose = 0xc029d000
+Scanning bus 00
+Fixups for bus 00
+Bus scan for 00 returning with max=00
+PCI: (pcibios_init) finished pci_scan_bus(hose->first_busno = 0, hose->ops = c01a1a74, hose = c029d000)
+PCI: (pcibios_init) PCI Bus Count = 0 =?= Next Bus# = 1
+PCI: (pcibios_init@pci_fixup_irqs) finished machine dependent PCI interrupt routing!
+PCI: bridge rsrc 81000000..81ffffff (100), parent c01a7f88
+PCI: bridge rsrc 84000000..87ffffff (200), parent c01a7fa4
+PCI: (pcibios_init) finished allocating and assigning resources!
+initDma!
+Using 90 DMA buffer descriptors
+descUsed f0023600, descriptors f002360c freeSram f0024140
+unmask SDMA tasks: 0xf0008018 = 0x6f000000
+Linux NET4.0 for Linux 2.4
+Based upon Swansea University Computer Society NET3.039
+Initializing RT netlink socket
+Starting kswapd
+Journalled Block Device driver loaded
+JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
+JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
+pty: 256 Unix98 ptys configured
+tracek: Copyright (C) Motorola, 2003.
+Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
+ttyS00 at 0xf1001008 (irq = 73) is a ST16650
+ttyS01 at 0xf1001010 (irq = 74) is a ST16650
+elp-fpanel: Copyright (C) Motorola, 2003.
+fpanel: fpanelWait timeout
+elp-engine: Copyright (C) Motorola, 2003.
+Video disabled due to configuration switch 4
+Alpine 1284 driver: Copyright (C) Motorola, 2003.
+1284 disabled due to configuration switch 5
+Alpine USB driver: Copyright (C) Motorola, 2003.
+OK
+USB: Descriptor download completed OK
+enable_irq(41) unbalanced
+enable_irq(75) unbalanced
+elp-dmaram: Copyright (C) Motorola, 2003.
+Total memory in system: 256 MB
+elp_dmaram: offset is 0x10000000, size is 0
+Xicor NVRAM driver: Copyright (C) Motorola, 2003.
+elp-video: Copyright (C) Motorola, 2003.
+Video disabled due to configuration switch 4
+elp-pfm: Copyright (C) Motorola, 2003.
+paddle: Copyright (C) Motorola, 2001, present.
+RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
+loop: loaded (max 8 devices)
+PPP generic driver version 2.4.2
+PPP Deflate Compression module registered
+Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
+ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
+init_alaska_mtd: chip probing count 0
+cfi_cmdset_0001: Erase suspend on write enabled
+Using buffer write method
+init_alaska_mtd: bank1, name:ALASKA0, size:16777216bytes
+ALASKA flash0: Using Static image partition definition
+Creating 3 MTD partitions on "ALASKA0":
+0x00000000-0x00280000 : "kernel"
+0x00280000-0x00fe0000 : "user"
+0x00fe0000-0x01000000 : "signature"
+mgt_fec_module_init
+mgt_fec_init()
+mgt_fec_init
+mgt_init_fec_dev(0xc05f6000,0)
+dev c05f6000 fec_priv c05f6160 fec f0009000
+mgt_init_fec_dev(0xc05f6800,1)
+dev c05f6800 fec_priv c05f6960 fec f0009800
+NET4: Linux TCP/IP 1.0 for NET4.0
+IP Protocols: ICMP, UDP, TCP, IGMP
+IP: routing cache hash table of 2048 buckets, 16Kbytes
+TCP: Hash tables configured (established 16384 bind 32768)
+NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
+RAMDISK: Compressed image found at block 0
+Freeing initrd memory: 1845k freed
+JFFS: Trying to mount a non-mtd device.
+VFS: Mounted root (romfs filesystem) readonly.
+Freeing unused kernel memory: 228k init
+INIT: version 2.78 booting
+INIT: Entering runlevel: 1
+"Space, a great big place of unknown stuff."  -Dexter, for our MotD.
+[01/Jan/1970:00:00:01 +0000] boa: server version Boa/0.94.8.3
+[01/Jan/1970:00:00:01 +0000] boa: server built Sep  7 2004 at 17:40:55.
+[01/Jan/1970:00:00:01 +0000] boa: starting server pid=28, port 80
+Mounting flash filesystem, will take a minute...
+/etc/rc: line 30: /dev/lp0: No such devish-2.05b#
+sh-2.05b# ifup eth0
+client (v0.9.9-pre) started
+adapter index 2
+adapter hardware address 00:e0:0c:bc:e0:60
+execle'ing /usr/share/udhcpc/default.script
+/sbin/ifconfig eth0
+eth0	  Link encap:Ethernet  HWaddr 00:E0:0C:BC:E0:60
+	  BROADCAST MULTICAST  MTU:1500	 Metric:1
+	 mgt_fec_open
+ Rfec request irq
+X fec_open: rcv_ring_size 8, xmt_ring_size 8
+packmgt_fec_open(): call netif_start_queue()
+ets:0 errors:0 dropped:0 overruns:0 frame:0
+	  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+	  collisions:0 txqueuelen:100
+	  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
+	  Base address:0x9000
+
+/sbin/ifconfig eth0 up
+entering raw listen mode
+Opening raw socket on ifindex 2
+adding option 0x35
+adding option 0x3d
+adding option 0x3c
+Sending discover...
+Waiting on select...
+unrelated/bogus packet
+Waiting on select...
+oooooh!!! got some!
+adding option 0x35
+adding option 0x3d
+adding option 0x3c
+adding option 0x32
+adding option 0x36
+Sending select for 163.12.48.146...
+Waiting on select...
+oooooh!!! got some!
+Waiting on select...
+oooooh!!! got some!
+Lease of 163.12.48.146 obtained, lease time 345600
+execle'ing /usr/share/udhcpc/default.script
+/sbin/ifconfig eth0 163.12.48.146 netmask 255.255.254.0
+/sbin/ifconfig eth0 up
+deleting routers
+/sbin/route del default
+/sbin/route add default gw 163.12.49.254 dev eth0
+adding dns 163.12.252.230
+adding dns 192.55.22.4
+adding dns 192.5.249.4
+entering none listen mode
+sh-2.05b#
+
+5. REPROGRAM U-BOOT
+===================
+5.1 Reprogram u-boot (boot from AMD)
+    1. Unprotect the boot sector
+    => protect off bank 3
+    2. Download new u-boot binary file
+    => tftp 0x10000 u-boot.bin
+    3. Erase bootsector (max 7 sectors)
+    => erase 0xfff00000 0xfff6ffff
+    4. Program the u-boot to flash
+    => cp.b 0x10000 0xfff00000
+    5. Reset for the new u-boot to take place
+    => reset
+
+5.2 Reprogram u-boot (boot from AMD program at INTEL)
+    1. Unprotect the boot sector
+    => protect off bank 2
+    2. Download new u-boot binary file
+    => tftp 0x10000 u-boot.bin
+    3. Erase bootsector (max 7 sectors)
+    => erase 0xfef00000 0xfefdffff
+    4. Program the u-boot to flash
+    => cp.b 0x10000 0xfef00000
+    5. Reset for the new u-boot to take place
+    => reset
+
+5.3 Reprogram u-boot (boot from INTEL)
+    1. Unprotect the boot sector
+    => protect off bank 4
+    2. Download new u-boot binary file
+    => tftp 0x10000 u-boot.bin
+    3. Erase bootsector (max 7 sectors)
+    => erase 0xfff00000 0xfffdffff
+    4. Program the u-boot to flash
+    => cp.b 0x10000 0xfff00000
+    5. Reset for the new u-boot to take place
+    => reset
+
+5.4 Reprogram u-boot (boot from INTEL program at AMD)
+    1. Unprotect the boot sector
+    => protect off bank 1
+    2. Download new u-boot binary file
+    => tftp 0x10000 u-boot.bin
+    3. Erase bootsector (max 7 sectors)
+    => erase 0xfe080000 0xfe0effff
+    4. Program the u-boot to flash
+    => cp.b 0x10000 0xfe080000
+    5. Reset for the new u-boot to take place
+    => reset
diff --git a/u-boot/doc/README.amigaone b/u-boot/doc/README.amigaone
new file mode 100644
index 0000000..9975977
--- /dev/null
+++ b/u-boot/doc/README.amigaone
@@ -0,0 +1,12 @@
+AmigaOne U-Boot and the SciTech emulator
+
+The directory board/MAI/bios_emulator contains the source code
+of the SciTech x86 emulator. This emulator is normally available
+under a BSD license. However, SciTech kindly gave us permission
+to use their emulator in PPCBoot for the AmigaOne. It's available
+in this form only under GPL.
+
+Thanks to Kendall Bennett and the rest of the team at SciTech.
+See http://www.scitechsoft.com for their web site
+
+The GPL license can be found at http://www.gnu.org/licenses/gpl.html
diff --git a/u-boot/doc/README.arm-relocation b/u-boot/doc/README.arm-relocation
new file mode 100644
index 0000000..c0957c2
--- /dev/null
+++ b/u-boot/doc/README.arm-relocation
@@ -0,0 +1,194 @@
+To make relocation on arm working, the following changes are done:
+
+At arch level: add linker flag -pie
+
+	This causes the linker to generate fixup tables .rel.dyn and .dynsym,
+	which must be applied to the relocated image before transferring
+	control to it.
+
+	These fixups are described in the ARM ELF documentation as type 23
+	(program-base-relative) and 2 (symbol-relative)
+
+At cpu level: modify linker file and add a relocation and fixup loop
+
+	the linker file must be modified to include the .rel.dyn and .dynsym
+	tables in the binary image, and to provide symbols for the relocation
+	code to access these tables
+
+	The relocation and fixup loop must be executed after executing
+	board_init_f at initial location and before executing board_init_r
+	at final location.
+
+At board level:
+
+	dram_init(): bd pointer is now at this point not accessible, so only
+	detect the real dramsize, and store it in gd->ram_size. Bst detected
+	with get_ram_size().
+
+TODO:	move also dram initialization there on boards where it is possible.
+
+	Setup of the the bd_t dram bank info is done in the new function
+	dram_init_banksize() called after bd is accessible.
+
+At lib level:
+
+	Board.c code is adapted from ppc code
+
+* WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING ** WARNING *
+
+Boards which are not fixed to support relocation will be REMOVED!
+
+-----------------------------------------------------------------------------
+
+For boards which boot from nand_spl, it is possible to save one copy
+if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code
+is copied again in relocate_code().
+
+example for the tx25 board:
+
+a) cpu starts
+b) it copies the first page in nand to internal ram
+   (nand_spl_code)
+c) end executes this code
+d) this initialize CPU, RAM, ... and copy itself to RAM
+   (this bin must fit in one page, so board_init_f()
+    don;t fit in it ... )
+e) there it copy u-boot to CONFIG_SYS_NAND_U_BOOT_DST and
+   starts this image @ CONFIG_SYS_NAND_U_BOOT_START
+f) u-boot code steps through board_init_f() and calculates
+   the relocation address and copy itself to it
+
+If CONFIG_SYS_TEXT_BASE == relocation address, the copying of u-boot
+in f) could be saved.
+
+-----------------------------------------------------------------------------
+
+TODO
+
+- fill in bd_t infos (check)
+- adapt all boards
+
+- maybe adapt CONFIG_SYS_TEXT_BASE (this must be checked from board maintainers)
+  This *must* be done for boards, which boot from NOR flash
+
+  on other boards if CONFIG_SYS_TEXT_BASE = relocation baseaddr, this saves
+  one copying from u-boot code.
+
+- new function dram_init_banksize() is actual board specific. Maybe
+  we make a weak default function in arch/arm/lib/board.c ?
+
+-----------------------------------------------------------------------------
+
+Relocation with NAND_SPL (example for the tx25):
+
+- cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE)
+  and start with code execution on this address.
+
+- The First page contains u-boot code from u-boot:nand_spl/nand_boot_fsl_nfc.c
+  which inits the dram, cpu registers, reloacte itself to CONFIG_SYS_TEXT_BASE	and loads
+  the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution
+  @CONFIG_SYS_NAND_U_BOOT_START
+
+- This u-boot does no RAM init, nor CPU register setup. Just look
+  where it has to copy and relocate itself to this address. If
+  relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the
+  CONFIG_SYS_TEXT_BASE from the nand_spl code), then there is no need
+  to copy, just go on with bss clear and jump to board_init_r.
+
+-----------------------------------------------------------------------------
+
+How ELF relocations 23 and 2 work.
+
+TBC
+
+-------------------------------------------------------------------------------------
+
+Debugging u-boot in RAM:
+(example on the qong board)
+
+a) add in config.mk:
+
+PLATFORM_CPPFLAGS += -DDEBUG
+
+-----------------
+
+b) start debugger
+
+arm-linux-gdb u-boot
+
+[hs@pollux u-boot]$ arm-linux-gdb u-boot
+GNU gdb Red Hat Linux (6.7-2rh)
+Copyright (C) 2007 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
+The target architecture is set automatically (currently arm)
+..
+(gdb)
+
+-----------------
+
+c) connect to target
+
+target remote bdi10:2001
+
+(gdb) target remote bdi10:2001
+Remote debugging using bdi10:2001
+0x8ff17f10 in ?? ()
+(gdb)
+
+-----------------
+
+d) discard symbol-file
+
+(gdb) symbol-file
+Discard symbol table from `/home/hs/celf/u-boot/u-boot'? (y or n) y
+No symbol file now.
+(gdb)
+
+-----------------
+
+e) load new symbol table:
+
+(gdb) add-symbol-file u-boot 0x8ff08000
+add symbol table from file "u-boot" at
+	.text_addr = 0x8ff08000
+(y or n) y
+Reading symbols from /home/hs/celf/u-boot/u-boot...done.
+(gdb) c
+Continuing.
+^C
+Program received signal SIGSTOP, Stopped (signal).
+0x8ff17f18 in serial_getc () at serial_mxc.c:192
+192		while (__REG(UART_PHYS + UTS) & UTS_RXEMPTY);
+(gdb)
+
+add-symbol-file u-boot 0x8ff08000
+		       ^^^^^^^^^^
+		       get this address from u-boot debug printfs
+
+U-Boot 2010.06-rc2-00009-gf77b8b8-dirty (Jun 22 2010 - 09:43:46)
+
+U-Boot code: A0000000 -> A0058BAC  BSS: -> A0061F10
+CPU:   Freescale i.MX31 at 398 MHz
+Board: DAVE/DENX Qong
+mon: FFFFFFFF gd->monLen: 00061F10
+Top of RAM usable for U-Boot at: 90000000
+LCD panel info: 640 x 480, 16 bit/pix
+Reserving 600k for LCD Framebuffer at: 8ff6a000
+Reserving 391k for U-Boot at: 8ff08000
+			      ^^^^^^^^
+Reserving 1280k for malloc() at: 8fdc8000
+Reserving 24 Bytes for Board Info at: 8fdc7fe8
+Reserving 52 Bytes for Global Data at: 8fdc7fb4
+New Stack Pointer is: 8fdc7fb0
+RAM Configuration:
+Bank #0: 80000000 256 MiB
+relocation Offset is: eff08000
+mon: 00058BAC gd->monLen: 00061F10
+Now running in RAM - U-Boot at: 8ff08000
+				^^^^^^^^
+
+Now you can use gdb as usual :-)
diff --git a/u-boot/doc/README.at91 b/u-boot/doc/README.at91
new file mode 100644
index 0000000..84b5595
--- /dev/null
+++ b/u-boot/doc/README.at91
@@ -0,0 +1,124 @@
+Atmel AT91 Evaluation kits
+
+http://atmel.com/dyn/products/tools.asp?family_id=605#1443
+
+I. Board mapping & boot media
+------------------------------------------------------------------------------
+AT91SAM9260EK, AT91SAM9G20EK & AT91SAM9XEEK
+------------------------------------------------------------------------------
+
+Memory map
+	0x20000000 - 23FFFFFF	SDRAM (64 MB)
+	0xC0000000 - Cxxxxxxx	Atmel Dataflash card (J13)
+	0xD0000000 - Dxxxxxxx	Soldered Atmel Dataflash
+
+Environment variables
+
+	U-Boot environment variables can be stored at different places:
+		- Dataflash on SPI chip select 1 (default)
+		- Dataflash on SPI chip select 0 (dataflash card)
+		- Nand flash.
+
+	You can choose your storage location at config step (here for at91sam9260ek) :
+		make at91sam9260ek_config		- use data flash (spi cs1) (default)
+		make at91sam9260ek_nandflash_config	- use nand flash
+		make at91sam9260ek_dataflash_cs0_config	- use data flash (spi cs0)
+		make at91sam9260ek_dataflash_cs1_config	- use data flash (spi cs1)
+
+
+------------------------------------------------------------------------------
+AT91SAM9261EK, AT91SAM9G10EK
+------------------------------------------------------------------------------
+
+Memory map
+	0x20000000 - 23FFFFFF	SDRAM (64 MB)
+	0xC0000000 - Cxxxxxxx	Soldered Atmel Dataflash
+	0xD0000000 - Dxxxxxxx	Atmel Dataflash card (J22)
+
+Environment variables
+
+	U-Boot environment variables can be stored at different places:
+		- Dataflash on SPI chip select 0 (default)
+		- Dataflash on SPI chip select 3 (dataflash card)
+		- Nand flash.
+
+	You can choose your storage location at config step (here for at91sam9260ek) :
+		make at91sam9261ek_config		- use data flash (spi cs0) (default)
+		make at91sam9261ek_nandflash_config	- use nand flash
+		make at91sam9261ek_dataflash_cs0_config	- use data flash (spi cs0)
+		make at91sam9261ek_dataflash_cs3_config	- use data flash (spi cs3)
+
+
+------------------------------------------------------------------------------
+AT91SAM9263EK
+------------------------------------------------------------------------------
+
+Memory map
+	0x20000000 - 23FFFFFF	SDRAM (64 MB)
+	0xC0000000 - Cxxxxxxx	Atmel Dataflash card (J9)
+
+Environment variables
+
+	U-Boot environment variables can be stored at different places:
+		- Dataflash on SPI chip select 0 (dataflash card)
+		- Nand flash.
+		- Nor falsh (not populate by default)
+
+	You can choose your storage location at config step (here for at91sam9260ek) :
+		make at91sam9263ek_config		- use data flash (spi cs0) (default)
+		make at91sam9263ek_nandflash_config	- use nand flash
+		make at91sam9263ek_dataflash_cs0_config	- use data flash (spi cs0)
+		make at91sam9263ek_norflash_config	- use nor falsh
+
+	You can choose to boot directly from U-Boot at config step
+		make at91sam9263ek_norflash_boot_config	- boot from nor falsh
+
+
+------------------------------------------------------------------------------
+AT91SAM9M10G45EK
+------------------------------------------------------------------------------
+
+Memory map
+	0x20000000 - 23FFFFFF	SDRAM (64 MB)
+	0xC0000000 - Cxxxxxxx	Atmel Dataflash card (J12)
+
+Environment variables
+
+	U-Boot environment variables can be stored at different places:
+		- Dataflash on SPI chip select 0 (dataflash card)
+		- Nand flash.
+
+	You can choose your storage location at config step (here for at91sam9m10g45ek) :
+		make at91sam9m10g45ek_config			- use data flash (spi cs0) (default)
+		make at91sam9m10g45ek_nandflash_config		- use nand flash
+		make at91sam9m10g45ek_dataflash_cs0_config	- use data flash (spi cs0)
+
+
+------------------------------------------------------------------------------
+AT91SAM9RLEK
+------------------------------------------------------------------------------
+
+Memory map
+	0x20000000 - 23FFFFFF	SDRAM (64 MB)
+	0xC0000000 - Cxxxxxxx	Soldered Atmel Dataflash
+
+Environment variables
+
+	U-Boot environment variables can be stored at different places:
+		- Dataflash on SPI chip select 0
+		- Nand flash.
+
+	You can choose your storage location at config step (here for at91sam9260ek) :
+		make at91sam9263ek_config		- use data flash (spi cs0) (default)
+		make at91sam9263ek_nandflash_config	- use nand flash
+		make at91sam9263ek_dataflash_cs0_config	- use data flash (spi cs0)
+
+II. Watchdog support
+
+	For security reasons, the at91 watchdog is running at boot time and,
+	if deactivated, cannot be used anymore.
+	If you want to use the watchdog, you will need to keep it running in
+	your code (make sure not to disable it in AT91Bootstrap for instance).
+
+	In the U-Boot configuration, the AT91 watchdog support is enabled using
+	the CONFIG_AT91SAM9_WATCHDOG and CONFIG_HW_WATCHDOG options.
diff --git a/u-boot/doc/README.at91-soc b/u-boot/doc/README.at91-soc
new file mode 100644
index 0000000..425fc58
--- /dev/null
+++ b/u-boot/doc/README.at91-soc
@@ -0,0 +1,64 @@
+ New C structure AT91 SoC access
+=================================
+
+The goal
+--------
+
+Currently the at91 arch uses hundreds of address defines and special
+at91_xxxx_write/read functions to access the SOC.
+The u-boot project perferred method is to access memory mapped hw
+regisister via a c structure.
+
+e.g. old
+
+	*AT91C_PIOA_IDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+	*AT91C_PIOC_PUDR = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+	*AT91C_PIOC_PER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+	*AT91C_PIOC_OER = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+	*AT91C_PIOC_PIO = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+
+	at91_sys_write(AT91_RSTC_CR,
+		AT91_RSTC_KEY | AT91_RSTC_PROCRST | AT91_RSTC_PERRST);
+
+e.g new
+	pin = AT91_PMX_AA_TWD | AT91_PMX_AA_TWCK;
+	writel(pin, &pio->pioa.idr);
+	writel(pin, &pio->pioa.pudr);
+	writel(pin, &pio->pioa.per);
+	writel(pin, &pio->pioa.oer);
+	writel(pin, &pio->pioa.sodr);
+
+	writel(AT91_RSTC_KEY | AT91_RSTC_CR_PROCRST |
+		AT91_RSTC_CR_PERRST, &rstc->cr);
+
+The method for updating
+------------------------
+
+1. add's the temporary CONFIG_AT91_LEGACY to all at91 board configs
+2. Display a compile time warning, if the board has not been converted
+3. add new structures for SoC access
+4. Convert arch, driver and boards file to new SoC
+5. remove legacy code, if all boards and drives are ready
+
+ Join AT91 and AT91RM9200 SoC
+==============================
+
+Approximately 95 percent of AT91 and AT91RM9200 SoC parts are the same.
+So, we should use the chance, to join both archs togetter.
+
+To do this follow step needed:
+
+1. change Makefile
+	@$(MKCONFIG) $(@:_config=) arm arm920t board vendor at91rm9200
+  to
+	@$(MKCONFIG) $(@:_config=) arm arm920t board vendor at91
+2. remove CONFIG_AT91_LEGACY in board config
+3. convert boards file to new SoC access
+4. convert or change drivers
+
+To support the joining process, a new SoC dir (at91) has been adding to
+arm920t arch directory. This directory contains files like at91rm9200 dir, but
+uses the new c structure Soc access. The advantage of this is, we don't merge
+old Soc access code and new code while the board are not converted.
+Finally we can delete the whole at91rm9200 dir, if all board support the
+new AT91-SoC access.
diff --git a/u-boot/doc/README.atmel_mci b/u-boot/doc/README.atmel_mci
new file mode 100644
index 0000000..dee0cf0
--- /dev/null
+++ b/u-boot/doc/README.atmel_mci
@@ -0,0 +1,85 @@
+How to use SD/MMC cards with Atmel SoCs having MCI hardware
+-----------------------------------------------------------
+2010-08-16 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+
+This is a new approach to use Atmel MCI hardware with the
+general MMC framework. Therefore it benefits from that
+framework's abilities to handle SDHC Cards and the ability
+to write blocks.
+
+- AT91SAM9XE512 (tested, will definitely work with XE128 and XE256)
+- AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
+- AT91SAM9G20 (not tested, should work)
+
+It should work with all other ATMEL devices that have MCI,
+including AVR32.
+
+The generic driver does NOT assign port pins to the MCI block
+nor does it start the MCI clock. This has to be handled in a
+board/SoC specific manner before the driver is initialized:
+
+example: this is added to at91sam9260_devices.c:
+
+#if defined(CONFIG_ATMEL_MCI) || defined(CONFIG_GENERIC_ATMEL_MCI)
+void at91_mci_hw_init(void)
+{
+	at91_set_a_periph(AT91_PIO_PORTA, 8, PUP);	/* MCCK */
+#if defined(CONFIG_ATMEL_MCI_PORTB)
+	at91_set_b_periph(AT91_PIO_PORTA, 1, PUP);	/* MCCDB */
+	at91_set_b_periph(AT91_PIO_PORTA, 0, PUP);	/* MCDB0 */
+	at91_set_b_periph(AT91_PIO_PORTA, 5, PUP);	/* MCDB1 */
+	at91_set_b_periph(AT91_PIO_PORTA, 4, PUP);	/* MCDB2 */
+	at91_set_b_periph(AT91_PIO_PORTA, 3, PUP);	/* MCDB3 */
+#else
+	at91_set_a_periph(AT91_PIO_PORTA, 7, PUP);	/* MCCDA */
+	at91_set_a_periph(AT91_PIO_PORTA, 6, PUP);	/* MCDA0 */
+	at91_set_a_periph(AT91_PIO_PORTA, 9, PUP);	/* MCDA1 */
+	at91_set_a_periph(AT91_PIO_PORTA, 10, PUP);	/* MCDA2 */
+	at91_set_a_periph(AT91_PIO_PORTA, 11, PUP);	/* MCDA3 */
+#endif
+}
+#endif
+
+the board specific file need added:
+...
+#ifdef CONFIG_GENERIC_ATMEL_MCI
+# include <mmc.h>
+#endif
+...
+#ifdef CONFIG_GENERIC_ATMEL_MCI
+/* this is a weak define that we are overriding */
+int board_mmc_init(bd_t *bd)
+{
+	/* Enable clock */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI);
+	at91_mci_hw_init();
+
+	/* This calls the atmel_mci_init in gen_atmel_mci.c */
+	return atmel_mci_init((void *)AT91_BASE_MCI);
+}
+
+/* this is a weak define that we are overriding */
+int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+{
+	/*
+	 * the only currently existing use of this function
+	 * (fsl_esdhc.c) suggests this function must return
+	 * *cs = TRUE if a card is NOT detected -> in most
+	 * cases the value of the pin when the detect switch
+	 * closes to GND
+	 */
+	*cd = at91_get_gpio_value (CONFIG_SYS_MMC_CD_PIN) ? 1 : 0;
+	return 0;
+}
+
+#endif
+
+and the board definition files needs:
+
+/* SD/MMC card */
+#define CONFIG_MMC			1
+#define CONFIG_GENERIC_MMC		1
+#define CONFIG_GENERIC_ATMEL_MCI	1
+#define CONFIG_ATMEL_MCI_PORTB		1	/* Atmel XE-EK uses port B */
+#define CONFIG_SYS_MMC_CD_PIN		AT91_PIN_PC9
+#define CONFIG_CMD_MMC			1
diff --git a/u-boot/doc/README.autoboot b/u-boot/doc/README.autoboot
new file mode 100644
index 0000000..2042fe5
--- /dev/null
+++ b/u-boot/doc/README.autoboot
@@ -0,0 +1,165 @@
+/*
+ * (C) Copyright 2001
+ * Dave Ellis, SIXNET, dge@sixnetio.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+Using autoboot configuration options
+====================================
+
+The basic autoboot configuration options are documented in the main
+U-Boot README. See it for details. They are:
+
+  bootdelay
+  bootcmd
+  CONFIG_BOOTDELAY
+  CONFIG_BOOTCOMMAND
+
+Some additional options that make autoboot safer in a production
+product are documented here.
+
+Why use them?
+-------------
+
+The basic autoboot feature allows a system to automatically boot to
+the real application (such as Linux) without a user having to enter
+any commands. If any key is pressed before the boot delay time
+expires, U-Boot stops the autoboot process, gives a U-Boot prompt
+and waits forever for a command. That's a good thing if you pressed a
+key because you wanted to get the prompt.
+
+It's not so good if the key press was a stray character on the
+console serial port, say because a user who knows nothing about
+U-Boot pressed a key before the system had time to boot. It's even
+worse on an embedded product that doesn't have a console during
+normal use. The modem plugged into that console port sends a
+character at the wrong time and the system hangs, with no clue as to
+why it isn't working.
+
+You might want the system to autoboot to recover after an external
+configuration program stops autoboot. If the configuration program
+dies or loses its connection (modems can disconnect at the worst
+time) U-Boot will patiently wait forever for it to finish.
+
+These additional configuration options can help provide a system that
+boots when it should, but still allows access to U-Boot.
+
+What they do
+------------
+
+  CONFIG_BOOT_RETRY_TIME
+  CONFIG_BOOT_RETRY_MIN
+
+  "bootretry" environment variable
+
+	These options determine what happens after autoboot is
+	stopped and U-Boot is waiting for commands.
+
+	CONFIG_BOOT_RETRY_TIME must be defined to enable the boot
+	retry feature. If the environment variable "bootretry" is
+	found then its value is used, otherwise the retry timeout is
+	CONFIG_BOOT_RETRY_TIME. CONFIG_BOOT_RETRY_MIN is optional and
+	defaults to CONFIG_BOOT_RETRY_TIME. All times are in seconds.
+
+	If the retry timeout is negative, the U-Boot command prompt
+	never times out. Otherwise it is forced to be at least
+	CONFIG_BOOT_RETRY_MIN seconds. If no valid U-Boot command is
+	entered before the specified time the boot delay sequence is
+	restarted. Each command that U-Boot executes restarts the
+	timeout.
+
+	If CONFIG_BOOT_RETRY_TIME < 0 the feature is there, but
+	doesn't do anything unless the environment variable
+	"bootretry" is >= 0.
+
+  CONFIG_AUTOBOOT_KEYED
+  CONFIG_AUTOBOOT_PROMPT
+  CONFIG_AUTOBOOT_DELAY_STR
+  CONFIG_AUTOBOOT_STOP_STR
+  CONFIG_AUTOBOOT_DELAY_STR2
+  CONFIG_AUTOBOOT_STOP_STR2
+
+  "bootdelaykey"  environment variable
+  "bootstopkey"	  environment variable
+  "bootdelaykey2" environment variable
+  "bootstopkey2"  environment variable
+
+	These options give more control over stopping autoboot. When
+	they are used a specific character or string is required to
+	stop or delay autoboot.
+
+	Define CONFIG_AUTOBOOT_KEYED (no value required) to enable
+	this group of options.	CONFIG_AUTOBOOT_DELAY_STR,
+	CONFIG_AUTOBOOT_STOP_STR or both should be specified (or
+	specified by the corresponding environment variable),
+	otherwise there is no way to stop autoboot.
+
+	CONFIG_AUTOBOOT_PROMPT is displayed before the boot delay
+	selected by CONFIG_BOOTDELAY starts. If it is not defined
+	there is no output indicating that autoboot is in progress.
+
+	Note that CONFIG_AUTOBOOT_PROMPT is used as the (only)
+	argument to a printf() call, so it may contain '%' format
+	specifications, provided that it also includes, sepearated by
+	commas exactly like in a printf statement, the required
+	arguments. It is the responsibility of the user to select only
+	such arguments that are valid in the given context. A
+	reasonable prompt could be defined as
+
+		#define CONFIG_AUTOBOOT_PROMPT \
+			"autoboot in %d seconds\n",bootdelay
+
+	If CONFIG_AUTOBOOT_DELAY_STR or "bootdelaykey" is specified
+	and this string is received from console input before
+	autoboot starts booting, U-Boot gives a command prompt. The
+	U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is
+	used, otherwise it never times out.
+
+	If CONFIG_AUTOBOOT_STOP_STR or "bootstopkey" is specified and
+	this string is received from console input before autoboot
+	starts booting, U-Boot gives a command prompt. The U-Boot
+	prompt never times out, even if CONFIG_BOOT_RETRY_TIME is
+	used.
+
+	The string recognition is not very sophisticated. If a
+	partial match is detected, the first non-matching character
+	is checked to see if starts a new match. There is no check
+	for a shorter partial match, so it's best if the first
+	character of a key string does not appear in the rest of the
+	string.
+
+	Using the CONFIG_AUTOBOOT_DELAY_STR2 #define or the
+	"bootdelaykey2" environment variable and/or the
+	CONFIG_AUTOBOOT_STOP_STR2 #define or the "bootstopkey"
+	environment variable you can specify a second, alternate
+	string (which allows you to have two "password" strings).
+
+  CONFIG_ZERO_BOOTDELAY_CHECK
+
+	If this option is defined, you can stop the autoboot process
+	by hitting a key even in that case when "bootdelay" has been
+	set to 0. You can set "bootdelay" to a negative value to
+	prevent the check for console input.
+
+  CONFIG_RESET_TO_RETRY
+
+	(Only effective when CONFIG_BOOT_RETRY_TIME is also set)
+	After the countdown timed out, the board will be reset to restart
+	again.
diff --git a/u-boot/doc/README.bamboo b/u-boot/doc/README.bamboo
new file mode 100644
index 0000000..e139c6d
--- /dev/null
+++ b/u-boot/doc/README.bamboo
@@ -0,0 +1,77 @@
+The 2 important dipswitches are configured as shown below:
+
+SW1 (for 33MHz SysClk)
+----------------------
+S1   S2   S3   S4   S5   S6   S7   S8
+OFF  OFF  OFF  OFF  OFF  OFF  OFF  ON
+
+SW7 (for Op-Code Flash and Boot Option H)
+-----------------------------------------
+S1   S2   S3   S4   S5   S6   S7   S8
+OFF  OFF  OFF  ON   OFF  OFF  OFF  OFF
+
+The EEPROM at location 0x52 is loaded with these 16 bytes:
+C47042A6 05D7A190 40082350 0d050000
+
+SDR0_SDSTP0[ENG]:	1		: PLL's VCO is the source for PLL forward divisors
+SDR0_SDSTP0[SRC]:	1		: Feedback originates from PLLOUTB
+SDR0_SDSTP0[SEL]:	0		: Feedback selection is PLL output
+SDR0_SDSTP0[TUNE]:	1000111000	: 10 <= M <= 22, 600MHz < VCO <= 900MHz
+SDR0_SDSTP0[FBDV]:	4		: PLL feedback divisor
+SDR0_SDSTP0[FBDVA]:	2		: PLL forward divisor A
+SDR0_SDSTP0[FBDVB]:	5		: PLL forward divisor B
+SDR0_SDSTP0[PRBDV0]:	1		: PLL primary divisor B
+SDR0_SDSTP0[OPBDV0]:	2		: OPB clock divisor
+SDR0_SDSTP0[LFBDV]:	1		: PLL local feedback divisor
+SDR0_SDSTP0[PERDV0]:	3		: Peripheral clock divisor 0
+SDR0_SDSTP0[MALDV0]:	2		: MAL clock divisor 0
+SDR0_SDSTP0[PCIDV0]:	2		: Sync PCI clock divisor 0
+SDR0_SDSTP0[PLLTIMER]:	7		: PLL locking timer
+SDR0_SDSTP0[RW]:	1		: EBC ROM width: 16-bit
+SDR0_SDSTP0[RL]:	0		: EBC ROM location: EBC
+SDR0_SDSTP0[PAE]:	0		: PCI internal arbiter: disabled
+SDR0_SDSTP0[PHCE]:	0		: PCI host configuration: disabled
+SDR0_SDSTP0[ZM]:	3		: ZMII mode: RMII mode 100
+SDR0_SDSTP0[CTE]:	0		: CPU trace: disabled
+SDR0_SDSTP0[Nto1]:	0		: CPU/PLB ratio N/P: not N to 1
+SDR0_SDSTP0[PAME]:	1		: PCI asynchronous mode: enabled
+SDR0_SDSTP0[MEM]:	1		: Multiplex: EMAC
+SDR0_SDSTP0[NE]:	0		: NDFC: disabled
+SDR0_SDSTP0[NBW]:	0		: NDFC boot width: 8-bit
+SDR0_SDSTP0[NBW]:	0		: NDFC boot page selection
+SDR0_SDSTP0[NBAC]:	0		: NDFC boot address selection cycle: 3 Addr. Cycles, 1 Col. + 2 Row (512 page size)
+SDR0_SDSTP0[NARE]:	0		: NDFC auto read : disabled
+SDR0_SDSTP0[NRB]:	0		: NDFC Ready/Busy : Ready
+SDR0_SDSTP0[NDRSC]:	33333		: NDFC device reset counter
+SDR0_SDSTP0[NCG0]:	0		: NDFC/EBC chip select gating CS0 : EBC
+SDR0_SDSTP0[NCG1]:	0		: NDFC/EBC chip select gating CS1 : EBC
+SDR0_SDSTP0[NCG2]:	0		: NDFC/EBC chip select gating CS2 : EBC
+SDR0_SDSTP0[NCG3]:	0		: NDFC/EBC chip select gating CS3 : EBC
+SDR0_SDSTP0[NCRDC]:	3333		: NDFC device read count
+
+PPC440EP Clocking Configuration
+
+SysClk is 33.0MHz, M is 20, VCO is 660.0MHz, CPU is 330.0MHz, PLB is 132.0MHz
+OPB is 66.0MHz, EBC is 44.0MHz, MAL is 66.0MHz, Sync PCI is 66.0MHz
+
+The above information is reported by Eugene O'Brien
+<Eugene.O'Brien@advantechamt.com>. Thanks a lot.
+
+2007-08-06, Stefan Roese <sr@denx.de>
+---------------------------------------------------------------------
+
+The configuration for the AMCC 440EP eval board "Bamboo" was changed
+to only use 384 kbytes of FLASH for the U-Boot image. This way the
+redundant environment can be saved in the remaining 2 sectors of the
+same flash chip.
+
+Caution: With an upgrade from an earlier U-Boot version the current
+environment will be erased since the environment is now saved in
+different sectors. By using the following command the environment can
+be saved after upgrading the U-Boot image and *before* resetting the
+board:
+
+setenv recover_env 'prot off FFF80000 FFF9FFFF;era FFF80000 FFF9FFFF;' \
+	'cp.b FFF60000 FFF80000 20000'
+
+2006-07-27, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/README.bedbug b/u-boot/doc/README.bedbug
new file mode 100644
index 0000000..35e9d27
--- /dev/null
+++ b/u-boot/doc/README.bedbug
@@ -0,0 +1,78 @@
+BEDBUG Support for U-Boot
+--------------------------
+
+These changes implement the bedbug (emBEDded deBUGger) debugger in U-Boot.
+A specific implementation is made for the AMCC 405 processor but other flavors
+can be easily implemented.
+
+#####################
+### Modifications ###
+#####################
+
+./common/Makefile
+	Included cmd_bedbug.c and bedbug.c in the Makefile.
+
+./common/command.c
+	Added bedbug commands to command table.
+
+./common/board.c
+	Added call to initialize debugger on startup.
+
+./arch/powerpc/cpu/ppc4xx/Makefile
+	Added bedbug_405.c to the Makefile.
+
+./arch/powerpc/cpu/ppc4xx/start.S
+	Added code to handle the debug exception (0x2000) on the 405.
+	Also added code to handle critical exceptions since the debug
+	is treated as critical on the 405.
+
+./arch/powerpc/cpu/ppc4xx/traps.c
+	Added more detailed output for the program exception to tell
+	if it is an illegal instruction, privileged instruction or
+	a trap. Also added debug trap handler.
+
+./include/ppc_asm.tmpl
+	Added code to handle critical exceptions
+
+#################
+### New Stuff ###
+#################
+
+./include/bedbug/ppc.h
+./include/bedbug/regs.h
+./include/bedbug/bedbug.h
+./include/bedbug/elf.h		[obsoleted by new include/elf.h]
+./include/bedbug/tables.h
+./include/cmd_bedbug.h
+./common/cmd_bedbug.c
+./common/bedbug.c
+	Bedbug library includes code for assembling and disassembling
+	PowerPC instructions to/from memory as well as handling
+	hardware breakpoints and stepping through code.  These
+	routines are common to all PowerPC processors.
+
+./arch/powerpc/cpu/ppc4xx/bedbug_405.c
+	AMCC  PPC405 specific debugger routines.
+
+
+Bedbug support for the MPC860
+-----------------------------
+
+Changes:
+
+	common/cmd_bedbug.c
+		Added call to initialize 860 debugger.
+
+	arch/powerpc/cpu/mpc8xx/Makefile
+		Added new file "bedbug_860.c" to the makefile
+
+	arch/powerpc/cpu/mpc8xx/start.S
+		Added handler for InstructionBreakpoint (0xfd00)
+
+	arch/powerpc/cpu/mpc8xx/traps.c
+		Added new routine DebugException()
+
+New Files:
+
+	arch/powerpc/cpu/mpc8xx/bedbug_860.c
+		CPU-specific routines for 860 debug registers.
diff --git a/u-boot/doc/README.bitbangMII b/u-boot/doc/README.bitbangMII
new file mode 100644
index 0000000..0a2fa48
--- /dev/null
+++ b/u-boot/doc/README.bitbangMII
@@ -0,0 +1,56 @@
+This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
+support an arbitrary number of mii buses. This feature is useful when your
+board uses different mii buses for different phys and all (or a part) of these
+buses are implemented via bit-banging mode.
+
+The driver requires that the following macros should be defined into the board
+configuration file:
+
+CONFIG_BITBANGMII	- Enable the miiphybb driver
+CONFIG_BITBANGMII_MULTI - Enable the multi bus support
+
+If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs
+to define at least the following macros:
+
+MII_INIT      - Generic code to enable the MII bus (optional)
+MDIO_DECLARE  - Declaration needed to access to the MDIO pin (optional)
+MDIO_ACTIVE   - Activate the MDIO pin as out pin
+MDIO_TRISTATE - Activate the MDIO pin as input/tristate pin
+MDIO_READ     - Read the MDIO pin
+MDIO(v)       - Write v on the MDIO pin
+MDC_DECLARE   - Declaration needed to access to the MDC pin (optional)
+MDC(v)	      - Write v on the MDC pin
+
+The previous macros make the driver compatible with the previous version
+(that didn't support the multi-bus).
+
+When the CONFIG_BITBANGMII_MULTI is also defined, the board code needs to fill
+the bb_miiphy_buses[] array with a record for each required bus and declare
+the bb_miiphy_buses_num variable with the number of mii buses.
+The record (struct bb_miiphy_bus) has the following fields/callbacks (see
+miiphy.h for details):
+
+char name[]	       - The symbolic name that must be equal to the MII bus
+			 registered name
+int (*init)()	       - Initialization function called at startup time (just
+			 before the Ethernet initialization)
+int (*mdio_active)()   - Activate the MDIO pin as output
+int (*mdio_tristate)() - Activate the MDIO pin as input/tristate pin
+int (*set_mdio)()      - Write the MDIO pin
+int (*get_mdio)()      - Read the MDIO pin
+int (*set_mdc)()       - Write the MDC pin
+int (*delay)()	       - Delay function
+void *priv	       - Private data used by board specific code
+
+The board code will look like:
+
+struct bb_miiphy_bus bb_miiphy_buses[] = {
+ { .name = "miibus#1", .init = b1_init, .mdio_active = b1_mdio_active, ... },
+ { .name = "miibus#2", .init = b2_init, .mdio_active = b2_mdio_active, ... },
+ ...
+};
+int bb_miiphy_buses_num = sizeof(bb_miiphy_buses) /
+			  sizeof(bb_miiphy_buses[0]);
+
+2009 Industrie Dial Face S.p.A.
+     Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
diff --git a/u-boot/doc/README.blackfin b/u-boot/doc/README.blackfin
new file mode 100644
index 0000000..a837d90
--- /dev/null
+++ b/u-boot/doc/README.blackfin
@@ -0,0 +1,46 @@
+Notes for the Blackfin architecture port of Das U-Boot
+
+ =========
+ ! ABOUT !
+ =========
+
+<marketing blurb>
+Blackfin Processors embody a new breed of 16/32-bit embedded processor, ideally
+suited for products where a convergence of capabilities are necessary -
+multi-format audio, video, voice and image processing; multi-mode baseband and
+packet processing; control processing; and real-time security.  The Blackfin's
+unique combination of software flexibility and scalability has gained it
+widespread adoption in convergent applications.
+</marketing blurb>
+
+The Blackfin processor is wholly developed by Analog Devices Inc.
+
+ ===========
+ ! SUPPORT !
+ ===========
+
+All open source code for the Blackfin processors are being handled via our
+collaborative website:
+http://blackfin.uclinux.org/
+
+In particular, bug reports, feature requests, help etc... for Das U-Boot are
+handled in the Das U-Boot sub project:
+http://blackfin.uclinux.org/gf/project/u-boot
+
+This website is backed both by an open source community as well as a dedicated
+team from Analog Devices Inc.
+
+ =============
+ ! TOOLCHAIN !
+ =============
+
+To compile the Blackfin aspects, you'll need the GNU toolchain configured for
+the Blackfin processor.  You can obtain such a cross-compiler here:
+http://blackfin.uclinux.org/gf/project/toolchain
+
+ =================
+ ! DOCUMENTATION !
+ =================
+
+For Blackfin specific documentation, you can visit our dedicated doc wiki:
+http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot
diff --git a/u-boot/doc/README.bus_vcxk b/u-boot/doc/README.bus_vcxk
new file mode 100644
index 0000000..cbcd8c9
--- /dev/null
+++ b/u-boot/doc/README.bus_vcxk
@@ -0,0 +1,84 @@
+/*
+ * (C) Copyright 2008-2009
+ * BuS Elektronik GmbH & Co. KG <www.bus-elektronik.de>
+ * Jens Scharsig <esw@bus-elektronik.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+U-Boot vcxk video controller driver
+======================================
+
+By defining CONFIG_VIDEO_VCXK this driver can be used with VC2K, VC4K and
+VC8K devices on following boards:
+
+board           | ARCH          | Vendor
+-----------------------------------------------------------------------
+EB+CPU5282-T1   | MCF5282       | BuS Elektronik GmbH & Co. KG
+EB+MCF-EVB123   | MCF5282       | BuS Elektronik GmbH & Co. KG
+EB+CPUx9K2      | AT91RM9200    | BuS Elektronik GmbH & Co. KG
+ZLSA            | AT91RM9200    | Ruf Telematik AG
+
+Driver configuration
+--------------------
+
+The driver needs some defines to describe the target hardware:
+
+CONFIG_SYS_VCXK_BASE
+
+	base address of VCxK hardware memory
+
+CONFIG_SYS_VCXK_DEFAULT_LINEALIGN
+
+	defines the physical alignment of a pixel row
+
+CONFIG_SYS_VCXK_DOUBLEBUFFERED
+
+	some boards that use vcxk prevent read from framebuffer memory.
+	define this option to enable double buffering (needs 16KiB RAM)
+
+CONFIG_SYS_VCXK_<xxxx>_PIN
+
+	defines the number of the I/O line PIN in the port
+	valid values for <xxxx> are:
+
+		ACKNOWLEDGE
+			describes the acknowledge line from vcxk hardware
+
+		ENABLE
+			describes the enable line to vcxk hardware
+
+		INVERT
+			describes the invert line to vcxk hardware
+
+		RESET
+			describes the reset line to vcxk hardware
+
+		REQUEST
+			describes the request line to vcxk hardware
+
+CONFIG_SYS_VCXK_<xxxx>_PORT
+
+	defines the I/O port which is connected with the line
+	for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN
+
+CONFIG_SYS_VCXK_<xxxx>_DDR
+
+	defines the register which configures the direction
+	for valid values for <xxxx> see CONFIG_SYS_VCXK_<xxxx>_PIN
diff --git a/u-boot/doc/README.cfi b/u-boot/doc/README.cfi
new file mode 100644
index 0000000..d087ff0
--- /dev/null
+++ b/u-boot/doc/README.cfi
@@ -0,0 +1,29 @@
+The common CFI driver provides this weak default implementation for
+flash_cmd_reset():
+
+void __flash_cmd_reset(flash_info_t *info)
+{
+	/*
+	 * We do not yet know what kind of commandset to use, so we issue
+	 * the reset command in both Intel and AMD variants, in the hope
+	 * that AMD flash roms ignore the Intel command.
+	 */
+	flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+	flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
+}
+void flash_cmd_reset(flash_info_t *info)
+	__attribute__((weak,alias("__flash_cmd_reset")));
+
+
+Some flash chips seems to have trouble with this reset sequence. In this case
+the board specific code can override this weak default version with a board
+specific function. For example the digsy_mtc board equipped with the M29W128GH
+from Numonyx needs this version to function properly:
+
+void flash_cmd_reset(flash_info_t *info)
+{
+	flash_write_cmd(info, 0, 0, AMD_CMD_RESET);
+}
+
+see also:
+http://www.mail-archive.com/u-boot@lists.denx.de/msg24368.html
diff --git a/u-boot/doc/README.cmi b/u-boot/doc/README.cmi
new file mode 100644
index 0000000..0edd50a
--- /dev/null
+++ b/u-boot/doc/README.cmi
@@ -0,0 +1,84 @@
+
+Summary:
+========
+
+This file contains information about the cmi board configuration.
+Please see cmi_mpc5xx_config for further details. The cmi board is
+a customer specific board but should work with small modifications
+on every board which has a MPC5xx and either a 28F128J3A,
+28F320J3A or 28F640J3A Intel flash mounted.
+
+Board Discription:
+==================
+
+* Motorola MPC555
+* RS232 connection
+* Intel flash 28F640J3A
+* Micron SRAM 1M
+* Altera PLD
+
+Bootstrap:
+==========
+
+In contrast to the usual boot sequence used in U-Boot, on the
+cmi board we don't boot from the external flash directly.
+Because of we use a 16-bit flash and don't sample a RCW
+from the data bus to set the startup buswidth to 16-bit.
+Unfortunatly the default width, sampled from the default RCW
+is 32-bit. For this reason we burn the proper RCW into the
+internal flash shadow location and boot after power-on or
+reset from the internal flash and then branch to 0x02000100
+where the U-Boot reset vector handler is located.
+
+Memory Map:
+===========
+
+Memory Map after relocation:
+
+    0x0000 0000		CONFIG_SYS_SDRAM_BASE
+	  :
+    0x000F 9FFF
+	  :
+	  :
+    0x0100 0000		CONFIG_SYS_IMMR (Internal memory map base adress)
+	  :
+    0x0130 7FFF
+	  :
+	  :
+    0x0200 0000		CONFIG_SYS_FLASH_BASE
+	  :
+    0x027C FFFF
+	  :
+	  :
+    0x0300 0000		PLD_BASE
+
+Flash Partition:
+
+    0x0200 0000		Block 0 and 1 contain U-Boot except
+	  :		environment
+	  :
+    0x0201 FFFF
+    0x0202 0000		Block 2 contains environment (.ppcenv)
+	  :
+    0x0202 FFFF
+
+See README file for futher information about U-Boot relocation
+and partitioning.
+
+Tested Features:
+================
+
+* U-Boot commands: go, loads, loadb, all memory features, printenv,
+  setenv, saveenv, protect, erase, fli, bdi, mtest, reset, version,
+  coninfo, help (see configuration file for available commands)
+
+* Blinking led to indicate boot process
+
+Added or Changed Files:
+=======================
+
+u-boot-0.2.0/board/cmi/*
+u-boot-0.2.0/include/configs/cmi_mpc5xx.h
+
+Regards,
+Martin
diff --git a/u-boot/doc/README.commands b/u-boot/doc/README.commands
new file mode 100644
index 0000000..d678992
--- /dev/null
+++ b/u-boot/doc/README.commands
@@ -0,0 +1,31 @@
+
+Commands are added to U-Boot by creating a new command structure.
+This is done by first including command.h
+
+Then using the U_BOOT_CMD() macro to fill in a cmd_tbl_t struct.
+
+U_BOOT_CMD(name,maxargs,repeatable,command,"usage","help")
+
+name:	 is the name of the commad. THIS IS NOT a string.
+maxargs: the maximumn numbers of arguments this function takes
+command: Function pointer (*cmd)(struct cmd_tbl_s *, int, int, char *[]);
+usage:	 Short description. This is a string
+help:	 long description. This is a string
+
+
+**** Behinde the scene ******
+
+The structure created is named with a special prefix (__u_boot_cmd_)
+and placed by the linker in a special section.
+
+This makes it possible for the final link to extract all commands
+compiled into any object code and construct a static array so the
+command can be found in an array starting at __u_boot_cmd_start.
+
+If a new board is defined do not forget to define the command section
+by writing in u-boot.lds ($(TOPDIR)/board/boardname/u-boot.lds) these
+3 lines:
+
+	__u_boot_cmd_start = .;
+	.u_boot_cmd : { *(.u_boot_cmd) }
+	__u_boot_cmd_end = .;
diff --git a/u-boot/doc/README.commands.itest b/u-boot/doc/README.commands.itest
new file mode 100644
index 0000000..5e0fe86
--- /dev/null
+++ b/u-boot/doc/README.commands.itest
@@ -0,0 +1,16 @@
+A slow day today so here is a revised itest command with provisional
+support for comparing strings as well :-))
+
+Now table driven to allow the operators
+-eq, -ne, -lt, -gt, -le, -ge, ==, !=, <>, <, >, <=, >=
+
+Uses the expected command modifier for integer compares of width 1, 2 or
+4 bytes of .b, .w, .l and the new modifer of .s for a string compare.
+String comparison is over the length of the shorter, this hopefully
+avoids missing terminators when using an indirect pointer.
+
+eg.
+if itest.l *40000 == 12345678 then; ....
+if itest.w *40000 != 1234 then; ....
+if itest.b *40000 >= 12 then; ....
+if itest.s *40000 -eq hello then; ....
diff --git a/u-boot/doc/README.console b/u-boot/doc/README.console
new file mode 100644
index 0000000..25c4f1d
--- /dev/null
+++ b/u-boot/doc/README.console
@@ -0,0 +1,118 @@
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+U-Boot console handling
+========================
+
+HOW THE CONSOLE WORKS?
+----------------------
+
+At system startup U-Boot initializes a serial console. When U-Boot
+relocates itself to RAM, all console drivers are initialized (they
+will register all detected console devices to the system for further
+use).
+
+If not defined in the environment, the first input device is assigned
+to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
+
+You can use the command "coninfo" to see all registered console
+devices and their flags. You can assign a standard file (stdin,
+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 stdout video		<- To use the video console
+
+Do a simple "saveenv" to save the console settings in the environment
+and get them working on the next startup, too.
+
+HOW CAN I USE STANDARD FILE INTO THE SOURCES?
+---------------------------------------------
+
+You can use the following functions to access the console:
+
+* STDOUT:
+    putc	(to put a char to stdout)
+    puts	(to put a string to stdout)
+    printf	(to format and put a string to stdout)
+
+* STDIN:
+    tstc	(to test for the presence of a char in stdin)
+    getc	(to get a char from stdin)
+
+* STDERR:
+    eputc	(to put a char to stderr)
+    eputs	(to put a string to stderr)
+    eprintf	(to format and put a string to stderr)
+
+* FILE (can be 'stdin', 'stdout', 'stderr'):
+    fputc	(like putc but redirected to a file)
+    fputs	(like puts but redirected to a file)
+    fprintf	(like printf but redirected to a file)
+    ftstc	(like tstc but redirected to a file)
+    fgetc	(like getc but redirected to a file)
+
+Remember that all FILE-related functions CANNOT be used before
+U-Boot relocation (done in 'board_init_r' in common/board.c).
+
+HOW CAN I USE STANDARD FILE INTO APPLICATIONS?
+----------------------------------------------
+
+Use the 'bd_mon_fnc' field of the bd_t structure passed to the
+application to do everything you want with the console.
+
+But REMEMBER that that will work only if you have not overwritten any
+U-Boot code while loading (or uncompressing) the image of your
+application.
+
+For example, you won't get the console stuff running in the Linux
+kernel because the kernel overwrites U-Boot before running. Only
+some parameters like the framebuffer descriptors are passed to the
+kernel in the high memory area to let the applications (the kernel)
+use the framebuffers initialized by U-Boot.
+
+SUPPORTED DRIVERS
+-----------------
+
+Working drivers:
+
+    serial	(architecture dependent serial stuff)
+    video	(mpc8xx video controller)
+
+Work in progress:
+
+    wl_kbd	(Wireless 4PPM keyboard)
+
+Waiting for volounteers:
+
+    lcd	(mpc8xx lcd controller; to )
+
+TESTED CONFIGURATIONS
+---------------------
+
+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/u-boot/doc/README.davinci b/u-boot/doc/README.davinci
new file mode 100644
index 0000000..0204372
--- /dev/null
+++ b/u-boot/doc/README.davinci
@@ -0,0 +1,141 @@
+Summary
+=======
+
+This README is about U-Boot support for TI's ARM 926EJS based family of SoCs.
+These SOCs are used for cameras, video security and surveillance, DVR's, etc.
+DaVinci SOC's comprise of DM644x, DM646x, DM35x and DM36x series of SOC's
+Additionally there are some SOCs meant for the audio market which though have
+an OMAP part number are very similar to the DaVinci series of SOC's
+Additionally, some family members contain a TI DSP and/or graphics
+co processors along with a host of other peripherals.
+
+Currently the following boards are supported:
+
+* TI DaVinci DM644x EVM
+
+* TI DaVinci DM646x EVM
+
+* TI DaVinci DM355 EVM
+
+* TI DaVinci DM365 EVM
+
+* TI DA830 EVM
+
+* TI DA850 EVM
+
+* DM355 based Leopard board
+
+* DM644x based schmoogie board
+
+* DM644x based sffsdr board
+
+* DM644x based sonata board
+
+Build
+=====
+
+* TI DaVinci DM644x EVM:
+
+make davinci_dvevm_config
+make
+
+* TI DaVinci DM646x EVM:
+
+make davinci_dm6467evm_config
+make
+
+* TI DaVinci DM355 EVM:
+
+make davinci_dm355evm_config
+make
+
+* TI DaVinci DM365 EVM:
+
+make davinci_dm365evm_config
+make
+
+* TI DA830 EVM:
+
+make da830evm_config
+make
+
+* TI DA850 EVM:
+
+make da850evm_config
+make
+
+* DM355 based Leopard board:
+
+make davinci_dm355leopard_config
+make
+
+* DM644x based schmoogie board:
+
+make davinci_schmoogie_config
+make
+
+* DM644x based sffsdr board:
+
+make davinci_sffsdr_config
+make
+
+* DM644x based sonata board:
+
+make davinci_sonata_config
+make
+
+Bootloaders
+===============
+
+The DaVinci SOC's use 2 bootloaders. The low level initialization
+is done by a UBL(user boot loader). The UBL is written to a NAND/NOR/SPI flash
+by a programmer. During initial bootup, the ROM Bootloader reads the UBL
+from a storage device and loads it into the IRAM. The UBL then loads the U-Boot
+into the RAM.
+The programmers and UBL are always released as part of any standard TI
+software release associated with an SOC.
+
+Environment Variables
+=====================
+
+The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
+silicon, in Hz, via an environment variable "maxcpuclk".
+
+The maximum clock rate allowed depends on the silicon populated on the EVM.
+Please make sure you understand the restrictions placed on this clock in the
+device specific datasheet before setting up this variable. This information is
+passed to the Linux kernel using the ATAG_REVISION atag.
+
+If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
+is used to obtain this information.
+
+Links
+=====
+
+1) TI DaVinci DM355 EVM:
+http://focus.ti.com/docs/prod/folders/print/tms320dm355.html
+http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=203&osCsid=c499af6087317f11b3da19b4e8f1af32
+
+2) TI DaVinci DM365 EVM:
+http://focus.ti.com/docs/prod/folders/print/tms320dm365.html?247SEM=
+http://support.spectrumdigital.com/boards/evmdm365/revc/
+
+3) DaVinci DM355 based leopard board
+http://designsomething.org/leopardboard/default.aspx
+http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=192&osCsid=67c20335668ffc57cb35727106eb24b1
+
+4) TI DaVinci DM6467 EVM:
+http://focus.ti.com/docs/prod/folders/print/tms320dm6467.html
+http://support.spectrumdigital.com/boards/evmdm6467/revf/
+
+5) TI DaVinci DM6446 EVM:
+http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html
+http://www.spectrumdigital.com/product_info.php?cPath=103&products_id=222
+
+6) TI DA830 EVM
+http://focus.ti.com/apps/docs/gencontent.tsp?appId=1&contentId=52385
+http://www.spectrumdigital.com/product_info.php?cPath=37&products_id=214
+
+7) TI DA850 EVM
+http://focus.ti.com/docs/prod/folders/print/omap-l138.html
+http://www.logicpd.com/products/development-kits/zoom-omap-l138-evm-development-kit
diff --git a/u-boot/doc/README.db64360 b/u-boot/doc/README.db64360
new file mode 100644
index 0000000..ebac4ce
--- /dev/null
+++ b/u-boot/doc/README.db64360
@@ -0,0 +1,105 @@
+This file contains status information for the port of the U-Boot to the Marvell Development Board DB64360.
+
+Author: Ronen Shitrit <rshitrit@il.marvell.com>
+
+This U-Boot version is based on the work of Brian Waite and his team from Sky Computers, THANKS A LOT.
+
+Supported CPU Types :
++++++++++++++++++++++
+ IBM750FX (ver 2.3)
+ MPC7455 (ver 2.1)
+
+Supported CPU Cache Library:
+++++++++++++++++++++++++++++
+ L1 and L2 only.
+
+CPU Control:
+++++++++++++
+ Marvell optimized CPU control settings:
+  Big Endian
+  Enable CPU pipeline
+  Data and address parity checking
+  AACK# assert after 2 cycles
+
+U-Boot I/O Interface Support:
++++++++++++++++++++++++++++++
+- Serial Interface (UART)
+  This version of U-Boot supports the SIO U-Boot interface driver, with a PC standard baud rate up to 115200 BPS on the ST16C2552 DUART device located on DB-64360-BP device module.
+- Network Interface
+  This LSP supports the following network devices:
+  o MV64360 Gigabit Ethernet Controller device
+  o Intel 82559 PCI NIC device
+- PCI Interface
+  This LSP supports the following capabilities over the Marvell(r) device PCI0/1 units:
+  o Local PCI configuration header control.
+  o External PCI configuration header control (for other agents on the bus).
+  o PCI configuration application. Scans and configures the PCI agents on the bus.
+  o PCI Internal Arbiter activation and configuration.
+
+Memory Interface Support:
++++++++++++++++++++++++++
+- DDR
+  o DDR auto-detection and configuration. Enables access up to 256 MB, due to the limitations of using only four Base Address Translations (BATs).
+  o Enable DDR ECC in case both DIMM support ECC, and initialize the entire DDR memory by using the idma.
+
+- Devices
+  o Initializes the MV64360 device's chip-selects 0-3 to enable access to the boot flash, main flash, real time clock (RTC), and external SRAM.
+  o JFFS2
+    JFFS2 is a crash/power down safe file system for disk-less embedded devices.
+    This version of U-Boot supports scanning a JFFS2 file system on the large flash and loading files from it.
+
+Unsupported Features:
++++++++++++++++++++++
+ Messaging unit - No support for MV64360 Messaging unit.
+ Watchdog Timer - No support for MV64360 Watchdog unit.
+ L3 cache - No support for L3 cache on MPC7455
+ Dual PCU - No support for Dual CPU
+ PCI-X was never tested
+ IDMA driver - No support for MV64360 IDMA unit.
+
+BSP Special Considerations:
++++++++++++++++++++++++++++
+- DDR DIMM location: Due to PCI specifications, place the larger DIMM module in the MAIN DIMM slot, in order to have full access from the PCI to the DDR while using both DDR slots.
+- DDR DIMM types: Due to architectural and software limitations, the registration, CAS Latency, and ECC of both DIMMS should be identical.
+
+Test Cases:
+###########
+UART:
++++++
+Check that the UART baud rate is configured to 57600 and 115200, and check:
+	Transmit (to the hyper terminal) and Receive (using the keyboard) using Linux minicom.
+	Load S-Record file over the UART using Windows HyperTerminal.
+
+Network:
+++++++++
+Use TFTP application to load a debugged executable and execute it.
+Insert Intel PCI NIC 82557 rev 08 to PCI slots 0-3 Check correct detection of the PCI NIC, correct configuration of the NIC BARs , and load files by using tftp through the PCI NIC.
+
+Memory:
++++++++
+Test DDR DIMMs on DB-64360-BP. See that Uboot report their correct parameters:
+o	128MB DIMM consist of 16 x 64Mbit devices
+o	128MB DIMM consist of 09 x 128Mbit devices @ 266MHz.
+o	256MB DIMM consist of 16 x 128Mbit devices @ 266MHz.
+o	256MB DIMM consist of 09 x 256Mbit devices @ 400MHz.
+o	512MB DIMM consist of 16 x 256Mbit devices @ 333MHz.
+o	512MB DIMM consist of 18 x 256Mbit devices @ 266MHz.
+o	GigaB DIMM consist of 36 x 256Mbit devices @ 266MHz registered
+
+For each chip select device perform data access to verify its accessibility.
+
+Create a JFFS2 on the large flash through the Linux holding few files, few dirs and a uImage.
+Load the U-Boot and:
+use the ls command to check correct scan of the JFFS2 on the large flash.
+Use the floads command to copy the uImage from the JFFS2 on the large flash to the DIMM SDRAM, and boot the uImage.
+
+PCI:
+++++
+1)Insert different PCI cards:
+Galileo 64120A rev 10 and 12, Intel Nic 82557 rev 08 and Real Tech  NIC 8139 rev10
+on different slots (0-3) of the PCI and check:
+o	Correct detection of the PCI devices.
+o	Correct address mapping of the PCI devices.
+2)Insert Galileo 64120A rev 10 on different slots (0-3) of the PCI and check writing and reading pci configuration register through the U-Boot.
+
+Booting Linux through the U-Boot (use the bootargs of the U-Boot as a bootcmd to the kernal)
diff --git a/u-boot/doc/README.db64460 b/u-boot/doc/README.db64460
new file mode 100644
index 0000000..c6e01fe
--- /dev/null
+++ b/u-boot/doc/README.db64460
@@ -0,0 +1,105 @@
+This file contains status information for the port of the U-Boot to the Marvell Development Board DB64460.
+
+Author: Ronen Shitrit <rshitrit@il.marvell.com>
+
+
+Supported CPU Types :
++++++++++++++++++++++
+IBM750Gx Rev 1.0
+MPC7457 Rev 1.1
+
+Supported CPU Cache Library:
+++++++++++++++++++++++++++++
+ L1 and L2 only.
+
+CPU Control:
+++++++++++++
+ Marvell optimized CPU control settings:
+  Big Endian
+  Enable CPU pipeline
+  Data and address parity checking
+  AACK# assert after 2 cycles
+
+U-Boot I/O Interface Support:
++++++++++++++++++++++++++++++
+- Serial Interface (UART)
+  This version of U-Boot supports the SIO U-Boot interface driver, with a PC standard baud rate up to 115200 BPS on the ST16C2552 DUART device located on DB-64360-BP device module.
+- Network Interface
+  This LSP supports the following network devices:
+  o MV64360 Gigabit Ethernet Controller device
+  o Intel 82559 PCI NIC device
+- PCI Interface
+  This LSP supports the following capabilities over the Marvell(r) device PCI0/1 units:
+  o Local PCI configuration header control.
+  o External PCI configuration header control (for other agents on the bus).
+  o PCI configuration application. Scans and configures the PCI agents on the bus.
+  o PCI Internal Arbiter activation and configuration.
+
+Memory Interface Support:
++++++++++++++++++++++++++
+- DDR
+  o DDR auto-detection and configuration. Enables access up to 256 MB, due to the limitations of using only four Base Address Translations (BATs).
+  o Enable DDR ECC in case both DIMM support ECC, and initialize the entire DDR memory by using the idma.
+
+- Devices
+  o Initializes the MV64360 device's chip-selects 0-3 to enable access to the boot flash, main flash, real time clock (RTC), and external SRAM.
+  o JFFS2
+    JFFS2 is a crash/power down safe file system for disk-less embedded devices.
+    This version of U-Boot supports scanning a JFFS2 file system on the large flash and loading files from it.
+
+Unsupported Features:
++++++++++++++++++++++
+ Messaging unit - No support for MV64360 Messaging unit.
+ Watchdog Timer - No support for MV64360 Watchdog unit.
+ L3 cache - No support for L3 cache on MPC7455
+ Dual PCU - No support for Dual CPU
+ PCI-X was never tested
+ IDMA driver - No support for MV64360 IDMA unit.
+ XOR Engine - No support for MV64460 XOR Engine
+
+BSP Special Considerations:
++++++++++++++++++++++++++++
+- DDR DIMM location: Due to PCI specifications, place the larger DIMM module in the MAIN DIMM slot, in order to have full access from the PCI to the DDR while using both DDR slots.
+- DDR DIMM types: Due to architectural and software limitations, the registration, CAS Latency, and ECC of both DIMMS should be identical.
+
+Test Cases:
+###########
+UART:
++++++
+Check that the UART baud rate is configured to 57600 and 115200, and check:
+	Transmit (to the hyper terminal) and Receive (using the keyboard) using Linux minicom.
+	Load S-Record file over the UART using Windows HyperTerminal.
+
+Network:
+++++++++
+Use TFTP application to load a debugged executable and execute it.
+Insert Intel PCI NIC 82557 rev 08 to PCI slots 0-3 Check correct detection of the PCI NIC, correct configuration of the NIC BARs , and load files by using tftp through the PCI NIC.
+
+Memory:
++++++++
+Test DDR DIMMs on DB-64360-BP. See that Uboot report their correct parameters:
+o	128MB DIMM consist of 16 x 64Mbit devices
+o	128MB DIMM consist of 09 x 128Mbit devices @ 266MHz.
+o	256MB DIMM consist of 16 x 128Mbit devices @ 266MHz.
+o	256MB DIMM consist of 09 x 256Mbit devices @ 400MHz.
+o	512MB DIMM consist of 16 x 256Mbit devices @ 333MHz.
+o	512MB DIMM consist of 18 x 256Mbit devices @ 266MHz.
+o	GigaB DIMM consist of 36 x 256Mbit devices @ 266MHz registered
+
+For each chip select device perform data access to verify its accessibility.
+
+Create a JFFS2 on the large flash through the Linux holding few files, few dirs and a uImage.
+Load the U-Boot and:
+use the ls command to check correct scan of the JFFS2 on the large flash.
+Use the floads command to copy the uImage from the JFFS2 on the large flash to the DIMM SDRAM, and boot the uImage.
+
+PCI:
+++++
+1)Insert different PCI cards:
+Galileo 64120A rev 10 and 12, Intel Nic 82557 rev 08 and Real Tech  NIC 8139 rev10
+on different slots (0-3) of the PCI and check:
+o	Correct detection of the PCI devices.
+o	Correct address mapping of the PCI devices.
+2)Insert Galileo 64120A rev 10 on different slots (0-3) of the PCI and check writing and reading pci configuration register through the U-Boot.
+
+Booting Linux through the U-Boot (use the bootargs of the U-Boot as a bootcmd to the kernal)
diff --git a/u-boot/doc/README.designware_eth b/u-boot/doc/README.designware_eth
new file mode 100644
index 0000000..25ec6bd
--- /dev/null
+++ b/u-boot/doc/README.designware_eth
@@ -0,0 +1,25 @@
+This driver supports Designware Ethernet Controller provided by Synopsis.
+
+The driver is enabled by CONFIG_DESIGNWARE_ETH.
+
+The driver has been developed and tested on SPEAr platforms. By default, the
+MDIO interface works at 100/Full. #defining the below options in board
+configuration file changes this behavior.
+
+Call an subroutine from respective board/.../board.c
+designware_initialize(u32 id, ulong base_addr, u32 phy_addr);
+
+The various options suported by the driver are
+1. CONFIG_DW_ALTDESCRIPTOR
+	Define this to use the Alternate/Enhanced Descriptor configurations.
+1. CONFIG_DW_AUTONEG
+	Define this to autonegotiate with the host before proceeding with mac
+	level configuration. This obviates the definitions of CONFIG_DW_SPEED10M
+	and CONFIG_DW_DUPLEXHALF.
+2. CONFIG_DW_SPEED10M
+	Define this to change the default behavior from 100Mbps to 10Mbps.
+3. CONFIG_DW_DUPLEXHALF
+	Define this to change the default behavior from Full Duplex to Half.
+4. CONFIG_DW_SEARCH_PHY
+	Define this to search the phy address. This would overwrite the value
+	passed as 3rd arg from designware_initialize routine.
diff --git a/u-boot/doc/README.dns b/u-boot/doc/README.dns
new file mode 100644
index 0000000..8dff454
--- /dev/null
+++ b/u-boot/doc/README.dns
@@ -0,0 +1,62 @@
+Domain Name System
+-------------------------------------------
+
+The Domain Name System (DNS) is a hierarchical naming system for computers,
+services, or any resource participating in the Internet. It associates various
+information with domain names assigned to each of the participants. Most
+importantly, it translates domain names meaningful to humans into the numerical
+(binary) identifiers associated with networking equipment for the purpose of
+locating and addressing these devices world-wide. An often used analogy to
+explain the Domain Name System is that it serves as the "phone book" for the
+Internet by translating human-friendly computer hostnames into IP addresses.
+For example, www.example.com translates to 208.77.188.166.
+
+For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
+
+U-Boot and DNS
+------------------------------------------
+
+CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
+		 will send name lookups to the dns server (env var 'dnsip')
+		 Turning this option on will about abou 1k to U-Boot's size.
+
+		 Example:
+
+bfin> print dnsip
+dnsip=192.168.0.1
+
+bfin> dns www.google.com
+66.102.1.104
+
+		 By default, dns does nothing except print the IP number on
+		 the default console - which by itself, would be pretty
+		 useless. Adding a third argument to the dns command will
+		 use that as the environment variable to be set.
+
+		 Example:
+
+bfin> print googleip
+## Error: "googleip" not defined
+bfin> dns www.google.com googleip
+64.233.161.104
+bfin> print googleip
+googleip=64.233.161.104
+bfin> ping ${googleip}
+Using Blackfin EMAC device
+host 64.233.161.104 is alive
+
+		 In this way, you can lookup, and set many more meaningful
+		 things.
+
+bfin> sntp
+ntpserverip not set
+bfin> dns pool.ntp.org ntpserverip
+72.18.205.156
+bfin> sntp
+Date: 2009-07-18 Time:	4:06:57
+
+		 For some helpful things that can be related to DNS in U-Boot,
+		 look at the top level README for these config options:
+		    CONFIG_CMD_DHCP
+		    CONFIG_BOOTP_DNS
+		    CONFIG_BOOTP_DNS2
diff --git a/u-boot/doc/README.drivers.eth b/u-boot/doc/README.drivers.eth
new file mode 100644
index 0000000..eb83038
--- /dev/null
+++ b/u-boot/doc/README.drivers.eth
@@ -0,0 +1,190 @@
+-----------------------
+ Ethernet Driver Guide
+-----------------------
+
+The networking stack in Das U-Boot is designed for multiple network devices
+to be easily added and controlled at runtime.  This guide is meant for people
+who wish to review the net driver stack with an eye towards implementing your
+own ethernet device driver.  Here we will describe a new pseudo 'APE' driver.
+
+------------------
+ Driver Functions
+------------------
+
+All functions you will be implementing in this document have the return value
+meaning of 0 for success and non-zero for failure.
+
+ ----------
+  Register
+ ----------
+
+When U-Boot initializes, it will call the common function eth_initialize().
+This will in turn call the board-specific board_eth_init() (or if that fails,
+the cpu-specific cpu_eth_init()).  These board-specific functions can do random
+system handling, but ultimately they will call the driver-specific register
+function which in turn takes care of initializing that particular instance.
+
+Keep in mind that you should code the driver to avoid storing state in global
+data as someone might want to hook up two of the same devices to one board.
+Any such information that is specific to an interface should be stored in a
+private, driver-defined data structure and pointed to by eth->priv (see below).
+
+So the call graph at this stage would look something like:
+board_init()
+	eth_initialize()
+		board_eth_init() / cpu_eth_init()
+			driver_register()
+				initialize eth_device
+				eth_register()
+
+At this point in time, the only thing you need to worry about is the driver's
+register function.  The pseudo code would look something like:
+int ape_register(bd_t *bis, int iobase)
+{
+	struct ape_priv *priv;
+	struct eth_device *dev;
+
+	priv = malloc(sizeof(*priv));
+	if (priv == NULL)
+		return 1;
+
+	dev = malloc(sizeof(*dev));
+	if (dev == NULL) {
+		free(priv);
+		return 1;
+	}
+
+	/* setup whatever private state you need */
+
+	memset(dev, 0, sizeof(*dev));
+	sprintf(dev->name, "APE");
+
+	/* if your device has dedicated hardware storage for the
+	 * MAC, read it and initialize dev->enetaddr with it
+	 */
+	ape_mac_read(dev->enetaddr);
+
+	dev->iobase = iobase;
+	dev->priv = priv;
+	dev->init = ape_init;
+	dev->halt = ape_halt;
+	dev->send = ape_send;
+	dev->recv = ape_recv;
+	dev->write_hwaddr = ape_write_hwaddr;
+
+	eth_register(dev);
+
+#ifdef CONFIG_CMD_MII)
+	miiphy_register(dev->name, ape_mii_read, ape_mii_write);
+#endif
+
+	return 1;
+}
+
+The exact arguments needed to initialize your device are up to you.  If you
+need to pass more/less arguments, that's fine.  You should also add the
+prototype for your new register function to include/netdev.h.
+
+The return value for this function should be as follows:
+< 0 - failure (hardware failure, not probe failure)
+>=0 - number of interfaces detected
+
+You might notice that many drivers seem to use xxx_initialize() rather than
+xxx_register().  This is the old naming convention and should be avoided as it
+causes confusion with the driver-specific init function.
+
+Other than locating the MAC address in dedicated hardware storage, you should
+not touch the hardware in anyway.  That step is handled in the driver-specific
+init function.  Remember that we are only registering the device here, we are
+not checking its state or doing random probing.
+
+ -----------
+  Callbacks
+ -----------
+
+Now that we've registered with the ethernet layer, we can start getting some
+real work done.  You will need five functions:
+	int ape_init(struct eth_device *dev, bd_t *bis);
+	int ape_send(struct eth_device *dev, volatile void *packet, int length);
+	int ape_recv(struct eth_device *dev);
+	int ape_halt(struct eth_device *dev);
+	int ape_write_hwaddr(struct eth_device *dev);
+
+The init function checks the hardware (probing/identifying) and gets it ready
+for send/recv operations.  You often do things here such as resetting the MAC
+and/or PHY, and waiting for the link to autonegotiate.  You should also take
+the opportunity to program the device's MAC address with the dev->enetaddr
+member.  This allows the rest of U-Boot to dynamically change the MAC address
+and have the new settings be respected.
+
+The send function does what you think -- transmit the specified packet whose
+size is specified by length (in bytes).  You should not return until the
+transmission is complete, and you should leave the state such that the send
+function can be called multiple times in a row.
+
+The recv function should process packets as long as the hardware has them
+readily available before returning.  i.e. you should drain the hardware fifo.
+For each packet you receive, you should call the NetReceive() function on it
+along with the packet length.  The common code sets up packet buffers for you
+already in the .bss (NetRxPackets), so there should be no need to allocate your
+own.  This doesn't mean you must use the NetRxPackets array however; you're
+free to call the NetReceive() function with any buffer you wish.  So the pseudo
+code here would look something like:
+int ape_recv(struct eth_device *dev)
+{
+	int length, i = 0;
+	...
+	while (packets_are_available()) {
+		...
+		length = ape_get_packet(&NetRxPackets[i]);
+		...
+		NetReceive(&NetRxPackets[i], length);
+		...
+		if (++i >= PKTBUFSRX)
+			i = 0;
+		...
+	}
+	...
+	return 0;
+}
+
+The halt function should turn off / disable the hardware and place it back in
+its reset state.  It can be called at any time (before any call to the related
+init function), so make sure it can handle this sort of thing.
+
+The write_hwaddr function should program the MAC address stored in dev->enetaddr
+into the Ethernet controller.
+
+So the call graph at this stage would look something like:
+some net operation (ping / tftp / whatever...)
+	eth_init()
+		dev->init()
+	eth_send()
+		dev->send()
+	eth_rx()
+		dev->recv()
+	eth_halt()
+		dev->halt()
+
+-----------------------------
+ CONFIG_MII / CONFIG_CMD_MII
+-----------------------------
+
+If your device supports banging arbitrary values on the MII bus (pretty much
+every device does), you should add support for the mii command.  Doing so is
+fairly trivial and makes debugging mii issues a lot easier at runtime.
+
+After you have called eth_register() in your driver's register function, add
+a call to miiphy_register() like so:
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+	miiphy_register(dev->name, mii_read, mii_write);
+#endif
+
+And then define the mii_read and mii_write functions if you haven't already.
+Their syntax is straightforward:
+	int mii_read(char *devname, uchar addr, uchar reg, ushort *val);
+	int mii_write(char *devname, uchar addr, uchar reg, ushort val);
+
+The read function should read the register 'reg' from the phy at address 'addr'
+and store the result in the pointer 'val'.  The implementation for the write
+function should logically follow.
diff --git a/u-boot/doc/README.ebony b/u-boot/doc/README.ebony
new file mode 100644
index 0000000..a8479a4
--- /dev/null
+++ b/u-boot/doc/README.ebony
@@ -0,0 +1,136 @@
+			   AMCC Ebony Board
+
+		    Last Update: September 12, 2002
+=======================================================================
+
+This file contains some handy info regarding U-Boot and the AMCC
+Ebony evalutation board. See the README.ppc440 for additional
+information.
+
+
+SWITCH SETTINGS & JUMPERS
+==========================
+
+Here's what I've been using successfully. If you feel inclined to
+change things ... please read the docs!
+
+DIPSW   U46         U80
+------------------------
+SW 1    off         on
+SW 2    on          on
+SW 3    on          on
+SW 4    off         on
+SW 5    on          off
+SW 6    on          on
+SW 7    on          off
+SW 8    on          off
+
+J41: strapped
+J42: open
+
+All others are factory default.
+
+
+I2C probe
+=====================
+
+The i2c utilities have been tested on both Rev B. and Rev C. and
+look good. The CONFIG_SYS_I2C_NOPROBES macro is defined to prevent
+probing the CDCV850 clock controller at address 0x69 (since reading
+it causes the i2c implementation to misbehave. The output of
+'i2c probe' should look like this (assuming you are only using a single
+SO-DIMM:
+
+=> i2c probe
+Valid chip addresses: 50 53 54
+Excluded chip addresses: 69
+
+
+GETTING OUT OF I2C TROUBLE
+===========================
+
+If you're like me ... you may have screwed up your bootstrap serial
+eeprom ... or worse, your SPD eeprom when experimenting with the
+i2c commands. If so, here are some ideas on how to get out of
+trouble:
+
+Serial bootstrap eeprom corruption:
+-----------------------------------
+Power down the board and set the following straps:
+
+J41 - open
+J42 - strapped
+
+This will select the default sys0 and sys1 settings (the serial
+eeproms are not used). Then power up the board and fix the serial
+eeprom using the 'i2c mm' command. Here are the values I currently
+use:
+
+=> i2c md 50 0 10
+0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00    ................
+
+=> i2c md 54 0 10
+0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00    ..$.M...........
+
+Once you have the eeproms set correctly change the
+J41/J42 straps as you desire.
+
+SPD eeprom corruption:
+------------------------
+I've corrupted the SPD eeprom several times ... perhaps too much coffee
+and not enough presence of mind ;-). By default, the ebony code uses
+the SPD to initialize the DDR SDRAM control registers. So if the SPD
+eeprom is corrupted, U-Boot will never get into ram. Here's how I got
+out of this situation:
+
+0. First, _before_ playing with the i2c utilities, do an 'i2c probe', then
+use 'i2c md' to capture the various device contents to a file. Some day
+you may be glad you did this ... trust me :-). Otherwise try the
+following:
+
+1. In the include/configs/EBONY.h file find the line that defines
+the CONFIG_SPD_EEPROM macro and undefine it. E.g:
+
+#undef CONFIG_SPD_EEPROM
+
+This will make the code use default SDRAM control register
+settings without using the SPD eeprom.
+
+2. Rebuild U-Boot
+
+3. Load the new U-Boot image and reboot ebony.
+
+4. Repair the SPD eeprom using the 'i2c mm' command. Here's the eeprom
+contents that work with the default SO-DIMM that comes with the
+ebony board (micron 8VDDT164AG-265A1). Note: these are probably
+_not_ the factory settings ... but they work.
+
+=> i2c md 53 0 10 80
+0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01    ......@..uu.....
+0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20    ..... ..u..P<P-
+0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00    ..PP.....AK42u..
+0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c    ................
+0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36    ,........8VDDT16
+0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63    64AG-265A1 ...,c
+0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00    "%..............
+0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
+
+
+PCI DOUBLE-ENUMERATION WOES
+===========================
+
+If you're not using PCI-X cards and are simply using 32-bit and/or
+33 MHz cards via extenders and the like, you may notice that the
+initial pci scan reports various devices twice ... and configuration
+does not succeed (one or more devices are enumerated twice). To correct
+this we replaced the 2K ohm resistor on the IDSEL line(s) with a
+22 ohm resistor and the problem went away. This change hasn't broken
+anything yet -- use at your own risk.
+
+We never tested anything other than 33 MHz/32-bit cards. If you have
+the chance to do this, please let me know how things turn out :-)
+
+
+Regards,
+--Scott
+<smcnutt@artesyncp.com>
diff --git a/u-boot/doc/README.enetaddr b/u-boot/doc/README.enetaddr
new file mode 100644
index 0000000..2d8e24f
--- /dev/null
+++ b/u-boot/doc/README.enetaddr
@@ -0,0 +1,112 @@
+---------------------------------
+ Ethernet Address (MAC) Handling
+---------------------------------
+
+There are a variety of places in U-Boot where the MAC address is used, parsed,
+and stored.  This document covers proper usage of each location and the moving
+of data between them.
+
+-----------
+ Locations
+-----------
+
+Here are the places where MAC addresses might be stored:
+
+ - board-specific location (eeprom, dedicated flash, ...)
+	Note: only used when mandatory due to hardware design etc...
+
+ - environment ("ethaddr", "eth1addr", ...) (see CONFIG_ETHADDR)
+	Note: this is the preferred way to permanently store MAC addresses
+
+ - ethernet data (struct eth_device -> enetaddr)
+	Note: these are temporary copies of the MAC address which exist only
+	      after the respective init steps have run and only to make usage
+	      in other places easier (to avoid constant env lookup/parsing)
+
+ - struct bd_info and/or device tree
+	Note: these are temporary copies of the MAC address only for the
+	      purpose of passing this information to an OS kernel we are about
+	      to boot
+
+Correct flow of setting up the MAC address (summarized):
+
+1. Read from hardware in initialize() function
+2. Read from environment in net/eth.c after initialize()
+3. Give priority to the value in the environment if a conflict
+4. Program the address into hardware if the following conditions are met:
+	a) The relevant driver has a 'write_addr' function
+	b) The user hasn't set an 'ethmacskip' environment variable
+	c) The address is valid (unicast, not all-zeros)
+
+Previous behavior had the MAC address always being programmed into hardware
+in the device's init() function.
+
+-------
+ Usage
+-------
+
+If the hardware design mandates that the MAC address is stored in some special
+place (like EEPROM etc...), then the board specific init code (such as the
+board-specific misc_init_r() function) is responsible for locating the MAC
+address(es) and initializing the respective environment variable(s) from it.
+Note that this shall be done if, and only if, the environment does not already
+contain these environment variables, i.e. existing variable definitions must
+not be overwritten.
+
+During runtime, the ethernet layer will use the environment variables to sync
+the MAC addresses to the ethernet structures.  All ethernet driver code should
+then only use the enetaddr member of the eth_device structure.  This is done
+on every network command, so the ethernet copies will stay in sync.
+
+Any other code that wishes to access the MAC address should query the
+environment directly.  The helper functions documented below should make
+working with this storage much smoother.
+
+---------
+ Helpers
+---------
+
+To assist in the management of these layers, a few helper functions exist.  You
+should use these rather than attempt to do any kind of parsing/manipulation
+yourself as many common errors have arisen in the past.
+
+	* void eth_parse_enetaddr(const char *addr, uchar *enetaddr);
+
+Convert a string representation of a MAC address to the binary version.
+char *addr = "00:11:22:33:44:55";
+uchar enetaddr[6];
+eth_parse_enetaddr(addr, enetaddr);
+/* enetaddr now equals { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 } */
+
+	* int eth_getenv_enetaddr(char *name, uchar *enetaddr);
+
+Look up an environment variable and convert the stored address.  If the address
+is valid, then the function returns 1.  Otherwise, the function returns 0.  In
+all cases, the enetaddr memory is initialized.  If the env var is not found,
+then it is set to all zeros.  The common function is_valid_ether_addr() is used
+to determine address validity.
+uchar enetaddr[6];
+if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
+	/* "ethaddr" is not set in the environment */
+	... try and setup "ethaddr" in the env ...
+}
+/* enetaddr is now set to the value stored in the ethaddr env var */
+
+	* int eth_setenv_enetaddr(char *name, const uchar *enetaddr);
+
+Store the MAC address into the named environment variable.  The return value is
+the same as the setenv() function.
+uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
+eth_setenv_enetaddr("ethaddr", enetaddr);
+/* the "ethaddr" env var should now be set to "00:11:22:33:44:55" */
+
+	* the %pM format modifier
+
+The %pM format modifier can be used with any standard printf function to format
+the binary 6 byte array representation of a MAC address.
+uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 };
+printf("The MAC is %pM\n", enetaddr);
+
+char buf[20];
+sprintf(buf, "%pM", enetaddr);
+/* the buf variable is now set to "00:11:22:33:44:55" */
diff --git a/u-boot/doc/README.evb64260 b/u-boot/doc/README.evb64260
new file mode 100644
index 0000000..74211de
--- /dev/null
+++ b/u-boot/doc/README.evb64260
@@ -0,0 +1,54 @@
+This file contains status information for the port of U-Boot to the
+Galileo Evaluation Board.
+
+Author: Josh Huber <huber@mclx.com>
+	Mission Critical Linux, Inc.
+
+The support for the Galileo Evaluation board is fairly minimal now.
+It's sufficient to boot Linux, but doesn't provide too much more than
+what's required to do this.
+
+Both DUART channels are supported (to use the second one, you have to
+modify the board -- see the schematics for where to solder on the
+devices module).  The ethernet ports are supported, and the MPSC is
+supported as a console driver. (keep in mind that the kernel has no
+support for this yet)
+
+There are still occaisonal lockups with the MPSC console driver due to
+(we think!) overrun problems.  If you're looking for something stable
+to use for Linux development, consider sticking with the DUART console
+for now.
+
+Automatic memory sizing mostly works.  We've had problems with some
+combinations of memory.  Please send us email if you're having trouble
+with respect to the memory detection.
+
+Right now, only the 512k boot flash is supported.  Support for the
+16MB flash on the devices module is forthcoming.  Right now the flash
+is stored at the 256k boundry in flash, wasting a whole sector (64k!)
+for environment data.  This isn't really a big deal since we're not
+using the 512k for anything else. (Just U-Boot and the environment)
+
+Finally, here is a sample output session:
+
+U-Boot 1.0.0-pre1 (Jun  6 2001 - 12:45:11)
+
+Initializing...
+  CPU:   MPC7400 (altivec enabled) v2.9
+  Board: EVB64260
+  DRAM:  256 MB
+  FLASH: 512 kB
+  In:    serial
+  Out:   serial
+  Err:   serial
+
+=>
+
+The default configuration should be correct for the evaluation board,
+as it's shipped from Galileo.  Keep in mind that the default baudrate
+is set to 38400, 8N1.
+
+Good luck, and make sure to send any bugreports to us (or the
+u-boot-users list).
+
+Josh
diff --git a/u-boot/doc/README.fads b/u-boot/doc/README.fads
new file mode 100644
index 0000000..bae9652
--- /dev/null
+++ b/u-boot/doc/README.fads
@@ -0,0 +1,89 @@
+/*
+ * (C) Copyright 2000
+ * Dave Ellis, SIXNET, dge@sixnetio.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+Using the Motorola MPC8XXFADS development board
+===============================================
+
+CONFIGURATIONS
+--------------
+
+There are ready-to-use default configurations available for the
+FADS823, FADS850SAR and FADS860T. The FADS860T configuration also
+works for the 855T processor.
+
+LOADING U-Boot INTO FADS FLASH MEMORY
+--------------------------------------
+
+MPC8BUG can load U-Boot into the FLASH memory using LOADF.
+
+    loadf u-boot.srec 100000
+
+
+STARTING U-Boot FROM MPC8BUG
+-----------------------------
+
+To start U-Boot from MPC8BUG:
+
+1. Reset the board:
+    reset :h
+
+2. Change BR0 and OR0 back to their values at reset:
+    rms memc br0 00000001
+    rms memc or0 00000d34
+
+3. Modify DER so MPC8BUG gets control only when it should:
+    rms der 2002000f
+
+4. Start as if from reset:
+    go 100
+
+This is NOT exactly the same as starting U-Boot without
+MPC8BUG. MPC8BUG turns off the watchdog as part of the hard reset.
+After it does the reset it writes SYPCR (to disable the watchdog)
+and sets BR0 and OR0 to map the FLASH at 0x02800000 (and does lots
+of other initialization). That is why it is necessary to set BR0
+and OR0 to map the FLASH everywhere. U-Boot can't turn on the
+watchdog after that, since MPC8BUG has used the only chance to write
+to SYPCR.
+
+Here is a bizarre sequence of MPC8BUG and U-Boot commands that lets
+U-Boot write to SYPCR. It works with MPC8BUG 1.5 and an 855T
+processor (your mileage may vary). It is probably better (and a lot
+easier) just to accept having the watchdog disabled when the debug
+cable is connected.
+
+in MPC8BUG:
+  reset :h
+  rms memc br0 00000001
+  rms memc or0 00000d34
+  rms der 2000f
+  go 100
+
+Now U-Boot is running with the MPC8BUG value for SYPCR. Use the
+U-Boot 'reset' command to reset the board.
+  =>reset
+Next, in MPC8BUG:
+  rms der 2000f
+  go
+
+Now U-Boot is running with the U-Boot value for SYPCR.
diff --git a/u-boot/doc/README.fsl-ddr b/u-boot/doc/README.fsl-ddr
new file mode 100644
index 0000000..c1ee0a6
--- /dev/null
+++ b/u-boot/doc/README.fsl-ddr
@@ -0,0 +1,172 @@
+
+Table of interleaving modes supported in cpu/8xxx/ddr/
+======================================================
+  +-------------+---------------------------------------------------------+
+  |		|		    Rank Interleaving			  |
+  |		+--------+-----------+-----------+------------+-----------+
+  |Memory	|	 |	     |		 |    2x2     |    4x1	  |
+  |Controller	|  None  | 2x1 lower | 2x1 upper | {CS0+CS1}, | {CS0+CS1+ |
+  |Interleaving |	 | {CS0+CS1} | {CS2+CS3} | {CS2+CS3}  |  CS2+CS3} |
+  +-------------+--------+-----------+-----------+------------+-----------+
+  |None		|  Yes	 | Yes	     | Yes	 | Yes	      | Yes	  |
+  +-------------+--------+-----------+-----------+------------+-----------+
+  |Cacheline	|  Yes	 | Yes	     | No	 | No, Only(*)| Yes	  |
+  |		|CS0 Only|	     |		 | {CS0+CS1}  |		  |
+  +-------------+--------+-----------+-----------+------------+-----------+
+  |Page		|  Yes	 | Yes	     | No	 | No, Only(*)| Yes	  |
+  |		|CS0 Only|	     |		 | {CS0+CS1}  |		  |
+  +-------------+--------+-----------+-----------+------------+-----------+
+  |Bank		|  Yes	 | Yes	     | No	 | No, Only(*)| Yes	  |
+  |		|CS0 Only|	     |		 | {CS0+CS1}  |		  |
+  +-------------+--------+-----------+-----------+------------+-----------+
+  |Superbank	|  No	 | Yes	     | No	 | No, Only(*)| Yes	  |
+  |		|	 |	     |		 | {CS0+CS1}  |		  |
+  +-------------+--------+-----------+-----------+------------+-----------+
+ (*) Although the hardware can be configured with memory controller
+ interleaving using "2x2" rank interleaving, it only interleaves {CS0+CS1}
+ from each controller. {CS2+CS3} on each controller are only rank
+ interleaved on that controller.
+
+ For memory controller interleaving, identical DIMMs are suggested. Software
+ doesn't check the size or organization of interleaved DIMMs.
+
+The ways to configure the ddr interleaving mode
+==============================================
+1. In board header file(e.g.MPC8572DS.h), add default interleaving setting
+   under "CONFIG_EXTRA_ENV_SETTINGS", like:
+	#define CONFIG_EXTRA_ENV_SETTINGS				\
+	 "hwconfig=fsl_ddr:ctlr_intlv=bank"			\
+	 ......
+
+2. Run u-boot "setenv" command to configure the memory interleaving mode.
+   Either numerical or string value is accepted.
+
+  # disable memory controller interleaving
+  setenv hwconfig "fsl_ddr:ctlr_intlv=null"
+
+  # cacheline interleaving
+  setenv hwconfig "fsl_ddr:ctlr_intlv=cacheline"
+
+  # page interleaving
+  setenv hwconfig "fsl_ddr:ctlr_intlv=page"
+
+  # bank interleaving
+  setenv hwconfig "fsl_ddr:ctlr_intlv=bank"
+
+  # superbank
+  setenv hwconfig "fsl_ddr:ctlr_intlv=superbank"
+
+  # disable bank (chip-select) interleaving
+  setenv hwconfig "fsl_ddr:bank_intlv=null"
+
+  # bank(chip-select) interleaving cs0+cs1
+  setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1"
+
+  # bank(chip-select) interleaving cs2+cs3
+  setenv hwconfig "fsl_ddr:bank_intlv=cs2_cs3"
+
+  # bank(chip-select) interleaving (cs0+cs1) and (cs2+cs3)  (2x2)
+  setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_and_cs2_cs3"
+
+  # bank(chip-select) interleaving (cs0+cs1+cs2+cs3) (4x1)
+  setenv hwconfig "fsl_ddr:bank_intlv=cs0_cs1_cs2_cs3"
+
+Memory controller address hashing
+==================================
+If the DDR controller supports address hashing, it can be enabled by hwconfig.
+
+Syntax is:
+hwconfig=fsl_ddr:addr_hash=true
+
+Memory controller ECC on/off
+============================
+If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC,
+ECC can be turned on/off by hwconfig.
+
+Syntax is
+hwconfig=fsl_ddr:ecc=off
+
+Memory testing options for mpc85xx
+==================================
+1. Memory test can be done once U-boot prompt comes up using mtest, or
+2. Memory test can be done with Power-On-Self-Test function, activated at
+   compile time.
+
+   In order to enable the POST memory test, CONFIG_POST needs to be
+   defined in board configuraiton header file. By default, POST memory test
+   performs a fast test. A slow test can be enabled by changing the flag at
+   compiling time. To test memory bigger than 2GB, 36BIT support is needed.
+   Memory is tested within a 2GB window. TLBs are used to map the virtual 2GB
+   window to physical address so that all physical memory can be tested.
+
+Combination of hwconfig
+=======================
+Hwconfig can be combined with multiple parameters, for example, on a supported
+platform
+
+hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
+
+Table for dynamic ODT for DDR3
+==============================
+For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT may
+be needed, depending on the configuration. The numbers in the following tables are
+in Ohms.
+
+* denotes dynamic ODT
+
+Two slots system
++-----------------------+----------+---------------+-----------------------------+-----------------------------+
+|     Configuration	|	   |DRAM controller|	       Slot 1		 |	      Slot 2	       |
++-----------+-----------+----------+-------+-------+--------------+--------------+--------------+--------------+
+|	    |		|	   |	   |	   |	 Rank 1   |	Rank 2	 |   Rank 1	|    Rank 2    |
++  Slot 1   |	Slot 2	|Write/Read| Write | Read  |-------+------+-------+------+-------+------+-------+------+
+|	    |		|	   |	   |	   | Write | Read | Write | Read | Write | Read | Write | Read |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 1  |  off  | 75    | 120   | off  | off   | off  | off	 | off	| 30	| 30   |
+| Dual Rank | Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 2  |  off  | 75    | off   | off  | 30	  | 30	 | 120	 | off	| off	| off  |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 1  |  off  | 75    | 120   | off  | off   | off  | 20	 | 20	|	|      |
+| Dual Rank |Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 2  |  off  | 75    | off   | off  | 20	  | 20	 | 120	*| off	|	|      |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 1  |  off  | 75    | 120  *| off  |	  |	 | off	 | off	| 20	| 20   |
+|Single Rank| Dual Rank |----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 2  |  off  | 75    | 20    | 20   |	  |	 | 120	 | off	| off	| off  |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 1  |  off  | 75    | 120  *| off  |	  |	 | 30	 | 30	|	|      |
+|Single Rank|Single Rank|----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	    |		|  Slot 2  |  off  | 75    | 30    | 30   |	  |	 | 120	*| off	|	|      |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+| Dual Rank |	Empty	|  Slot 1  |  off  | 75    | 40    | off  | off   | off  |	 |	|	|      |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|   Empty   | Dual Rank |  Slot 2  |  off  | 75    |	   |	  |	  |	 | 40	 | off	| off	| off  |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|Single Rank|	Empty	|  Slot 1  |  off  | 75    | 40    | off  |	  |	 |	 |	|	|      |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|   Empty   |Single Rank|  Slot 2  |  off  | 75    |	   |	  |	  |	 | 40	 | off	|	|      |
++-----------+-----------+----------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+
+Single slot system
++-------------+------------+---------------+-----------------------------+-----------------------------+
+|	      |		   |DRAM controller|	 Rank 1   |    Rank 2	 |    Rank 3	|    Rank 4    |
+|Configuration| Write/Read |-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |		   | Write | Read  | Write | Read | Write | Read | Write | Read | Write | Read |
++-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |   R1	   | off   | 75    | 120  *| off  | off   | off  | 20	 | 20	| off	| off  |
+|	      |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |   R2	   | off   | 75    | off   | 20   | 120   | off  | 20	 | 20	| off	| off  |
+|  Quad Rank  |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |   R3	   | off   | 75    | 20    | 20   | off   | off  | 120	*| off	| off	| off  |
+|	      |------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |   R4	   | off   | 75    | 20    | 20   | off   | off  | off	 | 20	| 120	| off  |
++-------------+------------+-------+-------+-------+------+-------+------+-------+------+-------+------+
+|	      |   R1	   | off   | 75    | 40    | off  | off   | off  |
+|  Dual Rank  |------------+-------+-------+-------+------+-------+------+
+|	      |   R2	   | off   | 75    | 40    | off  | off   | off  |
++-------------+------------+-------+-------+-------+------+-------+------+
+| Single Rank |   R1	   | off   | 75    | 40    | off  |
++-------------+------------+-------+-------+-------+------+
+
+Reference http://www.xrosstalkmag.com/mag_issues/xrosstalk_oct08_final.pdf
+	  http://download.micron.com/pdf/technotes/ddr3/tn4108_ddr3_design_guide.pdf
diff --git a/u-boot/doc/README.fsl-hwconfig b/u-boot/doc/README.fsl-hwconfig
new file mode 100644
index 0000000..03fea74
--- /dev/null
+++ b/u-boot/doc/README.fsl-hwconfig
@@ -0,0 +1,21 @@
+Freescale-specific 'hwconfig' options.
+
+This file documents Freescale-specific key:value pairs for the 'hwconfig'
+option.  See README.hwconfig for general information about 'hwconfig'.
+
+audclk
+	Specific to the P1022DS reference board.
+
+	This option specifies which of the two oscillator frequencies should be
+	routed to the Wolfson WM8776 codec.  The ngPIXIS can be programmed to
+	route either a 11.2896MHz or a 12.288MHz clock.  The default is
+	12.288MHz.  This option has two effects.  First, the MUX on the board
+	will be programmed accordingly.  Second, the clock-frequency property
+	in the codec node in the device tree will be updated to the correct
+	value.
+
+	'audclk:11'
+		Select the 11.2896MHz clock
+
+	'audclk:12'
+		Select the 12.288MHz clock
diff --git a/u-boot/doc/README.generic_usb_ohci b/u-boot/doc/README.generic_usb_ohci
new file mode 100644
index 0000000..ba7cea8
--- /dev/null
+++ b/u-boot/doc/README.generic_usb_ohci
@@ -0,0 +1,63 @@
+Notes on the the generic USB-OHCI driver
+========================================
+
+This driver (drivers/usb/usb_ohci.[ch]) is the result of the merge of
+various existing OHCI drivers that were basically identical beside
+cpu/board dependant initalization. This initalization has been moved
+into cpu/board directories and are called via the hooks below.
+
+Configuration options
+----------------------
+
+	CONFIG_USB_OHCI_NEW: enable the new OHCI driver
+
+	CONFIG_SYS_USB_OHCI_BOARD_INIT: call the board dependant hooks:
+
+		  - extern int usb_board_init(void);
+		  - extern int usb_board_stop(void);
+		  - extern int usb_cpu_init_fail(void);
+
+	CONFIG_SYS_USB_OHCI_CPU_INIT: call the cpu dependant hooks:
+
+		  - extern int usb_cpu_init(void);
+		  - extern int usb_cpu_stop(void);
+		  - extern int usb_cpu_init_fail(void);
+
+	CONFIG_SYS_USB_OHCI_REGS_BASE: defines the base address of the OHCI
+				registers
+
+	CONFIG_SYS_USB_OHCI_SLOT_NAME: slot name
+
+	CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS: maximal number of ports of the
+				     root hub.
+
+
+Endianness issues
+------------------
+
+The USB bus operates in little endian, but unfortunately there are
+OHCI controllers that operate in big endian such as ppc4xx and
+mpc5xxx. For these the config option
+
+	CONFIG_SYS_OHCI_BE_CONTROLLER
+
+needs to be defined.
+
+
+PCI Controllers
+----------------
+
+You'll need to define
+
+	CONFIG_PCI_OHCI
+
+If you have several USB PCI controllers, define
+
+	CONFIG_PCI_OHCI_DEVNO: number of the OHCI device in PCI list
+
+If undefined, the first instance found in PCI space will be used.
+
+PCI Controllers need to do byte swapping on register accesses, so they
+should to define:
+
+	CONFIG_SYS_OHCI_SWAP_REG_ACCESS
diff --git a/u-boot/doc/README.hawkboard b/u-boot/doc/README.hawkboard
new file mode 100644
index 0000000..b7afec4
--- /dev/null
+++ b/u-boot/doc/README.hawkboard
@@ -0,0 +1,93 @@
+Summary
+=======
+The README is for the boot procedure used for TI's OMAP-L138 based
+hawkboard. The hawkboard comes with a 128MiB Nand flash and a 128MiB
+DDR SDRAM along with a host of other controllers.
+
+The hawkboard is booted in three stages. The initial bootloader which
+executes upon reset is the Rom Boot Loader(RBL) which sits in the
+internal ROM of the omap. The RBL initialises the memory and the nand
+controller, and copies the image stored at a predefined location(block
+1) of the nand flash. The image loaded by the RBL to the memory is the
+AIS signed nand_spl image. This, in turns copies the u-boot binary
+from the nand flash to the memory and jumps to the u-boot entry point.
+
+AIS is an image format defined by TI for the images that are to be
+loaded to memory by the RBL. The image is divided into a series of
+sections and the image's entry point is specified. Each section comes
+with meta data like the target address the section is to be copied to
+and the size of the section, which is used by the RBL to load the
+image. At the end of the image the RBL jumps to the image entry
+point.
+
+The secondary stage bootloader(nand_spl) which is loaded by the RBL
+then loads the u-boot from a predefined location in the nand to the
+memory and jumps to the u-boot entry point.
+
+The reason a secondary stage bootloader is used is because the ECC
+layout expected by the RBL is not the same as that used by
+u-boot/linux. This also implies that for flashing the nand_spl image,
+we need to use the u-boot which uses the ECC layout expected by the
+RBL[1]. Booting u-boot over UART(UART boot) is explained here[2].
+
+
+Compilation
+===========
+Three images might be needed
+
+* nand_spl - This is the secondary bootloader which boots the u-boot
+  binary.
+
+  hawkboard_nand_config
+
+  The nand_spl ELF gets generated under nand_spl/u-boot-spl. This
+  needs to be processed with the AISGen tool for generating the AIS
+  signed image to be flashed. Steps for generating the AIS image are
+  explained here[3].
+
+* u-boot binary - This is the image flashed to the nand and copied to
+  the memory by the nand_spl.
+
+  hawkboard_config
+
+* u-boot for uart boot - This is same as the u-boot binary generated
+  above, with the sole difference of the CONFIG_SYS_TEXT_BASE being
+  0xc1080000, as expected by the RBL.
+
+  hawkboard_uart_config
+
+
+Flashing the images to Nand
+===========================
+The nand_spl AIS image needs to be flashed to the block 1 of the
+Nand flash, as that is the location the RBL expects the image[4]. For
+flashing the nand_spl, boot over the u-boot specified in [1], and
+flash the image
+
+=> tftpboot 0xc0700000 <nand_spl_ais.bin>
+=> nand erase 0x20000 0x20000
+=> nand write.e 0xc0700000 0x20000 <nand_spl_size>
+
+The u-boot binary is flashed at location 0xe0000(block 6) of the nand
+flash. The nand_spl loader expects the u-boot at this location. For
+flashing the u-boot binary
+
+=> tftpboot 0xc0700000 u-boot.bin
+=> nand erase 0xe0000 0x40000
+=> nand write.e 0xc0700000 0xe0000 <u-boot-size>
+
+
+Links
+=====
+
+[1]
+ http://code.google.com/p/hawkboard/downloads/detail?name=u-boot_uart_ais_v1.bin
+
+[2]
+ http://elinux.org/Hawkboard#Booting_u-boot_over_UART
+
+[3]
+ http://elinux.org/Hawkboard#Signing_u-boot_for_UART_boot
+
+[4]
+ http://processors.wiki.ti.com/index.php/RBL_UBL_and_host_program#RBL_booting_from_NAND_and_ECC.2FBad_blocks
diff --git a/u-boot/doc/README.hwconfig b/u-boot/doc/README.hwconfig
new file mode 100644
index 0000000..cf54965
--- /dev/null
+++ b/u-boot/doc/README.hwconfig
@@ -0,0 +1,50 @@
+To enable this feature just define CONFIG_HWCONFIG in your board
+config file.
+
+This implements a simple hwconfig infrastructure: an
+interface for software knobs to control hardware.
+
+This a is very simple implementation, i.e. it is implemented
+via the `hwconfig' environment variable. Later we could write
+some "hwconfig <enable|disable|list>" commands, ncurses
+interface for Award BIOS-like interface, and frame-buffer
+interface for AMI GUI[1] BIOS-like interface with mouse
+support[2].
+
+Current implementation details/limitations:
+
+1. Doesn't support options dependencies and mutual exclusion.
+   We can implement this by integrating apt-get[3] into Das
+   U-Boot. But I haven't bothered yet.
+
+2. Since we don't implement a hwconfig command, i.e. we're working
+   with the environement directly, there is no way to tell that
+   toggling a particular option will need a reboot to take
+   effect. So, for now it's advised to always reboot the
+   target after modifying the hwconfig variable.
+
+3. We support hwconfig options with arguments. For example,
+
+   set hwconfig "dr_usb:mode=peripheral,phy_type=ulpi"
+
+   This selects three hwconfig options:
+   1. dr_usb - enable Dual-Role USB controller;
+   2. dr_usb_mode:peripheral - USB in Function mode;
+   3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs.
+
+The purpose of this simple implementation is to refine the
+internal API and then we can continue improving the user
+experience by adding more mature interfaces, like a hwconfig
+command with bells and whistles. Or not adding, if we feel
+that the current interface fits people's needs.
+
+[1] http://en.wikipedia.org/wiki/American_Megatrends
+[2] Regarding ncurses and GUI with mouse support -- I'm just
+    kidding.
+[3] The comment regarding apt-get is also a joke, meaning that
+    dependency tracking could be non-trivial. For example, for
+    enabling HW feature X we may need to disable Y, and turn Z
+    into reduced mode (like RMII-only interface for ethernet,
+    no MII).
+
+    It's quite trivial to implement simple cases though.
diff --git a/u-boot/doc/README.idma2intr b/u-boot/doc/README.idma2intr
new file mode 100644
index 0000000..1828b51
--- /dev/null
+++ b/u-boot/doc/README.idma2intr
@@ -0,0 +1,10 @@
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
+
+Attached is an IDMA example code for MPC8260/PPCBoot. I had tried to
+search around and could not find any for implementing IDMA, so
+implemented one. Its not coded in the best way, but works.
+
+Also, I was able to test the IDMA specific code under Linux also
+(with modifications). My requirement was to implement it for
+CompactFlash implemented in memory mode, and it works for it under
+PPCBoot and Linux.
diff --git a/u-boot/doc/README.imx31 b/u-boot/doc/README.imx31
new file mode 100644
index 0000000..91ef766
--- /dev/null
+++ b/u-boot/doc/README.imx31
@@ -0,0 +1,29 @@
+U-Boot for Freescale i.MX31
+
+This file contains information for the port of U-Boot to the Freescale
+i.MX31 SoC.
+
+1. CONFIGURATION OPTIONS/SETTINGS
+---------------------------------
+
+1.1 Configuration of MC13783 SPI bus
+------------------------------------
+	The power management companion chip MC13783 is connected to the
+	i.MX31 via an SPI bus. Use the following configuration options
+	to setup the bus and chip select used for a particular board.
+
+	CONFIG_MC13783_SPI_BUS	-- defines the SPI bus the MC13783 is connected to.
+			   Note that 0 is CSPI1, 1 is CSPI2 and 2 is CSPI3.
+	CONFIG_MC13783_SPI_CS	-- define the chip select the MC13783 s connected to.
+
+1.2 Timer precision
+-------------------
+	CONFIG_MX31_TIMER_HIGH_PRECISION
+
+	Enable higher precision timer. The low-precision timer
+	(default) provides approximately 4% error, whereas the
+	high-precision timer is about 0.4% accurate. The extra
+	accuracy is achieved at the cost of higher computational
+	overhead, which, in places where time is measured, should
+	not be critical, so, it should be safe to enable this
+	option.
diff --git a/u-boot/doc/README.imximage b/u-boot/doc/README.imximage
new file mode 100644
index 0000000..c74239d
--- /dev/null
+++ b/u-boot/doc/README.imximage
@@ -0,0 +1,196 @@
+---------------------------------------------
+Imximage Boot Image generation using mkimage
+---------------------------------------------
+
+This document describes how to set up a U-Boot image
+that can be booted by Freescale MX25, MX35 and MX51
+processors via internal boot mode.
+
+These processors can boot directly from NAND, SPI flash and SD card flash
+using its internal boot ROM support. They can boot from an internal
+UART, if booting from device media fails.
+Booting from NOR flash does not require to use this image type.
+
+For more details refer Chapter 2 - System Boot and section 2.14
+(flash header description) of the processor's manual.
+
+This implementation does not use at the moment the secure boot feature
+of the processor. The image is generated disabling all security fields.
+
+Command syntax:
+--------------
+./tools/mkimage -l <mx u-boot_file>
+		to list the imx image file details
+
+./tools/mkimage -T imximage \
+		-n <board specific configuration file> \
+		-e <execution address> -d <u-boot binary>  <output image file>
+
+For example, for the mx51evk board:
+./tools/mkimage -n ./board/freescale/mx51evk/imximage.cfg \
+		-T imximage -e 0x97800000  \
+		-d u-boot.bin u-boot.imx
+
+You can generate directly the image when you compile u-boot with:
+
+$ make u-boot.imx
+
+The output image can be flashed on the board SPI flash or on a SD card.
+In both cases, you have to copy the image at the offset required for the
+chosen media devices (0x400 for both SPI flash or SD card).
+
+Please check Freescale documentation for further details.
+
+Board specific configuration file specifications:
+-------------------------------------------------
+1. This file must present in the $(BOARDDIR) and the name should be
+	imximage.cfg (since this is used in Makefile).
+2. This file can have empty lines and lines starting with "#" as first
+	character to put comments.
+3. This file can have configuration command lines as mentioned below,
+	any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+---------------------------------
+1. Each command line is must have two strings, first one command or address
+	and second one data string
+2. Following are the valid command strings and associated data strings:-
+	Command string		data string
+	--------------		-----------
+	IMXIMAGE_VERSION        1/2
+				1 is for mx25/mx35/mx51 compatible,
+				2 is for mx53 compatible,
+				others is invalid and error is generated.
+				This command need appear the fist before
+				other valid commands in configuration file.
+
+	BOOT_FROM		nand/spi/sd/onenand
+				Example:
+				BOOT_FROM spi
+	DATA			type address value
+
+				type: word=4, halfword=2, byte=1
+				address: physycal register address
+				value: value to be set in register
+				All values are in in hexadecimal.
+				Example (write to IOMUXC):
+				DATA 4 0x73FA88a0 0x200
+
+The processor support up to 60 register programming commands for IMXIMAGE_VERSION 1
+and 121 register programming commands for IMXIMAGE_VERSION 2.
+An error is generated if more commands are found in the configuration file.
+
+3. All commands are optional to program.
+
+Setup a SD Card for booting
+--------------------------------
+
+The following example prepare a SD card with u-boot and a FAT partition
+to be used to stored the kernel to be booted.
+I will set the SD in the most compatible mode, setting it with
+255 heads and 63 sectors, as suggested from several documentation and
+howto on line (I took as reference the preparation of a SD Card for the
+Beagleboard, running u-boot as bootloader).
+
+You should start clearing the partitions table on the SD card. Because
+the u-boot image must be stored at the offset 0x400, it must be assured
+that there is no partition at that address. A new SD card is already
+formatted with FAT filesystem and the partition starts from the first
+cylinder, so we need to change it.
+
+You can do all steps with fdisk. If the device for the SD card is
+/dev/mmcblk0, the following commands make the job:
+
+1. Start the fdisk utility (as superuser)
+	fdisk /dev/mmcblk0
+
+2. Clear the actual partition
+
+Command (m for help): o
+
+3. Print card info:
+
+Command (m for help): p
+Disk /dev/mmcblk0: 1981 MB, 1981284352 bytes
+
+In my case, I have a 2 GB card. I need the size to set later the correct value
+for the cylinders.
+
+4. Go to expert mode:
+
+Command (m for help): x
+
+5. Set card geometry
+
+Expert command (m for help): h
+Number of heads (1-256, default 4): 255
+
+Expert command (m for help): s
+Number of sectors (1-63, default 16): 63
+Warning: setting sector offset for DOS compatiblity
+
+We have set 255 heads, 63 sector. We have to set the cylinder.
+The value to be set can be calculated with:
+
+	cilynder = <total size> / <heads> / <sectors> / <blocksize>
+
+in this example,
+	1981284352 / 255 / 63 / 512 = 239.x = 239
+
+
+Expert command (m for help): c
+Number of cylinders (1-1048576, default 60032): 239
+
+6. Leave the expert mode
+Expert command (m for help): r
+
+7. Set up a partition
+
+Now set a partition table to store the kernel or whatever you want. Of course,
+you can set additional partitions to store rootfs, data, etc.
+In my example I want to set a single partition. I must take care
+to not overwrite the space where I will put u-boot.
+
+Command (m for help): n
+Command action
+   e   extended
+   p   primary partition (1-4)
+p
+Partition number (1-4): 1
+First cylinder (1-239, default 1): 3
+Last cylinder, +cylinders or +size{K,M,G} (3-239, default 239): +100M
+
+Command (m for help): p
+
+Disk /dev/mmcblk0: 1967 MB, 1967128576 bytes
+255 heads, 63 sectors/track, 239 cylinders
+Units = cylinders of 16065 * 512 = 8225280 bytes
+Disk identifier: 0xb712a870
+
+	Device Boot	 Start	       End	Blocks	 Id  System
+/dev/mmcblk0p1		     3		16	112455	 83  Linux
+
+I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
+there.
+
+8. Write the partition table and exit.
+
+Command (m for help): w
+The partition table has been altered!
+
+Calling ioctl() to re-read partition table.
+
+9. Copy u-boot.imx on the SD card
+
+I use dd:
+
+dd if=u-boot.imx of=/dev/mmcblk0 bs=512 seek=2
+
+This command copies the u-boot image at the address 0x400, as required
+by the processor.
+
+Now remove your card from the PC and go to the target. If evrything went right,
+the u-boot prompt should come after power on.
+
+------------------------------------------------
+Author: Stefano babic <sbabic@denx.de>
diff --git a/u-boot/doc/README.iomux b/u-boot/doc/README.iomux
new file mode 100644
index 0000000..5b82a86
--- /dev/null
+++ b/u-boot/doc/README.iomux
@@ -0,0 +1,106 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH <garyj@denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+U-Boot console multiplexing
+===========================
+
+HOW CONSOLE MULTIPLEXING WORKS
+------------------------------
+
+This functionality is controlled with CONFIG_CONSOLE_MUX in the board
+configuration file.
+
+Two new files, common/iomux.c and include/iomux.h, contain the heart
+(iomux_doenv()) of the environment setting implementation.
+
+iomux_doenv() is called in common/cmd_nvedit.c to handle setenv and in
+common/console.c in console_init_r() during bootup to initialize
+stdio_devices[].
+
+A user can use a comma-separated list of devices to set stdin, stdout
+and stderr.  For example: "setenv stdin serial,nc".  NOTE: No spaces
+are allowed around the comma(s)!
+
+The length of the list is limited by malloc(), since the array used
+is allocated and freed dynamically.
+
+It should be possible to specify any device which console_assign()
+finds acceptable, but the code has only been tested with serial and
+nc.
+
+iomux_doenv() prevents multiple use of the same device, e.g. "setenv
+stdin nc,nc,serial" will discard the second nc.  iomux_doenv() is
+not able to modify the environment, however, so that "pri stdin" still
+shows "nc,nc,serial".
+
+The major change in common/console.c was to modify fgetc() to call
+the iomux_tstc() routine in a for-loop.  iomux_tstc() in turn calls
+the tstc() routine for every registered device, but exits immediately
+when one of them returns true.  fgetc() then calls iomux_getc(),
+which calls the corresponding getc() routine.  fgetc() hangs in
+the for-loop until iomux_tstc() returns true and the input can be
+retrieved.
+
+Thus, a user can type into any device registered for stdin.  No effort
+has been made to demulitplex simultaneous input from multiple stdin
+devices.
+
+fputc() and fputs() have been modified to call iomux_putc() and
+iomux_puts() respectively, which call the corresponding output
+routines for every registered device.
+
+Thus, a user can see the ouput for any device registered for stdout
+or stderr on all devices registered for stdout or stderr.  As an
+example, if stdin=serial,nc and stdout=serial,nc then all output
+for serial, e.g. echos of input on serial, will appear on serial and nc.
+
+Just as with the old console code, this statement is still true:
+If not defined in the environment, the first input device is assigned
+to the 'stdin' file, the first output one to 'stdout' and 'stderr'.
+
+If CONFIG_SYS_CONSOLE_IS_IN_ENV is defined then multiple input/output
+devices can be set at boot time if defined in the environment.
+
+CAVEATS
+-------
+
+Note that common/iomux.c calls console_assign() for every registered
+device as it is discovered.  This means that the environment settings
+for application consoles will be set to the last device in the list.
+
+On a slow machine, such as MPC852T clocked at 66MHz, the overhead associated
+with calling tstc() and then getc() means that copy&paste will normally not
+work, even when stdin=stdout=stderr=serial.
+On a faster machine, such as a sequoia, cut&paste of longer (about 80
+characters) lines works fine when serial is the only device used.
+
+Using nc as a stdin device results in even more overhead because nc_tstc()
+is quite slow.  Even on a sequoia cut&paste does not work on the serial
+interface when nc is added to stdin, although there is no character loss using
+the ethernet interface for input. In this test case stdin=serial,nc and
+stdout=serial.
+
+In addition, the overhead associated with sending to two devices, when one of
+them is nc, also causes problems.  Even on a sequoia cut&paste does not work
+on the serial interface (stdin=serial) when nc is added to stdout (stdout=
+serial,nc).
diff --git a/u-boot/doc/README.kmeter1 b/u-boot/doc/README.kmeter1
new file mode 100644
index 0000000..7f4fc99
--- /dev/null
+++ b/u-boot/doc/README.kmeter1
@@ -0,0 +1,91 @@
+Keymile kmeter1 Board
+-----------------------------------------
+1.	Alternative Boot EEPROM
+
+    Upon the kmeter1 startup the I2C_1 controller is used to fetch the boot
+    configuration from a serial EEPROM. During the development and debugging
+    phase it might be helpful to apply an alternative boot configuration in
+    a simple way. Therefore it is an alternative boot eeprom on the PIGGY,
+    which can be activated by setting the "ST" jumper on the PIGGY board.
+
+2.	Memory Map
+
+    BaseAddr    PortSz  Size  Device
+    ----------- ------  -----  ------
+    0x0000_0000 64 bit  256MB  DDR
+    0x8000_0000  8 bit  256KB  GPIO/PIGGY on CS1
+    0xa000_0000  8 bit  256MB  PAXE on CS3
+    0xe000_0000           2MB  Int Mem Reg Space
+    0xf000_0000 16 bit  256MB  FLASH on CS0
+
+
+    DDR-SDRAM:
+    The current realization is made with four 16-bits memory devices.
+    Mounting options have been foreseen for device architectures from
+    4Mx16 to 512Mx16. The kmeter1 is equipped with four 32Mx16 devices
+    thus resulting in a total capacity of 256MBytes.
+
+3. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+		make kmeter1_config
+		make
+
+4. Downloading and Flashing Images
+
+4.0 Download over serial line using Kermit:
+
+	loadb
+	[Drop to kermit:
+	    ^\c
+	    send <u-boot-bin-image>
+	    c
+	]
+
+
+    Or via tftp:
+
+	tftp 10000 u-boot.bin
+    => run load
+    Using UEC0 device
+    TFTP from server 192.168.1.1; our IP address is 192.168.205.4
+    Filename '/tftpboot/kmeter1/u-boot.bin'.
+    Load address: 0x200000
+    Loading: ##############
+    done
+    Bytes transferred = 204204 (31dac hex)
+    =>
+
+4.1 Reflash U-boot Image using U-boot
+
+    => run update
+    ..... done
+    Un-Protected 5 sectors
+
+    ..... done
+    Erased 5 sectors
+    Copy to Flash... done
+    ..... done
+    Protected 5 sectors
+    Total of 204204 bytes were the same
+    Saving Environment to Flash...
+    . done
+    Un-Protected 1 sectors
+    . done
+    Un-Protected 1 sectors
+    Erasing Flash...
+    . done
+    Erased 1 sectors
+    Writing to Flash... done
+    . done
+    Protected 1 sectors
+    . done
+    Protected 1 sectors
+    =>
+
+5. Notes
+	1) The console baudrate for kmeter1 is 115200bps.
diff --git a/u-boot/doc/README.korat b/u-boot/doc/README.korat
new file mode 100644
index 0000000..e059f78
--- /dev/null
+++ b/u-boot/doc/README.korat
@@ -0,0 +1,64 @@
+The Korat board has two NOR flashes, FLASH0 and FLASH1, which are connected to
+chip select 0 and 1, respectively.  FLASH0 contains 16 MiB, and is mapped to
+addresses 0xFF000000 - 0xFFFFFFFF as U-Boot Flash Bank #2.  FLASH1 contains
+from 16 to 128 MiB, and is mapped to 0xF?000000 - 0xF7FFFFFF as U-Boot Flash
+Bank #1 (with the starting address depending on the flash size detected at
+runtime).  The write-enable pin on FLASH0 is disabled, so the contents of FLASH0
+cannot be modified in the field.  This also prevents FLASH0 from executing
+commands to return chip information, so its configuration is hard-coded in
+U-Boot.
+
+There are two versions of U-Boot for Korat: "permanent" and "upgradable".  The
+permanent U-Boot is pre-programmed at the top of FLASH0, e.g., at addresses
+0xFFFA0000 - 0xFFFFFFFF for the current 384 KiB size.  The upgradable U-Boot is
+located 256 KiB from the top of FLASH1, e.g. at addresses 0xF7F6000 - 0xF7FC0000
+for the current 384 KiB size.  FLASH1 addresses 0xF7FE0000 - 0xF7FF0000 are
+used for the U-Boot environmental parameters, and addresses 0xF7FC0000 -
+0xF7FDFFFF are used for the redundant copy of the parameters.  These locations
+are used by both versions of U-Boot.
+
+On booting, the permanent U-Boot in FLASH0 begins executing.  After performing
+minimal setup, it monitors the state of the board's Reset switch (GPIO47).  If
+the switch is sensed as open before a timeout period, then U-Boot branches to
+address 0xF7FBFFFC.  This causes the upgradable U-Boot to execute from the
+beginning.  If the switch remains closed thoughout the timeout period, the
+permanent U-Boot activates the on-board buzzer until the switch is sensed as
+opened.  It then continues to execute without branching to FLASH1.  The effect
+of this is that normally the Korat board boots its upgradable U-Boot, but, if
+this has been corrupted, the user can boot the permanent U-Boot, which can then
+be used to erase and reload FLASH1 as needed.
+
+Note that it is not necessary for the permanent U-Boot to have all the latest
+features, but only that it have sufficient functionality (working "tftp",
+"erase", "cp.b", etc.) to repair FLASH1.  Also, the permanent U-Boot makes no
+assumptions about the size of FLASH1 or the size of the upgradable U-Boot: it is
+sufficient that the upgradable U-Boot can be started by a branch to 0xF7FBFFFC.
+
+The build sequence:
+
+	make korat_perm_config
+	make all
+
+builds the permanent U-Boot by selecting loader file "u-boot.lds" and defining
+preprocessor symbol "CONFIG_KORAT_PERMANENT".  The default build:
+
+	make korat_config
+	make all
+
+creates the upgradable U-Boot by selecting loader file "u-boot-F7FC.lds" and
+leaving preprocessor symbol "CONFIG_KORAT_PERMANENT" undefined.
+
+2008-02-22, Larry Johnson <lrj@acm.org>
+
+
+The CompactFlash(R) controller on the Korat board provides a hi-speed USB
+interface.  This may be connected to either a dedicated port on the on-board
+USB controller, or to a USB port on the PowerPC 440EPx processor.  The U-Boot
+environment variable "korat_usbcf" can be used to specify which of these two
+USB host ports is used for CompactFlash.  The valid setting for the variable are
+the strings "pci" and "ppc".  If the variable defined and set to "ppc", then the
+PowerPC USB port is used.  In all other cases the on-board USB controller is
+used, but if "korat_usbcf" is defined but is set to a string other than the two
+valid options, a warning is also issued.
+
+2009-01-28, Larry Johnson <lrj@acm.org>
diff --git a/u-boot/doc/README.kwbimage b/u-boot/doc/README.kwbimage
new file mode 100644
index 0000000..6dd942f
--- /dev/null
+++ b/u-boot/doc/README.kwbimage
@@ -0,0 +1,93 @@
+---------------------------------------------
+Kirkwood Boot Image generation using mkimage
+---------------------------------------------
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Command syntax:
+--------------
+./tools/mkimage -l <kwboot_file>
+		to list the kwb image file details
+
+./tools/mkimage -n <board specific configuration file> \
+		-T kwbimage -a <start address> -e <execution address> \
+		-d <input_raw_binary> <output_kwboot_file>
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+		-T kwbimage -a 0x00600000 -e 0x00600000 \
+		-d u-boot.bin u-boot.kwb
+
+kwimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash
+
+Board specific configuration file specifications:
+------------------------------------------------
+1. This file must present in the $(BOARDDIR) and the name should be
+	kwbimage.cfg (since this is used in Makefile)
+2. This file can have empty lines and lines starting with "#" as first
+	character to put comments
+3. This file can have configuration command lines as mentioned below,
+	any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+---------------------------------
+1. Each command line is must have two strings, first one command or address
+	and second one data string
+2. Following are the valid command strings and associated data strings:-
+	Command string		data string
+	--------------		-----------
+	BOOT_FROM		nand/spi/sata
+	NAND_ECC_MODE		default/rs/hamming/disabled
+	NAND_PAGE_SIZE		any uint16_t hex value
+	SATA_PIO_MODE		any uint32_t hex value
+	DDR_INIT_DELAY		any uint32_t hex value
+	DATA			regaddr and regdara hex value
+	you can have maximum 55 such register programming commands
+
+3. All commands are optional to program
+
+Typical example of kwimage.cfg file:
+-----------------------------------
+
+# Boot Media configurations
+BOOT_FROM	nand
+NAND_ECC_MODE	default
+NAND_PAGE_SIZE	0x0800
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+# DRAM Configuration
+DATA 0xFFD01400 0x43000c30
+DATA 0xFFD01404 0x37543000
+DATA 0xFFD01408 0x22125451
+DATA 0xFFD0140C 0x00000a33
+DATA 0xFFD01410 0x000000cc
+DATA 0xFFD01414 0x00000000
+DATA 0xFFD01418 0x00000000
+DATA 0xFFD0141C 0x00000C52
+DATA 0xFFD01420 0x00000040
+DATA 0xFFD01424 0x0000F17F
+DATA 0xFFD01428 0x00085520
+DATA 0xFFD0147C 0x00008552
+DATA 0xFFD01504 0x0FFFFFF1
+DATA 0xFFD01508 0x10000000
+DATA 0xFFD0150C 0x0FFFFFF5
+DATA 0xFFD01514 0x00000000
+DATA 0xFFD0151C 0x00000000
+DATA 0xFFD01494 0x00030000
+DATA 0xFFD01498 0x00000000
+DATA 0xFFD0149C 0x0000E803
+DATA 0xFFD01480 0x00000001
+# End of Header extension
+DATA 0x0 0x0
+
+------------------------------------------------
+Author: Prafulla Wadaskar <prafulla@marvell.com>
diff --git a/u-boot/doc/README.lynxkdi b/u-boot/doc/README.lynxkdi
new file mode 100644
index 0000000..076f018
--- /dev/null
+++ b/u-boot/doc/README.lynxkdi
@@ -0,0 +1,57 @@
+			   LYNX KDI SUPPORT
+
+		    Last Update: July 20, 2003
+=======================================================================
+
+This file describes support for LynuxWorks KDI within U-Boot. Support
+is enabled by defining CONFIG_LYNXKDI.
+
+
+LYNXOS AND BLUECAT SUPPORTED
+============================
+Both LynxOS and BlueCat linux KDIs are supported. The implementation
+automatically detects which is being booted. When you use mkimage
+you should specify "lynxos" for both (see target-specific notes).
+
+
+SUPPORTED ARCHITECTURE/TARGETS
+==============================
+The following targets have been tested:
+
+-PowerPC  MPC8260ADS
+
+
+FILES TO LOOK AT
+================
+include/lynxkdi.h    -defines a simple struct passed to a kdi.
+common/lynxkdi.c     -implements the call to the kdi.
+common/cmd_bootm.c   -top-level command implementation ("bootm").
+
+
+====================================================================
+TARGET SPECIFIC NOTES
+====================================================================
+
+MPC8260ADS
+===========
+The default LynxOS and BlueCat implementations require some
+modifications to the config file.
+
+Edit include/configs/MPC8260ADS.h to use the following:
+
+#define CONFIG_SYS_IMMR	0xFA200000
+#define CONFIG_SYS_BCSR	0xFA100000
+#define CONFIG_SYS_BR1_PRELIM	0xFA101801
+
+When creating a LynxOS or BlueCat u-boot image using mkimage,
+you must specify the following:
+
+Both:    -A ppc -O lynxos -T kernel -C none
+LynxOS:  -a 0x00004000 -e 0x00004020
+BlueCat: -a 0x00500000 -e 0x00507000
+
+To pass the MAC address to BlueCat you should define the
+"fcc2_ether_addr" parameter in the "bootargs" environment
+variable. E.g.:
+
+==> setenv bootargs fcc2_ether_addr=00:11:22:33:44:55:66
diff --git a/u-boot/doc/README.m52277evb b/u-boot/doc/README.m52277evb
new file mode 100644
index 0000000..b6e955b
--- /dev/null
+++ b/u-boot/doc/README.m52277evb
@@ -0,0 +1,231 @@
+Freescale MCF52277EVB ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created Jan 8, 2008
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m52277evb/m52277evb.c	Dram setup
+- board/freescale/m52277evb/Makefile	Makefile
+- board/freescale/m52277evb/config.mk	config make
+- board/freescale/m52277evb/u-boot.lds	Linker description
+
+- arch/m68k/cpu/mcf5227x/cpu.c		cpu specific code
+- arch/m68k/cpu/mcf5227x/cpu_init.c	FBCS, Mux pins, icache and RTC extra regs
+- arch/m68k/cpu/mcf5227x/interrupts.c	cpu specific interrupt support
+- arch/m68k/cpu/mcf5227x/speed.c		system, flexbus, and cpu clock
+- arch/m68k/cpu/mcf5227x/Makefile		Makefile
+- arch/m68k/cpu/mcf5227x/config.mk	config make
+- arch/m68k/cpu/mcf5227x/start.S		start up assembly code
+
+- doc/README.m52277evb		This readme file
+
+- drivers/serial/mcfuart.c	ColdFire common UART driver
+- drivers/rtc/mcfrtc.c		Realtime clock Driver
+
+- include/asm-m68k/bitops.h		Bit operation function export
+- include/asm-m68k/byteorder.h		Byte order functions
+- include/asm-m68k/crossbar.h		CrossBar structure and definition
+- include/asm-m68k/dspi.h		DSPI structure and definition
+- include/asm-m68k/edma.h		eDMA structure and definition
+- include/asm-m68k/flexbus.h		FlexBus structure and definition
+- include/asm-m68k/fsl_i2c.h		I2C structure and definition
+- include/asm-m68k/global_data.h	Global data structure
+- include/asm-m68k/immap.h		ColdFire specific header file and driver macros
+- include/asm-m68k/immap_5227x.h	mcf5227x specific header file
+- include/asm-m68k/io.h			io functions
+- include/asm-m68k/lcd.h		LCD structure and definition
+- include/asm-m68k/m5227x.h		mcf5227x specific header file
+- include/asm-m68k/posix_types.h	Posix
+- include/asm-m68k/processor.h		header file
+- include/asm-m68k/ptrace.h		Exception structure
+- include/asm-m68k/rtc.h		Realtime clock header file
+- include/asm-m68k/ssi.h		SSI structure and definition
+- include/asm-m68k/string.h		String function export
+- include/asm-m68k/timer.h		Timer structure and definition
+- include/asm-m68k/types.h		Data types definition
+- include/asm-m68k/uart.h		Uart structure and definition
+- include/asm-m68k/u-boot.h		u-boot structure
+
+- include/configs/M52277EVB.h		Board specific configuration file
+
+- arch/m68k/lib/board.c			board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts			Coldfire common interrupt functions
+- arch/m68k/lib/m68k_linux.c
+- arch/m68k/lib/time.c			Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c			Exception init code
+
+1 MCF52277 specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in this coldfire family
+
+1.2 Configuration settings for M52277EVB Development Board
+CONFIG_MCF5227x		-- define for all MCF5227x CPUs
+CONFIG_M52277		-- define for all Freescale MCF52277 CPUs
+CONFIG_M52277EVB	-- define for M52277EVB board
+
+CONFIG_MCFUART		-- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT		-- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE		-- define UART baudrate
+
+CONFIG_MCFRTC		-- define to use common CF RTC driver
+CONFIG_SYS_MCFRTC_BASE		-- provide base address for RTC in immap.h
+CONFIG_SYS_RTC_OSCILLATOR	-- define RTC clock frequency
+RTC_DEBUG		-- define to show RTC debug message
+CONFIG_CMD_DATE		-- enable to use date feature in u-boot
+
+CONFIG_MCFTMR		-- define to use DMA timer
+CONFIG_MCFPIT		-- define to use PIT timer
+
+CONFIG_FSL_I2C		-- define to use FSL common I2C driver
+CONFIG_HARD_I2C		-- define for I2C hardware support
+CONFIG_SOFT_I2C		-- define for I2C bit-banged
+CONFIG_SYS_I2C_SPEED		-- define for I2C speed
+CONFIG_SYS_I2C_SLAVE		-- define for I2C slave address
+CONFIG_SYS_I2C_OFFSET		-- define for I2C base address offset
+CONFIG_SYS_IMMR		-- define for MBAR offset
+
+CONFIG_SYS_MBAR		-- define MBAR offset
+
+CONFIG_MONITOR_IS_IN_RAM -- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR	-- defines the base address of the MCF52277 internal SRAM
+
+CONFIG_SYS_CSn_BASE	-- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK	-- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL	-- defines the Chip Select Control register
+
+CONFIG_SYS_SDRAM_BASE	-- defines the DRAM Base
+
+CONFIG_LCD and CONFIG_CMD_USB are not supported in this current u-boot,
+update will be provided at later time
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+	Flash:		0x00000000-0x3FFFFFFF (1024MB)
+	DDR:		0x40000000-0x7FFFFFFF (1024MB)
+	SRAM:		0x80000000-0x8FFFFFFF (256MB)
+	IP:		0xF0000000-0xFFFFFFFF (256MB)
+
+2.2. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+	linux kernel, you can customize it based on your system requirements:
+	Flash0:		0x00000000-0x00FFFFFF (16MB)
+
+	DDR:		0x40000000-0x4FFFFFFF (64MB)
+	SRAM:		0x80000000-0x80007FFF (32KB)
+	IP:		0xFC000000-0xFC0FFFFF (64KB)
+
+3. COMPILATION
+==============
+3.1	To create U-Boot the gcc-4.1-xx compiler set (ColdFire ELF or
+uClinux version) from codesourcery.com was used. Download it from:
+http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+3.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot-1.x.x
+   make distclean
+   make M52277EVB_config
+   make
+
+4. SCREEN DUMP
+==============
+4.1 M52277EVB Development board
+    (NOTE: May not show exactly the same)
+
+U-Boot 1.3.1 (Jan 8 2008 - 12:44:08)
+
+CPU:   Freescale MCF52277 (Mask:6c Version:0)
+       CPU CLK 160 Mhz BUS CLK 80 Mhz FLB CLK 80 MHZ
+       INP CLK 16 Mhz VCO CLK 480 Mhz
+Board: Freescale 52277 EVB
+I2C:   ready
+DRAM:  64 MB
+FLASH: 16 MB
+In:    serial
+Out:   serial
+Err:   serial
+-> print
+baudrate=115200
+hostname=M52277EVB
+inpclk=16000000
+loadaddr=(0x40000000 + 0x10000)
+load=tftp ${loadaddr) ${u-boot}
+upd=run load; run prog
+prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
+u-boot=u-boot.bin
+stdin=serial
+stdout=serial
+stderr=serial
+mem=65024k
+
+Environment size: 280/32764 bytes
+-> bdinfo
+memstart    = 0x40000000
+memsize     = 0x04000000
+flashstart  = 0x00000000
+flashsize   = 0x01000000
+flashoffset = 0x00000000
+sramstart   = 0x80000000
+sramsize    = 0x00008000
+mbar        = 0xFC000000
+busfreq     =     80 MHz
+flbfreq     =     80 Mhz
+inpfreq     =     16 Mhz
+vcofreq     =    480 Mhz
+
+baudrate    = 115200 bps
+->
+-> help
+?       - alias for 'help'
+base    - print or set address offset
+bdinfo  - print Board Info structure
+boot    - boot default, i.e., run 'bootcmd'
+bootd   - boot default, i.e., run 'bootcmd'
+bootelf - Boot from an ELF image in memory
+bootm   - boot application image from memory
+bootp	- boot image via network using BootP/TFTP protocol
+bootvx  - Boot vxWorks from an ELF image
+cmp     - memory compare
+coninfo - print console devices and information
+cp      - memory copy
+crc32   - checksum calculation
+date    - get/set/reset date & time
+dcache  - enable or disable data cache
+echo    - echo args to console
+erase   - erase FLASH memory
+flinfo  - print FLASH memory information
+go      - start application at address 'addr'
+help    - print online help
+i2c     - I2C sub-system
+icache  - enable or disable instruction cache
+iminfo  - print header information for application image
+imls    - list all images found in flash
+itest	- return true/false on integer compare
+loadb   - load binary file over serial line (kermit mode)
+loads   - load S-Record file over serial line
+loady   - load binary file over serial line (ymodem mode)
+loop    - infinite loop on address range
+ls	- list files in a directory (default /)
+md      - memory display
+mm      - memory modify (auto-incrementing)
+mtest   - simple RAM test
+mw      - memory write (fill)
+nm      - memory modify (constant address)
+ping	- send ICMP ECHO_REQUEST to network host
+printenv- print environment variables
+protect - enable or disable FLASH write protection
+reset   - Perform RESET of the CPU
+run     - run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv  - set environment variables
+sleep   - delay execution for some time
+source  - run script from memory
+version - print monitor version
+->
diff --git a/u-boot/doc/README.m5253evbe b/u-boot/doc/README.m5253evbe
new file mode 100644
index 0000000..f51609f
--- /dev/null
+++ b/u-boot/doc/README.m5253evbe
@@ -0,0 +1,103 @@
+Freescale Amadeus Plus M5253EVBE board
+======================================
+
+Hayden Fraser(Hayden.Fraser@freescale.com)
+Created 06/05/2007
+===========================================
+
+
+1. SWITCH SETTINGS
+==================
+1.1 N/A
+
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+	linux kernel, you can customize it based on your system requirements:
+	SDR:	0x00000000-0x00ffffff
+	SRAM0:	0x20010000-0x20017fff
+	SRAM1:	0x20000000-0x2000ffff
+	MBAR1:	0x10000000-0x4fffffff
+	MBAR2:	0x80000000-0xCfffffff
+	Flash:	0xffe00000-0xffffffff
+
+3. DEFINITIONS AND COMPILATION
+==============================
+3.1 Explanation on NEW definitions in include/configs/M5253EVBE.h
+	CONFIG_MCF52x2		Processor family
+	CONFIG_MCF5253		MCF5253 specific
+	CONFIG_M5253EVBE	Amadeus Plus board specific
+	CONFIG_SYS_CLK			Define Amadeus Plus CPU Clock
+	CONFIG_SYS_MBAR		MBAR base address
+	CONFIG_SYS_MBAR2		MBAR2 base address
+
+3.2 Compilation
+	export CROSS_COMPILE=/usr/local/freescale-coldfire-4.1-elf/bin/m68k-elf-
+	cd u-boot-1-2-x
+	make distclean
+	make M5253EVBE_config
+	make
+
+
+4. SCREEN DUMP
+==============
+4.1 U-Boot 1.2.0 (Jun 18 2007 - 18:20:00)
+
+CPU:   Freescale Coldfire MCF5253 at 62 MHz
+Board: Freescale MCF5253 EVBE
+DRAM:  16 MB
+FLASH:  2 MB
+In:    serial
+Out:   serial
+Err:   serial
+=> flinfo
+
+Bank # 1: CFI conformant FLASH (16 x 16)  Size: 2 MB in 35 Sectors
+  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x49
+  Erase timeout: 16384 ms, write timeout: 1 ms
+
+  Sector Start Addresses:
+  FFE00000   RO   FFE04000   RO   FFE06000   RO   FFE08000   RO   FFE10000   RO
+  FFE20000        FFE30000        FFE40000        FFE50000        FFE60000
+  FFE70000        FFE80000        FFE90000        FFEA0000        FFEB0000
+  FFEC0000        FFED0000        FFEE0000        FFEF0000        FFF00000
+  FFF10000        FFF20000        FFF30000        FFF40000        FFF50000
+  FFF60000        FFF70000        FFF80000        FFF90000        FFFA0000
+  FFFB0000        FFFC0000        FFFD0000        FFFE0000        FFFF0000
+
+=> bdinfo
+boot_params = 0x00F62F90
+memstart    = 0x00000000
+memsize     = 0x01000000
+flashstart  = 0xFFE00000
+flashsize   = 0x00200000
+flashoffset = 0x00000000
+baudrate    = 19200 bps
+
+=> printenv
+bootdelay=5
+baudrate=19200
+stdin=serial
+stdout=serial
+stderr=serial
+
+Environment size: 134/8188 bytes
+=> saveenv
+Saving Environment to Flash...
+Un-Protected 1 sectors
+Erasing Flash...
+. done
+Erased 1 sectors
+Writing to Flash... done
+Protected 1 sectors
+=>
+
+5. COMPILER
+-----------
+To create U-Boot the CodeSourcery's version of the GNU Toolchain for the ColdFire architecture
+compiler set (freescale-coldfire-4.1-elf) from www.codesourcery.com was used.
+You can download it from:http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+compiler that you used - for example, codesourcery_elf requires -MQ in rules.mk, old M68K 2.95.3 just -M
+codesourcery_elf requires -MQ in rules.mk, old M68K 2.95.3 just -M
diff --git a/u-boot/doc/README.m53017evb b/u-boot/doc/README.m53017evb
new file mode 100644
index 0000000..42798c2
--- /dev/null
+++ b/u-boot/doc/README.m53017evb
@@ -0,0 +1,181 @@
+Freescale MCF53017EVB ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created 10/22/08
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m53017evb/m53017evb.c	Dram setup
+- board/freescale/m53017evb/mii.c	Mii access
+- board/freescale/m53017evb/Makefile	Makefile
+- board/freescale/m53017evb/config.mk	config make
+- board/freescale/m53017evb/u-boot.lds	Linker description
+
+- arch/m68k/cpu/mcf532x/cpu.c			cpu specific code
+- arch/m68k/cpu/mcf532x/cpu_init.c		FBCS, Mux pins, icache and RTC extra regs
+- arch/m68k/cpu/mcf532x/interrupts.c		cpu specific interrupt support
+- arch/m68k/cpu/mcf532x/speed.c			system, flexbus, and cpu clock
+- arch/m68k/cpu/mcf532x/Makefile			Makefile
+- arch/m68k/cpu/mcf532x/config.mk			config make
+- arch/m68k/cpu/mcf532x/start.S			start up assembly code
+
+- doc/README.m53017evb			This readme file
+
+- drivers/net/mcffec.c			ColdFire common FEC driver
+- drivers/net/mcfmii.c			ColdFire common Mii driver
+- drivers/serial/mcfuart.c		ColdFire common UART driver
+- drivers/rtc/mcfrtc.c			Realtime clock Driver
+
+- include/asm-m68k/bitops.h		Bit operation function export
+- include/asm-m68k/byteorder.h		Byte order functions
+- include/asm-m68k/fec.h		FEC structure and definition
+- include/asm-m68k/fsl_i2c.h		I2C structure and definition
+- include/asm-m68k/global_data.h	Global data structure
+- include/asm-m68k/immap.h		ColdFire specific header file and driver macros
+- include/asm-m68k/immap_5301x.h	mcf5301x specific header file
+- include/asm-m68k/io.h			io functions
+- include/asm-m68k/m532x.h		mcf5301x specific header file
+- include/asm-m68k/posix_types.h	Posix
+- include/asm-m68k/processor.h		header file
+- include/asm-m68k/ptrace.h		Exception structure
+- include/asm-m68k/rtc.h		Realtime clock header file
+- include/asm-m68k/string.h		String function export
+- include/asm-m68k/timer.h		Timer structure and definition
+- include/asm-m68k/types.h		Data types definition
+- include/asm-m68k/uart.h		Uart structure and definition
+- include/asm-m68k/u-boot.h		u-boot structure
+
+- include/configs/M53017EVB.h		Board specific configuration file
+
+- arch/m68k/lib/board.c			board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts			Coldfire common interrupt functions
+- arch/m68k/lib/m68k_linux.c
+- arch/m68k/lib/time.c			Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c			Exception init code
+
+1 MCF5301x specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M53017EVB Development Board
+CONFIG_MCF5301x			-- define for all MCF5301x CPUs
+CONFIG_M53015			-- define for MCF53015 CPUs
+CONFIG_M53017EVB		-- define for M53017EVB board
+
+CONFIG_MCFUART			-- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT		-- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE			-- define UART baudrate
+
+CONFIG_MCFRTC			-- define to use common CF RTC driver
+CONFIG_SYS_MCFRTC_BASE		-- provide base address for RTC in immap.h
+CONFIG_SYS_RTC_OSCILLATOR	-- define RTC clock frequency
+RTC_DEBUG			-- define to show RTC debug message
+CONFIG_CMD_DATE			-- enable to use date feature in u-boot
+
+CONFIG_MCFFEC			-- define to use common CF FEC driver
+CONFIG_NET_MULTI		-- define to use multi FEC in u-boot
+CONFIG_MII			-- enable to use MII driver
+CONFIG_CF_DOMII			-- enable to use MII feature in cmd_mii.c
+CONFIG_SYS_DISCOVER_PHY		-- enable PHY discovery
+CONFIG_SYS_RX_ETH_BUFFER	-- Set FEC Receive buffer
+CONFIG_SYS_FAULT_ECHO_LINK_DOWN	--
+CONFIG_SYS_FEC0_PINMUX		-- Set FEC0 Pin configuration
+CONFIG_SYS_FEC0_MIIBASE		-- Set FEC0 MII base register
+MCFFEC_TOUT_LOOP		-- set FEC timeout loop
+
+CONFIG_MCFTMR			-- define to use DMA timer
+CONFIG_MCFPIT			-- define to use PIT timer
+
+CONFIG_FSL_I2C			-- define to use FSL common I2C driver
+CONFIG_HARD_I2C			-- define for I2C hardware support
+CONFIG_SOFT_I2C			-- define for I2C bit-banged
+CONFIG_SYS_I2C_SPEED		-- define for I2C speed
+CONFIG_SYS_I2C_SLAVE		-- define for I2C slave address
+CONFIG_SYS_I2C_OFFSET		-- define for I2C base address offset
+CONFIG_SYS_IMMR			-- define for MBAR offset
+
+CONFIG_SYS_MBAR			-- define MBAR offset
+
+CONFIG_MONITOR_IS_IN_RAM 	-- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR	-- defines the base address of the MCF5301x internal SRAM
+
+CONFIG_SYS_CSn_BASE		-- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK		-- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL		-- defines the Chip Select Control register
+
+CONFIG_SYS_SDRAM_BASE		-- defines the DRAM Base
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+	Flash:		0x00000000-0x3FFFFFFF (1024MB)
+	DDR:		0x40000000-0x7FFFFFFF (1024MB)
+	SRAM:		0x80000000-0x8FFFFFFF (256MB)
+	IP:		0xFC000000-0xFFFFFFFF (256MB)
+
+2.2. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+	linux kernel, you can customize it based on your system requirements:
+	Flash0:		0x00000000-0x00FFFFFF (16MB)
+	DDR:		0x40000000-0x4FFFFFFF (256MB)
+	SRAM:		0x80000000-0x80007FFF (32KB)
+	IP:		0xFC000000-0xFC0FFFFF (64KB)
+
+3. COMPILATION
+==============
+3.1	To create U-Boot the gcc-4.x-xx compiler set (ColdFire ELF or
+uClinux version) from codesourcery.com was used. Download it from:
+http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+3.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot
+   make distclean
+   make M53017EVB_config
+   make
+
+4. SCREEN DUMP
+==============
+4.1 M53017EVB Development board
+    (NOTE: May not show exactly the same)
+
+U-Boot 2008.10 (Oct 22 2007 - 11:07:57)
+
+CPU:   Freescale MCF53015 (Mask:76 Version:0)
+       CPU CLK 240 Mhz BUS CLK 80 Mhz
+Board: Freescale M53017EVB
+I2C:   ready
+DRAM:  64 MB
+FLASH: 16 MB
+In:    serial
+Out:   serial
+Err:   serial
+NAND:  16 MiB
+Net:   FEC0, FEC1
+-> print
+bootdelay=1
+baudrate=115200
+ethaddr=00:e0:0c:bc:e5:60
+hostname=M53017EVB
+netdev=eth0
+loadaddr=40010000
+u-boot=u-boot.bin
+load=tftp ${loadaddr) ${u-boot}
+upd=run load; run prog
+prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
+gatewayip=192.168.1.1
+netmask=255.255.255.0
+ipaddr=192.168.1.3
+serverip=192.168.1.2
+stdin=serial
+stdout=serial
+stderr=serial
+mem=65024k
+
+Environment size: 437/4092 bytes
+->
diff --git a/u-boot/doc/README.m5373evb b/u-boot/doc/README.m5373evb
new file mode 100644
index 0000000..e90a320
--- /dev/null
+++ b/u-boot/doc/README.m5373evb
@@ -0,0 +1,327 @@
+Freescale MCF5373EVB ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created 11/08/07
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m5373evb/m5373evb.c	Dram setup
+- board/freescale/m5373evb/mii.c	Mii access
+- board/freescale/m5373evb/Makefile	Makefile
+- board/freescale/m5373evb/config.mk	config make
+- board/freescale/m5373evb/u-boot.lds	Linker description
+
+- arch/m68k/cpu/mcf532x/cpu.c		cpu specific code
+- arch/m68k/cpu/mcf532x/cpu_init.c	FBCS, Mux pins, icache and RTC extra regs
+- arch/m68k/cpu/mcf532x/interrupts.c	cpu specific interrupt support
+- arch/m68k/cpu/mcf532x/speed.c		system, pci, flexbus, and cpu clock
+- arch/m68k/cpu/mcf532x/Makefile		Makefile
+- arch/m68k/cpu/mcf532x/config.mk		config make
+- arch/m68k/cpu/mcf532x/start.S		start up assembly code
+
+- doc/README.m5373evb		This readme file
+
+- drivers/net/mcffec.c		ColdFire common FEC driver
+- drivers/serial/mcfuart.c	ColdFire common UART driver
+- drivers/rtc/mcfrtc.c		Realtime clock Driver
+
+- include/asm-m68k/bitops.h		Bit operation function export
+- include/asm-m68k/byteorder.h		Byte order functions
+- include/asm-m68k/fec.h		FEC structure and definition
+- include/asm-m68k/fsl_i2c.h		I2C structure and definition
+- include/asm-m68k/global_data.h	Global data structure
+- include/asm-m68k/immap.h		ColdFire specific header file and driver macros
+- include/asm-m68k/immap_532x.h		mcf532x specific header file
+- include/asm-m68k/io.h			io functions
+- include/asm-m68k/m532x.h		mcf532x specific header file
+- include/asm-m68k/posix_types.h	Posix
+- include/asm-m68k/processor.h		header file
+- include/asm-m68k/ptrace.h		Exception structure
+- include/asm-m68k/rtc.h		Realtime clock header file
+- include/asm-m68k/string.h		String function export
+- include/asm-m68k/timer.h		Timer structure and definition
+- include/asm-m68k/types.h		Data types definition
+- include/asm-m68k/uart.h		Uart structure and definition
+- include/asm-m68k/u-boot.h		u-boot structure
+
+- include/configs/M5373EVB.h		Board specific configuration file
+
+- arch/m68k/lib/board.c			board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts			Coldfire common interrupt functions
+- arch/m68k/lib/m68k_linux.c
+- arch/m68k/lib/time.c			Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c			Exception init code
+
+1 MCF5373 specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M5373EVB Development Board
+CONFIG_MCF532x		-- define for all MCF532x CPUs
+CONFIG_M5373		-- define for all Freescale MCF5373 CPUs
+CONFIG_M5373EVB		-- define for M5373EVB board
+
+CONFIG_MCFUART		-- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT		-- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE		-- define UART baudrate
+
+CONFIG_MCFRTC		-- define to use common CF RTC driver
+CONFIG_SYS_MCFRTC_BASE		-- provide base address for RTC in immap.h
+CONFIG_SYS_RTC_OSCILLATOR	-- define RTC clock frequency
+RTC_DEBUG		-- define to show RTC debug message
+CONFIG_CMD_DATE		-- enable to use date feature in u-boot
+
+CONFIG_MCFFEC		-- define to use common CF FEC driver
+CONFIG_NET_MULTI	-- define to use multi FEC in u-boot
+CONFIG_MII		-- enable to use MII driver
+CONFIG_CF_DOMII		-- enable to use MII feature in cmd_mii.c
+CONFIG_SYS_DISCOVER_PHY	-- enable PHY discovery
+CONFIG_SYS_RX_ETH_BUFFER	-- Set FEC Receive buffer
+CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
+CONFIG_SYS_FEC0_PINMUX		-- Set FEC0 Pin configuration
+CONFIG_SYS_FEC0_MIIBASE	-- Set FEC0 MII base register
+MCFFEC_TOUT_LOOP	-- set FEC timeout loop
+
+CONFIG_MCFTMR		-- define to use DMA timer
+CONFIG_MCFPIT		-- define to use PIT timer
+
+CONFIG_FSL_I2C		-- define to use FSL common I2C driver
+CONFIG_HARD_I2C		-- define for I2C hardware support
+CONFIG_SOFT_I2C		-- define for I2C bit-banged
+CONFIG_SYS_I2C_SPEED		-- define for I2C speed
+CONFIG_SYS_I2C_SLAVE		-- define for I2C slave address
+CONFIG_SYS_I2C_OFFSET		-- define for I2C base address offset
+CONFIG_SYS_IMMR		-- define for MBAR offset
+
+CONFIG_SYS_MBAR		-- define MBAR offset
+
+CONFIG_MONITOR_IS_IN_RAM -- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR	-- defines the base address of the MCF5373 internal SRAM
+
+CONFIG_SYS_CSn_BASE	-- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK	-- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL	-- defines the Chip Select Control register
+
+CONFIG_SYS_SDRAM_BASE	-- defines the DRAM Base
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+	Flash:		0x00000000-0x3FFFFFFF (1024MB)
+	DDR:		0x40000000-0x7FFFFFFF (1024MB)
+	SRAM:		0x80000000-0x8FFFFFFF (256MB)
+	IP:		0xF0000000-0xFFFFFFFF (256MB)
+
+2.2. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+	linux kernel, you can customize it based on your system requirements:
+	Flash0:		0x00000000-0x00FFFFFF (16MB)
+
+	DDR:		0x40000000-0x4FFFFFFF (256MB)
+	SRAM:		0x80000000-0x80007FFF (32KB)
+	IP:		0xFC000000-0xFC0FFFFF (64KB)
+
+3. COMPILATION
+==============
+3.1	To create U-Boot the gcc-4.1-xx compiler set (ColdFire ELF or
+uClinux version) from codesourcery.com was used. Download it from:
+http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+3.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot-1.x.x
+   make distclean
+   make M5373EVB_config
+   make
+
+4. SCREEN DUMP
+==============
+4.1 M5373EVB Development board
+    (NOTE: May not show exactly the same)
+
+U-Boot 1.3.0 (Nov 8 2007 - 12:44:08)
+
+CPU:   Freescale MCF5373 (Mask:65 Version:1)
+       CPU CLK 240 Mhz BUS CLK 80 Mhz
+Board: Freescale FireEngine 5373 EVB
+I2C:   ready
+DRAM:  32 MB
+FLASH: 2 MB
+In:    serial
+Out:   serial
+Err:   serial
+NAND:  16 MiB
+Net:   FEC0
+-> print
+bootdelay=1
+baudrate=115200
+ethaddr=00:e0:0c:bc:e5:60
+hostname=M5373EVB
+netdev=eth0
+loadaddr=40010000
+load=tftp ${loadaddr) ${u-boot}
+upd=run load; run prog
+prog=prot off 0 2ffff;era 0 2ffff;cp.b ${loadaddr} 0 ${filesize};save
+ethact=FEC0
+u-boot=u-boot.bin
+gatewayip=192.168.1.1
+netmask=255.255.255.0
+ipaddr=192.168.1.3
+serverip=192.168.1.2
+stdin=serial
+stdout=serial
+stderr=serial
+mem=261632k
+
+Environment size: 401/8188 bytes
+-> bdinfo
+memstart    = 0x40000000
+memsize     = 0x02000000
+flashstart  = 0x00000000
+flashsize   = 0x00200000
+flashoffset = 0x00000000
+sramstart   = 0x80000000
+sramsize    = 0x00008000
+mbar	    = 0xFC000000
+busfreq     =	  80 MHz
+ethaddr     = 00:E0:0C:BC:E5:60
+ip_addr     = 192.168.1.3
+baudrate    = 115200 bps
+->
+-> help
+?	- alias for 'help'
+base	- print or set address offset
+bdinfo	- print Board Info structure
+boot	- boot default, i.e., run 'bootcmd'
+bootd	- boot default, i.e., run 'bootcmd'
+bootelf - Boot from an ELF image in memory
+bootm	- boot application image from memory
+bootp	- boot image via network using BootP/TFTP protocol
+bootvx	- Boot vxWorks from an ELF image
+cmp	- memory compare
+coninfo - print console devices and information
+cp	- memory copy
+crc32	- checksum calculation
+date	- get/set/reset date & time
+dcache	- enable or disable data cache
+echo	- echo args to console
+erase	- erase FLASH memory
+flinfo	- print FLASH memory information
+go	- start application at address 'addr'
+help	- print online help
+i2c	- I2C sub-system
+icache	- enable or disable instruction cache
+iminfo	- print header information for application image
+imls	- list all images found in flash
+itest	- return true/false on integer compare
+loadb	- load binary file over serial line (kermit mode)
+loads	- load S-Record file over serial line
+loady	- load binary file over serial line (ymodem mode)
+loop	- infinite loop on address range
+ls	- list files in a directory (default /)
+md	- memory display
+mii	- MII utility commands
+mm	- memory modify (auto-incrementing)
+mtest	- simple RAM test
+mw	- memory write (fill)
+nand	- NAND sub-system
+nboot	- boot from NAND device
+nfs	- boot image via network using NFS protocol
+nm	- memory modify (constant address)
+ping	- send ICMP ECHO_REQUEST to network host
+printenv- print environment variables
+protect - enable or disable FLASH write protection
+rarpboot- boot image via network using RARP/TFTP protocol
+reset	- Perform RESET of the CPU
+run	- run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv	- set environment variables
+sleep	- delay execution for some time
+source	- run script from memory
+tftpboot- boot image via network using TFTP protocol
+version - print monitor version
+-> tftp 0x40800000 uImage
+Using FEC0 device
+TFTP from server 192.168.1.3; our IP address is 192.168.1.3 Filename 'uImage'.
+Load address: 0x40800000
+Loading: #################################################################
+	  #################################################################
+	  ##########
+done
+Bytes transferred = 2053270 (1f5496 hex)
+-> bootm 0x40800000
+## Booting image at 40800000 ...
+    Image Name:   Linux Kernel Image
+    Created:	  2007-11-07  20:33:08 UTC
+    Image Type:   M68K Linux Kernel Image (gzip compressed)
+    Data Size:	  2053206 Bytes =  2 MB
+    Load Address: 40020000
+    Entry Point:  40020000
+    Verifying Checksum ... OK
+    Uncompressing Kernel Image ... OK
+Linux version 2.6.22-uc1 (mattw@loa) (gcc version 4.2.1 (Sourcery G++ Lite 4.2-7
+
+
+uClinux/COLDFIRE(m537x)
+COLDFIRE port done by Greg Ungerer, gerg@snapgear.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists.  Total pages: 8128 Kernel command line: rootfstype=romfs PID hash table entries: 128 (order: 7, 512 bytes) Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory available: 28092k/32768k RAM, (1788k kernel code, 244k data) Mount-cache hash table entries: 512
+NET: Registered protocol family 16
+USB-MCF537x: (HOST module) EHCI device is registered
+USB-MCF537x: (OTG module) EHCI device is registered
+USB-MCF537x: (OTG module) UDC device is registered
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+NET: Registered protocol family 2
+IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
+TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered
+JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
+io scheduler noop registered
+io scheduler cfq registered (default)
+ColdFire internal UART serial driver version 1.00 ttyS0 at 0xfc060000 (irq = 90) is a builtin ColdFire UART
+ttyS1 at 0xfc064000 (irq = 91) is a builtin ColdFire UART
+ttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
+loop: module loaded
+nbd: registered device at major 43
+usbcore: registered new interface driver ub FEC ENET Version 0.2
+fec: PHY @ 0x1, ID 0x20005c90 -- DP83848
+eth0: ethernet 00:e0:0c:bc:e5:60
+uclinux[mtd]: RAM probe address=0x4021c22c size=0x22b000 Creating 1 MTD partitions on "RAM":
+0x00000000-0x0022b000 : "ROMfs"
+uclinux[mtd]: set ROMfs to be root filesystem NAND device: Manufacturer ID: 0x20, Chip ID: 0x73 (ST Micro NAND 16MiB 3,3V 8-b) Scanning device for bad blocks Creating 1 MTD partitions on "NAND 16MiB 3,3V 8-bit":
+0x00000000-0x01000000 : "M53xx flash partition 1"
+QSPI: spi->max_speed_hz 300000
+QSPI: Baud set to 255
+SPI: Coldfire master initialized
+M537x - Disable UART1 when using Audio
+udc: Freescale MCF53xx UDC driver version 27 October 2006 init
+udc: MCF53xx USB Device is found. ID=0x5 Rev=0x41 i2c /dev entries driver
+usbcore: registered new interface driver usbhid
+drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver TCP cubic registered
+NET: Registered protocol family 1
+NET: Registered protocol family 17
+VFS: Mounted root (romfs filesystem) readonly.
+Freeing unused kernel memory: 64k freed (0x401f5000 - 0x40204000) init started:  BusyBox v1.00 (2007.11.07-19:57+0000) multi-call binary?Setting e Mounting filesystems
+mount: Mounting devpts on /dev/pts failed: No such device
+mount: Mounting usbfs on /proc/bus/usb failed: No such file or directory Starting syslogd and klogd Setting up networking on loopback device:
+Setting up networking on eth0:
+info, udhcpc (v0.9.9-pre) started
+eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
+debug, Sending discover...
+debug, Sending discover...
+debug, Sending select for 172.27.0.130...
+info, Lease of 172.27.0.130 obtained, lease time 43200 deleting routers
+route: SIOC[ADD|DEL]RT: No such process
+adding dns 172.27.0.1
+Starting the boa webserver:
+Setting time from ntp server: ntp.cs.strath.ac.uk
+ntp.cs.strath.ac.uk: Unknown host
+
+
+BusyBox v1.00 (2007.11.07-19:57+0000) Built-in shell (msh) Enter 'help' for a list of built-in commands.
+
+#
diff --git a/u-boot/doc/README.m54455evb b/u-boot/doc/README.m54455evb
new file mode 100644
index 0000000..918a746
--- /dev/null
+++ b/u-boot/doc/README.m54455evb
@@ -0,0 +1,410 @@
+Freescale MCF54455EVB ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created 4/08/07
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m54455evb/m54455evb.c	Dram setup, IDE pre init, and PCI init
+- board/freescale/m54455evb/flash.c		Atmel and INTEL flash support
+- board/freescale/m54455evb/Makefile		Makefile
+- board/freescale/m54455evb/config.mk	config make
+- board/freescale/m54455evb/u-boot.lds	Linker description
+
+- common/cmd_bdinfo.c		Clock frequencies output
+- common/cmd_mii.c		mii support
+
+- arch/m68k/cpu/mcf5445x/cpu.c		cpu specific code
+- arch/m68k/cpu/mcf5445x/cpu_init.c	Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs
+- arch/m68k/cpu/mcf5445x/interrupts.c	cpu specific interrupt support
+- arch/m68k/cpu/mcf5445x/speed.c		system, pci, flexbus, and cpu clock
+- arch/m68k/cpu/mcf5445x/Makefile		Makefile
+- arch/m68k/cpu/mcf5445x/config.mk	config make
+- arch/m68k/cpu/mcf5445x/start.S		start up assembly code
+
+- doc/README.m54455evb	This readme file
+
+- drivers/net/mcffec.c		ColdFire common FEC driver
+- drivers/serial/mcfuart.c	ColdFire common UART driver
+
+- include/asm-m68k/bitops.h		Bit operation function export
+- include/asm-m68k/byteorder.h		Byte order functions
+- include/asm-m68k/fec.h		FEC structure and definition
+- include/asm-m68k/fsl_i2c.h		I2C structure and definition
+- include/asm-m68k/global_data.h	Global data structure
+- include/asm-m68k/immap.h		ColdFire specific header file and driver macros
+- include/asm-m68k/immap_5445x.h	mcf5445x specific header file
+- include/asm-m68k/io.h			io functions
+- include/asm-m68k/m5445x.h		mcf5445x specific header file
+- include/asm-m68k/posix_types.h	Posix
+- include/asm-m68k/processor.h		header file
+- include/asm-m68k/ptrace.h		Exception structure
+- include/asm-m68k/rtc.h		Realtime clock header file
+- include/asm-m68k/string.h		String function export
+- include/asm-m68k/timer.h		Timer structure and definition
+- include/asm-m68k/types.h		Data types definition
+- include/asm-m68k/uart.h		Uart structure and definition
+- include/asm-m68k/u-boot.h		u-boot structure
+
+- include/configs/M54455EVB.h	Board specific configuration file
+
+- arch/m68k/lib/board.c			board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts			Coldfire common interrupt functions
+- arch/m68k/lib/m68k_linux.c
+- arch/m68k/lib/time.c			Timer functions (Dma timer and PIT)
+- arch/m68k/lib/traps.c			Exception init code
+
+- rtc/mcfrtc.c				Realtime clock Driver
+
+1 MCF5445x specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M54455EVB Development Board
+CONFIG_MCF5445x		-- define for all MCF5445x CPUs
+CONFIG_M54455		-- define for all Freescale MCF54455 CPUs
+CONFIG_M54455EVB	-- define for M54455EVB board
+
+CONFIG_MCFUART		-- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT		-- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE		-- define UART baudrate
+
+CONFIG_MCFRTC		-- define to use common CF RTC driver
+CONFIG_SYS_MCFRTC_BASE		-- provide base address for RTC in immap.h
+CONFIG_SYS_RTC_OSCILLATOR	-- define RTC clock frequency
+RTC_DEBUG		-- define to show RTC debug message
+CONFIG_CMD_DATE		-- enable to use date feature in u-boot
+
+CONFIG_MCFFEC		-- define to use common CF FEC driver
+CONFIG_NET_MULTI	-- define to use multi FEC in u-boot
+CONFIG_MII		-- enable to use MII driver
+CONFIG_CF_DOMII		-- enable to use MII feature in cmd_mii.c
+CONFIG_SYS_DISCOVER_PHY	-- enable PHY discovery
+CONFIG_SYS_RX_ETH_BUFFER	-- Set FEC Receive buffer
+CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
+CONFIG_SYS_FEC0_PINMUX		-- Set FEC0 Pin configuration
+CONFIG_SYS_FEC1_PINMUX		-- Set FEC1 Pin configuration
+CONFIG_SYS_FEC0_MIIBASE	-- Set FEC0 MII base register
+CONFIG_SYS_FEC1_MIIBASE	-- Set FEC0 MII base register
+MCFFEC_TOUT_LOOP	-- set FEC timeout loop
+CONFIG_HAS_ETH1		-- define to enable second FEC in u-boot
+
+CONFIG_ISO_PARTITION	-- enable ISO read/write
+CONFIG_DOS_PARTITION	-- enable DOS read/write
+CONFIG_IDE_RESET	-- define ide_reset()
+CONFIG_IDE_PREINIT	-- define ide_preinit()
+CONFIG_ATAPI		-- define ATAPI support
+CONFIG_LBA48		-- define LBA48 (larger than 120GB) support
+CONFIG_SYS_IDE_MAXBUS		-- define max channel
+CONFIG_SYS_IDE_MAXDEVICE	-- define max devices per channel
+CONFIG_SYS_ATA_BASE_ADDR	-- define ATA base address
+CONFIG_SYS_ATA_IDE0_OFFSET	-- define ATA IDE0 offset
+CONFIG_SYS_ATA_DATA_OFFSET	-- define ATA data IO
+CONFIG_SYS_ATA_REG_OFFSET	-- define for normal register accesses
+CONFIG_SYS_ATA_ALT_OFFSET	-- define for alternate registers
+CONFIG_SYS_ATA_STRIDE		-- define for Interval between registers
+_IO_BASE		-- define for IO base address
+
+CONFIG_MCFTMR		-- define to use DMA timer
+CONFIG_MCFPIT		-- define to use PIT timer
+
+CONFIG_FSL_I2C		-- define to use FSL common I2C driver
+CONFIG_HARD_I2C		-- define for I2C hardware support
+CONFIG_SOFT_I2C		-- define for I2C bit-banged
+CONFIG_SYS_I2C_SPEED		-- define for I2C speed
+CONFIG_SYS_I2C_SLAVE		-- define for I2C slave address
+CONFIG_SYS_I2C_OFFSET		-- define for I2C base address offset
+CONFIG_SYS_IMMR		-- define for MBAR offset
+
+CONFIG_PCI              -- define for PCI support
+CONFIG_PCI_PNP          -- define for Plug n play support
+CONFIG_SYS_PCI_MEM_BUS		-- PCI memory logical offset
+CONFIG_SYS_PCI_MEM_PHYS	-- PCI memory physical offset
+CONFIG_SYS_PCI_MEM_SIZE	-- PCI memory size
+CONFIG_SYS_PCI_IO_BUS		-- PCI IO logical offset
+CONFIG_SYS_PCI_IO_PHYS		-- PCI IO physical offset
+CONFIG_SYS_PCI_IO_SIZE		-- PCI IO size
+CONFIG_SYS_PCI_CFG_BUS		-- PCI Configuration logical offset
+CONFIG_SYS_PCI_CFG_PHYS	-- PCI Configuration physical offset
+CONFIG_SYS_PCI_CFG_SIZE	-- PCI Configuration size
+
+CONFIG_EXTRA_CLOCK	-- Enable extra clock such as vco, flexbus, pci, etc
+
+CONFIG_SYS_MBAR		-- define MBAR offset
+
+CONFIG_SYS_ATMEL_BOOT		-- To determine the u-boot is booted from Atmel or Intel
+
+CONFIG_MONITOR_IS_IN_RAM -- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR	-- defines the base address of the MCF54455 internal SRAM
+
+CONFIG_SYS_CSn_BASE	-- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK	-- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL	-- defines the Chip Select Control register
+
+CONFIG_SYS_ATMEL_BASE	-- defines the Atmel Flash base
+CONFIG_SYS_INTEL_BASE	-- defines the Intel Flash base
+
+CONFIG_SYS_SDRAM_BASE	-- defines the DRAM Base
+CONFIG_SYS_SDRAM_BASE1	-- defines the DRAM Base 1
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+	Flash:		0x00000000-0x3FFFFFFF (1024MB)
+	DDR:		0x40000000-0x7FFFFFFF (1024MB)
+	SRAM:		0x80000000-0x8FFFFFFF (256MB)
+	ATA:		0x90000000-0x9FFFFFFF (256MB)
+	PCI:		0xA0000000-0xBFFFFFFF (512MB)
+	FlexBus:	0xC0000000-0xDFFFFFFF (512MB)
+	IP:		0xF0000000-0xFFFFFFFF (256MB)
+
+2.2. For the initial bringup, we adopted a consistent memory scheme between u-boot and
+	linux kernel, you can customize it based on your system requirements:
+	Atmel boot:
+	Flash0:		0x00000000-0x0007FFFF (512KB)
+	Flash1:		0x04000000-0x05FFFFFF (32MB)
+	Intel boot:
+	Flash0:		0x00000000-0x01FFFFFF (32MB)
+	Flash1:		0x04000000-0x0407FFFF (512KB)
+
+	CPLD:		0x08000000-0x08FFFFFF (16MB)
+	FPGA:		0x09000000-0x09FFFFFF (16MB)
+	DDR:		0x40000000-0x4FFFFFFF (256MB)
+	SRAM:		0x80000000-0x80007FFF (32KB)
+	IP:		0xFC000000-0xFC0FFFFF (64KB)
+
+3. SWITCH SETTINGS
+==================
+3.1 SW1 Pin3: 0 - Boot from Atmel or 1 - INTEL
+	SW1 Pin4: 0 - ULPI chip not in reset state or 1 - ULPI chip in reset state
+	SW1 Pin5: 0 - Full ATA Bus enabled, FEC Phy1 powered down
+			  1 - Upper 8 bits ATA data bus disabled, FEC PHY1 active
+	SW1 Pin6: 0 - FEC Phy0 active or 1 - FEC Phy0 powered down
+	SW1 Pin3: 0 - Boot from Atmel or 1 - INTEL
+
+4. COMPILATION
+==============
+4.1	To create U-Boot the gcc-4.1-32 compiler set (ColdFire ELF version)
+from codesourcery.com was used. Download it from:
+http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+4.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot-1.x.x
+   make distclean
+   make M54455EVB_config, or		- default to atmel 33Mhz input clock
+   make M54455EVB_atmel_config, or	- default to atmel 33Mhz input clock
+   make M54455EVB_a33_config, or	- default to atmel 33Mhz input clock
+   make M54455EVB_a66_config, or	- default to atmel 66Mhz input clock
+   make M54455EVB_intel_config, or	- default to intel 33Mhz input clock
+   make M54455EVB_i33_config, or	- default to intel 33Mhz input clock
+   make M54455EVB_i66_config, or	- default to intel 66Mhz input clock
+   make
+
+5. SCREEN DUMP
+==============
+5.1 M54455EVB Development board
+    Boot from Atmel (NOTE: May not show exactly the same)
+
+U-Boot 1.2.0-g98c80b46-dirty (Jul 26 2007 - 12:44:08)
+
+CPU:   Freescale MCF54455 (Mask:48 Version:1)
+       CPU CLK 266 Mhz BUS CLK 133 Mhz FLB CLK 66 Mhz
+       PCI CLK 33 Mhz INP CLK 33 Mhz VCO CLK 533 Mhz
+Board: Freescale M54455 EVB
+I2C:   ready
+DRAM:  256 MB
+FLASH: 16.5 MB
+In:    serial
+Out:   serial
+Err:   serial
+Net:   FEC0, FEC1
+IDE:   Bus 0: not available
+-> print
+bootargs=root=/dev/ram rw
+bootdelay=1
+baudrate=115200
+ethaddr=00:e0:0c:bc:e5:60
+eth1addr=00:e0:0c:bc:e5:61
+hostname=M54455EVB
+netdev=eth0
+inpclk=33333333
+loadaddr=40010000
+load=tftp ${loadaddr) ${u-boot}
+upd=run load; run prog
+prog=prot off 0 2ffff;era 0 2ffff;cp.b ${loadaddr} 0 ${filesize};save
+ethact=FEC0
+mtdids=nor0=M54455EVB-1
+mtdparts=M54455EVB-1:16m(user)
+u-boot=u-boot54455.bin
+filesize=292b4
+fileaddr=40010000
+gatewayip=192.168.1.1
+netmask=255.255.255.0
+ipaddr=192.168.1.3
+serverip=192.168.1.2
+stdin=serial
+stdout=serial
+stderr=serial
+mem=261632k
+
+Environment size: 563/8188 bytes
+-> bdinfo
+memstart    = 0x40000000
+memsize     = 0x10000000
+flashstart  = 0x00000000
+flashsize   = 0x01080000
+flashoffset = 0x00000000
+sramstart   = 0x80000000
+sramsize    = 0x00008000
+mbar        = 0xFC000000
+busfreq     = 133.333 MHz
+pcifreq     = 33.333 MHz
+flbfreq     = 66.666 MHz
+inpfreq     = 33.333 MHz
+vcofreq     = 533.333 MHz
+ethaddr     = 00:E0:0C:BC:E5:60
+eth1addr    = 00:E0:0C:BC:E5:61
+ip_addr     = 192.168.1.3
+baudrate    = 115200 bps
+->
+-> help
+?       - alias for 'help'
+base    - print or set address offset
+bdinfo  - print Board Info structure
+boot    - boot default, i.e., run 'bootcmd'
+bootd   - boot default, i.e., run 'bootcmd'
+bootelf - Boot from an ELF image in memory
+bootm   - boot application image from memory
+bootp	- boot image via network using BootP/TFTP protocol
+bootvx  - Boot vxWorks from an ELF image
+cmp     - memory compare
+coninfo - print console devices and information
+cp      - memory copy
+crc32   - checksum calculation
+date    - get/set/reset date & time
+dcache  - enable or disable data cache
+diskboot- boot from IDE device
+echo    - echo args to console
+erase   - erase FLASH memory
+ext2load- load binary file from a Ext2 filesystem
+ext2ls  - list files in a directory (default /)
+fatinfo - print information about filesystem
+fatload - load binary file from a dos filesystem
+fatls   - list files in a directory (default /)
+flinfo  - print FLASH memory information
+fsinfo	- print information about filesystems
+fsload	- load binary file from a filesystem image
+go      - start application at address 'addr'
+help    - print online help
+i2c     - I2C sub-system
+icache  - enable or disable instruction cache
+ide     - IDE sub-system
+iminfo  - print header information for application image
+imls    - list all images found in flash
+itest	- return true/false on integer compare
+loadb   - load binary file over serial line (kermit mode)
+loads   - load S-Record file over serial line
+loady   - load binary file over serial line (ymodem mode)
+loop    - infinite loop on address range
+ls	- list files in a directory (default /)
+md      - memory display
+mii     - MII utility commands
+mm      - memory modify (auto-incrementing)
+mtest   - simple RAM test
+mw      - memory write (fill)
+nfs	- boot image via network using NFS protocol
+nm      - memory modify (constant address)
+pci     - list and access PCI Configuration Space
+ping	- send ICMP ECHO_REQUEST to network host
+printenv- print environment variables
+protect - enable or disable FLASH write protection
+rarpboot- boot image via network using RARP/TFTP protocol
+reset   - Perform RESET of the CPU
+run     - run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv  - set environment variables
+sleep   - delay execution for some time
+source  - run script from memory
+tftpboot- boot image via network using TFTP protocol
+version - print monitor version
+->bootm 4000000
+
+## Booting image at 04000000 ...
+   Image Name:   Linux Kernel Image
+   Created:      2007-08-14  15:13:00 UTC
+   Image Type:   M68K Linux Kernel Image (uncompressed)
+   Data Size:    2301952 Bytes =  2.2 MB
+   Load Address: 40020000
+   Entry Point:  40020000
+   Verifying Checksum ... OK
+OK
+Linux version 2.6.20-gfe5136d6-dirty (mattw@kea) (gcc version 4.2.0 20070318 (pr
+erelease) (Sourcery G++ Lite 4.2-20)) #108 Mon Aug 13 13:00:13 MDT 2007
+starting up linux startmem 0xc0254000, endmem 0xcfffffff, size 253MB
+Built 1 zonelists.  Total pages: 32624
+Kernel command line: root=/dev/mtdblock1 rw rootfstype=jffs2 ip=none mtdparts=ph
+ysmap-flash.0:5M(kernel)ro,-(jffs2)
+PID hash table entries: 1024 (order: 10, 4096 bytes)
+Console: colour dummy device 80x25
+Dentry cache hash table entries: 32768 (order: 4, 131072 bytes)
+Inode-cache hash table entries: 16384 (order: 3, 65536 bytes)
+Memory: 257496k/262136k available (1864k kernel code, 2440k data, 88k init)
+Mount-cache hash table entries: 1024
+NET: Registered protocol family 16
+SCSI subsystem initialized
+NET: Registered protocol family 2
+IP route cache hash table entries: 2048 (order: 0, 8192 bytes)
+TCP established hash table entries: 8192 (order: 2, 32768 bytes)
+TCP bind hash table entries: 4096 (order: 1, 16384 bytes)
+TCP: Hash tables configured (established 8192 bind 4096)
+TCP reno registered
+JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
+io scheduler noop registered
+io scheduler anticipatory registered
+io scheduler deadline registered
+io scheduler cfq registered (default)
+ColdFire internal UART serial driver version 1.00
+ttyS0 at 0xfc060000 (irq = 90) is a builtin ColdFire UART
+ttyS1 at 0xfc064000 (irq = 91) is a builtin ColdFire UART
+ttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART
+RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
+loop: loaded (max 8 devices)
+FEC ENET Version 0.2
+fec: PHY @ 0x0, ID 0x20005ca2 -- DP83849
+eth0: ethernet 00:08:ee:00:e4:19
+physmap platform flash device: 01000000 at 04000000
+physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
+ Intel/Sharp Extended Query Table at 0x0031
+Using buffer write method
+cfi_cmdset_0001: Erase suspend on write enabled
+2 cmdlinepart partitions found on MTD device physmap-flash.0
+Creating 2 MTD partitions on "physmap-flash.0":
+0x00000000-0x00500000 : "kernel"
+mtd: Giving out device 0 to kernel
+0x00500000-0x01000000 : "jffs2"
+mtd: Giving out device 1 to jffs2
+mice: PS/2 mouse device common for all mice
+i2c /dev entries driver
+TCP cubic registered
+NET: Registered protocol family 1
+NET: Registered protocol family 17
+NET: Registered protocol family 15
+VFS: Mounted root (jffs2 filesystem).
+Setting the hostname to freescale
+Mounting filesystems
+mount: Mounting usbfs on /proc/bus/usb failed: No such file or directory
+Starting syslogd and klogd
+Setting up networking on loopback device:
+Setting up networking on eth0:
+eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
+Adding static route for default gateway to 172.27.255.254:
+Setting nameserver to 172.27.0.1 in /etc/resolv.conf:
+Starting inetd:
+/ #
diff --git a/u-boot/doc/README.m5475evb b/u-boot/doc/README.m5475evb
new file mode 100644
index 0000000..f5658ea
--- /dev/null
+++ b/u-boot/doc/README.m5475evb
@@ -0,0 +1,273 @@
+Freescale MCF5475EVB ColdFire Development Board
+================================================
+
+TsiChung Liew(Tsi-Chung.Liew@freescale.com)
+Created Jan 08, 2008
+===========================================
+
+
+Changed files:
+==============
+
+- board/freescale/m547xevb/m547xevb.c	Dram setup, IDE pre init, and PCI init
+- board/freescale/m547xevb/mii.c	MII init
+- board/freescale/m547xevb/Makefile	Makefile
+- board/freescale/m547xevb/config.mk	config make
+- board/freescale/m547xevb/u-boot.lds	Linker description
+
+- arch/m68k/cpu/mcf547x_8x/cpu.c			cpu specific code
+- arch/m68k/cpu/mcf547x_8x/cpu_init.c		Flexbus ChipSelect, Mux pins setup, icache and RTC extra regs
+- arch/m68k/cpu/mcf547x_8x/interrupts.c		cpu specific interrupt support
+- arch/m68k/cpu/mcf547x_8x/slicetimer.c		Timer support
+- arch/m68k/cpu/mcf547x_8x/speed.c		system, pci, flexbus, and cpu clock
+- arch/m68k/cpu/mcf547x_8x/Makefile		Makefile
+- arch/m68k/cpu/mcf547x_8x/config.mk		config make
+- arch/m68k/cpu/mcf547x_8x/start.S		start up assembly code
+
+- doc/README.m5475evb			This readme file
+
+- drivers/dma/MCD_dmaApi.c		DMA API functions
+- drivers/dma/MCD_tasks.c		DMA Tasks
+- drivers/dma/MCD_tasksInit.c		DMA Tasks Init
+- drivers/net/fsl_mcdmafec.c		ColdFire common DMA FEC driver
+- drivers/serial/mcfuart.c		ColdFire common UART driver
+
+- include/MCD_dma.h			DMA header file
+- include/MCD_progCheck.h		DMA header file
+- include/MCD_tasksInit.h		DMA header file
+- include/asm-m68k/bitops.h		Bit operation function export
+- include/asm-m68k/byteorder.h		Byte order functions
+- include/asm-m68k/errno.h		Error Number definition
+- include/asm-m68k/fec.h		FEC structure and definition
+- include/asm-m68k/fsl_i2c.h		I2C structure and definition
+- include/asm-m68k/fsl_mcddmafec.h	DMA FEC structure and definition
+- include/asm-m68k/global_data.h	Global data structure
+- include/asm-m68k/immap.h		ColdFire specific header file and driver macros
+- include/asm-m68k/immap_547x_8x.h	mcf547x_8x specific header file
+- include/asm-m68k/io.h			io functions
+- include/asm-m68k/m547x_8x.h		mcf547x_8x specific header file
+- include/asm-m68k/posix_types.h	Posix
+- include/asm-m68k/processor.h		header file
+- include/asm-m68k/ptrace.h		Exception structure
+- include/asm-m68k/rtc.h		Realtime clock header file
+- include/asm-m68k/string.h		String function export
+- include/asm-m68k/timer.h		Timer structure and definition
+- include/asm-m68k/types.h		Data types definition
+- include/asm-m68k/uart.h		Uart structure and definition
+- include/asm-m68k/u-boot.h		u-boot structure
+
+- include/configs/M5475EVB.h		Board specific configuration file
+
+- arch/m68k/lib/board.c			board init function
+- arch/m68k/lib/cache.c
+- arch/m68k/lib/interrupts			Coldfire common interrupt functions
+- arch/m68k/lib/m68k_linux.c
+- arch/m68k/lib/traps.c			Exception init code
+
+1 MCF547x specific Options/Settings
+====================================
+1.1 pre-loader is no longer suppoer in thie coldfire family
+
+1.2 Configuration settings for M5475EVB Development Board
+CONFIG_MCF547x_8x	-- define for all MCF547x_8x CPUs
+CONFIG_M547x		-- define for all Freescale MCF547x CPUs
+CONFIG_M5475		-- define for M5475EVB board
+
+CONFIG_MCFUART		-- define to use common CF Uart driver
+CONFIG_SYS_UART_PORT		-- define UART port number, start with 0, 1 and 2
+CONFIG_BAUDRATE		-- define UART baudrate
+
+CONFIG_FSLDMAFEC	-- define to use common dma FEC driver
+CONFIG_NET_MULTI	-- define to use multi FEC in u-boot
+CONFIG_MII		-- enable to use MII driver
+CONFIG_CF_DOMII		-- enable to use MII feature in cmd_mii.c
+CONFIG_SYS_DISCOVER_PHY	-- enable PHY discovery
+CONFIG_SYS_RX_ETH_BUFFER	-- Set FEC Receive buffer
+CONFIG_SYS_FAULT_ECHO_LINK_DOWN--
+CONFIG_SYS_FEC0_PINMUX		-- Set FEC0 Pin configuration
+CONFIG_SYS_FEC1_PINMUX		-- Set FEC1 Pin configuration
+CONFIG_SYS_FEC0_MIIBASE	-- Set FEC0 MII base register
+CONFIG_SYS_FEC1_MIIBASE	-- Set FEC0 MII base register
+MCFFEC_TOUT_LOOP	-- set FEC timeout loop
+CONFIG_HAS_ETH1		-- define to enable second FEC in u-boot
+
+CONFIG_CMD_USB		-- enable USB commands
+CONFIG_USB_OHCI_NEW	-- enable USB OHCI driver
+CONFIG_USB_STORAGE	-- enable USB Storage device
+CONFIG_DOS_PARTITION	-- enable DOS read/write
+
+CONFIG_SLTTMR		-- define to use SLT timer
+
+CONFIG_FSL_I2C		-- define to use FSL common I2C driver
+CONFIG_HARD_I2C		-- define for I2C hardware support
+CONFIG_SOFT_I2C		-- define for I2C bit-banged
+CONFIG_SYS_I2C_SPEED		-- define for I2C speed
+CONFIG_SYS_I2C_SLAVE		-- define for I2C slave address
+CONFIG_SYS_I2C_OFFSET		-- define for I2C base address offset
+CONFIG_SYS_IMMR		-- define for MBAR offset
+
+CONFIG_PCI		-- define for PCI support
+CONFIG_PCI_PNP		-- define for Plug n play support
+CONFIG_SKIPPCI_HOSTBRIDGE	-- SKIP PCI Host bridge
+CONFIG_SYS_PCI_MEM_BUS		-- PCI memory logical offset
+CONFIG_SYS_PCI_MEM_PHYS	-- PCI memory physical offset
+CONFIG_SYS_PCI_MEM_SIZE	-- PCI memory size
+CONFIG_SYS_PCI_IO_BUS		-- PCI IO logical offset
+CONFIG_SYS_PCI_IO_PHYS		-- PCI IO physical offset
+CONFIG_SYS_PCI_IO_SIZE		-- PCI IO size
+CONFIG_SYS_PCI_CFG_BUS		-- PCI Configuration logical offset
+CONFIG_SYS_PCI_CFG_PHYS	-- PCI Configuration physical offset
+CONFIG_SYS_PCI_CFG_SIZE	-- PCI Configuration size
+
+CONFIG_SYS_MBAR		-- define MBAR offset
+
+CONFIG_MONITOR_IS_IN_RAM -- Not support
+
+CONFIG_SYS_INIT_RAM_ADDR	-- defines the base address of the MCF547x internal SRAM
+
+CONFIG_SYS_CSn_BASE	-- defines the Chip Select Base register
+CONFIG_SYS_CSn_MASK	-- defines the Chip Select Mask register
+CONFIG_SYS_CSn_CTRL	-- defines the Chip Select Control register
+
+CONFIG_SYS_SDRAM_BASE	-- defines the DRAM Base
+
+2. MEMORY MAP UNDER U-BOOT AND LINUX KERNEL
+===========================================
+2.1. System memory map:
+	Flash:		0xFF800000-0xFFFFFFFF (8MB)
+	DDR:		0x00000000-0x3FFFFFFF (1024MB)
+	SRAM:		0xF2000000-0xF2000FFF (4KB)
+	PCI:		0x70000000-0x8FFFFFFF (512MB)
+	IP:		0xF0000000-0xFFFFFFFF (256MB)
+
+3. COMPILATION
+==============
+3.1	To create U-Boot the gcc-4.x compiler set (ColdFire ELF or uclinux
+	version) from codesourcery.com was used. Download it from:
+	http://www.codesourcery.com/gnu_toolchains/coldfire/download.html
+
+3.2 Compilation
+   export CROSS_COMPILE=cross-compile-prefix
+   cd u-boot-1.x.x
+   make distclean
+   make M5475AFE_config, or	- boot 2MB, RAM 64MB
+   make M5475BFE_config, or	- boot 2MB, code 16MB, RAM 64MB
+   make M5475CFE_config, or	- boot 2MB, code 16MB, Video, USB, RAM 64MB
+   make M5475DFE_config, or	- boot 2MB, USB, RAM 64MB
+   make M5475EFE_config, or	- boot 2MB, Video, USB, RAM 64MB
+   make M5475FFE_config, or	- boot 2MB, code 32MB, Video, USB, RAM 128MB
+   make M5475GFE_config, or	- boot 2MB, RAM 64MB
+   make
+
+5. SCREEN DUMP
+==============
+5.1
+
+U-Boot 1.3.1 (Jan  8 2008 - 12:47:44)
+
+CPU:   Freescale MCF5475
+       CPU CLK 266 Mhz BUS CLK 133 Mhz
+Board: Freescale FireEngine 5475 EVB
+I2C:   ready
+DRAM:  64 MB
+FLASH: 18 MB
+In:    serial
+Out:   serial
+Err:   serial
+Net:   FEC0, FEC1
+-> pri
+bootdelay=1
+baudrate=115200
+ethaddr=00:e0:0c:bc:e5:60
+eth1addr=00:e0:0c:bc:e5:61
+ipaddr=192.162.1.2
+serverip=192.162.1.1
+gatewayip=192.162.1.1
+netmask=255.255.255.0
+hostname=M547xEVB
+netdev=eth0
+loadaddr=10000
+u-boot=u-boot.bin
+load=tftp ${loadaddr) ${u-boot}
+upd=run load; run prog
+prog=prot off bank 1;era ff800000 ff82ffff;cp.b ${loadaddr} ff800000 ${filesize};save
+stdin=serial
+stdout=serial
+stderr=serial
+ethact=FEC0
+mem=65024k
+
+Environment size: 433/8188 bytes
+-> bdin
+memstart    = 0x00000000
+memsize     = 0x04000000
+flashstart  = 0xFF800000
+flashsize   = 0x01200000
+flashoffset = 0x00000000
+sramstart   = 0xF2000000
+sramsize    = 0x00001000
+mbar	    = 0xF0000000
+busfreq     = 133.333 MHz
+pcifreq     =	   0 MHz
+ethaddr     = 00:E0:0C:BC:E5:60
+eth1addr    = 00:E0:0C:BC:E5:61
+ip_addr     = 192.162.1.2
+baudrate    = 115200 bps
+-> ?
+?	- alias for 'help'
+base	- print or set address offset
+bdinfo	- print Board Info structure
+boot	- boot default, i.e., run 'bootcmd'
+bootd	- boot default, i.e., run 'bootcmd'
+bootelf - Boot from an ELF image in memory
+bootm	- boot application image from memory
+bootp	- boot image via network using BootP/TFTP protocol
+bootvx	- Boot vxWorks from an ELF image
+cmp	- memory compare
+coninfo - print console devices and information
+cp	- memory copy
+crc32	- checksum calculation
+dcache	- enable or disable data cache
+echo	- echo args to console
+erase	- erase FLASH memory
+flinfo	- print FLASH memory information
+go	- start application at address 'addr'
+help	- print online help
+i2c	- I2C sub-system
+icache	- enable or disable instruction cache
+iminfo	- print header information for application image
+imls	- list all images found in flash
+itest	- return true/false on integer compare
+loadb	- load binary file over serial line (kermit mode)
+loads	- load S-Record file over serial line
+loady	- load binary file over serial line (ymodem mode)
+loop	- infinite loop on address range
+md	- memory display
+mii	- MII utility commands
+mm	- memory modify (auto-incrementing)
+mtest	- simple RAM test
+mw	- memory write (fill)
+nfs	- boot image via network using NFS protocol
+nm	- memory modify (constant address)
+pci	- list and access PCI Configuration Space
+ping	- send ICMP ECHO_REQUEST to network host
+printenv- print environment variables
+protect - enable or disable FLASH write protection
+rarpboot- boot image via network using RARP/TFTP protocol
+reset	- Perform RESET of the CPU
+run	- run commands in an environment variable
+saveenv - save environment variables to persistent storage
+setenv	- set environment variables
+sleep	- delay execution for some time
+source	- run script from memory
+tftpboot- boot image via network using TFTP protocol
+usb	- USB sub-system
+usbboot - boot from USB device
+version - print monitor version
+-> usb start
+(Re)start USB...
+USB:   OHCI pci controller (1131, 1561) found @(0:17:0)
+OHCI regs address 0x80000000
+scanning bus for devices... 2 USB Device(s) found
+       scanning bus for storage devices... 1 Storage Device(s) found
+->
diff --git a/u-boot/doc/README.m68k b/u-boot/doc/README.m68k
new file mode 100644
index 0000000..3766b33
--- /dev/null
+++ b/u-boot/doc/README.m68k
@@ -0,0 +1,166 @@
+
+U-Boot for Motorola M68K
+
+====================================================================
+History
+
+August 08,2005;		Jens Scharsig <esw@bus-elektronik.de>
+			MCF5282 implementation without preloader
+January 12, 2004;	<josef.baumgartner@telex.de>
+====================================================================
+
+This file contains status information for the port of U-Boot to the
+Motorola M68K series of CPUs.
+
+1. OVERVIEW
+-----------
+Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola Coldfire
+architecture. The patches of Bernhard support the MCF5272 and
+MCF5282. A great disadvantage of these patches was that they needed
+a pre-bootloader to start u-boot. Because of this, a new port was
+created which no longer needs a first stage booter.
+
+Although this port is intended to cover all M68k processors, only
+the parts for the Motorola Coldfire MCF5272 and MCF5282 are
+implemented at the moment. Additional CPUs and boards will be
+hopefully added soon!
+
+
+2. SUPPORTED CPUs
+-----------------
+
+2.1 Motorola Coldfire MCF5272
+-----------------------------
+CPU specific code is located in: arch/m68k/cpu/mcf52x2
+
+
+2.1 Motorola Coldfire MCF5282
+-----------------------------
+CPU specific code is located in: arch/m68k/cpu/mcf52x2
+
+The MCF5282 Port no longer needs a preloader and can place in external or
+internal FLASH.
+
+
+3. SUPPORTED BOARDs
+-------------------
+
+3.1 Motorola M5272C3 EVB
+------------------------
+Board specific code is located in: board/m5272c3
+
+To configure the board, type: make M5272C3_config
+
+U-Boot Memory Map:
+------------------
+0xffe00000 - 0xffe3ffff		u-boot
+0xffe04000 - 0xffe05fff		environment (embedded in u-boot!)
+0xffe40000 - 0xffffffff		free for linux/applications
+
+
+3.2 Motorola M5282 EVB
+------------------------
+Board specific code is located in: board/m5282evb
+
+To configure the board, type: make M5272C3_config
+
+At the moment the code isn't fully implemented and still needs a pre-loader!
+The preloader must initialize the processor and then start u-boot. The board
+must be configured for a pre-loader (see 4.1)
+
+For the preloader, please see
+http://mailman.uclinux.org/pipermail/uclinux-dev/2003-December/023384.html
+
+U-boot is configured to run at 0x20000 at default. This can be configured by
+change CONFIG_SYS_TEXT_BASE in board/m5282evb/config.mk and CONFIG_SYS_MONITOR_BASE in
+include/configs/M5282EVB.h.
+
+3.2 BuS EB+MCF-EV123
+---------------------
+
+Board specific code is located in: board/bus/EB+MCF-EV123
+
+To configure the board, type:
+
+make EB+MCF-EV123_config		for external FLASH
+make EB+MCF-EV123_internal_config	for internal FLASH
+
+
+4. CONFIGURATION OPTIONS/SETTINGS
+----------------------------------
+
+4.1 Configuration to use a pre-loader
+-------------------------------------
+If u-boot should be loaded to RAM and started by a pre-loader
+CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the
+initial vector table and basic processor initialization will not
+be compiled in. The start address of u-boot must be adjusted in
+the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile
+(CONFIG_SYS_TEXT_BASE) to the load address.
+
+4.1 MCF5272 specific Options/Settings
+-------------------------------------
+
+CONFIG_MCF52x2	-- defined for all MCF52x2 CPUs
+CONFIG_M5272	-- defined for all Motorola MCF5272 CPUs
+
+CONFIG_MONITOR_IS_IN_RAM
+		-- defined if u-boot is loaded by a pre-loader
+
+CONFIG_SYS_MBAR	-- defines the base address of the MCF5272 configuration registers
+CONFIG_SYS_INIT_RAM_ADDR
+		-- defines the base address of the MCF5272 internal SRAM
+CONFIG_SYS_ENET_BD_BASE
+		-- defines the base addres of the FEC buffer descriptors
+
+CONFIG_SYS_SCR		-- defines the contents of the System Configuration Register
+CONFIG_SYS_SPR		-- defines the contents of the System Protection Register
+CONFIG_SYS_BRx_PRELIM	-- defines the contents of the Chip Select Base Registers
+CONFIG_SYS_ORx_PRELIM	-- defines the contents of the Chip Select Option Registers
+
+CONFIG_SYS_PxDDR	-- defines the contents of the Data Direction Registers
+CONFIG_SYS_PxDAT	-- defines the contents of the Data Registers
+CONFIG_SYS_PXCNT	-- defines the contents of the Port Configuration Registers
+
+
+4.2 MCF5282 specific Options/Settings
+-------------------------------------
+
+CONFIG_MCF52x2	-- defined for all MCF52x2 CPUs
+CONFIG_M5282	-- defined for all Motorola MCF5282 CPUs
+
+CONFIG_MONITOR_IS_IN_RAM
+		-- defined if u-boot is loaded by a pre-loader
+
+CONFIG_SYS_MBAR	-- defines the base address of the MCF5282 internal register space
+CONFIG_SYS_INIT_RAM_ADDR
+		-- defines the base address of the MCF5282 internal SRAM
+CONFIG_SYS_INT_FLASH_BASE
+		-- defines the base address of the MCF5282 internal Flash memory
+CONFIG_SYS_ENET_BD_BASE
+		-- defines the base addres of the FEC buffer descriptors
+
+CONFIG_SYS_MFD
+		-- defines the PLL Multiplication Factor Devider
+		   (see table 9-4 of MCF user manual)
+CONFIG_SYS_RFD		-- defines the PLL Reduce Frecuency Devider
+		   (see table 9-4 of MCF user manual)
+
+CONFIG_SYS_CSx_BASE	-- defines the base address of chip select x
+CONFIG_SYS_CSx_SIZE	-- defines the memory size (address range) of chip select x
+CONFIG_SYS_CSx_WIDTH	-- defines the bus with of chip select x
+CONFIG_SYS_CSx_RO	-- if set to 0 chip select x is read/wirte
+			else chipselct is read only
+CONFIG_SYS_CSx_WS	-- defines the number of wait states  of chip select x
+
+CONFIG_SYS_PxDDR	-- defines the contents of the Data Direction Registers
+CONFIG_SYS_PxDAT	-- defines the contents of the Data Registers
+CONFIG_SYS_PXCNT	-- defines the contents of the Port Configuration Registers
+
+CONFIG_SYS_PxPAR	-- defines the function of ports
+
+
+5. COMPILER
+-----------
+To create U-Boot the gcc-2.95.3 compiler set (m68k-elf-20030314) from uClinux.org was used.
+You can download it from: http://www.uclinux.org/pub/uClinux/m68k-elf-tools/
diff --git a/u-boot/doc/README.marubun-pcmcia b/u-boot/doc/README.marubun-pcmcia
new file mode 100644
index 0000000..d3563a3
--- /dev/null
+++ b/u-boot/doc/README.marubun-pcmcia
@@ -0,0 +1,65 @@
+
+U-Boot MARUBUN MR-SHPC-01 PCMCIA controller driver
+	Last update 21/11/2007 by Nobuhiro Iwamatsu
+
+========================================================================================
+
+0. What's this?
+    This driver supports MARUBUN MR-SHPC-01.
+	url: http://www.marubun.co.jp/product/semicon/devices/qgc18e0000002n2z.html
+	(Sorry Japanese only.)
+
+    This chip is used with SuperH well, and adopted by the
+    reference board.
+	ex. * MS7750SE01
+		* MS7722SE01
+		* other
+
+    This chip doesn't support CardBus.
+
+1. base source code
+    The code is based on sources from the Linux kernel
+	( arch/sh/kernel/cf-enabler.c ).
+
+2. How to use
+    The options you have to specify in the config file are (with the
+    value for my board as an example):
+
+    * CONFIG_MARUBUN_PCCARD
+	If you want to use this device driver, should define CONFIG_MARUBUN_PCCARD.
+	ex.	#define CONFIG_MARUBUN_PCCARD
+
+    * CONFIG_PCMCIA_SLOT_A
+	Most devices have only one slot. You should define CONFIG_PCMCIA_SLOT_A .
+	ex.	#define CONFIG_PCMCIA_SLOT_A    1
+
+    * CONFIG_SYS_MARUBUN_MRSHPC
+	This is MR-SHPC-01 PCMCIA controler base address.
+	You should do the setting matched to your environment.
+	ex.  #define CONFIG_SYS_MARUBUN_MRSHPC 0xb03fffe0
+	     ( for MS7722SE01 environment )
+
+    * CONFIG_SYS_MARUBUN_MW1
+	This is MR-SHPC-01 memory window base address.
+	You should do the setting matched to your environment.
+	ex. #define CONFIG_SYS_MARUBUN_MW1 0xb0400000
+	     ( for MS7722SE01 environment )
+
+    * CONFIG_SYS_MARUBUN_MW1
+	This is MR-SHPC-01 attribute window base address.
+	You should do the setting matched to your environment.
+	ex. #define CONFIG_SYS_MARUBUN_MW2 0xb0500000
+	     ( for MS7722SE01 environment )
+
+    * CONFIG_SYS_MARUBUN_MW1
+	This is MR-SHPC-01 I/O window base address.
+	You should do the setting matched to your environment.
+	ex. #define CONFIG_SYS_MARUBUN_IO  0xb0600000
+	     ( for MS7722SE01 environment )
+
+3. Other
+    * Check Compact Flash only.
+    * Maybe, NE2000 compatible NIC is sure to move.
+
+Copyright (c) 2007
+	Nobuhiro Iwamatsu <iwamatsu@nigaur.org>
diff --git a/u-boot/doc/README.mflash b/u-boot/doc/README.mflash
new file mode 100644
index 0000000..50133b4
--- /dev/null
+++ b/u-boot/doc/README.mflash
@@ -0,0 +1,94 @@
+
+This document describes m[g]flash support in u-boot.
+
+Contents
+  1. Overview
+  2. Porting mflash driver
+  3. Mflash command
+  4. Misc.
+
+1. Overview
+Mflash and gflash are embedded flash drive. The only difference is mflash is
+MCP(Multi Chip Package) device. These two device operate exactly same way.
+So the rest mflash repersents mflash and gflash altogether.
+
+2. Porting mflash driver
+
+2-1. Board configuration
+* Mflash driver support
+#define CONFIG_CMD_MG_DISK
+#define CONFIG_LIBATA
+
+* Environment variable support (optional)
+#define CONFIG_ENV_IS_IN_MG_DISK
+Also CONFIG_ENV_ADDR and CONFIG_ENV_SIZE should be defined.
+CONFIG_ENV_ADDR is byte offset starting from 0.
+
+Following example sets environment variable location to 0x80000 (1024'th
+sector) and size of 0x400 (1024 byte)
+#define CONFIG_ENV_ADDR		0x80000
+#define CONFIG_ENV_SIZE		0x400
+
+* Reserved size config (optional)
+If you want to use some reserved area for bootloader, environment variable or
+whatever, use CONFIG_MG_DISK_RES. The unit is KB. Mflash's block operation
+method use this value as start offset. So any u-boot's partition table parser
+and file system command work consistently. You can access this area by using
+mflash command.
+
+Following example sets 10MB of reserved area.
+#define CONFIG_MG_DISK_RES	10240
+
+2-2. Porting mg_get_drv_data function
+Mflash is active device and need some gpio control for proper operation.
+This board dependency resolved by using mg_get_drv_data function.
+Port this function at your board init file. See include/mg_disk.h
+
+Here is some pseudo example.
+
+static void custom_hdrst_pin (u8 level)
+{
+	if (level)
+		/* set hard reset pin to high */
+	else
+		/* set hard reset pin to low */
+}
+
+static void custom_ctrl_pin_init (void)
+{
+	/* Set hard reset, write protect, deep power down pins
+	 * to gpio.
+	 * Set these pins to output high
+	 */
+}
+
+struct mg_drv_data* mg_get_drv_data (void)
+{
+	static struct mg_drv_data prv;
+
+	prv.base = /* base address of mflash */
+	prv.mg_ctrl_pin_init = custom_ctrl_pin_init;
+	prv.mg_hdrst_pin = custom_hdrst_pin;
+
+	return &prv;
+}
+
+3. Mflash command
+
+* initialize : mgd init
+* random read : mgd read [from] [to] [size]
+  ex) read 256 bytes from 0x300000 of mflash to 0xA0100000 of host memory
+      mgd read 0x300000 0xA0100000 256
+* random write : mgd write [from] [to] [size]
+* sector read : mgd readsec [sector] [to] [count]
+  ex) read 10 sectors starts from 400 sector to 0xA0100000
+      mgd readsec 400 0xA0100000 10
+* sector write : mgd writesec [from] [sector] [count]
+
+4. Misc.
+Mflash's device interface name for block driver is "mgd".
+Here is ext2 file system access example.
+
+ mgd init
+ ext2ls mgd 0:1 /boot
+ ext2load mgd 0:1 0xa0010000 /boot/uImage 1954156
diff --git a/u-boot/doc/README.mips b/u-boot/doc/README.mips
new file mode 100644
index 0000000..85dea40
--- /dev/null
+++ b/u-boot/doc/README.mips
@@ -0,0 +1,57 @@
+
+Notes for the MIPS architecture port of U-Boot
+
+Toolchains
+----------
+
+  http://www.denx.de/wiki/DULG/ELDK
+  ELDK < DULG < DENX
+
+  http://www.emdebian.org/crosstools.html
+  Embedded Debian -- Cross-development toolchains
+
+  http://buildroot.uclibc.org/
+  Buildroot
+
+Known Issues
+------------
+
+  * Little endian build problem
+
+    If use non-ELDK toolchains, -EB will be set to CPPFLAGS. Therefore all
+    objects will be generated in big-endian format.
+
+  * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c
+
+    Cache will be disabled before entering the loaded ELF image without
+    writing back and invalidating cache lines. This leads to cache
+    incoherency in most cases, unless the code gets loaded after U-Boot
+    re-initializes the cache. The more common uImage 'bootm' command does
+    not suffer this problem.
+
+    [workaround] To avoid this cache incoherency,
+    1) insert flush_cache(all) before calling dcache_disable(), or
+    2) fix dcache_disable() to do both flushing and disabling cache.
+
+  * Note that Linux users need to kill dcache_disable() in do_bootelf_exec()
+    or override do_bootelf_exec() not to disable I-/D-caches, because most
+    Linux/MIPS ports don't re-enable caches after entering kernel_entry.
+
+TODOs
+-----
+
+  * Probe CPU types, I-/D-cache and TLB size etc. automatically
+
+  * Secondary cache support missing
+
+  * Centralize the link directive files
+
+  * Initialize TLB entries redardless of their use
+
+  * R2000/R3000 class parts are not supported
+
+  * Limited testing across different MIPS variants
+
+  * Due to cache initialization issues, the DRAM on board must be
+    initialized in board specific assembler language before the cache init
+    code is run -- that is, initialize the DRAM in lowlevel_init().
diff --git a/u-boot/doc/README.modnet50 b/u-boot/doc/README.modnet50
new file mode 100644
index 0000000..2ac3c8f
--- /dev/null
+++ b/u-boot/doc/README.modnet50
@@ -0,0 +1,62 @@
+U-BOOT Port for FSForth ModNET50 Board
+--------------------------------------
+
+author: Thomas Elste <info@elste.org>
+	IMMS gGmbH <www.imms.de>
+
+The port based upon an early (partial complete)
+armboot-port from Stephan Linz for the ModNET50 Board.
+
+
+Overview:
+
+- board with Netsilicon NET+50 ARM7TDMI CPU without MMU
+- 16 MB SDRAM
+- 2 MB Flash (MBL29LV160BE)
+- 10/100 Ethernet PHY (LXT971A)
+
+
+Current Configuration (include/configs/modnet50.h):
+
+Memory Map: 0x00000000 - 0x00FFFFFF 16M SDRAM
+	    0x10000000 - 0x101FFFFF  2M Flash
+
+The Flash uses a BB-Architectur with 35 sectors
+(0:16K; 1,2:8K; 3:32K; 4-34:64K). U-Boot is located in
+the first 5 sectors.
+
+The environment is located at the end of the 4th Flash
+sector (0x1001C000-0x1001FFFF).
+
+Build:
+
+U-boot should be build by using the ELDK Toolchain (arm-linux-*).
+
+	make modnet50_config
+	make
+
+
+Status:
+
+Everything seems to work fine. Booting images was tested by
+booting uCLinux (with and without a separate ramdisk image) from
+flash.
+
+
+Files:
+
+arch/arm/cpu/arm720t/serial_netarm.c .. serial I/O for the cpu
+
+board/modnet50/lowlevel_init.S   .. memory setup for ModNET50
+board/modnet50/flash.c	    .. flash routines
+board/modnet50/modnet50.c   .. some board init stuff
+
+drivers/net/netarm_eth.c    .. ethernet driver for the NET+50 CPU
+drivers/net/netarm_eth.h    .. header for ethernet driver
+
+include/configs/modnet50.h  .. configuration file for ModNET50
+
+include/netarm_*.h	    .. register and macro definitions for
+			       the NETARM CPU family
+
+doc/README.modnet50	    .. this readme
diff --git a/u-boot/doc/README.mpc5xx b/u-boot/doc/README.mpc5xx
new file mode 100644
index 0000000..df51b5c
--- /dev/null
+++ b/u-boot/doc/README.mpc5xx
@@ -0,0 +1,48 @@
+
+Summary:
+========
+
+This file contains information about the port of U-Boot to the
+Motorola mpc5xx series of CPUs. Most of this code is taken from
+existing code mainly from the mpc8xx port. In contrast to mpc8xx,
+the mpc5xx has no CPM, MMU and cache facilities.
+
+The implemented features have been tested on the cmi board, a
+customer specific board (see README.cmi).
+
+Hence this port is only tested on the cmi board further possible
+tests on other boards will be very valuable.
+
+Not Tested Features:
+====================
+
+* System calls
+* Interrupts
+
+Added or Changed Files:
+=======================
+
+u-boot-0.2.0/common/cmd_boot.c
+u-boot-0.2.0/common/cmd_reginfo.c
+u-boot-0.2.0/common/environment.c
+u-boot-0.2.0/arch/powerpc/cpu/mpc5xx/*
+u-boot-0.2.0/include/cmd_reginfo.h
+u-boot-0.2.0/include/common.h
+u-boot-0.2.0/include/ppc_asm.tmpl
+u-boot-0.2.0/include/watchdog.h
+u-boot-0.2.0/include/mpc5xx.h
+u-boot-0.2.0/include/status_led.h
+u-boot-0.2.0/include/asm-ppc/u-boot.h
+u-boot-0.2.0/include/asm-ppc/5xx_immap.h
+u-boot-0.2.0/arch/powerpc/lib/board.c
+u-boot-0.2.0/arch/powerpc/lib/cache.c
+u-boot-0.2.0/arch/powerpc/lib/time.c
+u-boot-0.2.0/Makefile
+u-boot-0.2.0/CREDITS
+u-boot-0.2.0/doc/README.mpc5xx
+u-boot-0.2.0/doc/README.cmi
+u-boot-0.2.0/README
+u-boot-0.2.0/MAKEALL
+
+Regards,
+Martin
diff --git a/u-boot/doc/README.mpc7448hpc2 b/u-boot/doc/README.mpc7448hpc2
new file mode 100644
index 0000000..8659e83
--- /dev/null
+++ b/u-boot/doc/README.mpc7448hpc2
@@ -0,0 +1,184 @@
+Freescale MPC7448hpc2 (Taiga) board
+===================================
+
+Created 08/11/2006 Roy Zang
+--------------------------
+MPC7448hpc2 (Taiga) board is a high-performance PowerPC server reference
+design, which is optimized for high speed throughput between the processor and
+the memory, disk drive and Ethernet port subsystems.
+
+MPC7448hpc2(Taiga) is designed to the micro-ATX chassis, allowing it to be
+used in 1U or 2U rack-mount chassis¡¯, as well as in standard ATX/Micro-ATX
+chassis.
+
+Building U-Boot
+------------------
+The mpc7448hpc2 code base is known to compile using:
+	Binutils 2.15, Gcc 3.4.3, Glibc 2.3.3
+
+	$ make mpc7448hpc2_config
+	Configuring for mpc7448hpc2 board...
+
+	$ make
+
+Memory Map
+----------
+
+The memory map is setup for Linux to operate properly.
+
+The mapping is:
+
+	Range Start	Range End	Definition			Size
+
+	0x0000_0000	0x7fff_ffff	DDR				2G
+	0xe000_0000	0xe7ff_ffff	PCI Memory			128M
+	0xfa00_0000	0xfaff_ffff	PCI IO				16M
+	0xfb00_0000	0xfbff_ffff	PCI Config			16M
+	0xfc00_0000	0xfc0f_ffff	NVRAM/CADMUS			1M
+	0xfe00_0000	0xfeff_ffff	PromJet				16M
+	0xff00_0000	0xff80_0000	FLASH (boot flash)		8M
+	0xff80_0000	0xffff_ffff	FLASH (second half flash)	8M
+
+Using Flash
+-----------
+
+The MPC7448hpc2 board has two "banks" of flash, each 8MB in size
+(2^23 = 0x00800000).
+
+Note: the "bank" here refers to half of the flash. In fact, there is only one
+bank of flash, which is divided into low and high half. Each is controlled by
+the most significant bit of the address bus. The so called "bank" is only for
+convenience.
+
+There is a switch which allows the "bank" to be selected.  The switch
+settings for updating flash are given below.
+
+The u-boot commands for copying the boot-bank into the secondary bank are
+as follows:
+
+	erase ff800000 ff880000
+	cp.b ff000000 ff800000 80000
+
+U-boot commands for downloading an image via tftp and flashing
+it into the secondary bank:
+
+	tftp 10000 <u-boot.bin.image>
+	erase ff000000 ff080000
+	cp.b 10000 ff000000 80000
+
+After copying the image into the second bank of flash, be sure to toggle
+SW3[4] on board before resetting the board in order to set the
+secondary bank as the boot-bank.
+
+Board Switches
+----------------------
+
+Most switches on the board should not be changed.  The most frequent
+user-settable switches on the board are used to configure
+the flash banks and determining the PCI frequency.
+
+SW1[1-5]: Processor core voltage
+
+	12345		Core Voltage
+	-----
+	SW1=01111	1.000V.
+	SW1=01101	1.100V.
+	SW1=01011	1.200V.
+	SW1=01001	1.300V only for MPC7447A.
+
+
+SW2[1-6]: CPU core frequency
+
+		CPU Core Frequency (MHz)
+			Bus Frequency
+	123456		100	133	167	200	Ratio
+
+	------
+	SW2=101100	500	667	833	1000	5x
+	SW2=100100	550	733	917	1100	5.5x
+	SW2=110100	600	800	1000	1200	6x
+	SW2=010100	650	866	1083	1300	6.5x
+	SW2=001000	700	930	1167	1400	7x
+	SW2=000100	750	1000	1250	1500	7.5x
+	SW2=110000	800	1066	1333	1600	8x
+	SW2=011000	850	1333	1417	1700	8.5x only for MPC7447A
+	SW2=011110	900	1200	1500	1800	9x
+
+This table shows only a subset of available frequency options; see the CPU
+hardware specifications for more information.
+
+SW2[7-8]: Bus Protocol and CPU Reset Option
+
+	7
+	-
+	SW2=0		System bus uses MPX bus protocol
+	SW2=1		System bus uses 60x bus protocol
+
+	8
+	-
+	SW2=0		TSI108 can cause CPU reset
+	SW2=1		TSI108 can not cause CPU reset
+
+SW3[1-8] system options
+
+	123
+	---
+	SW3=xxx		Connected to GPIO[0:2] on TSI108
+
+	4
+	-
+	SW3=0		CPU boots from low half of flash
+	SW3=1		CPU boots from high half of flash
+
+	5
+	-
+	SW3=0		SATA and slot2 connected to PCI bus
+	SW3=1		Only slot1 connected to PCI bus
+
+	6
+	-
+	SW3=0		USB connected to PCI bus
+	SW3=1		USB disconnected from PCI bus
+
+	7
+	-
+	SW3=0		Flash is write protected
+	SW3=1		Flash is NOT write protected
+
+	8
+	-
+	SW3=0		CPU will boot from flash
+	SW3=1		CPU will boot from PromJet
+
+SW4[1-3]: System bus frequency
+
+			Bus Frequency (MHz)
+	---
+	SW4=010			183
+	SW4=011			100
+	SW4=100			133
+	SW4=101			166 only for MPC7447A
+	SW4=110			200 only for MPC7448
+	others			reserved
+
+SW4[4-6]: DDR2 SDRAM frequency
+
+			Bus Frequency (MHz)
+	---
+	SW4=000		external clock
+	SW4=011		system clock
+	SW4=100		133
+	SW4=101		166
+	SW4=110		200
+	others		reserved
+
+SW4[7-8]: PCI/PCI-X frequency control
+	7
+	-
+	SW4=0		PCI/PCI-X bus operates normally
+	SW4=1		PCI bus forced to PCI-33 mode
+
+	8
+	-
+	SW4=0		PCI-X mode at 133 MHz allowed
+	SW4=1		PCI-X mode limited to 100 MHz
diff --git a/u-boot/doc/README.mpc74xx b/u-boot/doc/README.mpc74xx
new file mode 100644
index 0000000..f81f1c2
--- /dev/null
+++ b/u-boot/doc/README.mpc74xx
@@ -0,0 +1,22 @@
+This file contains status information for the port of U-Boot to the
+Motorola mpc74xx series of CPUs.
+
+Author: Josh Huber <huber@mclx.com>
+	Mission Critical Linux, Inc.
+
+Currently the support for these CPUs is pretty minimal, but enough to
+get things going.  (much like the support for the Galileo Eval Board)
+
+There is a framework in place to enable the L2 cache, and to program
+the BATs.  Currently, there are still problems with the code which
+sets up the L2 cache, so it's not enabled. (IMHO, it shouldn't be
+anyway).  Additionally, there is support for enabling the MMU, which
+we also don't do.  The BATs are programmed just for the benefit of
+jumping into Linux in a sane configuration.
+
+Most of the code was based on other cpus supported by U-Boot.
+
+If you find any errors in the CPU setup code, please send us a note.
+
+Thanks,
+Josh
diff --git a/u-boot/doc/README.mpc8313erdb b/u-boot/doc/README.mpc8313erdb
new file mode 100644
index 0000000..be7ef32
--- /dev/null
+++ b/u-boot/doc/README.mpc8313erdb
@@ -0,0 +1,111 @@
+Freescale MPC8313ERDB Board
+-----------------------------------------
+
+1.	Board Switches and Jumpers
+
+	S3 is used to set CONFIG_SYS_RESET_SOURCE.
+
+	To boot the image at 0xFE000000 in NOR flash, use these DIP
+	switch settings for S3 S4:
+
+	+------+	+------+
+	|      |	| **** |
+	| **** |	|      |
+	+------+ ON	+------+ ON
+	  4321		  4321
+	(where the '*' indicates the position of the tab of the switch.)
+
+	To boot the image at the beginning of NAND flash, use these
+	DIP switch settings for S3 S4:
+
+	+------+	+------+
+	| *    |	|  *** |
+	|  *** |	| *    |
+	+------+ ON	+------+ ON
+	  4321		  4321
+	(where the '*' indicates the position of the tab of the switch.)
+
+	When booting from NAND, use u-boot-nand.bin, not u-boot.bin.
+
+2.	Memory Map
+	The memory map looks like this:
+
+	0x0000_0000	0x07ff_ffff	DDR		 128M
+	0x8000_0000	0x8fff_ffff	PCI MEM		 256M
+	0x9000_0000	0x9fff_ffff	PCI_MMIO	 256M
+	0xe000_0000	0xe00f_ffff	IMMR		 1M
+	0xe200_0000	0xe20f_ffff	PCI IO		 16M
+	0xe280_0000	0xe280_7fff	NAND FLASH (CS1) 32K
+	0xf000_0000	0xf001_ffff	VSC7385 (CS2)	 128K
+	0xfa00_0000	0xfa00_7fff	Board Status/	 32K
+					LED Control (CS3)
+	0xfe00_0000	0xfe7f_ffff	NOR FLASH (CS0)	 8M
+
+	When booting from NAND, NAND flash is CS0 and NOR flash
+	is CS1.
+
+3.	Definitions
+
+3.1	Explanation of NEW definitions in:
+
+	include/configs/MPC8313ERDB.h
+
+	CONFIG_MPC83xx		MPC83xx family
+	CONFIG_MPC831x		MPC831x specific
+	CONFIG_MPC8313ERDB	MPC8313ERDB board specific
+
+4.	Compilation
+
+	Assuming you're using BASH (or similar) as your shell:
+
+	export CROSS_COMPILE=your-cross-compiler-prefix-
+	make distclean
+	make MPC8313ERDB_XXX_config
+	(where XXX is:
+	   33 - 33 MHz oscillator, boot from NOR flash
+	   66 - 66 MHz oscillator, boot from NOR flash
+	   NAND_33 - 33 MHz oscillator, boot from NAND flash
+	   NAND_66 - 66 MHz oscillator, boot from NAND flash)
+	make
+
+5.	Downloading and Flashing Images
+
+5.1	Reflash U-boot Image using U-boot
+
+	NOR flash:
+
+	=>run tftpflash
+
+	You may want to try
+	=>tftpboot $loadaddr $uboot
+	first, to make sure that the TFTP load will succeed before it
+	goes ahead and wipes out your current firmware.  And of course,
+	have an alternate means of programming the flash available
+	if the new u-boot doesn't boot.
+
+	NAND flash:
+
+	=>tftpboot $loadaddr <filename>
+	=>nand erase 0 0x80000
+	=>nand write $loadaddr 0 0x80000
+
+	...where 0x80000 is the filesize rounded up to
+	the next 0x20000 increment.
+
+5.2	Downloading and Booting Linux Kernel
+
+	Ensure that all networking-related environment variables are set
+	properly (including ipaddr, serverip, gatewayip (if needed),
+	netmask, ethaddr, eth1addr, rootpath (if using NFS root),
+	fdtfile, and bootfile).
+
+	Then, do one of the following, depending on whether you
+	want an NFS root or a ramdisk root:
+
+	=>run nfsboot
+	or
+	=>run ramboot
+
+6	Notes
+
+	The console baudrate for MPC8313ERDB is 115200bps.
diff --git a/u-boot/doc/README.mpc8315erdb b/u-boot/doc/README.mpc8315erdb
new file mode 100644
index 0000000..b32132d
--- /dev/null
+++ b/u-boot/doc/README.mpc8315erdb
@@ -0,0 +1,105 @@
+Freescale MPC8315ERDB Board
+-----------------------------------------
+
+1.	Board Switches and Jumpers
+
+	S3 is used to set CONFIG_SYS_RESET_SOURCE.
+
+	To boot the image at 0xFE000000 in NOR flash, use these DIP
+	switch settings for S3 S4:
+
+	+------+	+------+
+	|      |	| **** |
+	| **** |	|      |
+	+------+ ON	+------+ ON
+	  4321		  4321
+	(where the '*' indicates the position of the tab of the switch.)
+
+	To boot the image at the beginning of NAND flash, use these
+	DIP switch settings for S3 S4:
+
+	+------+	+------+
+	| *    |	|  *** |
+	|  *** |	| *    |
+	+------+ ON	+------+ ON
+	  4321		  4321
+	(where the '*' indicates the position of the tab of the switch.)
+
+	When booting from NAND, use u-boot-nand.bin, not u-boot.bin.
+
+2.	Memory Map
+	The memory map looks like this:
+
+	0x0000_0000	0x07ff_ffff	DDR		 128M
+	0x8000_0000	0x8fff_ffff	PCI MEM		 256M
+	0x9000_0000	0x9fff_ffff	PCI_MMIO	 256M
+	0xe000_0000	0xe00f_ffff	IMMR		 1M
+	0xe030_0000	0xe03f_ffff	PCI IO		 1M
+	0xe060_0000	0xe060_7fff	NAND FLASH (CS1) 32K
+	0xfe00_0000	0xfe7f_ffff	NOR FLASH (CS0)	 8M
+
+	When booting from NAND, NAND flash is CS0 and NOR flash
+	is CS1.
+
+3.	Definitions
+
+3.1	Explanation of NEW definitions in:
+
+	include/configs/MPC8315ERDB.h
+
+	CONFIG_MPC83xx		MPC83xx family
+	CONFIG_MPC831x		MPC831x specific
+	CONFIG_MPC8315		MPC8315 specific
+	CONFIG_MPC8315ERDB	MPC8315ERDB board specific
+
+4.	Compilation
+
+	Assuming you're using BASH (or similar) as your shell:
+
+	export CROSS_COMPILE=your-cross-compiler-prefix-
+	make distclean
+	make MPC8315ERDB_config (or MPC8315ERDB_NAND_config for u-boot-nand.bin)
+	make all
+
+5.	Downloading and Flashing Images
+
+5.1	Reflash U-boot Image using U-boot
+
+	NOR flash:
+
+	tftp 40000 u-boot.bin
+	protect off all
+	erase fe000000 fe1fffff
+
+	cp.b 40000 fe000000 xxxx
+	protect on all
+
+	You have to supply the correct byte count with 'xxxx'
+	from the TFTP result log.
+
+	NAND flash:
+
+	=>tftpboot $loadaddr <filename>
+	=>nand erase 0 0x80000
+	=>nand write $loadaddr 0 0x80000
+
+	...where 0x80000 is the filesize rounded up to
+	the next 0x20000 increment.
+
+5.2	Downloading and Booting Linux Kernel
+
+	Ensure that all networking-related environment variables are set
+	properly (including ipaddr, serverip, gatewayip (if needed),
+	netmask, ethaddr, eth1addr, rootpath (if using NFS root),
+	fdtfile, and bootfile).
+
+	Then, do one of the following, depending on whether you
+	want an NFS root or a ramdisk root:
+
+	=>run nfsboot
+	or
+	=>run ramboot
+
+6	Notes
+
+	The console baudrate for MPC8315ERDB is 115200bps.
diff --git a/u-boot/doc/README.mpc8323erdb b/u-boot/doc/README.mpc8323erdb
new file mode 100644
index 0000000..6f89829
--- /dev/null
+++ b/u-boot/doc/README.mpc8323erdb
@@ -0,0 +1,71 @@
+Freescale MPC8323ERDB Board
+-----------------------------------------
+
+1.	Memory Map
+	The memory map looks like this:
+
+	0x0000_0000	0x03ff_ffff	DDR		 64M
+	0x8000_0000	0x8fff_ffff	PCI MEM		 256M
+	0x9000_0000	0x9fff_ffff	PCI_MMIO	 256M
+	0xe000_0000	0xe00f_ffff	IMMR		 1M
+	0xd000_0000	0xd3ff_ffff	PCI IO		 64M
+	0xfe00_0000	0xfeff_ffff	NOR FLASH (CS0)	 16M
+
+2.	Compilation
+
+	Assuming you're using BASH (or similar) as your shell:
+
+	export CROSS_COMPILE=your-cross-compiler-prefix-
+	make distclean
+	make MPC8323ERDB_config
+	make
+
+3.	Downloading and Flashing Images
+
+3.1	Reflash U-boot Image using U-boot
+
+	N.b, have an alternate means of programming
+	the flash available if the new u-boot doesn't boot.
+
+	First try a:
+
+	tftpboot $loadaddr $uboot
+
+	to make sure that the TFTP load will succeed before
+	an erase goes ahead and wipes out your current firmware.
+	Then do a:
+
+	run tftpflash
+
+	which is a shorter version of the manual sequence:
+
+	tftp $loadaddr u-boot.bin
+	protect off fe000000 +$filesize
+	erase fe000000 +$filesize
+	cp.b $loadaddr fe000000 $filesize
+
+	To keep your old u-boot's environment variables, do a:
+
+	saveenv
+
+	prior to resetting the board.
+
+3.2	Downloading and Booting Linux Kernel
+
+	Ensure that all networking-related environment variables are set
+	properly (including ipaddr, serverip, gatewayip (if needed),
+	netmask, ethaddr, eth1addr, rootpath (if using NFS root),
+	fdtfile, and bootfile).
+
+	Then, do one of the following, depending on whether you
+	want an NFS root or a ramdisk root:
+
+	run nfsboot
+
+	or
+
+	run ramboot
+
+4	Notes
+
+	The console baudrate for MPC8323ERDB is 115200bps.
diff --git a/u-boot/doc/README.mpc832xemds b/u-boot/doc/README.mpc832xemds
new file mode 100644
index 0000000..688bdbb
--- /dev/null
+++ b/u-boot/doc/README.mpc832xemds
@@ -0,0 +1,128 @@
+Freescale MPC832XEMDS Board
+-----------------------------------------
+1. Board Switches and Jumpers
+1.0 There are five Dual-In-Line Packages(DIP) Switches on MPC832XE SYS board
+	For some reason, the HW designers describe the switch settings
+	in terms of 0 and 1, and then map that to physical switches where
+	the label "On" refers to logic 0 and "Off" is logic 1.
+
+	Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
+	bits may contribute to signals that are numbered based at 0,
+	and some of those signals may be high-bit-number-0 too.  Heed
+	well the names and labels and do not get confused.
+
+		"Off" == 1
+		"On"  == 0
+
+	SW3 is switch 18 as silk-screened onto the board.
+	SW4[8] is the bit labled 8 on Switch 4.
+	SW5[1:6] refers to bits labeled 1 through 6 in order on switch 5.
+	SW6[7:1] refers to bits labeled 7 through 1 in order on switch 6.
+	SW7[1:8]= 0000_0001 refers to bits labeled 1 through 6 is set as "On"
+		and bits labeled 8 is set as "Off".
+
+1.1 For the MPC832XEMDS PROTO Board
+
+	First, make sure the board default setting is consistent with the document
+		 shipped with your board. Then apply the following setting:
+	SW3[1-8]= 0000_1000  (core PLL setting, core enable)
+	SW4[1-8]= 0001_0010  (Flash boot on local bus, system PLL setting)
+	SW5[1-8]= 0010_0110  (Boot from high end)
+	SW6[1-8]= 0011_0100  (Flash boot on 16 bit local bus)
+	SW7[1-8]= 1000_0011  (QE PLL setting)
+
+	ENET3/4 MII mode settings:
+	J1 1-2 (ETH3_TXER)
+	J2 2-3 (MII mode)
+	J3 2-3 (MII mode)
+	J4 2-3 (ADSL clockOscillator)
+	J5 1-2 (ETH4_TXER)
+	J6 2-3 (ClockOscillator)
+	JP1 removed (don't force PORESET)
+	JP2 mounted (ETH4/2 MII)
+	JP3 mounted (ETH3 MII)
+	JP4 mounted (HRCW from BCSR)
+
+	ENET3/4 RMII mode settings:
+	J1 1-2 (ETH3_TXER)
+	J2 1-2 (RMII mode)
+	J3 1-2 (RMII mode)
+	J4 2-3 (ADSL clockOscillator)
+	J5 1-2 (ETH4_TXER)
+	J6 2-3 (ClockOscillator)
+	JP1 removed (don't force PORESET)
+	JP2 removed (ETH4/2 RMII)
+	JP3 removed (ETH3 RMII)
+	JP4 removed (HRCW from FLASH)
+
+	on board Oscillator: 66M
+
+
+2. Memory Map
+
+2.1 The memory map should look pretty much like this:
+
+	0x0000_0000	0x7fff_ffff	DDR			2G
+	0x8000_0000	0x8fff_ffff	PCI MEM prefetch	256M
+	0x9000_0000	0x9fff_ffff	PCI MEM non-prefetch	256M
+	0xc000_0000	0xdfff_ffff	Empty			512M
+	0xe000_0000	0xe01f_ffff	Int Mem Reg Space	2M
+	0xe020_0000	0xe02f_ffff	Empty			1M
+	0xe030_0000	0xe03f_ffff	PCI IO			1M
+	0xe040_0000	0xefff_ffff	Empty			252M
+	0xf400_0000	0xf7ff_ffff	Empty			64M
+	0xf800_0000	0xf800_7fff	BCSR on CS1		32K
+	0xf800_8000	0xf800_ffff	PIB CS2			32K
+	0xf801_0000	0xf801_7fff	PIB CS3			32K
+	0xfe00_0000	0xfeff_ffff	FLASH on CS0		16M
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+	include/configs/MPC832XEPB.h
+
+    CONFIG_MPC83xx	MPC83xx family for MPC8349, MPC8360 and MPC832x
+    CONFIG_MPC832x	MPC832x specific
+    CONFIG_MPC832XEMDS	MPC832XEMDS board specific
+
+4. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+		make MPC832XEMDS_config
+		make
+
+	MPC832x support PCI 33MHz and PCI 66MHz, to make u-boot support PCI:
+
+		1)Make sure the DIP SW support PCI mode as described in Section 1.1.
+
+		2)To Make U-Boot image support PCI 33MHz, use
+			Make MPC832XEMDS_HOST_33_config
+
+		3)To Make U-Boot image support PCI 66MHz, use
+			Make MPC832XEMDS_HOST_66M_config
+
+5. Downloading and Flashing Images
+
+5.0 Download over network:
+
+	tftp 10000 u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+	tftp 20000 u-boot.bin
+	protect off fe000000 fe0fffff
+	erase fe000000 fe0fffff
+	cp.b 20000 fe000000 xxxx
+
+You have to supply the correct byte count with 'xxxx' from the TFTP result log.
+Maybe 3ffff will work too, that corresponds to the erased sectors.
+
+
+6. Notes
+	1) The console baudrate for MPC832XEMDS is 115200bps.
diff --git a/u-boot/doc/README.mpc8349itx b/u-boot/doc/README.mpc8349itx
new file mode 100644
index 0000000..48bbd50
--- /dev/null
+++ b/u-boot/doc/README.mpc8349itx
@@ -0,0 +1,187 @@
+Freescale MPC8349E-mITX and MPC8349E-mITX-GP Boards
+---------------------------------------------------
+
+1.	Board Description
+
+	The MPC8349E-mITX and MPC8349E-mITX-GP are reference boards featuring
+	the Freescale MPC8349E processor in a Mini-ITX form factor.
+
+	The MPC8349E-mITX-GP is an MPC8349E-mITX with the following differences:
+
+	A) One 8MB on-board flash EEPROM chip, instead of two.
+	B) No SATA controller
+	C) No Compact Flash slot
+	D) No Mini-PCI slot
+	E) No Vitesse 7385 5-port Ethernet switch
+	F) No 4-port USB Type-A interface
+
+2.	Board Switches and Jumpers
+
+2.0	Descriptions for all of the board jumpers can be found in the User
+	Guide.  Of particular interest to U-Boot developers is jumper J22:
+
+	Pos.	Name		Default		Description
+	-----------------------------------------------------------------------
+	A	LGPL0		ON (0)          HRCW source, bit 0
+	B       LGPL1           ON (0)          HRCW source, bit 1
+	C       LGPL3           ON (0)		HRCW source, bit 2
+	D       LGPL5           OFF (1)         PCI_SYNC_OUT frequency
+	E       BOOT1           ON (0)          Flash EEPROM boot device
+	F       PCI_M66EN       ON (0)          PCI 66MHz enable
+	G       I2C-WP          ON (0)          I2C EEPROM write protection
+	H       F_WP            OFF (1)         Flash EEPROM write protection
+
+	Jumper J22.E is only for the ITX, and it decides the configuration
+	of the flash chips.  If J22.E is ON (i.e. jumpered), then flash chip
+	U4 is located at address FE000000 and flash chip U7 is at FE800000.
+	If J22.E is OFF, then U7 is at FE000000 and U4 is at FE800000.
+
+	For U-Boot development, J22.E can be used to switch back-and-forth
+	between two U-Boot images.
+
+3.	Memory Map
+
+3.1.	The memory map should look pretty much like this:
+
+	0x0000_0000 - 0x0FFF_FFFF DDR SDRAM (256 MB)
+	0x8000_0000 - 0x9FFF_FFFF PCI1 memory space (512 MB)
+	0xA000_0000 - 0xBFFF_FFFF PCI2 memory space (512 MB)
+	0xE000_0000 - 0xEFFF_FFFF IMMR (1 MB)
+	0xE200_0000 - 0xE2FF_FFFF PCI1 I/O space (16 MB)
+	0xE300_0000 - 0xE3FF_FFFF PCI2 I/O space (16 MB)
+	0xF000_0000 - 0xF000_FFFF Compact Flash (ITX only)
+	0xF001_0000 - 0xF001_FFFF Local bus expansion slot
+	0xF800_0000 - 0xF801_FFFF Vitesse 7385 Parallel Interface (ITX only)
+	0xFE00_0000 - 0xFE7F_FFFF First 8MB bank of Flash memory
+	0xFE80_0000 - 0xFEFF_FFFF Second 8MB bank of Flash memory (ITX only)
+
+3.2	Flash EEPROM layout.
+
+	On the ITX, jumper J22.E is used to determine which flash chips are
+	at which address.  When J22.E is switched, addresses from FE000000
+	to FE7FFFFF are swapped with addresses from FE800000 to FEFFFFFF.
+
+	On the ITX, at the normal boot address (aka HIGHBOOT):
+
+	FE00_0000	HRCW
+	FE70_0000	Alternative U-Boot image
+	FE80_0000	Alternative HRCW
+	FEF0_0000	U-Boot image
+	FEFF_FFFF	End of flash
+
+	On the ITX, at the low boot address (LOWBOOT)
+
+	FE00_0000	HRCW and U-Boot image
+	FE04_0000	U-Boot environment variables
+	FE80_0000	Alternative HRCW and U-Boot image
+	FEFF_FFFF	End of flash
+
+	On the ITX-GP, the only option is LOWBOOT and there is only one chip
+
+	FE00_0000	HRCW and U-Boot image
+	FE04_0000	U-Boot environment variables
+	F7FF_FFFF	End of flash
+
+4. Definitions
+
+4.1 Explanation of NEW definitions in:
+
+	include/configs/MPC8349ITX.h
+
+	CONFIG_MPC83xx		MPC83xx family
+	CONFIG_MPC8349		MPC8349 specific
+	CONFIG_MPC8349ITX		MPC8349E-mITX
+	CONFIG_MPC8349ITXGP		MPC8349E-mITX-GP
+
+5. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+
+		make MPC8349ITX_config
+	or:
+		make MPC8349ITXGP_config
+	or:
+		make MPC8349ITX_LOWBOOT_config
+
+		make
+
+6. Downloading and Flashing Images
+
+6.1 Download via tftp:
+
+	tftp $loadaddr <uboot>
+
+	where "<uboot>" is the path and filename, on the TFTP server, of
+	the U-Boot image.
+
+6.1 Reflash U-Boot Image using U-Boot
+
+	setenv uboot <uboot>
+	run tftpflash
+
+	where "<uboot>" is the path and filename, on the TFTP server, of
+	the U-Boot image.
+
+6.2 Using the HRCW to switch between two different U-Boot images on the ITX
+
+	Because the ITX has 16MB of flash, it is possible to keep two U-Boot
+	images in flash, and use the HRCW to specify which one is to be used
+	when the board boots.  This trick is especially effective with a
+	hardware debugger that can override the HRCW, such as the BDI-2000.
+
+	When the BMS bit in the HRCW is 0, the ITX will boot the U-Boot image
+	at address FE000000.  When the BMS bit is 1, the ITX will boot the
+	image at address FEF00000.
+
+	Therefore, just put a U-Boot image at both FE000000 and FEF00000 and
+	change the BMS bit whenever you want to boot the other image.
+
+	Step-by-step instructions:
+
+	1) Build an ITX image to be loaded at FEF00000
+
+		make distclean
+		make MPC8349ITX_config
+		make
+
+	2) Take the u-boot.bin image and flash it at FEF00000.
+
+		tftp $loadaddr u-boot.bin
+		protect off all
+		erase FEF00000 +$filesize
+		cp.b $loadaddr FEF00000 $filesize
+
+	3) Build an ITX image to be loaded at FE000000
+
+		make distclean
+		make MPC8349ITX_LOWBOOT_config
+		make
+
+	4) Take the u-boot.bin image and flash it at FE000000.
+
+		tftp $loadaddr u-boot.bin
+		protect off FE000000 +$filesize
+		erase FE000000 +$filesize
+		cp.b $loadaddr FE000000 $filesize
+
+	The HRCW in flash is currently set to boot the image at FE000000.
+
+	If you have a hardware debugger, configure it to set the HRCW to
+	B460A000 04040000 if you want to boot the image at FEF00000, or set
+	it to B060A000 04040000 if you want to boot the image at FE000000.
+
+	To change the HRCW in flash to boot the image at FEF00000, use these
+	U-Boot commands:
+
+		cp.b FE000000 1000 10000	; copy 1st flash sector to 1000
+		mw.b 1020 b4 8			; modify BMS bit
+		protect off FE000000 +10000
+		erase FE000000 +10000
+		cp.b 1000 FE000000 10000
+
+7. Notes
+	1) The console baudrate for MPC8349EITX is 115200bps.
diff --git a/u-boot/doc/README.mpc8360emds b/u-boot/doc/README.mpc8360emds
new file mode 100644
index 0000000..d65a2a4
--- /dev/null
+++ b/u-boot/doc/README.mpc8360emds
@@ -0,0 +1,147 @@
+Freescale MPC8360EMDS Board
+-----------------------------------------
+1.	Board Switches and Jumpers
+1.0	There are four Dual-In-Line Packages(DIP) Switches on MPC8360EMDS board
+	For some reason, the HW designers describe the switch settings
+	in terms of 0 and 1, and then map that to physical switches where
+	the label "On" refers to logic 0 and "Off" is logic 1.
+
+	Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
+	bits may contribute to signals that are numbered based at 0,
+	and some of those signals may be high-bit-number-0 too.  Heed
+	well the names and labels and do not get confused.
+
+		"Off" == 1
+		"On"  == 0
+
+	SW18 is switch 18 as silk-screened onto the board.
+	SW4[8] is the bit labled 8 on Switch 4.
+	SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2.
+	SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3.
+	SW3[1:8]= 0000_0001 refers to bits labeled 1 through 6 is set as "On"
+		and bits labeled 8 is set as "Off".
+
+1.1	There are three type boards for MPC8360E silicon up to now, They are
+
+	* MPC8360E-MDS-PB PROTO (a.k.a 8360SYS PROTOTYPE)
+	* MPC8360E-MDS-PB PILOT (a.k.a 8360SYS PILOT)
+	* MPC8360EA-MDS-PB PROTO (a.k.a 8360SYS2 PROTOTYPE)
+
+1.2	For all the MPC8360EMDS Board
+
+	First, make sure the board default setting is consistent with the
+	document shipped with your board. Then apply the following setting:
+	SW3[1-8]= 0000_0100  (HRCW setting value is performed on local bus)
+	SW4[1-8]= 0011_0000  (Flash boot on local bus)
+	SW9[1-8]= 0110_0110  (PCI Mode enabled. HRCW is read from FLASH)
+	SW10[1-8]= 0000_1000  (core PLL setting)
+	SW11[1-8]= 0000_0100 (SW11 is on the another side of the board)
+	JP6 1-2
+	on board Oscillator: 66M
+
+1.3	Since different board/chip rev. combinations have AC timing issues,
+	u-boot forces RGMII-ID (RGMII with Internal Delay) mode on by default
+	by the patch (mpc83xx: Disable G1TXCLK, G2TXCLK h/w buffers).
+
+	When the rev2.x silicon mount on these boards, and if you are using
+	u-boot version after this patch, to make the ethernet interfaces usable,
+	and to enable RGMII-ID on your board, you have to setup the jumpers
+	correctly.
+
+	* MPC8360E-MDS-PB PROTO
+	  nothing to do
+	* MPC8360E-MDS-PB PILOT
+	  JP9 and JP8 should be ON
+	* MPC8360EA-MDS-PB PROTO
+	  JP2 and JP3 should be ON
+
+2.	Memory Map
+
+2.1.	The memory map should look pretty much like this:
+
+	0x0000_0000	0x7fff_ffff	DDR			2G
+	0x8000_0000	0x8fff_ffff	PCI MEM prefetch	256M
+	0x9000_0000	0x9fff_ffff	PCI MEM non-prefetch	256M
+	0xc000_0000	0xdfff_ffff	Empty			512M
+	0xe000_0000	0xe01f_ffff	Int Mem Reg Space	2M
+	0xe020_0000	0xe02f_ffff	Empty			1M
+	0xe030_0000	0xe03f_ffff	PCI IO			1M
+	0xe040_0000	0xefff_ffff	Empty			252M
+	0xf000_0000	0xf3ff_ffff	Local Bus SDRAM		64M
+	0xf400_0000	0xf7ff_ffff	Empty			64M
+	0xf800_0000	0xf800_7fff	BCSR on CS1		32K
+	0xf800_8000	0xf800_ffff	PIB CS4			32K
+	0xf801_0000	0xf801_7fff	PIB CS5			32K
+	0xfe00_0000	0xfeff_ffff	FLASH on CS0		16M
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+	include/configs/MPC8360EMDS.h
+
+    CONFIG_MPC83xx	    MPC83xx family for both MPC8349 and MPC8360
+    CONFIG_MPC8360	    MPC8360 specific
+    CONFIG_MPC8360EMDS	    MPC8360EMDS board specific
+
+4. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+		make MPC8360EMDS_config
+		make
+
+	MPC8360 support PCI in host and slave mode.
+
+	To make u-boot support PCI host 66M :
+	1) DIP SW support PCI mode as described in Section 1.1.
+	2) Make MPC8360EMDS_HOST_66_config
+
+	To make u-boot support PCI host 33M :
+	1) DIP SW setting is similar as Section 1.1, except for SW3[4] is 1
+	2) Make MPC8360EMDS_HOST_33_config
+
+	To make u-boot support PCI slave 66M :
+	1) DIP SW setting is similar as Section 1.1, except for SW9[3] is 1
+	2) Make MPC8360EMDS_SLAVE_config
+
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+	loadb
+	[Drop to kermit:
+	    ^\c
+	    send <u-boot-bin-image>
+	    c
+	]
+
+
+    Or via tftp:
+
+	tftp 10000 u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+	tftp 20000 u-boot.bin
+	protect off fef00000 fef3ffff
+	erase fef00000 fef3ffff
+
+	cp.b 20000 fef00000 xxxx
+
+	or
+
+	cp.b 20000 fef00000 3ffff
+
+
+You have to supply the correct byte count with 'xxxx' from the TFTP result log.
+Maybe 3ffff will work too, that corresponds to the erased sectors.
+
+
+6. Notes
+	1) The console baudrate for MPC8360EMDS is 115200bps.
diff --git a/u-boot/doc/README.mpc837xemds b/u-boot/doc/README.mpc837xemds
new file mode 100644
index 0000000..aa767ae
--- /dev/null
+++ b/u-boot/doc/README.mpc837xemds
@@ -0,0 +1,104 @@
+Freescale MPC837xEMDS Board
+-----------------------------------------
+1.	Board Switches and Jumpers
+1.0	There are four Dual-In-Line Packages(DIP) Switches on MPC837xEMDS board
+	For some reason, the HW designers describe the switch settings
+	in terms of 0 and 1, and then map that to physical switches where
+	the label "On" refers to logic 0 and "Off" is logic 1.
+
+	Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
+	bits may contribute to signals that are numbered based at 0,
+	and some of those signals may be high-bit-number-0 too.  Heed
+	well the names and labels and do not get confused.
+
+		"Off" == 1
+		"On"  == 0
+
+	SW4[8] is the bit labled 8 on Switch 4.
+	SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2.
+	SW2[1:8]= 0000_0001 refers to bits labeled 1 through 7 is set as "On"
+		and bits labeled 8 is set as "Off".
+
+1.1	For the MPC837xEMDS Processor Board
+
+	First, make sure the board default setting is consistent with the
+	document shipped with your board. Then apply the following setting:
+	SW3[1-8]= 0011_0000  (BOOTSEQ, ROMLOC setting)
+	SW4[1-8]= 0000_0110  (core PLL setting)
+	SW5[1-8]= 1001_1000  (system PLL, boot up from low end of flash)
+	SW6[1-8]= 0000_1000  (HRCW is read from NOR FLASH)
+	SW7[1-8]= 0110_1101  (TSEC1/2 interface setting - RGMII)
+	J3 2-3, TSEC1 LVDD1 with 2.5V
+	J6 2-3, TSEC2 LVDD2 with 2.5V
+	J9 2-3, CLKIN from osc on board
+	J10 removed, CS0 connect to NOR flash; when mounted, CS0 connect to NAND
+	J11 removed, Hardware Reset Configuration Word load from FLASH(NOR or NAND)
+	    mounted, HRCW load from BCSR.
+
+	on board Oscillator: 66M
+
+2.	Memory Map
+
+2.1.	The memory map should look pretty much like this:
+
+	0x0000_0000	0x7fff_ffff	DDR			2G
+	0x8000_0000	0x8fff_ffff	PCI MEM prefetch	256M
+	0x9000_0000	0x9fff_ffff	PCI MEM non-prefetch	256M
+	0xc000_0000	0xdfff_ffff	Empty			512M
+	0xe000_0000	0xe00f_ffff	Int Mem Reg Space	1M
+	0xe010_0000	0xe02f_ffff	Empty			2M
+	0xe030_0000	0xe03f_ffff	PCI IO			1M
+	0xe040_0000	0xe05f_ffff	Empty			2M
+	0xe060_0000	0xe060_7fff	NAND Flash		32K
+	0xf400_0000	0xf7ff_ffff	Empty			64M
+	0xf800_0000	0xf800_7fff	BCSR on CS1		32K
+	0xfe00_0000	0xffff_ffff	NOR Flash on CS0	32M
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+	include/configs/MPC837XEMDS.h
+
+    CONFIG_MPC83xx	    MPC83xx family for both MPC837x and MPC8360
+    CONFIG_MPC837x	    MPC837x specific
+    CONFIG_MPC837XEMDS	    MPC837XEMDS board specific
+
+4. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+		make MPC837XEMDS_config
+		make
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+	loadb
+	[Drop to kermit:
+	    ^\c
+	    send <u-boot-bin-image>
+	    c
+	]
+
+
+    Or via tftp:
+
+	tftp 40000 u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+	tftp 40000 u-boot.bin
+	protect off fe000000 fe1fffff
+	erase fe000000 fe1fffff
+
+	cp.b 40000 fe000000 xxxx
+
+You have to supply the correct byte count with 'xxxx' from the TFTP result log.
+
+6. Notes
+	1) The console baudrate for MPC837XEMDS is 115200bps.
diff --git a/u-boot/doc/README.mpc837xerdb b/u-boot/doc/README.mpc837xerdb
new file mode 100644
index 0000000..cfb6efa
--- /dev/null
+++ b/u-boot/doc/README.mpc837xerdb
@@ -0,0 +1,97 @@
+Freescale MPC837xE-RDB Board
+-----------------------------------------
+
+1.	Board Description
+
+	The MPC837xE-RDB are reference boards featuring the Freescale MPC8377E,
+	MPC8378E, and the MPC8379E processors in a Mini-ITX form factor.
+
+	The MPC837xE-RDB's have the following common features:
+
+	A) 256-MBytes on-board DDR2 unbuffered SDRAM
+	B) 8-Mbytes NOR Flash
+	C) 32-MBytes NAND Flash
+	D) 1 Secure Digital High Speed Card (SDHC) Interface
+	E) 1 Gigabit Ethernet
+	F) 5-port Ethernet switch (Vitesse 7385)
+	G) 1 32-bit, 3.3 V, PCI slot
+	H) 1 32-bit, 3.3 V, Mini-PCI slot
+	I) 4-port USB 2.0 Hub
+	J) 1-port OTG USB
+	K) 2 serial ports (top main console)
+	L) on board Oscillator: 66M
+
+	The MPC837xE-RDB's have the following differences:
+
+			    MPC8377E-RDB    MPC8378E-RDB    MPC8379E-RDB
+	SATA controllers	2		0		4
+	PCI-Express (mini)	2		2		0
+	SGMII Ports		0		2		0
+
+
+2.	Memory Map
+
+2.1.	The memory map should look pretty much like this:
+
+	Address Range			Device			Size		Port Size
+								(Bytes)		(Bits)
+	===========================	=================	=======		=========
+	0x0000_0000	0x0fff_ffff	DDR			256M		64
+	0x1000_0000	0x7fff_ffff	Empty			1.75G		-
+	0x8000_0000	0x8fff_ffff	PCI MEM prefetch	256M		32
+	0x9000_0000	0x9fff_ffff	PCI MEM non-prefetch	256M		32
+	0xe030_0000	0xe03f_ffff	PCI I/O space		1M		32
+	0xe000_0000	0xe00f_ffff	Int Mem Reg Space	1M		-
+	0xe060_0000	0xe060_7fff	NAND Flash		32K		8
+	0xfe00_0000	0xfe7f_ffff	NOR Flash on CS0	8M		16
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+	include/configs/MPC837XERDB.h
+
+    CONFIG_MPC83xx	    MPC83xx family for both MPC8349 and MPC8360
+    CONFIG_MPC837x	    MPC837x specific
+    CONFIG_MPC837XERDB	    MPC837xE-RDB board specific
+
+
+4. Compilation
+
+	Assuming you're using BASH shell:
+
+		export CROSS_COMPILE=your-cross-compile-prefix
+		cd u-boot
+		make distclean
+		make MPC837XERDB_config
+		make
+
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+	loadb $loadaddr
+	[Drop to kermit:
+	    ^\c
+	    send <u-boot-bin-image>
+	    c
+	]
+
+
+	Or via tftp:
+
+	tftp $loadaddr u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+	tftp $loadaddr u-boot.bin
+	protect off fe000000 fe0fffff
+	erase fe000000 fe0fffff
+	cp.b $loadaddr fe000000 $filesize
+
+
+6. Additional Notes:
+	1) The console is connected to the top RS-232 connector and the
+	   baudrate for MPC837XE-RDB is 115200bps.
diff --git a/u-boot/doc/README.mpc83xx.ddrecc b/u-boot/doc/README.mpc83xx.ddrecc
new file mode 100644
index 0000000..0029f08
--- /dev/null
+++ b/u-boot/doc/README.mpc83xx.ddrecc
@@ -0,0 +1,154 @@
+Overview
+========
+
+The overall usage pattern for ECC diagnostic commands is the following:
+
+  * (injecting errors is initially disabled)
+
+  * define inject mask (which tells the DDR controller what type of errors
+    we'll be injecting: single/multiple bit etc.)
+
+  * enable injecting errors - from now on the controller injects errors as
+    indicated in the inject mask
+
+IMPORTANT NOTICE: enabling injecting multiple-bit errors is potentially
+dangerous as such errors are NOT corrected by the controller. Therefore caution
+should be taken when enabling the injection of multiple-bit errors: it is only
+safe when used on a carefully selected memory area and used under control of
+the 'ecc testdw' 'ecc testword' command (see example 'Injecting Multiple-Bit
+Errors' below). In particular, when you simply set the multiple-bit errors in
+inject mask and enable injection, U-Boot is very likely to hang quickly as the
+errors will be injected when it accesses its code, data etc.
+
+
+Use cases for DDR 'ecc' command:
+================================
+
+Before executing particular tests reset target board or clear status registers:
+
+=> ecc captureclear
+=> ecc errdetectclr all
+=> ecc sbecnt 0
+
+
+Injecting Single-Bit Errors
+---------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Run test over some memory region
+
+=> ecc testdw 200000 10
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000000
+...
+Memory Single-Bit Error Management (0..255):
+  Single-Bit Error Threshold: 255
+  Single Bit Error Counter: 16
+...
+Memory Error Detect:
+  Multiple Memory Errors: 0
+  Multiple-Bit Error: 0
+  Single-Bit Error: 0
+...
+
+16 errors were generated, Single-Bit Error flag was not set as Single Bit Error
+Counter did not reach  Single-Bit Error Threshold.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef    ................
+00200090: deadbeef deadbeef deadbeef deadbeef    ................
+
+Injecting Multiple-Bit Errors
+-----------------------------
+
+1. Set more than 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+=> ecc injectdatalo 1
+
+2. Run test over some memory region
+
+=> ecc testword 200000 1
+
+3. Check ECC status
+
+=> ecc status
+...
+Memory Data Path Error Injection Mask High/Low: 00000001 00000001
+...
+Memory Error Detect:
+  Multiple Memory Errors: 0
+  Multiple-Bit Error: 1
+  Single-Bit Error: 0
+...
+
+The Multiple Memory Errors flags not set and Multiple-Bit Error flags are set.
+
+4. Make sure used memory region got re-initialized with 0x0123456789abcdef
+
+=> md 200000
+00200000: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200010: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200020: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200030: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200040: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200050: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200060: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200070: 01234567 89abcdef 01234567 89abcdef    .#Eg.....#Eg....
+00200080: deadbeef deadbeef deadbeef deadbeef    ................
+00200090: deadbeef deadbeef deadbeef deadbeef    ................
+
+
+Test Single-Bit Error Counter and Threshold
+-------------------------------------------
+
+1. Set 1 bit in Data Path Error Inject Mask
+
+=> ecc injectdatahi 1
+
+2. Enable error injection
+
+=> ecc inject en
+
+3. Let u-boot run for a with Single-Bit error injection enabled
+
+4. Disable error injection
+
+=> ecc inject dis
+
+4. Check status
+
+=> ecc status
+
+...
+Memory Single-Bit Error Management (0..255):
+  Single-Bit Error Threshold: 255
+  Single Bit Error Counter: 199
+
+Memory Error Detect:
+  Multiple Memory Errors: 1
+  Multiple-Bit Error: 0
+  Single-Bit Error: 1
+...
+
+Observe that Single-Bit Error is 'on' which means that Single-Bit Error Counter
+reached Single-Bit Error Threshold. Multiple Memory Errors bit is also 'on', that
+is Counter reached Threshold more than one time (it wraps back after reaching
+Threshold).
diff --git a/u-boot/doc/README.mpc83xxads b/u-boot/doc/README.mpc83xxads
new file mode 100644
index 0000000..d456103
--- /dev/null
+++ b/u-boot/doc/README.mpc83xxads
@@ -0,0 +1,98 @@
+Freescale MPC83xx ADS Boards
+-----------------------------------------
+
+0. Toolchain / Building
+
+    $ PATH=$PATH:/usr/powerpc/bin
+    $ CROSS_COMPILE=powerpc-linux-
+    $ export PATH CROSS_COMPILE
+
+    $ powerpc-linux-gcc -v
+    Reading specs from /usr/powerpc/lib/gcc/powerpc-linux/3.4.3/specs
+    Configured with: ../configure --prefix=/usr/powerpc
+    --exec-prefix=/usr/powerpc --target=powerpc-linux --enable-shared
+    --disable-nls --disable-multilib --enable-languages=c,c++,ada,f77,objc
+    Thread model: posix
+    gcc version 3.4.3 (Debian)
+
+    $ powerpc-linux-as -v
+    GNU assembler version 2.15 (powerpc-linux) using BFD version 2.15
+
+
+    $ make MPC8349ADS_config
+    Configuring for MPC8349ADS board...
+
+    $ make
+
+
+1. Board Switches and Jumpers
+
+
+2. Memory Map
+
+2.1. The memory map should look pretty much like this:
+
+     0x0000_0000     0x7fff_ffff     DDR		     2G
+     0x8000_0000     0x9fff_ffff     PCI MEM		     512M
+     0xc000_0000     0xdfff_ffff     Rapid IO		     512M
+     0xe000_0000     0xe00f_ffff     CCSR		     1M
+     0xe200_0000     0xe2ff_ffff     PCI IO		     16M
+     0xf000_0000     0xf7ff_ffff     SDRAM		     128M
+     0xf800_0000     0xf80f_ffff     BCSR		     1M
+     0xfe00_0000     0xffff_ffff     FLASH (boot bank)	     16M
+
+
+3. Definitions
+
+3.1 Explanation of NEW definitions in:
+
+	include/configs/MPC8349ADS.h
+
+    CONFIG_MPC83xx	    MPC83xx family
+    CONFIG_MPC8349	    MPC8349 specific
+    CONFIG_MPC8349ADS	    MPC8349ADS board specific
+    CONFIG_TSEC_ENET	    Use on-chip 10/100/1000 ethernet
+
+
+4. Compilation
+
+    Assuming you're using BASH shell:
+
+	export CROSS_COMPILE=your-cross-compile-prefix
+	cd u-boot
+	make distclean
+	make MPC8349ADS_config
+	make
+
+5. Downloading and Flashing Images
+
+5.0 Download over serial line using Kermit:
+
+	loadb
+	[Drop to kermit:
+	    ^\c
+	    send <u-boot-bin-image>
+	    c
+	]
+
+
+    Or via tftp:
+
+	tftp 10000 u-boot.bin
+
+5.1 Reflash U-boot Image using U-boot
+
+    tftp 10000 u-boot.bin
+    protect off fe000000 fe09ffff
+    erase fe000000 fe09ffff
+
+    cp.b 10000 fe000000 xxxx
+or
+    cp.b 10000 fe000000 a0000
+
+You might have to supply the correct byte count for 'xxxx' from
+the TFTP.  Maybe a0000 will work too, that corresponds to the
+erased sectors.
+
+
+6. Notes
diff --git a/u-boot/doc/README.mpc8536ds b/u-boot/doc/README.mpc8536ds
new file mode 100644
index 0000000..2a38bd6
--- /dev/null
+++ b/u-boot/doc/README.mpc8536ds
@@ -0,0 +1,127 @@
+Overview:
+=========
+
+The MPC8536E integrates a PowerPC processor core with system logic
+required for imaging, networking, and communications applications.
+
+Boot from NAND:
+===============
+
+The MPC8536E is capable of booting from NAND flash which uses the image
+u-boot-nand.bin. This image contains two parts: a first stage image(also
+call 4K NAND loader and a second stage image. The former is appended to
+the latter to produce u-boot-nand.bin.
+
+The bootup process can be divided into two stages: the first stage will
+configure the L2SRAM, then copy the second stage image to L2SRAM and jump
+to it. The second stage image is to configure all the hardware and boot up
+to U-Boot command line.
+
+The 4K NAND loader's code comes from the corresponding nand_spl directory,
+along with the code twisted by CONFIG_NAND_SPL. The macro CONFIG_NAND_SPL
+is mainly used to shrink the code size to the 4K size limitation.
+
+The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the
+second stage image. It's set in the board config file when boot from NAND
+is selected.
+
+Build and boot steps
+--------------------
+
+1. Building image
+	make MPC8536DS_NAND_config
+	make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+	SW2[5-8] = 1011
+	SW9[1-3] = 101
+	Note: 1 stands for 'on', 0 stands for 'off'
+
+3. Flash image
+	tftp 1000000 u-boot-nand.bin
+	nand erase 0 a0000
+	nand write 1000000 0 a0000
+
+Boot from On-chip ROM:
+======================
+
+The MPC8536E is capable of booting from the on-chip ROM - boot from eSDHC
+and boot from eSPI. When power on, the porcessor excutes the ROM code to
+initialize the eSPI/eSDHC controller, and loads the mian U-Boot image from
+the memory device that interfaced to the controller, such as the SDCard or
+SPI EEPROM, to the target memory, e.g. SDRAM or L2SRAM, then boot from it.
+
+The memory device should contain a specific data structure with control word
+and config word at the fixed address. The config word direct the process how
+to config the memory device, and the control word direct the processor where
+to find the image on the memory device, or where copy the main image to. The
+user can use any method to store the data structure to the memory device, only
+if store it on the assigned address.
+
+Build and boot steps
+--------------------
+
+For boot from eSDHC:
+1. Build image
+	make MPC8536DS_SDCARD_config
+	make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+	SW2[5-8] = 0111
+	SW3[1]   = 0
+	SW8[7]   = 0 - The on-board SD/MMC slot is active
+	SW8[7]   = 1 - The externel SD/MMC slot is active
+
+3. Put image to SDCard
+	Put the follwing info at the assigned address on the SDCard:
+
+	   Offset   |   Data     | Description
+	--------------------------------------------------------
+	| 0x40-0x43 | 0x424F4F54 | BOOT signature              |
+	--------------------------------------------------------
+	| 0x48-0x4B | 0x00080000 | u-boot.bin's size           |
+	--------------------------------------------------------
+	| 0x50-0x53 | 0x???????? | u-boot.bin's Addr on SDCard |
+	--------------------------------------------------------
+	| 0x58-0x5B | 0xF8F80000 | Target Address              |
+	-------------------------------------------------------
+	| 0x60-0x63 | 0xF8FFF000 | Execution Starting Address  |
+	--------------------------------------------------------
+	| 0x68-0x6B | 0x6        | Number of Config Addr/Data  |
+	--------------------------------------------------------
+	| 0x80-0x83 | 0xFF720100 | Config Addr 1               |
+	| 0x84-0x87 | 0xF8F80000 | Config Data 1               |
+	--------------------------------------------------------
+	| 0x88-0x8b | 0xFF720e44 | Config Addr 2               |
+	| 0x8c-0x8f | 0x0000000C | Config Data 2               |
+	--------------------------------------------------------
+	| 0x90-0x93 | 0xFF720000 | Config Addr 3               |
+	| 0x94-0x97 | 0x80010000 | Config Data 3               |
+	--------------------------------------------------------
+	| 0x98-0x9b | 0xFF72e40c | Config Addr 4               |
+	| 0x9c-0x9f | 0x00000040 | Config Data 4               |
+	--------------------------------------------------------
+	| 0xa0-0xa3 | 0x40000001 | Config Addr 5               |
+	| 0xa4-0xa7 | 0x00000100 | Config Data 5               |
+	--------------------------------------------------------
+	| 0xa8-0xab | 0x80000001 | Config Addr 6               |
+	| 0xac-0xaf | 0x80000001 | Config Data 6               |
+	--------------------------------------------------------
+	|              ......                                  |
+	--------------------------------------------------------
+	| 0x???????? | u-boot.bin                              |
+	--------------------------------------------------------
+
+	then insert the SDCard to the active slot to boot up.
+
+For boot from eSPI:
+1. Build image
+	make MPC8536DS_SPIFLASH_config
+	make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+	SW2[5-8] = 0110
+
+3. Put image to SPI flash
+	Put the info in the above table onto the SPI flash, then
+	boot up.
diff --git a/u-boot/doc/README.mpc8544ds b/u-boot/doc/README.mpc8544ds
new file mode 100644
index 0000000..bf257a0
--- /dev/null
+++ b/u-boot/doc/README.mpc8544ds
@@ -0,0 +1,122 @@
+Overview
+--------
+The MPC8544DS system is similar to the 85xx CDS systems such
+as the MPC8548CDS due to the similar E500 core.  However, it
+is placed on the same board as the 8641 HPCN system.
+
+
+Flash Banks
+-----------
+Like the 85xx CDS systems, the 8544 DS board has two flash banks.
+They are both present on boot, but there locations can be swapped
+using the dip-switch SW10, bit 2.
+
+However, unlike the CDS systems, but similar to the 8641 HPCN
+board, a runtime reset through the FPGA can also affect a swap
+on the flash bank mappings for the next reset cycle.
+
+Irrespective of the switch SW10[2], booting is always from the
+boot bank at 0xfff8_0000.
+
+
+Memory Map
+----------
+
+0xff80_0000 - 0xffbf_ffff	Alernate bank		4MB
+0xffc0_0000 - 0xffff_ffff	Boot bank		4MB
+
+0xffb8_0000			Alternate image start	512KB
+0xfff8_0000			Boot image start	512KB
+
+
+Flashing Images
+---------------
+
+For example, to place a new image in the alternate flash bank
+and then reset with that new image temporarily, use this:
+
+    tftp 1000000 u-boot.bin.8544ds
+    erase ffb80000 ffbfffff
+    cp.b 1000000 ffb80000 80000
+    pixis_reset altbank
+
+
+To overwrite the image in the boot flash bank:
+
+    tftp 1000000 u-boot.bin.8544ds
+    protect off all
+    erase fff80000 ffffffff
+    cp.b 1000000 fff80000 80000
+
+Other example U-Boot image and flash manipulations examples
+can be found in the README.mpc85xxcds file as well.
+
+
+The pixis_reset command
+-----------------------
+A new command, "pixis_reset", is introduced to reset mpc8641hpcn board
+using the FPGA sequencer.  When the board restarts, it has the option
+of using either the current or alternate flash bank as the boot
+image, with or without the watchdog timer enabled, and finally with
+or without frequency changes.
+
+Usage is;
+
+	pixis_reset
+	pixis_reset altbank
+	pixis_reset altbank wd
+	pixis_reset altbank cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+	pixis_reset cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+
+Examples;
+
+	/* reset to current bank, like "reset" command */
+	pixis_reset
+
+	/* reset board but use the to alternate flash bank */
+	pixis_reset altbank
+
+	/* reset board, use alternate flash bank with watchdog timer enabled*/
+	pixis_reset altbank wd
+
+	/* reset board to alternate bank with frequency changed.
+	 * 40 is SYSCLK, 2.5 is COREPLL ratio, 10 is MPXPLL ratio
+	 */
+	pixis-reset altbank cf 40 2.5 10
+
+Valid clock choices are in the 8641 Reference Manuals.
+
+
+Using the Device Tree Source File
+---------------------------------
+To create the DTB (Device Tree Binary) image file,
+use a command similar to this:
+
+    dtc -b 0 -f -I dts -O dtb mpc8544ds.dts > mpc8544ds.dtb
+
+Likely, that .dts file will come from here;
+
+    linux-2.6/arch/powerpc/boot/dts/mpc8544ds.dts
+
+After placing the DTB file in your TFTP disk area,
+you can download that dtb file using a command like:
+
+    tftp 900000 mpc8544ds.dtb
+
+Burn it to flash if you want.
+
+
+Booting Linux
+-------------
+
+Place a linux uImage in the TFTP disk area too.
+
+    tftp 1000000 uImage.8544
+    tftp 900000 mpc8544ds.dtb
+    bootm 1000000 - 900000
+
+Watch your ethact, netdev and bootargs U-Boot environment variables.
+You may want to do something like this too:
+
+    setenv ethact eTSEC3
+    setenv netdev eth1
diff --git a/u-boot/doc/README.mpc8569mds b/u-boot/doc/README.mpc8569mds
new file mode 100644
index 0000000..3d12a96
--- /dev/null
+++ b/u-boot/doc/README.mpc8569mds
@@ -0,0 +1,77 @@
+Overview
+--------
+MPC8569MDS is composed of two boards - PB (Processor Board) and PIB (Platform
+I/O Board). The mpc8569 PowerTM processor is mounted on PB board.
+
+Building U-boot
+-----------
+	make MPC8569MDS_config
+	make
+
+Memory Map
+----------
+0x0000_0000   0x7fff_ffff     DDR                     2G
+0xa000_0000   0xbfff_ffff     PCIe MEM                512MB
+0xe000_0000   0xe00f_ffff     CCSRBAR                 1M
+0xe280_0000   0xe2ff_ffff     PCIe I/O                8M
+0xc000_0000   0xdfff_ffff     SRIO                    512MB
+0xf000_0000   0xf3ff_ffff     SDRAM                   64MB
+0xf800_0000   0xf800_7fff     BCSR                    32KB
+0xf800_8000   0xf800_ffff     PIB (CS4)               32KB
+0xf801_0000   0xf801_7fff     PIB (CS5)               32KB
+0xfe00_0000   0xffff_ffff     Flash                   32MB
+
+
+Flashing u-boot Images
+---------------
+
+Use the following commands to program u-boot image into flash:
+
+	=> tftp 1000000 u-boot.bin
+	=> protect off all
+	=> erase fff80000 ffffffff
+	=> cp.b 1000000 fff80000 80000
+
+
+Setting the correct MAC addresses
+-----------------------
+The command - "mac", is introduced to set on-board system EEPROM in the format
+defined in board/freescale/common/sys_eeprom.c. we must set all 8 MAC
+addresses for the MPC8569MDS's 8 Ethernet ports and save it by "mac save" when
+we first get the board. The commands are as follows:
+	=> mac i NXID	/* Set NXID to this EEPROM */
+	=> mac e 01	/* Set Errata, this value is not defined by hardware
+			   designer, we can set whatever we want */
+	=> mac n a0	/* Set Serial Number. This is not defined by hardware
+			   designer, we can set whatever we want */
+	=> mac date 090512080000  /* Set the date in YYMMDDhhmmss format */
+
+	=> mac p 8	/* Set the number of mac ports, it should be 8 */
+	=> mac 0 xx:xx:xx:xx:xx:xx  /* xx:xx:xx:xx:xx:xx should be the real mac
+				       address, you can refer to the value on
+				       the sticker of the rear side of the board
+				     */
+	.....
+	=> mac 7 xx:xx:xx:xx:xx:xx
+	=> mac read
+	=> mac save
+
+After resetting the board, the ethxaddrs will be filled with the mac addresses
+if such environment variables are blank(never been set before). If the ethxaddr
+has been set but we want to update it, we can use the following commands:
+	=> setenv ethxaddr	/* x = "none",1,2,3,4,5,6,7 */
+	=> save
+	=> reset
+
+
+Programming the ucode to flash
+---------------------------------
+MPC8569 doesn't have ROM in QE, so we must upload the microcode(ucode) to QE's
+IRAM so that the QE can work. The ucode binary can be downloaded from
+http://opensource.freescale.com/firmware/, and it must be programmed to
+the address 0xfff0000 in the flash. Otherwise, the QE can't work and uboot
+hangs at "Net:"
+
+
+Please note the above two steps(setting mac addresses and programming ucode) are
+very important to get the board booting up and working properly.
diff --git a/u-boot/doc/README.mpc8572ds b/u-boot/doc/README.mpc8572ds
new file mode 100644
index 0000000..06dab59
--- /dev/null
+++ b/u-boot/doc/README.mpc8572ds
@@ -0,0 +1,166 @@
+Overview
+--------
+MPC8572DS is a high-performance computing, evaluation and development platform
+supporting the mpc8572 PowerTM processor.
+
+Building U-boot
+-----------
+	make MPC8572DS_config
+	make
+
+Flash Banks
+-----------
+MPC8572DS board has two flash banks. They are both present on boot, but their
+locations can be swapped using the dip-switch SW9[1:2].
+
+Booting is always from the boot bank at 0xec00_0000.
+
+
+Memory Map
+----------
+
+0xe800_0000 - 0xebff_ffff	Alernate bank		64MB
+0xec00_0000 - 0xefff_ffff	Boot bank		64MB
+
+0xebf8_0000 - 0xebff_ffff	Alternate u-boot address	512KB
+0xeff8_0000 - 0xefff_ffff	Boot u-boot address		512KB
+
+
+Flashing Images
+---------------
+
+To place a new u-boot image in the alternate flash bank and then reset with that
+ new image temporarily, use this:
+
+	tftp 1000000 u-boot.bin
+	erase ebf80000 ebffffff
+	cp.b 1000000 ebf80000 80000
+	pixis_reset altbank
+
+
+To program the image in the boot flash bank:
+
+	tftp 1000000 u-boot.bin
+	protect off all
+	erase eff80000 ffffffff
+	cp.b 1000000 eff80000 80000
+
+
+The pixis_reset command
+-----------------------
+The command - "pixis_reset", is introduced to reset mpc8572ds board
+using the FPGA sequencer.  When the board restarts, it has the option
+of using either the current or alternate flash bank as the boot
+image, with or without the watchdog timer enabled, and finally with
+or without frequency changes.
+
+Usage is;
+
+	pixis_reset
+	pixis_reset altbank
+	pixis_reset altbank wd
+	pixis_reset altbank cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+	pixis_reset cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+
+Examples:
+
+	/* reset to current bank, like "reset" command */
+	pixis_reset
+
+	/* reset board but use the to alternate flash bank */
+	pixis_reset altbank
+
+
+Using the Device Tree Source File
+---------------------------------
+To create the DTB (Device Tree Binary) image file,
+use a command similar to this:
+
+	dtc -b 0 -f -I dts -O dtb mpc8572ds.dts > mpc8572ds.dtb
+
+Likely, that .dts file will come from here;
+
+	linux-2.6/arch/powerpc/boot/dts/mpc8572ds.dts
+
+
+Booting Linux
+-------------
+
+Place a linux uImage in the TFTP disk area.
+
+	tftp 1000000 uImage.8572
+	tftp c00000 mpc8572ds.dtb
+	bootm 1000000 - c00000
+
+
+Implementing AMP(Asymmetric MultiProcessing)
+-------------
+1. Build kernel image for core0:
+
+	a. $ make 85xx/mpc8572_ds_defconfig
+
+	b. $ make menuconfig
+	   - un-select "Processor support"->"Symetric multi-processing support"
+
+	c. $ make uImage
+
+	d. $ cp arch/powerpc/boot/uImage /tftpboot/uImage.core0
+
+2. Build kernel image for core1:
+
+	a. $ make 85xx/mpc8572_ds_defconfig
+
+	b. $ make menuconfig
+	   - Un-select "Processor support"->"Symetric multi-processing support"
+	   - Select "Advanced setup" -> " Prompt for advanced kernel
+	     configuration options"
+		- Select "Set physical address where the kernel is loaded" and
+		  set it to 0x20000000, asssuming core1 will start from 512MB.
+		- Select "Set custom page offset address"
+		- Select "Set custom kernel base address"
+		- Select "Set maximum low memory"
+	   - "Exit" and save the selection.
+
+	c. $ make uImage
+
+	d. $ cp arch/powerpc/boot/uImage /tftpboot/uImage.core1
+
+3. Create dtb for core0:
+
+	$ dtc -I dts -O dtb -f -b 0 arch/powerpc/boot/dts/mpc8572ds_core0.dts > /tftpboot/mpc8572ds_core0.dtb
+
+4. Create dtb for core1:
+
+	$ dtc -I dts -O dtb -f -b 1 arch/powerpc/boot/dts/mpc8572ds_core1.dts > /tftpboot/mpc8572ds_core1.dtb
+
+5. Bring up two cores separately:
+
+	a. Power on the board, under u-boot prompt:
+		=> setenv <serverip>
+		=> setenv <ipaddr>
+		=> setenv bootargs root=/dev/ram rw console=ttyS0,115200
+	b. Bring up core1's kernel first:
+		=> setenv bootm_low 0x20000000
+		=> setenv bootm_size 0x10000000
+		=> tftp 21000000 8572/uImage.core1
+		=> tftp 22000000 8572/ramdiskfile
+		=> tftp 20c00000 8572/mpc8572ds_core1.dtb
+		=> interrupts off
+		=> bootm start 21000000 22000000 20c00000
+		=> bootm loados
+		=> bootm ramdisk
+		=> bootm fdt
+		=> fdt boardsetup
+		=> fdt chosen $initrd_start $initrd_end
+		=> bootm prep
+		=> cpu 1 release $bootm_low - $fdtaddr -
+	c. Bring up core0's kernel(on the same u-boot console):
+		=> setenv bootm_low 0
+		=> setenv bootm_size 0x20000000
+		=> tftp 1000000 8572/uImage.core0
+		=> tftp 2000000 8572/ramdiskfile
+		=> tftp c00000 8572/mpc8572ds_core0.dtb
+		=> bootm 1000000 2000000 c00000
+
+Please note only core0 will run u-boot, core1 starts kernel directly after
+"cpu release" command is issued.
diff --git a/u-boot/doc/README.mpc85xxads b/u-boot/doc/README.mpc85xxads
new file mode 100644
index 0000000..d059a97
--- /dev/null
+++ b/u-boot/doc/README.mpc85xxads
@@ -0,0 +1,303 @@
+Motorola MPC8540ADS and MPC8560ADS board
+
+Created 10/15/03 Xianghua Xiao
+Updated 13-July-2004 Jon Loeliger
+-----------------------------------------
+
+0. Toolchain
+
+    The Binutils in current ELDK toolchain will not support MPC85xx
+    chip.  You need to use binutils-2.14.tar.bz2 (or newer) from
+    http://ftp.gnu.org/gnu/binutils.
+
+    The 8540/8560 ADS code base is known to compile using:
+	gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
+
+
+1. SWITCH SETTINGS & JUMPERS
+
+1.0 Nomenclature
+
+    For some reason, the HW designers describe the switch settings
+    in terms of 0 and 1, and then map that to physical switches where
+    the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1.
+    Luckily, we're SW types and virtual settings are handled daily.
+
+    The switches for the Rev A board are numbered differently than
+    for the Pilot board.  Oh yeah.
+
+    Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
+    bits may contribute to signals that are numbered based at 0,
+    and some of those signals may be high-bit-number-0 too.  Heed
+    well the names and labels and do not get confused.
+
+    "Off" == 1
+    "On"  == 0
+
+    SW18 is switch 18 as silk-screened onto the board.
+    SW4[8] is the bit labled 8 on Switch 4.
+    SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2
+    SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3
+
+1.1 For the MPC85xxADS Pilot Board
+
+    First, make sure the board default setting is consistent with the document
+    shipped with your board. Then apply the following changes:
+    SW3[1-6]="all OFF"	(boot from 32bit flash, no boot sequence is used)
+    SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560)
+    SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode)
+    SW11[7]='ON' (rev2), 'OFF' (rev1)
+    SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector)
+    SW22[1-4]="OFF OFF ON OFF"
+    SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF"
+    J1 = "Enable Prog" (Make sure your flash is programmable for development)
+
+    If you want to test PCI functionality with a 33Mhz PCI card, you will
+    have to change the system clock from the default 66Mhz to 33Mhz by
+    setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need
+    double your platform clock(SW6) because the system clock is now only
+    half of its original value. For example, if at 66MHz your system
+    clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10.
+
+	SW17[8] ------+	   SW6
+	SW15[1] ----+ |	  [0:1]
+		    V V	   V V
+	33MHz	    1 1	   1 0
+	66MHz	    0 0	   0 1
+
+    Hmmm... That SW6 setting description is incomplete but it works.
+
+
+1.3 For the MPC85xxADS Rev A Board
+
+    As shipped, the board should be a 33MHz PCI bus with a CPU Clock
+    rate of 825 +/- fuzz:
+
+	Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC:	82 MHz
+
+    For 33MHz PCI, the switch settings should be like this:
+
+	SW18[7:1] = 0100001 = M==33 =>	  33MHz
+	SW18[8]	  =	  1	    => PWD Divider == 16
+	SW16[1:2] =	 11	    => N == 16 as PWD==1
+
+    Use the magical formula:
+	Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz
+
+	SW7[1:4]  =    1010 = 10    => 10 x 33	 = 330	CCB Sysclk
+	SW7[5:6]  =	 01	    => 5:2 x 330 = 825	Core clock
+
+
+    For 66MHz PCI, the switch settings should be like this:
+
+	SW18[7:1] = 0100001 = M==33 =>	  33MHz
+	SW18[8]	  =	  0	    => PWD Divider == 1
+	SW16[1:2] =	 01	    => N == 8 as PWD == 0
+
+    Use the magical formula:
+	Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz
+
+	SW7[1:4]  =    0101 =  5    => 5 x 66	 = 330	CCB Sysclk
+	SW7[5:6]  =	 01	    => 5:2 x 330 = 825	Core clock
+
+    In order to use PCI-X (only in the first PCI slot.  The one with
+    the RIO connector), you need to set SW1[4] (config) to 1 (off).
+    Also, configure the board to run PCI at 66 MHz.
+
+2. MEMORY MAP TO WORK WITH LINUX KERNEL
+
+2.1. For the initial bringup, we adopted a consistent memory scheme
+     between u-boot and linux kernel, you can customize it based on your
+     system requirements:
+
+     0x0000_0000     0x7fff_ffff     DDR		     2G
+     0x8000_0000     0x9fff_ffff     PCI MEM		     512M
+     0xc000_0000     0xdfff_ffff     Rapid IO		     512M
+     0xe000_0000     0xe00f_ffff     CCSR		     1M
+     0xe200_0000     0xe2ff_ffff     PCI IO		     16M
+     0xf000_0000     0xf7ff_ffff     SDRAM		     128M
+     0xf800_0000     0xf80f_ffff     BCSR		     1M
+     0xff00_0000     0xffff_ffff     FLASH (boot bank)	     16M
+
+2.2 We are submitting Linux kernel patches for MPC8540 and MPC8560. You
+    can download them from linuxppc-2.4 public source. Please make sure the
+    kernel's ppcboot.h is consistent with U-Boot's u-boot.h. You can use two
+    default configuration files as your starting points to configure the
+    kernel:
+	arch/powerpc/configs/mpc8540_ads_defconfig
+	arch/powerpc/configs/mpc8560_ads_defconfig
+
+3. DEFINITIONS AND COMPILATION
+
+3.1 Explanation on NEW definitions in:
+	include/configs/MPC8540ADS.h
+	include/configs/MPC8560ADS.h
+
+    CONFIG_BOOKE	    BOOKE(e.g. Motorola MPC85xx, AMCC 440, etc)
+    CONFIG_E500		    BOOKE e500 family(Motorola)
+    CONFIG_MPC85xx	    MPC8540,MPC8560 and their derivatives
+    CONFIG_MPC8540	    MPC8540 specific
+    CONFIG_MPC8540ADS	    MPC8540ADS board specific
+    CONFIG_MPC8560ADS	    MPC8560ADS board specific
+    CONFIG_TSEC_ENET	    Use on-chip 10/100/1000 ethernet for networking
+    CONFIG_SPD_EEPROM	    Use SPD EEPROM for DDR auto configuration, you can
+			    also manual config the DDR after undef this
+			    definition.
+    CONFIG_DDR_ECC	    only for ECC DDR module
+    CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN	    DLL fix on some ADS boards needed
+			    for more stability.
+    CONFIG_HAS_FEC	    If an FEC is on chip, set to 1, else 0.
+
+Other than the above definitions, the rest in the config files are
+straightforward.
+
+
+3.2 Compilation
+
+    Assuming you're using BASH shell:
+
+	export CROSS_COMPILE=your-cross-compile-prefix
+	cd u-boot
+	make distclean
+	make MPC8560ADS_config (or make MPC8540ADS_config)
+	make
+
+4.  Notes:
+
+4.1 When connecting with kermit, the following commands must be present.in
+    your .kermrc file. These are especially important when booting as
+    MPC8560, as the serial console will not work without them:
+
+	set speed 115200
+	set carrier-watch off
+	set handshake none
+	set flow-control none
+	robust
+
+
+4.2 Sometimes after U-Boot is up, the 'tftp' won't work well with TSEC
+    ethernet. If that happens, you can try the following steps to make
+    network work:
+
+	MPC8560ADS>tftp 1000000 pImage
+	(if it hangs, use Ctrl-C to quit)
+	MPC8560ADS>nm fdf24524
+	>0
+	>1
+	>. (to quit this memory operation)
+	MPC8560ADS>tftp 1000000 pImage
+
+4.3 If you're one of the early developers using the Rev1 8540/8560 chips,
+    please use U-Boot 1.0.0, as the newer silicon will only support Rev2
+    and future revisions of 8540/8560.
+
+
+4.4 Reflash U-boot Image using U-boot
+
+    tftp 10000 u-boot.bin
+    protect off fff80000 ffffffff
+    erase fff80000 ffffffff
+    cp.b 10000 fff80000 80000
+
+
+4.5 Reflash U-Boot with a BDI-2000
+
+    BDI> erase 0xFFF80000 0x4000 0x20
+    BDI> prog 0xfff80000 u-boot.bin.8560ads
+    BDI> verify
+
+
+5. Screen dump MPC8540ADS board
+
+U-Boot 1.1.2(pq3-20040707-0) (Jul  6 2004 - 17:34:25)
+
+Freescale PowerPC
+    Core: E500, Version: 2.0, (0x80200020)
+    System: 8540, Version: 2.0, (0x80300020)
+    Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC:  82 MHz
+    L1 D-cache 32KB, L1 I-cache 32KB enabled.
+Board: ADS
+    PCI1: 32 bit, 66 MHz (compiled)
+I2C:   ready
+DRAM:  Initializing
+    SDRAM: 64 MB
+    DDR: 256 MB
+FLASH: 16 MB
+L2 cache enabled: 256KB
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   MOTO ENET0: PHY is Marvell 88E1011S (1410c62)
+MOTO ENET1: PHY is Marvell 88E1011S (1410c62)
+MOTO ENET2: PHY is Davicom DM9161E (181b881)
+MOTO ENET0, MOTO ENET1, MOTO ENET2
+Hit any key to stop autoboot:  0
+=>
+=> fli
+
+Bank # 1: Intel 28F640J3A (64 Mbit, 64 x 128K)
+  Size: 16 MB in 64 Sectors
+  Sector Start Addresses:
+    FF000000	  FF040000	FF080000      FF0C0000	    FF100000
+    FF140000	  FF180000	FF1C0000      FF200000	    FF240000
+    FF280000	  FF2C0000	FF300000      FF340000	    FF380000
+    FF3C0000	  FF400000	FF440000      FF480000	    FF4C0000
+    FF500000	  FF540000	FF580000      FF5C0000	    FF600000
+    FF640000	  FF680000	FF6C0000      FF700000	    FF740000
+    FF780000	  FF7C0000	FF800000      FF840000	    FF880000
+    FF8C0000	  FF900000	FF940000      FF980000	    FF9C0000
+    FFA00000	  FFA40000	FFA80000      FFAC0000	    FFB00000
+    FFB40000	  FFB80000	FFBC0000      FFC00000	    FFC40000
+    FFC80000	  FFCC0000	FFD00000      FFD40000	    FFD80000
+    FFDC0000	  FFE00000	FFE40000      FFE80000	    FFEC0000
+    FFF00000	  FFF40000	FFF80000 (RO) FFFC0000 (RO)
+
+=> bdinfo
+memstart    = 0x00000000
+memsize	    = 0x10000000
+flashstart  = 0xFF000000
+flashsize   = 0x01000000
+flashoffset = 0x00000000
+sramstart   = 0x00000000
+sramsize    = 0x00000000
+immr_base   = 0xE0000000
+bootflags   = 0xE4013F80
+intfreq	    =	 825 MHz
+busfreq	    =	 330 MHz
+ethaddr	    = 00:E0:0C:00:00:FD
+eth1addr    = 00:E0:0C:00:01:FD
+eth2addr    = 00:E0:0C:00:02:FD
+IP addr	    = 192.168.1.253
+baudrate    = 115200 bps
+
+
+=> printenv
+bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
+ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;bootm $loadaddr $ramdiskaddr
+nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
+bootdelay=10
+baudrate=115200
+loads_echo=1
+ethaddr=00:E0:0C:00:00:FD
+eth1addr=00:E0:0C:00:01:FD
+eth2addr=00:E0:0C:00:02:FD
+ipaddr=192.168.1.253
+serverip=192.168.1.1
+rootpath=/nfsroot
+gatewayip=192.168.1.1
+netmask=255.255.255.0
+hostname=unknown
+bootfile=your.uImage
+loadaddr=200000
+netdev=eth0
+consoledev=ttyS0
+ramdiskaddr=400000
+ramdiskfile=your.ramdisk.u-boot
+stdin=serial
+stdout=serial
+stderr=serial
+ethact=MOTO ENET0
+
+Environment size: 1020/8188 bytes
diff --git a/u-boot/doc/README.mpc85xxcds b/u-boot/doc/README.mpc85xxcds
new file mode 100644
index 0000000..bc5db0c
--- /dev/null
+++ b/u-boot/doc/README.mpc85xxcds
@@ -0,0 +1,225 @@
+Motorola MPC85xxCDS boards
+--------------------------
+
+The CDS family of boards consists of a PCI backplane called the
+"Arcadia", a PCI-form-factor carrier card that plugs into a PCI slot,
+and a CPU daughter card that bolts onto the daughter card.
+
+Much of the content of the README.mpc85xxads for the 85xx ADS boards
+applies to the 85xx CDS boards as well.	 In particular the toolchain,
+the switch nomenclature, and the basis for the memory map.  There are
+some differences, though.
+
+
+Building U-Boot
+---------------
+
+The Binutils in current ELDK toolchain will not support MPC85xx
+chip.  You need to use binutils-2.14.tar.bz2 (or newer) from
+    http://ftp.gnu.org/gnu/binutils.
+
+The 85xx CDS code base is known to compile using:
+    gcc (GCC) 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a)
+
+
+Memory Map
+----------
+
+The memory map for u-boot and linux has been extended w.r.t. the ADS
+platform to allow for utilization of all 85xx CDS devices.  The memory
+map is setup for linux to operate properly.  The linux source when
+configured for MPC85xx CDS has been updated to reflect the new memory
+map.
+
+The mapping is:
+
+   0x0000_0000	   0x7fff_ffff	   DDR			   2G
+   0x8000_0000	   0x9fff_ffff	   PCI1 MEM		   512M
+   0xa000_0000	   0xbfff_ffff	   PCI2 MEM		   512M
+   0xe000_0000	   0xe00f_ffff	   CCSR			   1M
+   0xe200_0000	   0xe2ff_ffff	   PCI1 IO		   16M
+   0xe300_0000	   0xe3ff_ffff	   PCI2 IO		   16M
+   0xf000_0000	   0xf7ff_ffff	   SDRAM		   128M
+   0xf800_0000	   0xf80f_ffff	   NVRAM/CADMUS (*)	   1M
+   0xff00_0000	   0xff7f_ffff	   FLASH (2nd bank)	   8M
+   0xff80_0000	   0xffff_ffff	   FLASH (boot bank)	   8M
+
+   (*) The system control registers (CADMUS) start at offset 0xfdb0_4000
+   within the NVRAM/CADMUS region of memory.
+
+
+Using Flash
+-----------
+
+The CDS board  has two flash banks, each 8MB in size (2^23 = 0x00800000).
+There is a switch which allows the boot-bank to be selected.  The switch
+settings for updating flash are given below.
+
+The u-boot commands for copying the boot-bank into the secondary bank are
+as follows:
+
+     erase ff780000 ff7fffff
+     cp.b fff80000 ff780000 80000
+
+
+U-boot/kermit commands for downloading an image, then copying
+it into the secondary bank:
+
+     loadb
+     [Drop to kermit:
+	^\c
+	send <u-boot-bin-image>
+	c
+     ]
+
+     erase ff780000 ff7fffff
+     cp.b $loadaddr ff780000 80000
+
+
+U-boot commands for downloading an image via tftp and flashing
+it into the second bank:
+
+     tftp 10000 <u-boot.bin.image>
+     erase ff780000 ff7fffff
+     cp.b 10000 ff780000 80000
+
+
+After copying the image into the second bank of flash, be sure to toggle
+SW2[2] on the carrier card before resetting the board in order to set the
+secondary bank as the boot-bank.
+
+
+Carrier Board Switches
+----------------------
+
+As a reminder, you should read the README.mpc85xxads too.
+
+Most switches on the carrier board should not be changed.  The only
+user-settable switches on the carrier board are used to configure
+the flash banks and determining the PCI slot.
+
+The first two bits of SW2 control how flash is used on the board:
+
+      12345678
+      --------
+  SW2=00XXXXXX	   FLASH:  Boot bank 1, bank 2 available.
+      01XXXXXX	   FLASH:  Boot bank 2, bank 1 available (swapped).
+      10XXXXXX	   FLASH:  Boot promjet, bank 1 available
+      11XXXXXX	   FLASH:  Boot promjet, bank 2 available
+
+The boot bank is always mapped to FF80_0000 and listed first by
+the "flinfo" command.  The secondary bank is always FF00_0000.
+
+When using PCI, linux needs to know to which slot the CDS carrier is
+connected..  By convention, the user-specific bits of SW2 are used to
+convey this information:
+
+      12345678
+      --------
+  SW2=xxxxxx00	   PCI SLOT INFORM: The CDS carrier is in slot0 of the Arcadia
+      xxxxxx01	   PCI SLOT INFORM: The CDS carrier is in slot1 of the Arcadia
+      xxxxxx10	   PCI SLOT INFORM: The CDS carrier is in slot2 of the Arcadia
+      xxxxxx11	   PCI SLOT INFORM: The CDS carrier is in slot3 of the Arcadia
+
+These are cleverly, er, clearly silkscreened as Slot 1 through 4,
+respectively, on the Arcadia near the support posts.
+
+
+The default setting of all switches on the carrier board is:
+
+      12345678
+      --------
+  SW1=01101100
+  SW2=0x1111yy	   x=Flash bank, yy=PCI slot
+  SW3=11101111
+  SW4=10001000
+
+
+8555/41 CPU Card Switches
+-------------------------
+
+Most switches on the CPU Card should not be changed.  However, the
+frequency can be changed by setting SW3:
+
+      12345678
+      --------
+  SW3=XX00XXXX == CORE:CCB 2:1
+      XX01XXXX == CORE:CCB 5:2
+      XX10XXXX == CORE:CCB 3:1
+      XX11XXXX == CORE:CCB 7:2
+      XXXX1000 == CCB:SYSCLK 8:1
+      XXXX1010 == CCB:SYSCLK 10:1
+
+A safe default setting for all switches on the CPU board is:
+
+      12345678
+      --------
+  SW1=10001111
+  SW2=01000111
+  SW3=00001000
+  SW4=11111110
+
+
+8548 CPU Card Switches
+----------------------
+And, just to be confusing, in this set of switches:
+
+    ON  = 1
+    OFF = 0
+
+Default
+  SW1=11111101
+  SW2=10011111
+  SW3=11001000    (8X) (2:1)
+  SW4=11110011
+
+  SW3=X000XXXX  == CORE:CCB    4:1
+      X001XXXX  == CORE:CCB    9:2
+      X010XXXX  == CORE:CCB    1:1
+      X011XXXX  == CORE:CCB    3:2
+      X100XXXX  == CORE:CCB    2:1
+      X101XXXX  == CORE:CCB    5:2
+      X110XXXX  == CORE:CCB    3:1
+      X111XXXX  == CORE:CCB    7:2
+      XXXX0000  == CCB:SYSCLK 16:1
+      XXXX0001  == RESERVED
+      XXXX0010  == CCB:SYSCLK  2:1
+      XXXX0011  == CCB:SYSCLK  3:1
+      XXXX0100  == CCB:SYSCLK  4:1
+      XXXX0101  == CCB:SYSCLK  5:1
+      XXXX0110  == CCB:SYSCLK  6:1
+      XXXX0111  == RESERVED
+      XXXX1000  == CCB:SYSCLK  8:1
+      XXXX1001  == CCB:SYSCLK  9:1
+      XXXX1010  == CCB:SYSCLK 10:1
+      XXXX1011  == RESERVED
+      XXXX1100  == CCB:SYSCLK 12:1
+      XXXX1101  == CCB:SYSCLK 20:1
+      XXXX1110  == RESERVED
+      XXXX1111  == RESERVED
+
+
+eDINK Info
+----------
+
+One bank of flash may contain an eDINK image.
+
+Memory Map:
+
+   CCSRBAR @ 0xe0000000
+   Flash Bank 1 @ 0xfe000000
+   Flash Bank 2 @ 0xff000000
+   Ram @ 0
+
+Commands for downloading a u-boot image to memory from edink:
+
+   env -c
+   time -s 4/8/2004 4:30p
+   dl -k -b -o 100000
+   [Drop to kermit:
+	^\c
+	transmit /binary <u-boot-bin-image>
+	c
+   ]
+
+   fu -l 100000 fe780000 80000
diff --git a/u-boot/doc/README.mpc8610hpcd b/u-boot/doc/README.mpc8610hpcd
new file mode 100644
index 0000000..31a9af3
--- /dev/null
+++ b/u-boot/doc/README.mpc8610hpcd
@@ -0,0 +1,73 @@
+Freescale MPC8610HPCD board
+===========================
+
+
+Building U-Boot
+---------------
+
+    $ make MPC8610HPCD_config
+    Configuring for MPC8610HPCD board...
+
+    $ make
+
+
+Flashing U-Boot
+---------------
+The flash is 128M starting at 0xF800_0000.
+
+The alternate image is at 0xFBF0_0000
+The      boot image is at 0xFFF0_0000.
+
+
+To Flash U-Boot into the booting bank:
+
+	tftp 1000000 u-boot.bin
+	protect off all
+	erase fff00000 +$filesize
+	cp.b 1000000 fff00000 $filesize
+
+
+To Flash U-boot into the alternate bank
+
+	tftp 1000000 u-boot.bin
+	erase fbf00000 +$filesize
+	cp.b 1000000 fbf00000 $filesize
+
+
+pixis_reset command
+-------------------
+A new command, "pixis_reset", is introduced to reset mpc8610hpcd board
+using the FPGA sequencer.  When the board restarts, it has the option
+of using either the current or alternate flash bank as the boot
+image, with or without the watchdog timer enabled, and finally with
+or without frequency changes.
+
+Usage is;
+
+	pixis_reset
+	pixis_reset altbank
+	pixis_reset altbank wd
+	pixis_reset altbank cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+	pixis_reset cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+
+Examples;
+
+	/* reset to current bank, like "reset" command */
+	pixis_reset
+
+	/* reset board but use the to alternate flash bank */
+	pixis_reset altbank
+
+	/* reset board, use alternate flash bank with watchdog timer enabled*/
+	pixis_reset altbank wd
+
+	/* reset board to alternate bank with frequency changed.
+	 * 40 is SYSCLK, 2.5 is COREPLL ratio, 10 is MPXPLL ratio
+	 */
+	pixis-reset altbank cf 40 2.5 10
+
+
+DIP Switch Settings
+-------------------
+To manually switch the flash banks using the DIP switch
+settings, toggle both SW6:1 and SW6:2.
diff --git a/u-boot/doc/README.mpc8641hpcn b/u-boot/doc/README.mpc8641hpcn
new file mode 100644
index 0000000..d8fe0a4
--- /dev/null
+++ b/u-boot/doc/README.mpc8641hpcn
@@ -0,0 +1,186 @@
+Freescale MPC8641HPCN board
+===========================
+
+Created 05/24/2006 Haiying Wang
+-------------------------------
+
+1. Building U-Boot
+------------------
+The 86xx HPCN code base is known to compile using:
+    Binutils 2.15, Gcc 3.4.3, Glibc 2.3.3
+
+    $ make MPC8641HPCN_config
+    Configuring for MPC8641HPCN board...
+
+    $ make
+
+
+2. Switch and Jumper Setting
+----------------------------
+Jumpers:
+	J14 Pins 1-2 (near plcc32 socket)
+
+Switches:
+	SW1(1-5) = 01100	CONFIG_SYS_COREPLL	= 01000 :: CORE =   2:1
+						  01100 :: CORE = 2.5:1
+						  10000 :: CORE =   3:1
+						  11100 :: CORE = 3.5:1
+						  10100 :: CORE =   4:1
+						  01110 :: CORE = 4.5:1
+	SW1(6-8) = 001		CONFIG_SYS_SYSCLK	= 000	:: SYSCLK = 33MHz
+						  001	:: SYSCLK = 40MHz
+
+	SW2(1-4) = 1100		CONFIG_SYS_CCBPLL	= 0010	:: 2X
+						  0100	:: 4X
+						  0110	:: 6X
+						  1000	:: 8X
+						  1010	:: 10X
+						  1100	:: 12X
+						  1110	:: 14X
+						  0000	:: 16X
+	SW2(5-8) = 1110		CONFIG_SYS_BOOTLOC	= 1110	:: boot 16-bit localbus
+
+	SW3(1-7) = 0011000	CONFIG_SYS_VID		= 0011000 :: VCORE = 1.2V
+						  0100000 :: VCORE = 1.11V
+	SW3(8)	 = 0		VCC_PLAT	= 0	:: VCC_PLAT = 1.2V
+						  1	:: VCC_PLAT = 1.0V
+
+	SW4(1-2) = 11		CONFIG_SYS_HOSTMODE	= 11	:: both prots host/root
+	SW4(3-4) = 11		CONFIG_SYS_BOOTSEQ	= 11	:: no boot seq
+	SW4(5-8) = 0011		CONFIG_SYS_IOPORT	= 0011	:: both PEX
+
+	SW5(1)	 = 1		CONFIG_SYS_FLASHMAP	= 1	:: boot from flash
+						  0	:: boot from PromJet
+	SW5(2)	 = 1		CONFIG_SYS_FLASHBANK	= 1	:: swap upper/lower
+							 halves (virtual banks)
+						  0	:: normal
+	SW5(3)	 = 0		CONFIG_SYS_FLASHWP	= 0	:: not protected
+	SW5(4)	 = 0		CONFIG_SYS_PORTDIV	= 1	:: 2:1 for PD4
+							   1:1 for PD6
+	SW5(5-6) = 11		CONFIG_SYS_PIXISOPT	= 11	:: s/w determined
+	SW5(7-8) = 11		CONFIG_SYS_LADOPT	= 11	:: s/w determined
+
+	SW6(1)	 = 1		CONFIG_SYS_CPUBOOT	= 1	:: no boot holdoff
+	SW6(2)	 = 1		CONFIG_SYS_BOOTADDR	= 1	:: no traslation
+	SW6(3-5) = 000		CONFIG_SYS_REFCLKSEL	= 000	:: 100MHZ
+	SW6(6)	 = 1		CONFIG_SYS_SERROM_ADDR= 1	::
+	SW6(7)	 = 1		CONFIG_SYS_MEMDEBUG	= 1	::
+	SW6(8)	 = 1		CONFIG_SYS_DDRDEBUG	= 1	::
+
+	SW8(1)	 = 1		ACZ_SYNC	= 1	:: 48MHz on TP49
+	SW8(2)	 = 1		ACB_SYNC	= 1	:: THRMTRIP disabled
+	SW8(3)	 = 1		ACZ_SDOUT	= 1	:: p4 mode
+	SW8(4)	 = 1		ACB_SDOUT	= 1	:: PATA freq. = 133MHz
+	SW8(5)	 = 0		SUSLED		= 0	:: SouthBridge Mode
+	SW8(6)	 = 0		SPREAD		= 0	:: REFCLK SSCG Disabled
+	SW8(7)	 = 1		ACPWR		= 1	:: non-battery
+	SW8(8)	 = 0		CONFIG_SYS_IDWP	= 0	:: write enable
+
+
+3. Flash U-Boot
+---------------
+The flash range 0xEF800000 to 0xEFFFFFFF can be divided into 2 halves.
+It is possible to use either half to boot using u-boot.  Switch 5 bit 2
+is used for this purpose.
+
+0xEF800000 to 0xEFBFFFFF - 4MB
+0xEFC00000 to 0xEFFFFFFF - 4MB
+When this bit is 0, U-Boot is at 0xEFF00000.
+When this bit is 1, U-Boot is at 0xEFB00000.
+
+Use the above mentioned flash commands to program the other half, and
+use switch 5, bit 2 to alternate between the halves.  Note: The booting
+version of U-Boot will always be at 0xEFF00000.
+
+To Flash U-Boot into the booting bank (0xEFC00000 - 0xEFFFFFFF):
+
+	tftp 1000000 u-boot.bin
+	protect off all
+	erase eff00000 +$filesize
+	cp.b 1000000 eff00000 $filesize
+
+or use tftpflash command:
+	run tftpflash
+
+To Flash U-boot into the alternative bank (0xEF800000 - 0xEFBFFFFF):
+
+	tftp 1000000 u-boot.bin
+	erase efb00000 +$filesize
+	cp.b 1000000 efb00000 $filesize
+
+
+4. Memory Map
+-------------
+NOTE:  RIO and PCI are mutually exclusive, so they share an address
+
+For 32-bit u-boot, devices are mapped so that the virtual address ==
+the physical address, and the map looks liks this:
+
+	Memory Range			Device		Size
+	------------			------		----
+	0x0000_0000	0x7fff_ffff	DDR		2G
+	0x8000_0000	0x9fff_ffff	RIO MEM		512M
+	0x8000_0000	0x9fff_ffff	PCI1/PEX1 MEM	512M
+	0xa000_0000	0xbfff_ffff	PCI2/PEX2 MEM	512M
+	0xffe0_0000	0xffef_ffff	CCSR		1M
+	0xffdf_0000	0xffdf_7fff	PIXIS		8K
+	0xffdf_8000	0xffdf_ffff	CF		8K
+	0xf840_0000	0xf840_3fff	Stack space	32K
+	0xffc0_0000	0xffc0_ffff	PCI1/PEX1 IO	64K
+	0xffc1_0000	0xffc1_ffff	PCI2/PEX2 IO	64K
+	0xef80_0000	0xefff_ffff	Flash		8M
+
+For 36-bit-enabled u-boot, the virtual map is the same as for 32-bit.
+However, the physical map is altered to reside in 36-bit space, as follows.
+Addresses are no longer mapped with VA == PA.  All accesses from
+software use the VA; the PA is only used for setting up windows
+and mappings. Note that with the exception of PCI MEM and RIO, the low
+ 32 bits are the same as the VA above; only the top 4 bits vary:
+
+	Memory Range			Device		Size
+	------------			------		----
+	0x0_0000_0000	0x0_7fff_ffff	DDR		2G
+	0xc_0000_0000	0xc_1fff_ffff	RIO MEM		512M
+	0xc_0000_0000	0xc_1fff_ffff	PCI1/PEX1 MEM	512M
+	0xc_2000_0000	0xc_3fff_ffff	PCI2/PEX2 MEM	512M
+	0xf_ffe0_0000	0xf_ffef_ffff	CCSR		1M
+	0xf_ffdf_0000	0xf_ffdf_7fff	PIXIS		8K
+	0xf_ffdf_8000	0xf_ffdf_ffff	CF		8K
+	0x0_f840_0000	0xf_f840_3fff	Stack space	32K
+	0xf_ffc0_0000	0xf_ffc0_ffff	PCI1/PEX1 IO	64K
+	0xf_ffc1_0000	0xf_ffc1_ffff	PCI2/PEX2 IO	64K
+	0xf_ef80_0000	0xf_efff_ffff	Flash		8M
+
+5. pixis_reset command
+--------------------
+A new command, "pixis_reset", is introduced to reset mpc8641hpcn board
+using the FPGA sequencer.  When the board restarts, it has the option
+of using either the current or alternate flash bank as the boot
+image, with or without the watchdog timer enabled, and finally with
+or without frequency changes.
+
+Usage is;
+
+	pixis_reset
+	pixis_reset altbank
+	pixis_reset altbank wd
+	pixis_reset altbank cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+	pixis_reset cf <SYSCLK freq> <COREPLL ratio> <MPXPLL ratio>
+
+Examples;
+
+	/* reset to current bank, like "reset" command */
+	pixis_reset
+
+	/* reset board but use the to alternate flash bank */
+	pixis_reset altbank
+
+	/* reset board, use alternate flash bank with watchdog timer enabled*/
+	pixis_reset altbank wd
+
+	/* reset board to alternate bank with frequency changed.
+	 * 40 is SYSCLK, 2.5 is COREPLL ratio, 10 is MPXPLL ratio
+	 */
+	pixis-reset altbank cf 40 2.5 10
+
+Valid clock choices are in the 8641 Reference Manuals.
diff --git a/u-boot/doc/README.mvbc_p b/u-boot/doc/README.mvbc_p
new file mode 100644
index 0000000..e3fcb4e
--- /dev/null
+++ b/u-boot/doc/README.mvbc_p
@@ -0,0 +1,73 @@
+Matrix Vision mvBlueCOUGAR-P (mvBC-P)
+-------------------------------------
+
+1.	Board Description
+
+	The mvBC-P is a 70x40x40mm multi board gigabit ethernet network camera
+	with main focus on GigEVision protocol in combination with local image
+	preprocessing.
+
+	Power Supply is either VDC 48V or Pover over Ethernet (PoE).
+
+2	System Components
+
+2.1	CPU
+	Freescale MPC5200B CPU running at 400MHz core and 133MHz XLB/IPB.
+	64MB SDRAM @ 133MHz.
+	8 MByte Nor Flash on local bus.
+	1 serial ports. Console running on ttyS0 @ 115200 8N1.
+
+2.2	PCI
+	PCI clock fixed at 66MHz. Arbitration inside FPGA.
+	Intel GD82541ER network MAC/PHY and FPGA connected.
+
+2.3	FPGA
+	Altera Cyclone-II EP2C8 with PCI DMA engine.
+	Connects to Matrix Vision specific CCD/CMOS sensor interface.
+	Utilizes 64MB Nand Flash.
+
+2.3.1	I/O @ FPGA
+	2 Outputs : photo coupler
+	2 Inputs  : photo coupler
+
+2.4	I2C
+	LM75 @ 0x90 for temperature monitoring.
+	EEPROM @ 0xA0 for vendor specifics.
+	image sensor interface (slave adresses depend on sensor)
+
+3	Flash layout.
+
+	reset vector is 0x00000100, i.e. "LOWBOOT".
+
+	FF800000	u-boot
+	FF840000	u-boot script image
+	FF850000	redundant u-boot script image
+	FF860000	FPGA raw bit file
+	FF8A0000	tbd.
+	FF900000	root FS
+	FFC00000	kernel
+	FFFC0000	device tree blob
+	FFFD0000	redundant device tree blob
+	FFFE0000	environment
+	FFFF0000	redundant environment
+
+	mtd partitions are propagated to linux kernel via device tree blob.
+
+4	Booting
+
+	On startup the bootscript @ FF840000 is executed. This script can be
+	exchanged easily. Default boot mode is "boot from flash", i.e. system
+	works stand-alone.
+
+	This behaviour depends on some environment variables :
+
+	"netboot" : yes ->try dhcp/bootp and boot from network.
+	A "dhcp_client_id" and "dhcp_vendor-class-identifier" can be used for
+	DHCP server configuration, e.g. to provide different images to
+	different devices.
+
+	During netboot the system tries to get 3 image files:
+	1. Kernel - name + data is given during BOOTP.
+	2. Initrd - name is stored in "initrd_name"
+	3. device tree blob - name is stored in "dtb_name"
+	Fallback files are the flash versions.
diff --git a/u-boot/doc/README.mvblm7 b/u-boot/doc/README.mvblm7
new file mode 100644
index 0000000..3ee9396
--- /dev/null
+++ b/u-boot/doc/README.mvblm7
@@ -0,0 +1,84 @@
+Matrix Vision mvBlueLYNX-M7 (mvBL-M7)
+-------------------------------------
+
+1.	Board Description
+
+	The mvBL-M7 is a 120x120mm single board computing platform
+	with strong focus on stereo image processing applications.
+
+	Power Supply is either VDC 12-48V or Pover over Ethernet (PoE)
+	on any port (requires add-on board).
+
+2	System Components
+
+2.1	CPU
+	Freescale MPC8343VRAGDB CPU running at 400MHz core and 266MHz csb.
+	512MByte DDR-II memory @ 133MHz.
+	8 MByte Nor Flash on local bus.
+	2 Vitesse VSC8601 RGMII ethernet Phys.
+	1 USB host controller over ULPI I/F.
+	2 serial ports. Console running on ttyS0 @ 115200 8N1.
+	1 SD-Card slot connected to SPI.
+	System configuration (HRCW) is taken from I2C EEPROM.
+
+2.2	PCI
+	A miniPCI Type-III socket is present. PCI clock fixed at 66MHz.
+
+2.3	FPGA
+	Altera Cyclone-II EP2C20/35 with PCI DMA engines.
+	Connects to dual Matrix Vision specific CCD/CMOS sensor interfaces.
+	Utilizes another 256MB DDR-II memory and 32-128MB Nand Flash.
+
+2.3.1	I/O @ FPGA
+	2x8 Outputs : Infineon High-Side Switches to Main Supply.
+	2x8 Inputs  : Programmable input threshold + trigger capabilities
+	2 dedicated flash interfaces for illuminator boards.
+	Cross trigger for chaining several boards.
+
+2.4	I2C
+	Bus1:
+		MAX5381 DAC @ 0x60 for 1st digital input threshold.
+		LM75 @ 0x90 for temperature monitoring.
+		EEPROM @ 0xA0 for system setup (HRCW etc.) + vendor specifics.
+		1st image sensor interface (slave adresses depend on sensor)
+	Bus2:
+		MAX5381 DAC @ 0x60 for 2nd digital input threshold.
+		2nd image sensor interface (slave adresses depend on sensor)
+
+3	Flash layout.
+
+	reset vector is 0xFFF00100, i.e. "HIGHBOOT".
+
+	FF800000	environment
+	FF802000	redundant environment
+	FF804000	u-boot script image
+	FF806000	redundant u-boot script image
+	FF808000	device tree blob
+	FF80A000	redundant device tree blob
+	FF80C000	tbd.
+	FF80E000	tbd.
+	FF810000	kernel
+	FFC00000	root FS
+	FFF00000	u-boot
+	FFF80000	FPGA raw bit file
+
+	mtd partitions are propagated to linux kernel via device tree blob.
+
+4	Booting
+
+	On startup the bootscript @ FF804000 is executed. This script can be
+	exchanged easily. Default boot mode is "boot from flash", i.e. system
+	works stand-alone.
+
+	This behaviour depends on some environment variables :
+
+	"netboot" : yes ->try dhcp/bootp and boot from network.
+	A "dhcp_client_id" and "dhcp_vendor-class-identifier" can be used for
+	DHCP server configuration, e.g. to provide different images to
+	different devices.
+
+	During netboot the system tries to get 3 image files:
+	1. Kernel - name + data is given during BOOTP.
+	2. Initrd - name is stored in "initrd_name"
+	3. device tree blob - name is stored in "dtb_name"
+	Fallback files are the flash versions.
diff --git a/u-boot/doc/README.mvsmr b/u-boot/doc/README.mvsmr
new file mode 100644
index 0000000..d729ea6
--- /dev/null
+++ b/u-boot/doc/README.mvsmr
@@ -0,0 +1,55 @@
+Matrix Vision mvSMR
+-------------------
+
+1.	Board Description
+
+	The mvSMR is a 75x130mm single image processing board used
+	in automation. Power Supply is 24VDC.
+
+2	System Components
+
+2.1	CPU
+	Freescale MPC5200B CPU running at 400MHz core and 133MHz XLB/IPB.
+	64MB DDR-I @ 133MHz.
+	8 MByte Nor Flash on local bus.
+	2 serial ports. Console running on ttyS0 @ 115200 8N1.
+
+2.2	PCI
+	PCI clock fixed at 33MHz due to old'n'slow Xilinx PCI core.
+
+2.3	FPGA
+	Xilinx Spartan-3 XC3S200 with PCI DMA engine.
+	Connects to Matrix Vision specific CCD/CMOS sensor interface.
+
+2.4	I2C
+	EEPROM @ 0xA0 for vendor specifics.
+	image sensor interface (slave adresses depend on sensor)
+
+3	Flash layout.
+
+	reset vector is 0x00000100, i.e. "LOWBOOT".
+
+	FF800000	u-boot
+	FF806000	u-boot script image
+	FF808000	u-boot environment
+	FF840000	FPGA raw bit file
+	FF880000	root FS
+	FFF00000	kernel
+
+4	Booting
+
+	On startup the bootscript @ FF806000 is executed. This script can be
+	exchanged easily. Default boot mode is "boot from flash", i.e. system
+	works stand-alone.
+
+	This behaviour depends on some environment variables :
+
+	"netboot" : yes ->try dhcp/bootp and boot from network.
+	A "dhcp_client_id" and "dhcp_vendor-class-identifier" can be used for
+	DHCP server configuration, e.g. to provide different images to
+	different devices.
+
+	During netboot the system tries to get 3 image files:
+	1. Kernel - name + data is given during BOOTP.
+	2. Initrd - name is stored in "initrd_name"
+	Fallback files are the flash versions.
diff --git a/u-boot/doc/README.mx35pdk b/u-boot/doc/README.mx35pdk
new file mode 100644
index 0000000..3d69ed5
--- /dev/null
+++ b/u-boot/doc/README.mx35pdk
@@ -0,0 +1,188 @@
+Overview
+--------------
+
+mx35pdk (known als as mx35_3stack) is a development board by Freescale.
+It consists of three pluggable board:
+	- CPU module, with CPU, RAM, flash
+	- Personality board, with most interfaces (USB, Network,..)
+	- Debug board with JTAG header.
+
+The board is usually delivered with redboot. This howto explains how to boot
+a linux kernel and how to replace the original bootloader with U-Boot.
+
+The board is delivered with Redboot on the NAND flash. It is possible to
+switch the boot device with the switches SW1-SW2 on the Personality board,
+and with SW5-SW10 on the Debug board.
+
+Delivered Redboot script to start the kernel
+---------------------------------------------------
+
+In redboot the following script is stored:
+
+fis load kernel
+exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=dhcp fec_mac=00:04:9F:00:E7:76"
+
+Kernel is taken from flash. The image is in zImage format.
+
+Booting from NET, rootfs on NFS:
+-----------------------------------
+
+To change the script in redboot:
+
+load -r -b 0x100000 <path_to_zImage>
+exec -c "noinitrd console=ttymxc0,115200 root=/dev/nfsroot rootfstype=nfsroot nfsroot=192.168.1.1:/opt/eldk-4.2-arm/armVFP rw ip=dhcp"
+
+If the ip address is not set, you can set it with :
+
+ip_address -l <board_ip/netmask> -h <server_ip>
+
+Linux partitions:
+---------------------------
+
+As default, the board is shipped with these partition tables for NAND
+and for NOR:
+
+Creating 5 MTD partitions on "NAND 2GiB 3,3V 8-bit":
+0x00000000-0x00100000 : "nand.bootloader"
+0x00100000-0x00600000 : "nand.kernel"
+0x00600000-0x06600000 : "nand.rootfs"
+0x06600000-0x06e00000 : "nand.configure"
+0x06e00000-0x80000000 : "nand.userfs"
+
+Creating 6 MTD partitions on "mxc_nor_flash.0":
+0x00000000-0x00080000 : "Bootloader"
+0x00080000-0x00480000 : "nor.Kernel"
+0x00480000-0x02280000 : "nor.userfs"
+0x02280000-0x03e80000 : "nor.rootfs"
+0x01fe0000-0x01fe3000 : "FIS directory"
+0x01fff000-0x04000000 : "Redboot config"
+
+NAND partitions can be recognized enabling in kernel CONFIG_MTD_REDBOOT_PARTS.
+For this board, CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK should be set to 2.
+
+However, the setup in redboot is not correct and does not use the whole flash.
+
+Better solution is to use the kernel parameter mtdparts.
+Here the resulting script to be defined in RedBoot with fconfig:
+
+load -r -b 0x100000 sbabic/mx35pdk/zImage.2.6.37
+exec -c "noinitrd console=ttymxc0,115200 root=/dev/nfsroot rootfstype=nfsroot nfsroot=192.168.1.1:/opt/eldk-4.2-arm/arm rw ip=dhcp mtdparts=mxc_nand:1m(boot),5m(linux),96m(root),8m(cfg),1938m(user);physmap-flash.0:512k(b),4m(k),30m(u),28m(r)"
+
+Flashing U-Boot
+--------------------------------
+
+There are two options: the original bootloader in NAND can be replaced with
+u-boot, or u-boot can be stored on the NOR flash without erasing
+the delivered bootloader.
+The boot storage can be select using the switches on the personality board
+(SW1-SW2) and on the DEBUG board (SW4-SW10).
+
+The second option is to be preferred if you have not a JTAG debugger.
+If something goes wrong flashing the bootloader, it is always possible to
+recover the board booting from the other device.
+
+Replacing the bootloader on the NAND
+--------------------------------------
+To replace RedBoot with U-Boot, the easy way is to do this in linux.
+Start the kernel with the suggested options. Make sure to have set the
+mtdparts exactly as described, because this matches the layout on the
+mx35pdk.
+
+You should see in your boot log the following entries for the NAND
+flash:
+
+5 cmdlinepart partitions found on MTD device mxc_nand
+Creating 5 MTD partitions on "mxc_nand":
+0x000000000000-0x000000100000 : "boot"
+0x000000100000-0x000000600000 : "linux"
+0x000000600000-0x000006600000 : "root"
+0x000006600000-0x000006e00000 : "cfg"
+0x000006e00000-0x000080000000 : "user"
+
+You can use the utilities flash_eraseall and nandwrite to put
+u-boot on the NAND. The bootloader is marked as "boot", and 1MB is
+reserved. If everything is correct, this partition is accessed as
+/dev/mtd4. However, check if it is correct with "cat /proc/mtd" and
+get the device node from the partition name:
+
+$ cat /proc/mtd | grep boot
+
+I suggest you try the utilities on a different partition to be sure
+if everything works correctly. If not, and you remove RedBoot, you have to
+reinstall it using the ATK tool as suggested by Freescale, or using a
+JTAG debugger.
+
+I report the versions of the utilities I used (they are provided with ELDK):
+
+-bash-3.2# nandwrite --version
+nandwrite $Revision: 1.32 $
+
+flash_eraseall --version
+flash_eraseall $Revision: 1.22 $
+
+nandwrite reports a warning if the file to be saved is not sector aligned.
+This should have no consequences, but I preferred to pad u-boot.bin
+to get no problem at all.
+$ dd if=/dev/zero of=zeros bs=1 count=74800
+$ cat u-boot.bin zeros > u-boot-padded.bin
+
+To erase the partition:
+$ flash_eraseall /dev/mtd4
+
+Writing u-boot:
+
+$ nandwrite /dev/mtd4 u-boot-padded.bin
+
+Now U-Boot is stored on the booting partition.
+
+To boot from NAND, you have to select the switches as follows:
+
+Personality board
+	SW2	1, 4, 5 on
+		2, 3, 6, 7, 8 off
+	SW1	all off
+
+Debug Board:
+	SW5	0
+	SW6	0
+	SW7	0
+	SW8	1
+	SW9	1
+	SW10	0
+
+
+Saving U-Boot in the NOR flash
+---------------------------------
+
+The procedure to save in the NOR flash is quite the same as to write into the NAND.
+
+Check the partition for boot in the NOR flash. Setting the mtdparts as reported,
+the boot partition should be /dev/mtd0.
+
+Creating 6 MTD partitions on "mxc_nor_flash.0":
+0x00000000-0x00080000 : "Bootloader"
+0x00080000-0x00480000 : "nor.Kernel"
+0x00480000-0x02280000 : "nor.userfs"
+0x02280000-0x03e80000 : "nor.rootfs"
+0x01fe0000-0x01fe3000 : "FIS directory"
+0x01fff000-0x04000000 : "Redboot config"
+
+To erase the whole partition:
+$ flash_eraseall /dev/mtd0
+
+Writing u-boot:
+dd if=u-boot.bin of=/dev/mtd0
+
+To boot from NOR, you have to select the switches as follows:
+
+Personality board
+	SW2	all off
+	SW1	all off
+
+Debug Board:
+	SW5	0
+	SW6	0
+	SW7	0
+	SW8	1
+	SW9	1
+	SW10	0
diff --git a/u-boot/doc/README.nand b/u-boot/doc/README.nand
new file mode 100644
index 0000000..8eedb6c
--- /dev/null
+++ b/u-boot/doc/README.nand
@@ -0,0 +1,152 @@
+NAND FLASH commands and notes
+
+See NOTE below!!!
+
+# (C) Copyright 2003
+# Dave Ellis, SIXNET, dge@sixnetio.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+
+Commands:
+
+   nand bad
+      Print a list of all of the bad blocks in the current device.
+
+   nand device
+      Print information about the current NAND device.
+
+   nand device num
+      Make device `num' the current device and print information about it.
+
+   nand erase off|partition size
+   nand erase clean [off|partition size]
+      Erase `size' bytes starting at offset `off'. Alternatively partition
+      name can be specified, in this case size will be eventually limited
+      to not exceed partition size (this behaviour applies also to read
+      and write commands). Only complete erase blocks can be erased.
+
+      If `erase' is specified without an offset or size, the entire flash
+      is erased. If `erase' is specified with partition but without an
+      size, the entire partition is erased.
+
+      If `clean' is specified, a JFFS2-style clean marker is written to
+      each block after it is erased.
+
+      This command will not erase blocks that are marked bad. There is
+      a debug option in cmd_nand.c to allow bad blocks to be erased.
+      Please read the warning there before using it, as blocks marked
+      bad by the manufacturer must _NEVER_ be erased.
+
+   nand info
+      Print information about all of the NAND devices found.
+
+   nand read addr ofs|partition size
+      Read `size' bytes from `ofs' in NAND flash to `addr'.  Blocks that
+      are marked bad are skipped.  If a page cannot be read because an
+      uncorrectable data error is found, the command stops with an error.
+
+   nand read.oob addr ofs|partition size
+      Read `size' bytes from the out-of-band data area corresponding to
+      `ofs' in NAND flash to `addr'. This is limited to the 16 bytes of
+      data for one 512-byte page or 2 256-byte pages. There is no check
+      for bad blocks or ECC errors.
+
+   nand write addr ofs|partition size
+      Write `size' bytes from `addr' to `ofs' in NAND flash.  Blocks that
+      are marked bad are skipped.  If a page cannot be read because an
+      uncorrectable data error is found, the command stops with an error.
+
+      As JFFS2 skips blocks similarly, this allows writing a JFFS2 image,
+      as long as the image is short enough to fit even after skipping the
+      bad blocks.  Compact images, such as those produced by mkfs.jffs2
+      should work well, but loading an image copied from another flash is
+      going to be trouble if there are any bad blocks.
+
+   nand write.oob addr ofs|partition size
+      Write `size' bytes from `addr' to the out-of-band data area
+      corresponding to `ofs' in NAND flash. This is limited to the 16 bytes
+      of data for one 512-byte page or 2 256-byte pages. There is no check
+      for bad blocks.
+
+Configuration Options:
+
+   CONFIG_CMD_NAND
+      Enables NAND support and commmands.
+
+   CONFIG_MTD_NAND_ECC_JFFS2
+      Define this if you want the Error Correction Code information in
+      the out-of-band data to be formatted to match the JFFS2 file system.
+      CONFIG_MTD_NAND_ECC_YAFFS would be another useful choice for
+      someone to implement.
+
+   CONFIG_SYS_MAX_NAND_DEVICE
+      The maximum number of NAND devices you want to support.
+
+   CONFIG_SYS_NAND_MAX_CHIPS
+      The maximum number of NAND chips per device to be supported.
+
+NOTE:
+=====
+
+The current NAND implementation is based on what is in recent
+Linux kernels.  The old legacy implementation has been removed.
+
+If you have board code which used CONFIG_NAND_LEGACY, you'll need
+to convert to the current NAND interface for it to continue to work.
+
+The Disk On Chip driver is currently broken and has been for some time.
+There is a driver in drivers/mtd/nand, taken from Linux, that works with
+the current NAND system but has not yet been adapted to the u-boot
+environment.
+
+Additional improvements to the NAND subsystem by Guido Classen, 10-10-2006
+
+JFFS2 related commands:
+
+  implement "nand erase clean" and old "nand erase"
+  using both the new code which is able to skip bad blocks
+  "nand erase clean" additionally writes JFFS2-cleanmarkers in the oob.
+
+Miscellaneous and testing commands:
+  "markbad [offset]"
+  create an artificial bad block (for testing bad block handling)
+
+  "scrub [offset length]"
+  like "erase" but don't skip bad block. Instead erase them.
+  DANGEROUS!!! Factory set bad blocks will be lost. Use only
+  to remove artificial bad blocks created with the "markbad" command.
+
+
+NAND locking command (for chips with active LOCKPRE pin)
+
+  "nand lock"
+  set NAND chip to lock state (all pages locked)
+
+  "nand lock tight"
+  set NAND chip to lock tight state (software can't change locking anymore)
+
+  "nand lock status"
+  displays current locking status of all pages
+
+  "nand unlock [offset] [size]"
+  unlock consecutive area (can be called multiple times for different areas)
+
+
+I have tested the code with board containing 128MiB NAND large page chips
+and 32MiB small page chips.
diff --git a/u-boot/doc/README.nand-boot-ppc440 b/u-boot/doc/README.nand-boot-ppc440
new file mode 100644
index 0000000..1e9c102
--- /dev/null
+++ b/u-boot/doc/README.nand-boot-ppc440
@@ -0,0 +1,60 @@
+-----------------------------
+NAND boot on PPC440 platforms
+-----------------------------
+
+This document describes the U-Boot NAND boot feature as it
+is implemented for the AMCC Sequoia (PPC440EPx) board.
+
+The PPC440EP(x)/GR(x) cpu's can boot directly from NAND FLASH,
+completely without NOR FLASH. This can be done by using the NAND
+boot feature of the 440 NAND flash controller (NDFC).
+
+Here a short description of the different boot stages:
+
+a) IPL (Initial Program Loader, integrated inside CPU)
+------------------------------------------------------
+Will load first 4k from NAND (SPL) into cache and execute it from there.
+
+b) SPL (Secondary Program Loader)
+---------------------------------
+Will load special U-Boot version (NUB) from NAND and execute it. This SPL
+has to fit into 4kByte. It sets up the CPU and configures the SDRAM
+controller and the NAND controller so that the special U-Boot image can be
+loaded from NAND to SDRAM.
+This special image is build in the directory "nand_spl".
+
+c) NUB (NAND U-Boot)
+--------------------
+This NAND U-Boot (NUB) is a special U-Boot version which can be started
+from RAM. Therefore it mustn't (re-)configure the SDRAM controller.
+
+On 440EPx the SPL is copied to internal SRAM before the NAND controller
+is set up. While still running from cache, I experienced problems accessing
+the NAND controller.
+
+
+Example: Build and install NAND boot image for Sequoia (440EPx):
+
+a) Configure for sequoia with NAND boot support:
+# make sequoia_nand_config
+
+b) Build image(s)
+# make
+
+This will generate the SPL image in the "nand_spl" directory:
+nand_spl/u-boot-spl.bin
+Also another image is created spanning a whole NAND block (16kBytes):
+nand_spl/u-boot-spl-16k.bin
+The main NAND U-Boot image is generated in the toplevel directory:
+u-boot.bin
+A combined image of u-boot-spl-16k.bin and u-boot.bin is also created:
+u-boot-nand.bin
+
+This image should be programmed at offset 0 in the NAND flash:
+
+# tftp 100000 /tftpboot/sequoia/u-boot-nand.bin
+# nand erase 0 60000
+# nand write 100000 0 60000
+
+
+September 07 2006, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/README.ne2000 b/u-boot/doc/README.ne2000
new file mode 100644
index 0000000..d5ae9a9
--- /dev/null
+++ b/u-boot/doc/README.ne2000
@@ -0,0 +1,38 @@
+This driver supports NE2000 compatible cards (those based on DP8390,
+DP83902 and similar). It can be used with PCMCIA/CF cards provided
+that the CCR is correctly initialized.
+
+The code is based on sources from the Linux kernel (pcnet_cs.c,
+8390.h) and eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2
+wonderful world are GPL, so this is, of course, GPL.
+
+I developed and tested this driver on a custom PXA255 based system and
+with a billionton CF network card connected to the PCMCIA interface of
+the micro (have a look at README.PXA_CF for the support of this port).
+
+The options you have to specify in the config file are (with the
+value for my board as an example):
+
+#define CONFIG_DRIVER_NE2000
+
+- Enables the driver
+
+#define CONFIG_DRIVER_NE2000_BASE (0x20000000+0x300)
+
+- Address where the board is mapped
+
+#define CONFIG_DRIVER_NE2000_CCR (0x28000000+0x3f8)
+
+- Address of the CCR (card configuration register). It could be found
+by enabling DEBUG in cmd_pcmcia.c. If this is not defined nothing is
+done as far as PCMCIA support is concerned.
+
+#define CONFIG_DRIVER_NE2000_VAL (0x20)
+
+- The value to be written in the CCR. It selects among different I/O
+spaces that could be used by the card.
+
+
+Enjoy!
+
+Christian Pellegrin <chri@ascensit.com>
diff --git a/u-boot/doc/README.nhk8815 b/u-boot/doc/README.nhk8815
new file mode 100644
index 0000000..9008e39
--- /dev/null
+++ b/u-boot/doc/README.nhk8815
@@ -0,0 +1,32 @@
+
+The Nomadik 8815 CPU has a "secure" boot mode where no external access
+(not even JTAG) is allowed.  The "remap" bits in the evaluation board
+are configured in order to boot from the internal ROM memory (in
+secure mode).
+
+The boot process as defined by the manufacturer executes external code
+(loaded from NAND or OneNAND) that that disables such "security" in
+order to run u-boot and later the kernel without constraints. Such
+code is a proprietary initial boot loader, called "X-Loader" (in case
+anyone wonders, it has no relations with other loaders with the same
+name and there is no GPL code inside the ST X-Loader).
+
+SDRAM configuration, PLL setup and initial loading from NAND is
+implemented in the X-Loader, so U-Boot is already running in SDRAM
+when control is handed over to it.
+
+The Makefile offers two different configurations to be used if you
+boot from Nand or OneNand.
+
+    make nhk8815_config
+    make nhk8815_onenand_config
+
+Both support OneNand and Nand. Since U-Boot, running in RAM, can't know
+where it was loaded from, the configurations differ in where the filesystem
+is looked for by default.
+
+
+On www.st.com/nomadik and on www.stnwireless.com there are documents,
+summary data and white papers on Nomadik. The full datasheet for
+STn8815 is not currently available on line but under specific request
+to the local ST sales offices.
diff --git a/u-boot/doc/README.ns9750dev b/u-boot/doc/README.ns9750dev
new file mode 100644
index 0000000..2991440
--- /dev/null
+++ b/u-boot/doc/README.ns9750dev
@@ -0,0 +1,36 @@
+U-Boot Port to the NS9750 DevKit from NetSilicon
+
+1 Overview
+2 Board Configuration
+3 Installation
+
+
+1 Overview
+----------
+
+This port supports these NS9750 features.
+
+o one UART
+
+2 Board Configuration
+---------------------
+
+Switches:
+SW10: 4
+SW11: 6,7
+SW16: 6,7,8
+SW17-SW20: 1
+SW4: 3, 6
+SW 1: 1
+SW2: 4
+SW3: 3
+SW8: 3 (rotated by 180 degree!!!!)
+
+Serial Console is Port B (bottom right port)
+
+3 Installation
+--------------
+
+Have fun,
+--
+Markus Pietrek <mpietrek@fsforth.de>
diff --git a/u-boot/doc/README.ocotea b/u-boot/doc/README.ocotea
new file mode 100644
index 0000000..9ac3a18
--- /dev/null
+++ b/u-boot/doc/README.ocotea
@@ -0,0 +1,73 @@
+			   AMCC Ocotea Board
+
+		    Last Update: March 2, 2004
+=======================================================================
+
+This file contains some handy info regarding U-Boot and the AMCC
+Ocotea 440gx  evalutation board. See the README.ppc440 for additional
+information.
+
+
+SWITCH SETTINGS & JUMPERS
+==========================
+
+Here's what I've been using successfully. If you feel inclined to
+change things ... please read the docs!
+
+DIPSW   U46         U80
+------------------------
+SW 1    off         off
+SW 2    on          off
+SW 3    off         off
+SW 4    off         off
+SW 5    off         off
+SW 6    on          on
+SW 7    on          off
+SW 8    on          off
+
+J41: strapped
+J42: open
+
+All others are factory default.
+
+
+I2C Information
+=====================
+
+See README.ebony for information.
+
+PCI
+===========================
+
+Untested at the time of writing.
+
+PPC440GX Ethernet EMACs
+===========================
+
+All EMAC ports have been tested and are known to work
+with EPS Group 4.
+
+Special note about the Cicada CIS8201:
+	The CIS8201 Gigabit PHY comes up in GMII mode by default.
+	One must hit an extended register to allow use of RGMII mode.
+	This has been done in the 440gx_enet.c file with a #ifdef/endif
+	pair.
+
+AMCC does not store the EMAC ethernet addresses within their PIBS bootloader.
+The addresses contained in the config header file are from my particular
+board and you _*should*_ change them to reflect your board either in the
+config file and/or in your environment variables.  I found the addresses on
+labels on the bottom side of the board.
+
+
+BDI2k or JTAG Debugging
+===========================
+
+For ease of debugging you can swap the small boot flash and external SRAM
+by changing U46:3 to on.  You can then use the sram as your boot flash by
+loading the sram via the jtag debugger.
+
+
+Regards,
+--Travis
+<tsawyer@sandburst.com>
diff --git a/u-boot/doc/README.ocotea-PIBS-to-U-Boot b/u-boot/doc/README.ocotea-PIBS-to-U-Boot
new file mode 100644
index 0000000..25dd2a2
--- /dev/null
+++ b/u-boot/doc/README.ocotea-PIBS-to-U-Boot
@@ -0,0 +1,99 @@
+------------------------------------------
+Installation of U-Boot using PIBS firmware
+------------------------------------------
+
+This document describes how to install U-Boot on the Ocotea PPC440GX
+Evaluation Board. We do not erase the PIBS firmware but install U-Boot in the
+soldered FLASH. After this you should be able to switch between PIBS and
+U-Boot via the switch U46 SW1. Please check that SW1 is off (= open) before
+continuing.
+
+Connect to the serial port 0 (J11 lower) of the Ocotea board using the cu
+program. See the hints for configuring cu above. Make sure you can
+communicate with the PIBS firmware: reset the board and hit ENTER a couple of
+times until you see the PIBS prompt (PIBS $). Then proceed as follows:
+
+
+Read MAC Addresses from PIBS
+----------------------------
+
+To read the configured MAC addresses available on your Ocotea board please use
+the following commands:
+
+PIBS $ echo $hwdaddr0
+000173017FE3
+PIBS $ echo $hwdaddr1
+000173017FE4
+PIBS $ echo $hwdaddr2
+000173017FE1
+PIBS $ echo $hwdaddr3
+000173017FE2
+
+In U-Boot this is stored in the following environment variables:
+
+* Ethernet Address 0: ethaddr = 000173017FE3 (==> 00:01:73:01:7F:E3)
+* Ethernet Address 1: eth1addr = 000173017FE4 (==> 00:01:73:01:7F:E4)
+* Ethernet Address 2: eth2addr = 000173017FE1 (==> 00:01:73:01:7F:E1)
+* Ethernet Address 3: eth3addr = 000173017FE2 (==> 00:01:73:01:7F:E2)
+
+
+Configure the network interface (ent0 == emac0)
+-----------------------------------------------
+
+To download the U-Boot image we need to configure the ethernet interface with
+the following commands:
+
+PIBS $ ifconfig ent0 192.168.160.142 netmask 255.255.0.0 up
+PIBS $ set ipdstaddr0=192.168.1.1
+status: writing PIBS variable value to FLASH
+PIBS $ set bootfilename=/tftpboot/ocotea/u-boot.bin
+status: writing PIBS variable value to FLASH
+
+Please insert correct parameters for your configuration (ip-addresses and
+file-location).
+
+
+Program U-Boot into soldered User-FLASH
+---------------------------------------
+
+Please make sure to use a newer version of U-Boot (at least 1.1.3), since
+older versions don't support running from user-FLASH.
+
+To program U-Boot into the soldered user-FLASH use the following command:
+
+PIBS $ storefile bin eth 0xffbc0000
+
+This commands loads the file vis ethernet into ram and copies it into the
+user-FLASH.
+
+
+Switch to U-Boot
+----------------
+
+Now you can turn your board off and switch SW1 (U46) to on (= closed). After
+powering the board you should see the following message:
+
+U-Boot 1.1.3 (Apr  5 2005 - 22:59:57)
+
+AMCC PowerPC 440 GX Rev. C
+Board: AMCC 440GX Evaluation Board
+	VCO: 1066 MHz
+	CPU: 533 MHz
+	PLB: 152 MHz
+	OPB: 76 MHz
+	EPB: 76 MHz
+I2C:   ready
+DRAM:  256 MB
+FLASH:	5 MB
+PCI:   Bus Dev VenId DevId Class Int
+In:    serial
+Out:   serial
+Err:   serial
+KGDB:  kgdb ready
+ready
+Net:   ppc_440x_eth0, ppc_440x_eth1, ppc_440x_eth2, ppc_440x_eth3
+BEDBUG:ready
+=>
+
+
+April 06 2005, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/README.omap3 b/u-boot/doc/README.omap3
new file mode 100644
index 0000000..460950d
--- /dev/null
+++ b/u-boot/doc/README.omap3
@@ -0,0 +1,170 @@
+
+Summary
+=======
+
+This README is about U-Boot support for TI's ARM Cortex-A8 based OMAP3 [1]
+family of SoCs. TI's OMAP3 SoC family contains an ARM Cortex-A8. Additionally,
+some family members contain a TMS320C64x+ DSP and/or an Imagination SGX 2D/3D
+graphics processor and various other standard peripherals.
+
+Currently the following boards are supported:
+
+* OMAP3530 BeagleBoard [2]
+
+* Gumstix Overo [3]
+
+* TI EVM [4]
+
+* OpenPandora Ltd. Pandora [5]
+
+* TI/Logic PD Zoom MDK [6]
+
+* TI/Logic PD Zoom 2 [7]
+
+* CompuLab Ltd. CM-T35 [8]
+
+Toolchain
+=========
+
+While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
+with -march=armv5 to allow more compilers to work. For U-Boot code this has
+no performance impact.
+
+Build
+=====
+
+* BeagleBoard:
+
+make omap3_beagle_config
+make
+
+* Gumstix Overo:
+
+make omap3_overo_config
+make
+
+* TI EVM:
+
+make omap3_evm_config
+make
+
+* Pandora:
+
+make omap3_pandora_config
+make
+
+* Zoom MDK:
+
+make omap3_zoom1_config
+make
+
+* Zoom 2:
+
+make omap3_zoom2_config
+make
+
+* CM-T35:
+
+make cm_t35_config
+make
+
+Custom commands
+===============
+
+To make U-Boot for OMAP3 support NAND device SW or HW ECC calculation, U-Boot
+for OMAP3 supports custom user command
+
+nandecc hw/sw
+
+To be compatible with NAND drivers using SW ECC (e.g. kernel code)
+
+nandecc sw
+
+enables SW ECC calculation. HW ECC enabled with
+
+nandecc hw
+
+is typically used to write 2nd stage bootloader (known as 'x-loader') which is
+executed by OMAP3's boot rom and therefore has to be written with HW ECC.
+
+For all other commands see
+
+help
+
+Interfaces
+==========
+
+gpio
+
+To set a bit :
+
+	if (!omap_request_gpio(N)) {
+		omap_set_gpio_direction(N, 0);
+		omap_set_gpio_dataout(N, 1);
+	}
+
+To clear a bit :
+
+	if (!omap_request_gpio(N)) {
+		omap_set_gpio_direction(N, 0);
+		omap_set_gpio_dataout(N, 0);
+	}
+
+To read a bit :
+
+	if (!omap_request_gpio(N)) {
+		omap_set_gpio_direction(N, 1);
+		val = omap_get_gpio_datain(N);
+		omap_free_gpio(N);
+	}
+	if (val)
+		printf("GPIO N is set\n");
+	else
+		printf("GPIO N is clear\n");
+
+
+Acknowledgements
+================
+
+OMAP3 U-Boot is based on U-Boot tar ball [9] for BeagleBoard and EVM done by
+several TI employees.
+
+Links
+=====
+
+[1] OMAP3:
+
+http://www.ti.com/omap3 (high volume) and
+http://www.ti.com/omap35x (broad market)
+
+[2] OMAP3530 BeagleBoard:
+
+http://beagleboard.org/
+
+[3] Gumstix Overo:
+
+http://www.gumstix.net/Overo/
+
+[4] TI EVM:
+
+http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html
+
+[5] OpenPandora Ltd. Pandora:
+
+http://openpandora.org/
+
+[6] TI/Logic PD Zoom MDK:
+
+http://www.logicpd.com/products/devkit/ti/zoom_mobile_development_kit
+
+[7] TI/Logic PD Zoom 2
+
+http://www.logicpd.com/sites/default/files/1012659A_Zoom_OMAP34x-II_MDP_Brief.pdf
+
+[8] CompuLab Ltd. CM-T35:
+
+http://www.compulab.co.il/t3530/html/t3530-cm-datasheet.htm
+
+[9] TI OMAP3 U-Boot:
+
+http://beagleboard.googlecode.com/files/u-boot_beagle_revb.tar.gz
diff --git a/u-boot/doc/README.omap730p2 b/u-boot/doc/README.omap730p2
new file mode 100644
index 0000000..7c70916
--- /dev/null
+++ b/u-boot/doc/README.omap730p2
@@ -0,0 +1,91 @@
+
+		     u-boot for the TI OMAP730 Perseus2
+
+		      Dave Peverley, MPC-Data Limited
+			 http://www.mpc-data.co.uk
+
+
+Overview :
+
+ As the OMAP730 is similar to the OMAP1610 in many ways, this port was based
+on the u-boot port to the OMAP1610 Innovator. Supported features are :
+
+  - Serial terminal support
+  - Onboard NOR Flash
+  - Ethernet via the seperate debug board
+  - Tested on Rev4 and Rev5 boards
+
+ It has also been tested to work correctly when built with a 'standard' GCC
+3.2.1 cross-compiler as well as Montavista Linux CEE 3.1's toolchain.
+
+
+Hardware Configuration :
+
+ The main dips on the P2 board should be set to 2,3,7 and 9 on with all
+others off. On the debug board, dips 1 and 7 should be on with the rest off.
+The serial console has been set up to run from the DB9 connector on the
+P2 board at 115200 baud, 8 data bits, no stop bits, 1 parity bit.
+
+ It should be noted that the P2 board has NOR flash that is addressable via
+either CS0 or CS3. This mode can be changed via DIP9 on the P2 board.
+
+
+Installing u-boot for the P2 :
+
+ You can simply build u-boot for the Perseus by following the instructions
+in the main readme file. The target configuration is "omap730p2_config".
+Once u-boot has been built, you should strip the executable so it can be
+loaded via CCS (which cant cope with the symbols in the ELF binary) :
+  $ cp u-boot u-boot.out
+  $ arm-linux-strip u-boot.out
+
+ The method we've used for installing u-boot the first time on a P2 is
+as follows :
+
+1) Configure TI Code Composer Studio to connect to the P2 board via JTAG
+   as described in the Users Guide.
+
+2) Set up the P2 to boot from CS3, and connect with CCS. Reset the CPU
+   and run the "init_mmu" GEL script.
+
+3) Use the "Load Program" option to send the u-boot.out file to the P2 and
+   run.
+
+ At this point, u-boot should run and you will see the boot menu on your
+serial terminal. You can then load the u-boot image to memory :
+
+  # loadb 0x10000000
+
+ Send the "u-boot.bin" binary via the serial using Kermit. Once loaded
+you can self-flash u-boot :
+
+  # protect off 1:0
+  # erase 1:0
+  # cp.b 0x10000000 0x0 0x20000
+
+ You should now be able to reset the board and run u-boot from flash.
+
+
+Alternative flash option :
+
+ Sometimes, if you've been silly, you can get the board into a state where
+whats in flash has upset the board so much that you can no longer connect
+to the P2 via JTAG. However, you can set DIP9 to off to swap the boot mode
+of the P2 so that you boot from RAM instead of NOR flash. This moves NOR
+flash up to 0x0C000000. You can build a special version of u-boot to
+utilise this by the following config :
+
+  $ make omap730p2_cs0boot_config
+
+ If you load this up via CCS it will detect flash at its alternate location
+and allow you to programme your u-boot image (which, remember must be built
+for CS3 boot!) Once you do this, you can revert to CS3 boot and it will work
+fine again.
+
+
+Errata :
+
+1) It's been observed that sometimes the tftp transfer of kernels to the
+   board can have checksum errors or stall. This appears to be an issue
+   with the lan91c96.c driver, and can normally be worked around by
+   resetting the board and trying again.
diff --git a/u-boot/doc/README.p2020rdb b/u-boot/doc/README.p2020rdb
new file mode 100644
index 0000000..8a2302f
--- /dev/null
+++ b/u-boot/doc/README.p2020rdb
@@ -0,0 +1,145 @@
+Overview
+--------
+P2020RDB is a Low End Dual core platform supporting the P2020 processor
+of QorIQ series. P2020 is an e500 based dual core SOC.
+
+Building U-boot
+-----------
+To build the u-boot for P2020RDB:
+	make P2020RDB_config
+	make
+
+NOR Flash Banks
+-----------
+RDB board for P2020 has two flash banks. They are both present on boot.
+
+Booting by default is always from the boot bank at 0xef00_0000.
+
+Memory Map
+----------
+0xef00_0000 - 0xef7f_ffff	Alernate bank		8MB
+0xe800_0000 - 0xefff_ffff	Boot bank		8MB
+
+0xef78_0000 - 0xef7f_ffff	Alternate u-boot address	512KB
+0xeff8_0000 - 0xefff_ffff	Boot u-boot address		512KB
+
+Switch settings to boot from the NOR flash banks
+------------------------------------------------
+SW4[8]=0 default NOR Flash bank
+SW4[8]=1 Alternate NOR Flash bank
+
+Flashing Images
+---------------
+To place a new u-boot image in the alternate flash bank and then boot
+with that new image temporarily, use this:
+	tftp 1000000 u-boot.bin
+	erase ef780000 ef7fffff
+	cp.b 1000000 ef780000 80000
+
+Now to boot from the alternate bank change the SW4[8] from 0 to 1.
+
+To program the image in the boot flash bank:
+	tftp 1000000 u-boot.bin
+	protect off all
+	erase eff80000 ffffffff
+	cp.b 1000000 eff80000 80000
+
+Using the Device Tree Source File
+---------------------------------
+To create the DTB (Device Tree Binary) image file,
+use a command similar to this:
+
+	dtc -b 0 -f -I dts -O dtb p2020rdb.dts > p2020rdb.dtb
+
+Likely, that .dts file will come from here;
+
+	linux-2.6/arch/powerpc/boot/dts/p2020rdb.dts
+
+Booting Linux
+-------------
+Place a linux uImage in the TFTP disk area.
+
+	tftp 1000000 uImage.p2020rdb
+	tftp 2000000 rootfs.ext2.gz.uboot
+	tftp c00000 p2020rdb.dtb
+	bootm 1000000 2000000 c00000
+
+Implementing AMP(Asymmetric MultiProcessing)
+---------------------------------------------
+1. Build kernel image for core0:
+
+	a. $ make 85xx/p1_p2_rdb_defconfig
+
+	b. $ make menuconfig
+	   - un-select "Processor support"->
+		"Symetric multi-processing support"
+
+	c. $ make uImage
+
+	d. $ cp arch/powerpc/boot/uImage /tftpboot/uImage.core0
+
+2. Build kernel image for core1:
+
+	a. $ make 85xx/p1_p2_rdb_defconfig
+
+	b. $ make menuconfig
+	   - Un-select "Processor support"->
+		"Symetric multi-processing support"
+	   - Select "Advanced setup" ->
+		"Prompt for advanced kernel configuration options"
+		- Select
+			"Set physical address where the kernel is loaded"
+			and set it to 0x20000000, asssuming core1 will
+			start from 512MB.
+		- Select "Set custom page offset address"
+		- Select "Set custom kernel base address"
+		- Select "Set maximum low memory"
+	   - "Exit" and save the selection.
+
+	c. $ make uImage
+
+	d. $ cp arch/powerpc/boot/uImage /tftpboot/uImage.core1
+
+3. Create dtb for core0:
+
+	$ dtc -I dts -O dtb -f -b 0
+		 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts >
+		 /tftpboot/p2020rdb_camp_core0.dtb
+
+4. Create dtb for core1:
+
+	$ dtc -I dts -O dtb -f -b 1
+		 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts >
+		 /tftpboot/p2020rdb_camp_core1.dtb
+
+5. Bring up two cores separately:
+
+	a. Power on the board, under u-boot prompt:
+		=> setenv <serverip>
+		=> setenv <ipaddr>
+		=> setenv bootargs root=/dev/ram rw console=ttyS0,115200
+	b. Bring up core1's kernel first:
+		=> setenv bootm_low 0x20000000
+		=> setenv bootm_size 0x10000000
+		=> tftp 21000000 uImage.core1
+		=> tftp 22000000 ramdiskfile
+		=> tftp 20c00000 p2020rdb_camp_core1.dtb
+		=> interrupts off
+		=> bootm start 21000000 22000000 20c00000
+		=> bootm loados
+		=> bootm ramdisk
+		=> bootm fdt
+		=> fdt boardsetup
+		=> fdt chosen $initrd_start $initrd_end
+		=> bootm prep
+		=> cpu 1 release $bootm_low - $fdtaddr -
+	c. Bring up core0's kernel(on the same u-boot console):
+		=> setenv bootm_low 0
+		=> setenv bootm_size 0x20000000
+		=> tftp 1000000 uImage.core0
+		=> tftp 2000000 ramdiskfile
+		=> tftp c00000 p2020rdb_camp_core0.dtb
+		=> bootm 1000000 2000000 c00000
+
+Please note only core0 will run u-boot, core1 starts kernel directly
+after "cpu release" command is issued.
diff --git a/u-boot/doc/README.phytec.pcm030 b/u-boot/doc/README.phytec.pcm030
new file mode 100644
index 0000000..05faab6
--- /dev/null
+++ b/u-boot/doc/README.phytec.pcm030
@@ -0,0 +1,42 @@
+To build RAMBOOT, replace this section the main Makefile
+
+pcm030_config \
+pcm030_RAMBOOT_config \
+pcm030_LOWBOOT_config:	unconfig
+	@ >include/config.h
+	@[ -z "$(findstring LOWBOOT_,$@)" ] || \
+		{ echo "CONFIG_SYS_TEXT_BASE = 0xFF000000"	>board/phytec/pcm030/config.tmp ; \
+		  echo "... with LOWBOOT configuration" ; \
+		}
+	@[ -z "$(findstring RAMBOOT_,$@)" ] || \
+	       { echo "CONFIG_SYS_TEXT_BASE = 0x00100000" >board/phycore_mpc5200b_tiny/\
+			config.tmp ; \
+		 echo "... with RAMBOOT configuration" ; \
+		 echo "... remember to make sure that MBAR is already \
+				switched to 0xF0000000 !!!" ; \
+	       }
+	@$(MKCONFIG) -a pcm030 ppc mpc5xxx pcm030 phytec
+	@ echo "remember to set pcm030_REV to 0 for rev 1245.0 rev or to 1 for rev 1245.1"
+
+Alternative SDRAM settings:
+
+#define SDRAM_MODE	0x018D0000
+#define SDRAM_EMODE	0x40090000
+#define SDRAM_CONTROL	0x715f0f00
+#define SDRAM_CONFIG1	0x73722930
+#define SDRAM_CONFIG2	0x47770000
+
+/* Settings for XLB = 99 MHz */
+#define SDRAM_MODE	0x008D0000
+#define SDRAM_EMODE	0x40090000
+#define SDRAM_CONTROL	0x714b0f00
+#define SDRAM_CONFIG1	0x63611730
+#define SDRAM_CONFIG2	0x47670000
+
+The board ships default with the environment in EEPROM
+Moving the environment to flash can be more reliable
+
+#define CONFIG_ENV_IS_IN_FLASH	1
+#define CONFIG_ENV_ADDR		(CONFIG_SYS_FLASH_BASE + 0xfe0000)
+#define CONFIG_ENV_SIZE		0x20000
+#define CONFIG_ENV_SECT_SIZE	0x20000
diff --git a/u-boot/doc/README.ppc440 b/u-boot/doc/README.ppc440
new file mode 100644
index 0000000..dd8ccaa
--- /dev/null
+++ b/u-boot/doc/README.ppc440
@@ -0,0 +1,197 @@
+			   PowerPC 440
+
+		    Last Update: September 11, 2002
+=======================================================================
+
+
+OVERVIEW
+============
+
+Support for the ppc440 is contained in the cpu/ppc44x directory
+and enabled via the CONFIG_440 flag. It is largely based on the
+405gp code. A sample board support implementation is contained
+in the board/ebony directory.
+
+All testing was performed using the AMCC Ebony board using both
+Rev B and Rev C silicon. However, since the Rev B. silicon has
+extensive errata, support for Rev B. is minimal (it boots, and
+features such as i2c, pci, tftpboot, etc. seem to work ok).
+The expectation is that all new board designs will be using
+Rev C or later parts -- if not, you may be in for a rough ride ;-)
+
+The ppc440 port does a fair job of keeping "board-specific" code
+out of the "cpu-specific" source. The goal of course was to
+provide mechanisms for each board to customize without having
+to clutter the cpu-specific source with a lot of ifdefs. Most
+of these mechanisms are described in the following sections.
+
+
+MEMORY MANAGEMENT
+=================
+
+The ppc440 doesn't run in "real mode". The MMU must be active
+at all times. Additionally, the 440 implements a 36-bit physical
+memory space that gets mapped into the PowerPC 32-bit virtual
+address space. So things like memory-mapped peripherals, etc must
+all be mapped in. Once this is done, the 32-bit virtual address
+space is then viewed as though it were physical memory.
+
+However, this means that memory, peripherals, etc can be configured
+to appear (mostly) anywhere in the virtual address space. Each board
+must define its own mappings using the tlbtab (see board/ebony/init.S).
+The actual TLB setup is performed by the cpu-specific code.
+
+Although each board is free to define its own mappings, there are
+several definitions to be aware of. These definitions may be used in
+the cpu-specific code (vs. board-specific code), so you should
+at least review these before deciding to make any changes ... it
+will probably save you some headaches ;-)
+
+CONFIG_SYS_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)
+
+CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped.
+
+CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
+    This mapping provides access to PCI-bus memory.
+
+CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
+    peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).
+
+CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is
+    mapped. The internal SRAM is equivalent to 405gp OCM and is used
+    for the initial stack.
+
+CONFIG_SYS_PCI_BASE - The virtual address where the 440 PCI-x bridge config
+    registers are mapped.
+
+CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address
+    defined by CONFIG_SYS_PCI_MEMBASE.
+
+
+UART / SERIAL
+=================
+
+The UART port works fine when an external serial clock is provided
+(like the one on the Ebony board) and when using internal clocking.
+This is controlled with the CONFIG_SYS_EXT_SERIAL_CLOCK flag. When using
+internal clocking, the "ideal baud rate" settings in the 440GP
+user manual are automatically calculated.
+
+
+I2C
+=================
+
+The i2c utilities have been tested on both Rev B. and Rev C. and
+look good. The 'i2c probe' command implementation has been updated to
+allow for 'skipped' addresses. Some i2c slaves are write only and
+cause problems when a probe (read) is performed (for example the
+CDCV850 clock controller at address 0x69 on the ebony board).
+
+To prevent probing certain addresses you can define the
+CONFIG_SYS_I2C_NOPROBES macro in your board-specific header file. When
+defined, all specified addresses are skipped during a probe.
+The addresses that are skipped will be displayed in the output
+of the 'i2c probe' command.
+
+For example, to prevent probing address 0x69, define the macro as
+follows:
+
+#define CONFIG_SYS_I2C_NOPROBES {0x69}
+
+Similarly, to prevent probing addresses 0x69 and 0x70, define the
+macro a:
+
+#define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70}
+
+
+DDR SDRAM CONTROLLER
+====================
+
+SDRAM controller intialization using Serial Presence Detect (SPD) is
+now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
+The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.
+
+NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
+processors. Traditionally, it defined a single address. For the 440 it
+defines an array of addresses to support multiple banks. Address order
+is significant: the addresses are used in order to program the BankN
+registers. For example, two banks with i2c addresses of 0x53 (bank 0)
+and 0x52 (bank 1) would be defined as follows:
+
+#define SPD_EEPROM_ADDRESS {0x53,0x52}
+
+
+PCI-X BRIDGE
+====================
+
+PCI is an area that requires lots of flexibility since every board has
+its own set of constraints and configuration. This section describes the
+440 implementation.
+
+CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
+is aborted and an indication is printed. This is NOT considered an
+error -- only an indication that PCI shouldn't be initialized. This
+gives you a chance to edit the i2c bootstrap eeproms using the i2c
+utilities once you get to the U-Boot command prompt. NOTE: the default
+440 bootstrap options (not using i2c eeprom) negates this bit.
+
+The cpu-specific code sets up a default pci_controller structure
+that maps in a single PCI I/O space and PCI memory space. The I/O
+space begins at PCI I/O address 0 and the PCI memory space is
+256 MB starting at PCI address CONFIG_SYS_PCI_TARGBASE. After the
+pci_controller structure is initialized, the cpu-specific code will
+call the routine pci_pre_init(). This routine is implemented by
+board-specific code & is where the board can over-ride/extend the
+default pci_controller structure settings and exspecially provide
+a routine to map the PCI interrupts and do other pre-initialization
+tasks. If pci_pre_init() returns a value of zero, PCI initialization
+is aborted; otherwise the controller structure is registered and
+initialization continues.
+
+The default 440GP PCI target configuration is minimal -- it assumes that
+the strapping registers are set as necessary. Since the strapping bits
+provide very limited flexibility, you may want to customize the boards
+target configuration. If CONFIG_SYS_PCI_TARGET_INIT is defined, the cpu-specific
+code will call the routine pci_target_init() which you must implement
+in your board-specific code.
+
+Target initialization is completed by the cpu-specific code by
+initializing the subsystem id and subsystem vendor id, and then ensuring
+that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.
+
+The default PCI master initialization maps in 256 MB of pci memory
+starting at PCI address CONFIG_SYS_PCI_MEMBASE. To customize this, define
+PCI_MASTER_INIT. This will call the routine pci_master_init() in your
+board-specific code rather than performing the default master
+initialization.
+
+The decision to perform PCI host configuration must often be determined
+at run time. The ppc440 port differs from most other implementations in
+that it requires the board to determine its host configuration at run
+time rather than by using compile-time flags. This shouldn't create a
+large impact on the board-specific code since the board only needs to
+implement a single routine that returns a zero or non-zero value:
+is_pci_host().
+
+Justification for this becomes clear when considering systems running
+in a cPCI environment:
+
+1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
+part of the PCI-to-PCI bridge). Even though the arbiter is external (the
+arbiter strapping is negated), the CPU may still be required to perform
+local PCI bus configuration.
+
+2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
+Depending on the configuration of the carrier boar, the PPMC board must
+determine if it should configure the PCI bus at run-time. And in most
+cases, access to the MONARCH# signal is board-specific (e.g. via
+board-specific FPGA registers, etc).
+
+In any event, the is_pci_host() routine gives each board the opportunity
+to decide at run-time. If your board is always configured a certain way,
+then just hardcode a return of 1 or 0 as appropriate.
+
+
+Regards,
+--Scott
+<smcnutt@artesyncp.com>
diff --git a/u-boot/doc/README.qemu_mips b/u-boot/doc/README.qemu_mips
new file mode 100644
index 0000000..3985264
--- /dev/null
+++ b/u-boot/doc/README.qemu_mips
@@ -0,0 +1,164 @@
+
+Notes for the Qemu MIPS port
+
+I) Example usage:
+
+# ln -s u-boot.bin mips_bios.bin
+start it:
+qemu-system-mips -L . /dev/null -nographic
+
+or
+
+if you use a qemu version after commit 4224
+
+create image:
+# dd of=flash bs=1k count=4k if=/dev/zero
+# dd of=flash bs=1k conv=notrunc if=u-boot.bin
+start it:
+# qemu-system-mips -M mips -pflash flash -monitor null -nographic
+
+2) Download kernel + initrd
+
+On ftp://ftp.denx.de/pub/contrib/Jean-Christophe_Plagniol-Villard/qemu_mips/
+you can downland
+
+#config to build the kernel
+qemu_mips_defconfig
+#patch to fix mips interupt init on 2.6.24.y kernel
+qemu_mips_kernel.patch
+initrd.gz
+vmlinux
+vmlinux.bin
+System.map
+
+4) Generate uImage
+
+# tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x80010000 -e 0x80245650 -n "Linux 2.6.24.y" -d vmlinux.bin.gz uImage
+
+5) Copy uImage to Flash
+# dd if=uImage bs=1k conv=notrunc seek=224 of=flash
+
+6) Generate Ide Disk
+
+# dd of=ide bs=1k cout=100k if=/dev/zero
+
+# sfdisk -C 261 -d ide
+# partition table of ide
+unit: sectors
+
+     ide1 : start=       63, size=    32067, Id=83
+     ide2 : start=    32130, size=    32130, Id=83
+     ide3 : start=    64260, size=  4128705, Id=83
+     ide4 : start=        0, size=        0, Id= 0
+
+7) Copy to ide
+
+# dd if=uImage bs=512 conv=notrunc seek=63 of=ide
+
+8) Generate ext2 on part 2 on Copy uImage and initrd.gz
+
+# Attached as loop device ide offset = 32130 * 512
+# losetup -o 16450560 -f ide
+# Format as ext2 ( arg2 : nb blocks)
+# mke2fs /dev/loop0 16065
+# losetup -d /dev/loop0
+# Mount and copy uImage and initrd.gz to it
+# mount -o loop,offset=16450560 -t ext2 ide /mnt
+# mkdir /mnt/boot
+# cp {initrd.gz,uImage} /mnt/boot/
+# Umount it
+# umount /mnt
+
+9) Set Environment
+
+setenv rd_start 0x80800000
+setenv rd_size 2663940
+setenv kernel BFC38000
+setenv oad_addr 80500000
+setenv load_addr2 80F00000
+setenv kernel_flash BFC38000
+setenv load_addr_hello 80200000
+setenv bootargs 'root=/dev/ram0 init=/bin/sh'
+setenv load_rd_ext2 'ide res; ext2load ide 0:2 ${rd_start} /boot/initrd.gz'
+setenv load_rd_tftp 'tftp ${rd_start} /initrd.gz'
+setenv load_kernel_hda 'ide res; diskboot ${load_addr} 0:2'
+setenv load_kernel_ext2 'ide res; ext2load ide 0:2 ${load_addr} /boot/uImage'
+setenv load_kernel_tftp 'tftp ${load_addr} /qemu_mips/uImage'
+setenv boot_ext2_ext2 'run load_rd_ext2; run load_kernel_ext2; run addmisc; bootm ${load_addr}'
+setenv boot_ext2_flash 'run load_rd_ext2; run addmisc; bootm ${kernel_flash}'
+setenv boot_ext2_hda 'run load_rd_ext2; run load_kernel_hda; run addmisc; bootm ${load_addr}'
+setenv boot_ext2_tftp 'run load_rd_ext2; run load_kernel_tftp; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_hda 'run load_rd_tftp; run load_kernel_hda; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_ext2 'run load_rd_tftp; run load_kernel_ext2; run addmisc; bootm ${load_addr}'
+setenv boot_tftp_flash 'run load_rd_tftp; run addmisc; bootm ${kernel_flash}'
+setenv boot_tftp_tftp 'run load_rd_tftp; run load_kernel_tftp; run addmisc; bootm ${load_addr}'
+setenv load_hello_tftp 'tftp ${load_addr_hello} /examples/hello_world.bin'
+setenv go_tftp 'run load_hello_tftp; go ${load_addr_hello}'
+setenv addmisc 'setenv bootargs ${bootargs} console=ttyS0,${baudrate} rd_start=${rd_start} rd_size=${rd_size} ethaddr=${ethaddr}'
+setenv bootcmd 'run boot_tftp_flash'
+
+10) Now you can boot from flash, ide, ide+ext2 and tfp
+
+# qemu-system-mips -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide
+
+II) How to debug U-Boot
+
+In order to debug U-Boot you need to start qemu with gdb server support (-s)
+and waiting the connection to start the CPU (-S)
+
+# qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide
+
+in an other console you start gdb
+
+1) Debugging of U-Boot Before Relocation
+
+Before relocation, the addresses in the ELF file can be used without any problems
+by connecting to the gdb server localhost:1234
+
+# mipsel-unknown-linux-gnu-gdb u-boot
+GNU gdb 6.6
+Copyright (C) 2006 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB.  Type "show warranty" for details.
+This GDB was configured as "--host=i486-linux-gnu --target=mipsel-unknown-linux-gnu"...
+(gdb)  target remote localhost:1234
+Remote debugging using localhost:1234
+_start () at start.S:64
+64		RVECENT(reset,0)	/* U-boot entry point */
+Current language:  auto; currently asm
+(gdb)  b board.c:289
+Breakpoint 1 at 0xbfc00cc8: file board.c, line 289.
+(gdb) c
+Continuing.
+
+Breakpoint 1, board_init_f (bootflag=<value optimized out>) at board.c:290
+290		relocate_code (addr_sp, id, addr);
+Current language:  auto; currently c
+(gdb) p/x addr
+$1 = 0x87fa0000
+
+2) Debugging of U-Boot After Relocation
+
+For debugging U-Boot after relocation we need to know the address to which
+U-Boot relocates itself to 0x87fa0000 by default.
+And replace the symbol table to this offset.
+
+(gdb) symbol-file
+Discard symbol table from `/private/u-boot-arm/u-boot'? (y or n) y
+Error in re-setting breakpoint 1:
+No symbol table is loaded.  Use the "file" command.
+No symbol file now.
+(gdb) add-symbol-file u-boot 0x87fa0000
+add symbol table from file "u-boot" at
+	.text_addr = 0x87fa0000
+(y or n) y
+Reading symbols from /private/u-boot-arm/u-boot...done.
+Breakpoint 1 at 0x87fa0cc8: file board.c, line 289.
+(gdb) c
+Continuing.
+
+Program received signal SIGINT, Interrupt.
+0xffffffff87fa0de4 in udelay (usec=<value optimized out>) at time.c:78
+78		while ((tmo - read_c0_count()) < 0x7fffffff)
diff --git a/u-boot/doc/README.s5pc1xx b/u-boot/doc/README.s5pc1xx
new file mode 100644
index 0000000..ab1f024
--- /dev/null
+++ b/u-boot/doc/README.s5pc1xx
@@ -0,0 +1,72 @@
+
+Summary
+=======
+
+This README is about U-Boot support for SAMSUNG's ARM Cortex-A8 based S5PC1xx
+family of SoCs (S5PC100 [1] and S5PC110).
+
+Currently the following board is supported:
+
+* SMDKC100 [2]
+
+Toolchain
+=========
+
+While ARM Cortex-A8 support ARM v7 instruction set (-march=armv7a) we compile
+with -march=armv5 to allow more compilers to work. For U-Boot code this has
+no performance impact.
+
+Build
+=====
+
+* SMDKC100
+
+make smdkc100_config
+make
+
+
+Interfaces
+==========
+
+cpu
+
+To check SoC:
+
+	if (cpu_is_s5pc100())
+		printf("cpu is s5pc100\n");
+
+	or
+
+	if (cpu_is_s5pc110())
+		printf("cpu is s5pc110\n");
+
+gpio
+
+	struct s5pc100_gpio *gpio = (struct s5pc100_gpio*)S5PC100_GPIO_BASE;
+
+	/* GPA[0] pin set to irq */
+	gpio_cfg_pin(&gpio->gpio_a, 0, GPIO_IRQ);
+
+	/* GPA[0] pin set to input */
+	gpio_direction_input(&gpio->gpio_a, 0);
+
+	/* GPA[0] pin set to output/high */
+	gpio_direction_output(&gpio->gpio_a, 0, 1);
+
+	/* GPA[0] value set to low */
+	gpio_set_value(&gpio->gpio_a, 0, 0);
+
+	/* get GPA[0] value */
+	value = gpio_get_value(&gpio->gpio_a, 0);
+
+Links
+=====
+
+[1] S5PC100:
+
+http://www.samsung.com/global/business/semiconductor/productInfo.do?
+fmly_id=229&partnum=S5PC100
+
+[2] SMDKC100:
+
+http://meritech.co.kr/eng/products/product_view.php?num=28
diff --git a/u-boot/doc/README.sata b/u-boot/doc/README.sata
new file mode 100644
index 0000000..d0ce667
--- /dev/null
+++ b/u-boot/doc/README.sata
@@ -0,0 +1,68 @@
+1. SATA usage in U-boot
+
+	There are two ways to operate the hard disk
+
+	* Read/write raw blocks from/to SATA hard disk
+	* ext2load to read a file from ext2 file system
+
+1.0 How to read the SATA hard disk's information?
+
+	=> sata info
+
+SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#:		4QF01ZTN
+	    Type: Hard Disk
+	    Supports 48-bit addressing
+	    Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
+
+1.1 How to raw write the kernel, file system, dtb to a SATA hard disk?
+
+	Notes: Hard disk sectors are normally 512 bytes, so
+		0x1000 sectors = 2 MBytes
+
+	write kernel
+	=> tftp 40000 /tftpboot/uImage.837x
+	=> sata write 40000 0 2000
+
+	write ramdisk
+	=> tftp 40000 /tftpboot/ramdisk.837x
+	=> sata write 40000 2000 8000
+
+	write dtb
+	=> tftp 40000 /tftpboot/mpc837xemds.dtb
+	=> sata write 40000 a000 1000
+
+1.2 How to raw read the kernel, file system, dtb from a SATA hard disk?
+
+	load kernel
+	=> sata read 200000 0 2000
+
+	load ramdisk
+	=> sata read 1000000 2000 8000
+
+	load dtb
+	=> sata read 2000000 a000 1000
+
+	boot
+	=> bootm 200000 1000000 2000000
+
+1.3 How to load an image from an ext2 file system in U-boot?
+
+	U-boot doesn't support writing to an ext2 file system, so the
+	files must be written by other means (e.g. linux).
+
+	=> ext2ls sata 0:1 /
+	<DIR>	    4096 .
+	<DIR>	    4096 ..
+	<DIR>	   16384 lost+found
+		 1352023 uImage.837x
+		 3646377 ramdisk.837x
+		   12288 mpc837xemds.dtb
+		      12 hello.txt
+
+	=> ext2load sata 0:1 200000 /uImage.837x
+
+	=> ext2load sata 0:1 1000000 /ramdisk.837x
+
+	=> ext2load sata 0:1 2000000 /mpc837xemds.dtb
+
+	=> bootm 200000 1000000 2000000
diff --git a/u-boot/doc/README.sbc8349 b/u-boot/doc/README.sbc8349
new file mode 100644
index 0000000..2c35919
--- /dev/null
+++ b/u-boot/doc/README.sbc8349
@@ -0,0 +1,127 @@
+
+
+	U-Boot for Wind River SBC834x Boards
+	====================================
+
+
+The Wind River SBC834x board is a 6U form factor (not CPCI) reference
+design that uses the MPC8347E or MPC8349E processor.  U-Boot support
+for this board is heavily based on the existing U-Boot support for
+Freescale MPC8349 reference boards.
+
+Support has been primarily tested on the SBC8349 version of the board,
+although earlier versions were also tested on the SBC8347.  The primary
+difference in the two is the level of PCI functionality.
+
+	http://www.windriver.com/products/OCD/SBC8347E_49E/
+
+
+Flash Details:
+==============
+
+The flash type is intel 28F640Jx (4096x16) [one device].  Base address
+is 0xFF80_0000 which is also where the Hardware Reset Configuration
+Word (HRCW) is stored.  Caution should be used to not reset the
+board without having a valid HRCW in place (i.e. erased flash) as
+then a Wind River ICE will be required to restore the HRCW and flash
+image.
+
+
+Restoring a corrupted or missing flash image:
+=============================================
+
+Note that U-boot versions up to and including 2009.06 had essentially
+two copies of u-boot in flash; one at the very beginning, which set
+the HRCW, and one at the very end, which was the image that was run.
+As of this point in time, the two have been combined into just one
+at the beginning of flash, which provides both the HRCW, and the image
+that is executed.  This frees up the remainder of flash for other uses.
+Use of the u-boot command "fli" will indicate what parts are in use.
+Details for storing U-boot to flash using a Wind River ICE can be found
+on page 19 of the board manual (request ERG-00328-001).  The following
+is a summary of that information:
+
+  - Connect ICE and establish connection to it from WorkBench/OCD.
+  - Ensure you have background mode (BKM) in the OCD terminal window.
+  - Select the appropriate flash type (listed above)
+  - Prepare a u-boot image by using the Wind River Convert utility;
+    by using "Convert and Add file" on the ELF file from your build.
+    Convert from FF80_0000 to FFFF_FFFF (or to FF83_FFFF if you are
+    trying to preserve your old environment settings and user flash).
+  - Set the start address of the erase/flash process to FF80_0000
+  - Set the target RAM required to 64kB.
+  - Select sectors for erasing (see note on enviroment below)
+  - Select Erase and Reprogram.
+
+Note that some versions of the register files used with Workbench
+would zero some TSEC registers, which inhibits ethernet operation
+by u-boot when this register file is played to the target.  Using
+"INN" in the OCD terminal window instead of "IN" before the "GO"
+will not play the register file, and allow u-boot to use the TSEC
+interface while executed from the ICE "GO" command.
+
+Alternatively, you can locate the register file which will be named
+WRS_SBC8349_PCT00328001.reg or similar) and "REM" out all the lines
+beginning with "SCGA TSEC1" and "SCGA TSEC2".  This allows you to
+use all the remaining register file content.
+
+If you wish to preserve your prior U-Boot environment settings,
+then convert (and erase to) 0xFF83FFFF instead of 0xFFFFFFFF.
+The size for converting (and erasing) must be at least as large
+as u-boot.bin.
+
+
+Updating U-Boot with U-Boot:
+============================
+
+This procedure is very similar to other boards that have u-boot installed.
+Assuming that the network has been configured, and that the new u-boot.bin
+has been copied to the TFTP server, the commands are:
+
+	tftp 200000 u-boot.bin
+	protect off all
+	erase ff800000 ff83ffff
+	cp.b 200000 ff800000 40000
+	protect on all
+
+You may wish to do a "md ff800000 20" operation as a prefix and postfix
+to the above steps to inspect/compare the HRCW before/after as an extra
+safety check before resetting the board upon completion of the reflash.
+
+PCI:
+====
+
+There are three configuration choices:
+	sbc8349_config
+	sbc8349_PCI_33_config
+	sbc8349_PCI_66_config
+
+The 1st does not enable CONFIG_PCI, and assumes that the PCI slot
+will be left empty (M66EN high), and so the board will operate with
+a base clock of 66MHz.  Note that you need both PCI enabled in u-boot
+and linux in order to have functional PCI under linux.  The only
+reason for choosing to not enable PCI would be if you had a very
+early (rev 1.0) CPU with possible PCI issues.
+
+The second enables PCI support and builds for a 33MHz clock rate.  Note
+that if a 33MHz 32bit card is inserted in the slot, then the whole board
+will clock down to a 33MHz base clock instead of the default 66MHz.  This
+will change the baud clocks and mess up your serial console output if you
+were previously running at 66MHz.  If you want to use a 33MHz PCI card,
+then you should build a U-Boot with sbc8349_PCI_33_config and store this
+to flash prior to powering down the board and inserting the 33MHz PCI
+card.
+
+The third option builds PCI support in, and leaves the clocking at the
+default 66MHz.  This has been tested with an intel PCI-X e1000 card.
+This is also the appropriate choice for people with a recent (non 1.0)
+CPU who currently have the PCI slot physically empty, but intend to
+possibly add a PCI-X card at a later date.
+
+   => pci
+   Scanning PCI devices on bus 0
+   BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
+   _____________________________________________________________
+   00.00.00   0x1957     0x0080     Processor               0x20
+   00.11.00   0x8086     0x1026     Network controller      0x00
+   =>
diff --git a/u-boot/doc/README.sbc8548 b/u-boot/doc/README.sbc8548
new file mode 100644
index 0000000..6cbe12f
--- /dev/null
+++ b/u-boot/doc/README.sbc8548
@@ -0,0 +1,200 @@
+Intro:
+======
+
+The SBC8548 is a stand alone single board computer with a 1GHz
+MPC8548 CPU, 8MB boot flash, 64MB user flash and, 256MB DDR2 400MHz
+memory. It also has 128MB SDRAM 100MHz LBC memory, with both a PCI-e,
+and a PCI-X slot, dual mini-DB9 for UART, and dual RJ-45 for eTSEC
+ethernet connections.
+
+U-boot Configuration:
+=====================
+
+The following possible u-boot configuration targets are available:
+
+	1) sbc8548_config
+	2) sbc8548_PCI_33_config
+	3) sbc8548_PCI_66_config
+	4) sbc8548_PCI_33_PCIE_config
+	5) sbc8548_PCI_66_PCIE_config
+
+Generally speaking, most people should choose to use #5.  Details
+of each choice are listed below.
+
+Choice #1 does not enable CONFIG_PCI, and assumes that the PCI slot
+will be left empty (M66EN high), and so the board will operate with
+a base clock of 66MHz.  Note that you need both PCI enabled in u-boot
+and linux in order to have functional PCI under linux.
+
+The second enables PCI support and builds for a 33MHz clock rate.  Note
+that if a 33MHz 32bit card is inserted in the slot, then the whole board
+will clock down to a 33MHz base clock instead of the default 66MHz.  This
+will change the baud clocks and mess up your serial console output if you
+were previously running at 66MHz.  If you want to use a 33MHz PCI card,
+then you should build a U-Boot with a _PCI_33_ config and store this
+to flash prior to powering down the board and inserting the 33MHz PCI
+card. [The above discussion assumes that the SW2[1-4] has not been changed
+to reflect a different CCB:SYSCLK ratio]
+
+The third option builds PCI support in, and leaves the clocking at the
+default 66MHz.  Options four and five are just repeats of option two
+and three, but with PCI-e support enabled as well.
+
+PCI output listing with an intel e1000 PCI-x and a Syskonnect SK-9Exx
+is shown below for sbc8548_PCI_66_PCIE_config.  (Note that PCI-e with
+a 33MHz PCI configuration is currently untested.)
+
+    => pci 0
+    Scanning PCI devices on bus 0
+    BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
+    _____________________________________________________________
+    00.00.00   0x1057     0x0012     Processor               0x20
+    00.01.00   0x8086     0x1026     Network controller      0x00
+    => pci 1
+    Scanning PCI devices on bus 1
+    BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
+    _____________________________________________________________
+    01.00.00   0x1957     0x0012     Processor               0x20
+    => pci 2
+    Scanning PCI devices on bus 2
+    BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
+    _____________________________________________________________
+    02.00.00   0x1148     0x9e00     Network controller      0x00
+    =>
+
+
+Updating U-boot with U-boot:
+============================
+
+Note that versions of u-boot up to and including 2009.08 had u-boot stored
+at 0xfff8_0000 -> 0xffff_ffff (512k).  Currently it is being stored from
+0xfffa_0000 -> 0xffff_ffff (384k).  If you use an old macro/script to
+update u-boot with u-boot and it uses the old address, you will render
+your board inoperable, and you will require JTAG recovery.
+
+The following steps list how to update with the current address:
+
+	tftp u-boot.bin
+	md 200000 10
+	protect off all
+	erase fffa0000 ffffffff
+	cp.b 200000 fffa0000 60000
+	md fffa0000 10
+	protect on all
+
+The "md" steps in the above are just a precautionary step that allow
+you to confirm the u-boot version that was downloaded, and then confirm
+that it was copied to flash.
+
+
+Hardware Reference:
+===================
+
+The following contains some summary information on hardware settings
+that are relevant to u-boot, based on the board manual.  For the
+most up to date and complete details of the board, please request the
+reference manual ERG-00327-001.pdf from www.windriver.com
+
+Boot flash:
+	intel V28F640Jx, 8192x8 (one device) at 0xff80_0000
+
+Sodimm flash:
+	intel V28F128Jx, 16384x8 (4 devices) at 0xfb80_0000
+
+
+	Jumpers:
+
+Jumper		Name		ON		OFF
+----------------------------------------------------------------
+JP12		CS0/CS6 swap	see note[*]	see note[*]
+
+JP13		SODIMM flash	write OK	writes disabled
+		write prot.
+
+JP14		HRESET/TRST	joined		isolated
+
+JP15		PWR ON		when AC pwr	use S1 for on/off
+
+JP16		Demo LEDs	lit		not lit
+
+JP19		PCI mode	PCI		PCI-X
+
+
+[*]JP12, when jumpered parallel to the SODIMM, puts the boot flash
+onto /CS0 and the SODIMM flash on /CS6 (default).  When JP12
+is jumpered parallel to the LBC-SDRAM, then /CS0 is for the
+SODIMM flash and /CS6 is for the boot flash.  Note that in this
+alternate setting, you also need to switch SW2.8 to ON.  Currently
+u-boot doesn't support booting off the SODIMM in this alternate
+setting without manually altering BR0/OR0 and BR6/OR6 in the
+board config file appropriately.
+
+
+	Switches:
+
+The defaults are marked with a *
+
+Name		Desc.			ON		OFF
+------------------------------------------------------------------
+S1		Pwr toggle		n/a		n/a
+
+SW2.1		CFG_SYS_PLL0		1		0*
+SW2.2		CFG_SYS_PLL1		1*		0
+SW2.3		CFG_SYS_PLL2		1*		0
+SW2.4		CFG_SYS_PLL3		1		0*
+SW2.5		CFG_CORE_PLL0		1*		0
+SW2.6		CFG_CORE_PLL1		1		0*
+SW2.7		CFG_CORE_PLL2		1*		0
+SW2.8		CFG_ROM_LOC1		1		0*
+
+SW3.1		CFG_HOST_AGT0		1*		0
+SW3.2		CFG_HOST_AGT1		1*		0
+SW3.3		CFG_HOST_AGT2		1*		0
+SW3.4		CFG_IO_PORTS0		1*		0
+SW3.5		CFG_IO_PORTS0		1		0*
+SW3.6		CFG_IO_PORTS0		1		0*
+
+SerDes CLK(MHz)		SW5.1		SW5.2
+----------------------------------------------
+25			0		0
+100*			1		0
+125			0		1
+200			1		1
+
+SerDes CLK spread	SW5.3		SW5.4
+----------------------------------------------
++/- 0.25%		0		0
+-0.50%			1		0
+-0.75%			0		1
+No Spread*		1		1
+
+SW4 settings are readable from the EPLD and are currently not used for
+any hardware settings (i.e. user configuration switches).
+
+	LEDs:
+
+Name		Desc.			ON		OFF
+------------------------------------------------------------------
+D13		PCI/PCI-X		PCI-X		PCI
+D14		3.3V PWR		3.3V		no power
+D15		SYSCLK			66MHz		33MHz
+
+
+	Default Memory Map:
+
+start		end		CS<n>	width	Desc.
+----------------------------------------------------------------------
+0000_0000	0fff_ffff	MCS0,1	64	DDR2 (256MB)
+f000_0000	f7ff_ffff	CS3,4	32	LB SDRAM (128MB)
+f800_0000	f8b0_1fff	CS5	-	EPLD
+fb80_0000	ff7f_ffff	CS6	32	SODIMM flash (64MB)
+ff80_0000	ffff_ffff	CS0	8	Boot flash (8MB)
+
+The EPLD on CS5 demuxes the following devices at the following offsets:
+
+offset		size	width	device
+--------------------------------------------------------
+0		1fff	8	7 segment display LED
+10_0000		1fff	4	user switches
+30_0000		1fff	4	HW Rev. register
+b0_0000		1fff	8	8kB EEPROM
diff --git a/u-boot/doc/README.sbc8641d b/u-boot/doc/README.sbc8641d
new file mode 100644
index 0000000..a051466
--- /dev/null
+++ b/u-boot/doc/README.sbc8641d
@@ -0,0 +1,28 @@
+Wind River SBC8641D reference board
+===========================
+
+Created 06/14/2007 Joe Hamman
+Copyright 2007, Embedded Specialties, Inc.
+Copyright 2007 Wind River Systemes, Inc.
+-----------------------------
+
+1. Building U-Boot
+------------------
+The SBC8641D code is known to build using ELDK 4.1.
+
+    $ make sbc8641d_config
+    Configuring for sbc8641d board...
+
+    $ make
+
+
+2. Switch and Jumper Settings
+-----------------------------
+All Jumpers & Switches are in their default positions.  Please refer to
+the board documentation for details.  Some settings control CPU voltages
+and settings may change with board revisions.
+
+3. Known limitations
+--------------------
+PCI:
+	The PCI command may hang if no boards are present in either slot.
diff --git a/u-boot/doc/README.sched b/u-boot/doc/README.sched
new file mode 100644
index 0000000..3aa89e6
--- /dev/null
+++ b/u-boot/doc/README.sched
@@ -0,0 +1,53 @@
+Notes on the scheduler in sched.c:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+  'sched.c' provides an very simplistic multi-threading scheduler.
+   See the example, function 'sched(...)', in the same file for its
+   API usage.
+
+   Until an exhaustive testing can be done, the implementation cannot
+   qualify as that of production quality. It works with the example
+   in 'sched.c', it may or may not work in other cases.
+
+
+Limitations:
+~~~~~~~~~~~~
+
+  - There are NO primitives for thread synchronization (locking,
+    notify etc).
+
+  - Only the GPRs and FPRs context is saved during a thread context
+    switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
+    etc) are NOT saved.
+
+  - The scheduler is NOT transparent to the user. The user
+    applications must invoke thread_yield() to allow other threads to
+    scheduler.
+
+  - There are NO priorities, and the scheduling policy is round-robin
+    based.
+
+  - There are NO capabilities to collect thread CPU usage, scheduler
+    stats, thread status etc.
+
+  - The semantics are somewhat based on those of pthreads, but NOT
+    the same.
+
+  - Only seven threads are allowed. These can be easily increased by
+    changing "#define MAX_THREADS" depending on the available memory.
+
+  - The stack size of each thread is 8KBytes. This can be easily
+    increased depending on the requirement and the available memory,
+    by increasing "#define STK_SIZE".
+
+  - Only one master/parent thread is allowed, and it cannot be
+    stopped or deleted. Any given thread is NOT allowed to stop or
+    delete itself.
+
+  - There NOT enough safety checks as are probably in the other
+    threads implementations.
+
+  - There is no parent-child relationship between threads. Only one
+    thread may thread_join, preferably the master/parent thread.
+
+(C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>
diff --git a/u-boot/doc/README.scrapyard b/u-boot/doc/README.scrapyard
new file mode 100644
index 0000000..8f98b60
--- /dev/null
+++ b/u-boot/doc/README.scrapyard
@@ -0,0 +1,32 @@
+Over time, support for more and more boards gets added to U-Boot -
+while other board support code dies a silent death caused by
+negligence in combination with ordinary bitrot.  Sometimes this goes
+by unnoticed, but often build errors will result.  If nobody cares any
+more to resolve such problems, then the code is really dead and will
+be removed from the U-Boot source tree.  The remainders rest in piece
+in the imperishable depths of the git history.  This document tries to
+maintain a list of such former fellows, so archeologists can check
+easily if here is something they might want to dig for...
+
+
+Board	Arch	CPU	removed	    Commit	last known maintainer/contact
+=============================================================================
+barco	powerpc	MPC8245	-	  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>
+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>
+CCM	powerpc	MPC860	dff07e1   2010-10-06	Wolfgang Grandegger <wg@denx.de>
+PCU_E	powerpc	MPC860T	544d97e   2010-10-06	Wolfgang Denk <wd@denx.de>
+spieval	powerpc	MPC5200	69434e4   2010-09-19
+smmaco4	powerpc	MPC5200	9ddc3af   2010-09-19
+HMI10	powerpc	MPC823	77efe35   2010-09-19	Wolfgang Denk <wd@denx.de>
+GTH	powerpc	MPC860	0fe247b   2010-07-17	Thomas Lange <thomas@corelatus.se>
+AmigaOneG3SE		953b7e6   2010-06-23
+suzaku	microblaze	4f18060   2009-10-03	Yasushi Shoji <yashi@atmark-techno.com>
+XUPV2P	microblaze	8fab49e   2008-12-10	Michal Simek <monstr@monstr.eu>
+MVS1	powerpc	MPC823	306620b   2008-08-26	Andre Schwarz <andre.schwarz@matrix-vision.de>
+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>
diff --git a/u-boot/doc/README.serial_multi b/u-boot/doc/README.serial_multi
new file mode 100644
index 0000000..ad61d42
--- /dev/null
+++ b/u-boot/doc/README.serial_multi
@@ -0,0 +1,80 @@
+The support for multiple serial interfaces as implemented is mainly
+intended to allow for modem dial-in / dial-out while still being able
+to use a serial console on a (different) serial port.
+
+MPC8XX Specific
+===============
+At the moment, the ports must be split on a SMC and a SCC port  on  a
+8xx processor; other configurations are not (yet) supported.
+
+Support for hardware handshake has not been implemented yet (but is
+in the works).
+
+*) The default console depends on the keys pressed:
+	- SMC if keys not pressed (modem not enabled)
+	- SCC if keys pressed (modem enabled)
+
+*) The console can be switched to SCC by any of the following commands:
+
+	setenv stdout serial_scc
+	setenv stdin serial_scc
+	setenv stderr serial_scc
+
+*) The console can be switched to SMC by any of the following commands:
+
+	setenv stdout serial_smc
+	setenv stdin serial_smc
+	setenv stderr serial_smc
+
+*) If a file descriptor is set to "serial" then the current serial device
+will be used which, in turn, can be switched by above commands.
+
+*) The baudrate is the same for all serial devices. But it can be switched
+just after switching the console:
+
+	setenv sout serial_scc; setenv baudrate 38400
+
+After that press 'enter' at the SCC console. Note that baudrates <38400
+are not allowed on LWMON with watchdog enabled (see CONFIG_SYS_BAUDRATE_TABLE in
+include/configs/lwmon.h).
+
+
+PPC4XX Specific
+===============
+*) The default console is UART0
+
+*) The console can be switched to UART1 by any of the following commands:
+	setenv stdout serial1
+	setenv stderr serial1
+	setenv stdin serial1
+
+*) The console can be switched to UART0 by any of the following commands:
+	setenv stdout serial0
+	setenv stderr serial0
+	setenv stdin serial0
+
+MPC5xxx Specific
+================
+
+Up to two PSCs can be used as console.
+
+Support for hardware handshake has not been implemented yet.
+
+*) The first (default) console port is defined by:
+	#define CONFIG_PSC_CONSOLE <PSC number>
+
+*) The second (alternative) console port is defined by:
+	#define CONFIG_PSC_CONSOLE2 <PSC number>
+
+*) Commands to switch to the second console:
+	setenv stdout serial1
+	setenv stderr serial1
+	setenv stdin serial1
+
+*) Commands to switch to the first console:
+	setenv stdout serial0
+	setenv stderr serial0
+	setenv stdin serial0
+
+*) If a file descriptor is set to "serial" then the
+   current serial device will be used.
diff --git a/u-boot/doc/README.sh b/u-boot/doc/README.sh
new file mode 100644
index 0000000..6baee08
--- /dev/null
+++ b/u-boot/doc/README.sh
@@ -0,0 +1,104 @@
+
+U-Boot for Renesas SuperH
+	Last update 01/18/2008 by Nobuhiro Iwamatsu
+
+================================================================================
+0. What's this?
+	This file contains status information for the port of U-Boot to the
+	Renesas SuperH series of CPUs.
+
+================================================================================
+1. Overview
+	SuperH has an original boot loader. However, source code is dirty, and
+	maintenance is not done.
+	To improve sharing and the maintenance of the code, Nobuhiro Iwamatsu
+	started the porting to u-boot in 2007.
+
+================================================================================
+2. Supported CPUs
+
+	2.1. Renesas SH7750/SH7750R
+		This CPU has the SH4 core.
+
+	2.2. Renesas SH7722
+		This CPU has the SH4AL-DSP core.
+
+	2.3. Renesas SH7720
+		This CPU has the SH3 core.
+
+	2.4. Renesas SH7710/SH7712
+		This CPU has the SH3-DSP core and Ethernet controller.
+
+	2.5. Renesas SH7780
+		This CPU has the SH4A core.
+
+================================================================================
+3. Supported Boards
+
+	3.1. Hitachi UL MS7750SE01/MS7750RSE01
+		Board specific code is in board/ms7750se
+		To use this board, type "make ms7750se_config".
+		Support devices are :
+			- SCIF
+			- SDRAM
+			- NOR Flash
+			- Marubun PCMCIA
+
+	3.2. Hitachi UL MS7722SE01
+		Board specific code is in board/ms7722se
+		To use this board, type "make ms7722se_config".
+		Support devices are :
+			- SCIF
+			- SDRAM
+			- NOR Flash
+			- Marubun PCMCIA
+			- SMC91x ethernet
+
+	3.2. Hitachi UL MS7720ERP01
+		Board specific code is in board/ms7720se
+		To use this board, type "make ms7720se_config".
+		Support devices are :
+			- SCIF
+			- SDRAM
+			- NOR Flash
+			- Marubun PCMCIA
+
+	3.3. Renesas R7780MP
+		Board specific code is in board/r7780mp
+		To use this board, type "make r7780mp_config".
+		Support devices are :
+			- SCIF
+			- DDR-SDRAM
+			- NOR Flash
+			- Compact Flash
+			- ASIX ethernet
+			- SH7780 PCI bridge
+			- RTL8110 ethernet
+
+	** README **
+		In SuperH, S-record and binary of made u-boot work on the memory.
+		When u-boot is written in the flash, it is necessary to change the
+		address by using 'objcopy'.
+		ex) shX-linux-objcopy -Ibinary -Osrec u-boot.bin u-boot.flash.srec
+
+================================================================================
+4. Compiler
+	You can use the following of u-boot to compile.
+		- SuperH Linux Open site
+			http://www.superh-linux.org/
+		- KPIT GNU tools
+			http://www.kpitgnutools.com/
+
+================================================================================
+5. Future
+	I plan to support the following CPUs and boards.
+		5.1. CPUs
+			- SH7751R(SH4)
+			- SH7785(SH4)
+
+		5.2. Boards
+			- Many boards ;-)
+
+================================================================================
+Copyright (c) 2007,2008
+    Nobuhiro Iwamatsu <iwamatsu@nigaur.org>
diff --git a/u-boot/doc/README.sh7757lcr b/u-boot/doc/README.sh7757lcr
new file mode 100644
index 0000000..cae14e0
--- /dev/null
+++ b/u-boot/doc/README.sh7757lcr
@@ -0,0 +1,64 @@
+========================================
+Renesas R0P7757LC0030RL board
+========================================
+
+This board specification:
+=========================
+
+The R0P7757LC0030RL(board config name:sh7757lcr) has the following device:
+
+ - SH7757 (SH-4A)
+ - DDR3-SDRAM 256MB (with ECC)
+ - SPI ROM 8MB
+ - 2D Graphic controller
+ - Ethernet controller
+
+
+configuration for This board:
+=============================
+
+You can select the configuration as follows:
+
+ - make sh7785lcr_config
+
+
+This board specific command:
+============================
+
+This board has the following its specific command:
+
+ - sh_g200
+ - write_mac
+
+
+1. sh_g200
+
+If we run this command, SH4 can control the G200.
+The default setting is that SH4 cannot control the G200.
+
+
+2. write_mac
+
+You can write MAC address to SPI ROM.
+
+ Usage 1) Write MAC address
+
+   write_mac [ETHERC ch0] [ETHERC ch1] [GETHERC ch0] [GETHERC ch1]
+
+	For example)
+	 => write_mac 00:00:87:6c:21:80 00:00:87:6c:21:81 00:00:87:6c:21:82 00:00:87:6c:21:83
+		*) We have to input the command as a single line
+		   (without carriage return)
+		*) We have to reset after input the command.
+
+ Usage 2) Show current data
+
+   write_mac
+
+	For example)
+		=> write_mac
+		 ETHERC ch0 = 00:00:87:6c:21:80
+		 ETHERC ch1 = 00:00:87:6c:21:81
+		GETHERC ch0 = 00:00:87:6c:21:82
+		GETHERC ch1 = 00:00:87:6c:21:83
+
diff --git a/u-boot/doc/README.sh7785lcr b/u-boot/doc/README.sh7785lcr
new file mode 100644
index 0000000..56455fc
--- /dev/null
+++ b/u-boot/doc/README.sh7785lcr
@@ -0,0 +1,123 @@
+========================================
+Renesas Technology R0P7785LC0011RL board
+========================================
+
+This board specification:
+=========================
+
+The R0P7785LC0011RL(board config name:sh7785lcr) has the following device:
+
+ - SH7785 (SH-4A)
+ - DDR2-SDRAM 512MB
+ - NOR Flash 64MB
+ - 2D Graphic controller
+ - SATA controller
+ - Ethernet controller
+ - USB host/peripheral controller
+ - SD controller
+ - I2C controller
+ - RTC
+
+This board has 2 physical memory maps. It can be changed with DIP switch(S2-5).
+
+ phys address			| S2-5 = OFF	| S2-5 = ON
+ -------------------------------+---------------+---------------
+ 0x00000000 - 0x03ffffff(CS0)	| NOR Flash	| NOR Flash
+ 0x04000000 - 0x05ffffff(CS1)	| PLD		| PLD
+ 0x06000000 - 0x07ffffff(CS1)	| reserved	| I2C
+ 0x08000000 - 0x0bffffff(CS2)	| USB		| DDR SDRAM
+ 0x0c000000 - 0x0fffffff(CS3)	| SD		| DDR SDRAM
+ 0x10000000 - 0x13ffffff(CS4)	| SM107		| SM107
+ 0x14000000 - 0x17ffffff(CS5)	| I2C		| USB
+ 0x18000000 - 0x1bffffff(CS6)	| reserved	| SD
+ 0x40000000 - 0x5fffffff	| DDR SDRAM	| (cannot use)
+
+
+configuration for This board:
+=============================
+
+You can choose configuration as follows:
+
+ - make sh7785lcr_config
+ - make sh7785lcr_32bit_config
+
+When you use "make sh7785lcr_config", there is build U-Boot for 29-bit
+address mode. This mode can use 128MB DDR-SDRAM.
+
+When you use "make sh7785lcr_32bit_config", there is build U-Boot for 32-bit
+extended address mode. This mode can use 384MB DDR-SDRAM. And if you run
+"pmb" command, this mode can use 512MB DDR-SDRAM.
+
+ * 32-bit extended address mode PMB mapping *
+  a) on start-up
+   virt		| phys		| size		| device
+   -------------+---------------+---------------+---------------
+   0x88000000	| 0x48000000	| 384MB		| DDR-SDRAM (Cacheable)
+   0xa0000000	| 0x00000000	| 64MB		| NOR Flash
+   0xa4000000	| 0x04000000	| 16MB		| PLD
+   0xa6000000	| 0x08000000	| 16MB		| USB
+   0xa8000000	| 0x48000000	| 384MB		| DDR-SDRAM (Non-cacheable)
+
+  b) after "pmb" command
+   virt		| phys		| size		| device
+   -------------+---------------+---------------+---------------
+   0x80000000	| 0x40000000	| 512MB		| DDR-SDRAM (Cacheable)
+   0xa0000000	| 0x40000000	| 512MB		| DDR-SDRAM (Non-cacheable)
+
+
+This board specific command:
+============================
+
+This board has the following its specific command:
+
+ - hwtest
+ - printmac
+ - setmac
+ - pmb (sh7785lcr_32bit_config only)
+
+
+1. hwtest
+
+This is self-check command. This command has the following options:
+
+ - all		: test all hardware
+ - pld		: output PLD version
+ - led		: turn on LEDs
+ - dipsw	: test DIP switch
+ - sm107	: output SM107 version
+ - net		: check RTL8110 ID
+ - sata		: check SiI3512 ID
+ - net		: output PCI slot device ID
+
+i.e)
+=> hwtest led
+turn on LEDs 3, 5, 7, 9
+turn on LEDs 4, 6, 8, 10
+
+=> hwtest net
+Ethernet OK
+
+
+2. printmac
+
+This command outputs MAC address of this board.
+
+i.e)
+=> printmac
+MAC = 00:00:87:**:**:**
+
+
+3. setmac
+
+This command writes MAC address of this board.
+
+i.e)
+=> setmac 00:00:87:**:**:**
+
+
+4. pmb
+
+This command change PMB for DDR-SDRAM all mapping. However you cannot use
+NOR Flash and USB Host on U-Boot when you run this command.
+i.e)
+=> pmb
diff --git a/u-boot/doc/README.sha1 b/u-boot/doc/README.sha1
new file mode 100644
index 0000000..f6cca40
--- /dev/null
+++ b/u-boot/doc/README.sha1
@@ -0,0 +1,57 @@
+SHA1 usage:
+-----------
+
+In the U-Boot Image for the pcs440ep board is a SHA1 checksum integrated.
+This SHA1 sum is used, to check, if the U-Boot Image in Flash is not
+corrupted.
+
+The following command is available:
+
+=> help sha1
+sha1 address len [addr]  calculate the SHA1 sum [save at addr]
+     -p calculate the SHA1 sum from the U-Boot image in flash and print
+     -c check the U-Boot image in flash
+
+"sha1 -p"
+	calculates and prints the SHA1 sum, from the Image stored in Flash
+
+"sha1 -c"
+	check, if the SHA1 sum from the Image stored in Flash is correct
+
+
+It is possible to calculate a SHA1 checksum from a memoryrange with:
+
+"sha1 address len"
+
+If you want to store a new Image in Flash for the pcs440ep board,
+which has no SHA1 sum, you can do the following:
+
+a) cp the new Image on a position in RAM (here 0x300000)
+   (for this example we use the Image from Flash, stored at 0xfffa0000 and
+    0x60000 Bytes long)
+
+"cp.b fffa0000 300000 60000"
+
+b) Initialize the SHA1 sum in the Image with 0x00
+   The SHA1 sum is stored in Flash at:
+			   CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN + SHA1_SUM_POS
+   for the pcs440ep Flash:	 0xfffa0000 +	      0x60000 +        -0x20
+			    = 0xffffffe0
+   for the example in RAM:	   0x300000 +	      0x60000 +        -0x20
+			    = 0x35ffe0
+
+   note: a SHA1 checksum is 20 bytes long.
+
+"mw.b 35ffe0 0 14"
+
+c) now calculate the SHA1 sum from the memoryrange and write
+   the calculated checksum at the right place:
+
+"sha1 300000 60000 35ffe0"
+
+Now you have a U-Boot-Image for the pcs440ep board with the correct SHA1 sum.
+
+If you do a "./MAKEALL pcs440ep" or a "make all" to get the U-Boot image,
+the correct SHA1 sum will be automagically included in the U-Boot image.
+
+Heiko Schocher, 11 Jul 2007
diff --git a/u-boot/doc/README.silent b/u-boot/doc/README.silent
new file mode 100644
index 0000000..a26e3df
--- /dev/null
+++ b/u-boot/doc/README.silent
@@ -0,0 +1,20 @@
+The config option CONFIG_SILENT_CONSOLE can be used to quiet messages
+on the console.  If the option has been enabled, the output can be
+silenced by setting the environment variable "silent".  The variable
+is latched into the global data at an early stage in the boot process
+so deleting it with "setenv" will not take effect until the system is
+restarted.
+
+The following actions are taken if "silent" is set at boot time:
+
+ - Until the console devices have been initialized, output has to be
+   suppressed by testing for the flag "GD_FLG_SILENT" in "gd->flags".
+
+ - When the console devices have been initialized, "stdout" and
+   "stderr" are set to "nulldev", so subsequent messages are
+   suppressed automatically. Make sure to enable "nulldev" by
+   #defining CONFIG_SYS_DEVICE_NULLDEV in your board config file.
+
+ - When booting a linux kernel, the "bootargs" are fixed up so that
+   the argument "console=" will be in the command line, no matter how
+   it was set in "bootargs" before.
diff --git a/u-boot/doc/README.simpc8313 b/u-boot/doc/README.simpc8313
new file mode 100644
index 0000000..b362c6a
--- /dev/null
+++ b/u-boot/doc/README.simpc8313
@@ -0,0 +1,80 @@
+Sheldon Instruments SIMPC8313 Board
+-----------------------------------------
+
+1.	Board Switches and Jumpers
+
+	S2 is used to set CFG_RESET_SOURCE.
+
+	To boot the image in Large page NAND flash, use these DIP
+	switch settings for S2:
+
+	+----------+ ON
+	| * * **** |
+	|  * *     |
+	+----------+
+	  12345678
+
+	To boot the image in Small page NAND flash, use these DIP
+	switch settings for S2:
+
+	+----------+ ON
+	| *** **** |
+	|    *     |
+	+----------+
+	  12345678
+	(where the '*' indicates the position of the tab of the switch.)
+
+2.	Memory Map
+	The memory map looks like this:
+
+	0x0000_0000	0x1fff_ffff	DDR			512M
+	0x8000_0000	0x8fff_ffff	PCI MEM			256M
+	0x9000_0000	0x9fff_ffff	PCI_MMIO		256M
+	0xe000_0000	0xe00f_ffff	IMMR			1M
+	0xe200_0000	0xe20f_ffff	PCI IO			16M
+	0xe280_0000	0xe280_7fff	NAND FLASH (CS0)	32K
+	or
+	0xe280_0000	0xe281_ffff	NAND FLASH (CS0)	128K
+	0xff00_0000	0xff00_7fff	FPGA (CS1)		1M
+
+3.	Compilation
+
+	Assuming you're using BASH (or similar) as your shell:
+
+	export CROSS_COMPILE=your-cross-compiler-prefix-
+	make distclean
+	make SIMPC8313_LP_config
+	(or make SIMPC8313_SP_config, depending on the page size
+	of your NAND flash)
+	make
+
+4.	Downloading and Flashing Images
+
+4.1	Reflash U-boot Image using U-boot
+
+	=>run update_uboot
+
+	You may want to try
+	=>tftp $loadaddr $uboot
+	first, to make sure that the TFTP load will succeed before it
+	goes ahead and wipes out your current firmware.  And of course,
+	if the new u-boot doesn't boot, you can plug the board into
+	your PCI slot and with the supplied driver and sample app
+	you can reburn a working u-boot.
+
+4.2	Downloading and Booting Linux Kernel
+
+	Ensure that all networking-related environment variables are set
+	properly (including ipaddr, serverip, gatewayip (if needed),
+	netmask, ethaddr, eth1addr, fdtfile, and bootfile).
+
+	=>tftp $loadaddr uImage
+	=>nand write $loadaddr kernel $filesize
+	=>tftp $loadaddr $fdtfile
+	=>nand write $loadaddr 7e0000 1800
+
+	=>boot
+
+5	Notes
+
+	The console baudrate for SIMPC8313 is 115200bps.
diff --git a/u-boot/doc/README.spear b/u-boot/doc/README.spear
new file mode 100644
index 0000000..a8b1052
--- /dev/null
+++ b/u-boot/doc/README.spear
@@ -0,0 +1,48 @@
+
+SPEAr (Structured Processor Enhanced Architecture).
+
+SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic
+
+The SPEAr SoC family embeds a customizable logic that can be programmed
+one-time by a customer at silicon mask level (i.e. not at runtime!).
+
+We are now adding the support in u-boot for two SoC: SPEAr600 and SPEAr3xx.
+
+All 4 SoCs share common peripherals.
+
+1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux)
+2. FastEthernet (sp600 has Gbit version, but same controller - GMAC)
+3. USB Host
+4. USB Device
+5. NAND controller (FSMC)
+6. Serial NOR ctrl
+7. I2C
+8. SPI
+9. CLCD
+10. others ..
+
+Everything is supported in Linux.
+u-boot is not currently supporting all peripeharls (just a few as listed below).
+1. USB Device
+2. NAND controller (FSMC)
+3. Serial Memory Interface
+4. EMI (Parallel NOR interface)
+4. I2C
+5. UART
+
+Build options
+	make spear600_config
+	make spear300_config
+	make spear310_config
+	make spear320_config
+
+Further options
+	make ENV=NAND (supported by all 4 SoCs)
+	- This option generates a uboot image that saves environment inn NAND
+
+	make CONSOLE=USB (supported by all 4 SoCs)
+	- This option generates a uboot image for using usbdevice as a tty i/f
+
+	make FLASH=PNOR (supported by SPEAr310 and SPEAr320)
+	- This option generates a uboot image that supports emi controller for
+	CFI compliant parallel NOR flash
diff --git a/u-boot/doc/README.standalone b/u-boot/doc/README.standalone
new file mode 100644
index 0000000..6e6b65f
--- /dev/null
+++ b/u-boot/doc/README.standalone
@@ -0,0 +1,99 @@
+Design Notes on Exporting U-Boot Functions to Standalone Applications:
+======================================================================
+
+1. The functions are exported by U-Boot via a jump table. The jump
+   table is allocated and initialized in the jumptable_init() routine
+   (common/exports.c). Other routines may also modify the jump table,
+   however. The jump table can be accessed as the 'jt' field of the
+   'global_data' structure. The slot numbers for the jump table are
+   defined in the <include/exports.h> header. E.g., to substitute the
+   malloc() and free() functions that will be available to standalone
+   applications, one should do the following:
+
+	DECLARE_GLOBAL_DATA_PTR;
+
+	gd->jt[XF_malloc]	= my_malloc;
+	gd->jt[XF_free]		= my_free;
+
+   Note that the pointers to the functions all have 'void *' type and
+   thus the compiler cannot perform type checks on these assignments.
+
+2. The pointer to the jump table is passed to the application in a
+   machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II
+   architectures use a dedicated register to hold the pointer to the
+   'global_data' structure: r2 on PowerPC, r8 on ARM, k0 on MIPS,
+   P3 on Blackfin and gp on Nios II. The x86 architecture does not
+   use such a register; instead, the pointer to the 'global_data'
+   structure is passed as 'argv[-1]' pointer.
+
+   The application can access the 'global_data' structure in the same
+   way as U-Boot does:
+
+	DECLARE_GLOBAL_DATA_PTR;
+
+	printf("U-Boot relocation offset: %x\n", gd->reloc_off);
+
+3. The application should call the app_startup() function before any
+   call to the exported functions. Also, implementor of the
+   application may want to check the version of the ABI provided by
+   U-Boot. To facilitate this, a get_version() function is exported
+   that returns the ABI version of the running U-Boot. I.e., a
+   typical application startup may look like this:
+
+	int my_app (int argc, char * const argv[])
+	{
+		app_startup (argv);
+		if (get_version () != XF_VERSION)
+			return 1;
+	}
+
+4. The default load and start addresses of the applications are as
+   follows:
+
+			Load address	Start address
+	x86		0x00040000	0x00040000
+	PowerPC		0x00040000	0x00040004
+	ARM		0x0c100000	0x0c100000
+	MIPS		0x80200000	0x80200000
+	Blackfin	0x00001000	0x00001000
+	Nios II		0x02000000	0x02000000
+
+   For example, the "hello world" application may be loaded and
+   executed on a PowerPC board with the following commands:
+
+   => tftp 0x40000 hello_world.bin
+   => go 0x40004
+
+5. To export some additional function foobar(), the following steps
+   should be undertaken:
+
+   - Append the following line at the end of the include/_exports.h
+     file:
+
+	EXPORT_FUNC(foobar)
+
+   - Add the prototype for this function to the include/exports.h
+     file:
+
+	void foobar(void);
+
+   - Add the initialization of the jump table slot wherever
+     appropriate (most likely, to the jumptable_init() function):
+
+	gd->jt[XF_foobar] = foobar;
+
+   - Increase the XF_VERSION value by one in the include/exports.h
+     file
+
+6. The code for exporting the U-Boot functions to applications is
+   mostly machine-independent. The only places written in assembly
+   language are stub functions that perform the jump through the jump
+   table. That said, to port this code to a new architecture, the
+   only thing to be provided is the code in the examples/stubs.c
+   file. If this architecture, however, uses some uncommon method of
+   passing the 'global_data' pointer (like x86 does), one should add
+   the respective code to the app_startup() function in that file.
+
+   Note that these functions may only use call-clobbered registers;
+   those registers that are used to pass the function's arguments,
+   the stack contents and the return address should be left intact.
diff --git a/u-boot/doc/README.stxxtc b/u-boot/doc/README.stxxtc
new file mode 100644
index 0000000..7d9d4d3
--- /dev/null
+++ b/u-boot/doc/README.stxxtc
@@ -0,0 +1,59 @@
+
+
+First, some build notes on the Silicon Turnkey eXpress XTc.
+
+This board has both 87x/88x procesor options at various
+frequencies.  The configuration file has some macros for setting
+the clock speed, not all have been tested.  They all have
+a 10MHz input clock.  Please do not check in a configuration
+file that selects a high speed not available on all processors.
+We chose the 66MHz core and bus speed, which should be OK on
+all boards.  If you have a processor, lucky you! :-)
+Just build a new configuration with that speed, check
+the macro configuration to ensure it's correct.  If the
+macro is updated, please check that in, but keep default
+processor speed.
+
+The board is likely to have more than 1Mbyte of NOR boot flash.
+It was also configured with a high boot vector (Dan's fault)
+so the standard 8xx mapping doesn't work well. We had to move
+the addresses around a little bit so one copy would work.  The
+flash got fragmented, and we are working on a better solution.
+There is an "xtc.cfg" floating around for the BDI2000, use
+that for programming a new version of U-Boot.  You can probably
+find it on the Silicon Turnkey eXpress (www.silicontkx.com),
+Embedded Alley Solutions (embeddedalley.com), or Denx (denx.de)
+servers.
+
+The board will also have various SDRAM sizes, but the code
+should automatically determine the amount of memory.
+
+There are a couple of different board versions, visually
+they use different BGA or surface mount memory parts.  However,
+they are logically the same board.
+
+Now, some operational notes.
+
+The board has the option of sporting two FEC Ethernet ports.
+The second port isn't configured to be automatically available
+because it would cause U-Boot to generate a board data structure
+(the bd_t) with multiple MAC addresses and be incompatible with
+standard 8xx kernel builds.  You can use/test the second FEC
+in U-Boot by assigning an 'eth1addr' and selecting the second
+FEC as the port to use.
+
+Since this is just a development board and not a product, STx
+does not assign unique MAC addresses.  We just pilfer the
+"default" ones used by Wolfgang on some other boards.  Please
+ensure you assign unique MAC addresses when using these boards.
+
+The serial port baud rate is 38400, because that's the way
+I like it :-)
+
+Thanks to Pantelis for lots of the work on this board port.
+
+Have Fun!
+
+	-- Dan
+
+15 August 2005
diff --git a/u-boot/doc/README.timll b/u-boot/doc/README.timll
new file mode 100644
index 0000000..609bf51
--- /dev/null
+++ b/u-boot/doc/README.timll
@@ -0,0 +1,15 @@
+DevKit8000
+==========
+
+The OMAP3 DevKit8000 from Embest/Timll is a clone of the OMAP3 beagle board
+with Ethernet and Touch Screen controller on board.
+
+For more information go to:
+http://www.embedinfo.com/English/Product/devkit8000.asp
+
+There's no real MAC address available.
+If ethaddr is not set, 5 Bytes of the OMAP Die ID will be used.
+
+Build:
+make devkit8000_config
+make
diff --git a/u-boot/doc/README.ubi b/u-boot/doc/README.ubi
new file mode 100644
index 0000000..da2dfac
--- /dev/null
+++ b/u-boot/doc/README.ubi
@@ -0,0 +1,144 @@
+-------------------
+UBI usage in U-Boot
+-------------------
+
+Here the list of the currently implemented UBI commands:
+
+=> help ubi
+ubi - ubi commands
+
+Usage:
+ubi part [part] [offset]
+ - Show or set current partition (with optional VID header offset)
+ubi info [l[ayout]] - Display volume and ubi layout information
+ubi create[vol] volume [size] [type] - create volume name with size
+ubi write[vol] address volume size - Write volume from address with size
+ubi read[vol] address volume [size] - Read volume to address with size
+ubi remove[vol] volume - Remove volume
+[Legends]
+ volume: character name
+ size: specified in bytes
+ type: s[tatic] or d[ynamic] (default=dynamic)
+
+
+The first command that is needed to be issues is "ubi part" to connect
+one mtd partition to the UBI subsystem. This command will either create
+a new UBI device on the requested MTD partition. Or it will attach a
+previously created UBI device. The other UBI commands will only work
+when such a UBI device is attached (via "ubi part"). Here an example:
+
+=> mtdparts
+
+device nor0 <1fc000000.nor_flash>, # parts = 6
+ #: name                size            offset          mask_flags
+ 0: kernel              0x00200000      0x00000000      0
+ 1: dtb                 0x00040000      0x00200000      0
+ 2: root                0x00200000      0x00240000      0
+ 3: user                0x01ac0000      0x00440000      0
+ 4: env                 0x00080000      0x01f00000      0
+ 5: u-boot              0x00080000      0x01f80000      0
+
+active partition: nor0,0 - (kernel) 0x00200000 @ 0x00000000
+
+defaults:
+mtdids  : nor0=1fc000000.nor_flash
+mtdparts: mtdparts=1fc000000.nor_flash:2m(kernel),256k(dtb),2m(root),27392k(user),512k(env),512k(u-boot)
+
+=> ubi part root
+Creating 1 MTD partitions on "nor0":
+0x000000240000-0x000000440000 : "mtd=2"
+UBI: attaching mtd1 to ubi0
+UBI: physical eraseblock size:   262144 bytes (256 KiB)
+UBI: logical eraseblock size:    262016 bytes
+UBI: smallest flash I/O unit:    1
+UBI: VID header offset:          64 (aligned 64)
+UBI: data offset:                128
+UBI: attached mtd1 to ubi0
+UBI: MTD device name:            "mtd=2"
+UBI: MTD device size:            2 MiB
+UBI: number of good PEBs:        8
+UBI: number of bad PEBs:         0
+UBI: max. allowed volumes:       128
+UBI: wear-leveling threshold:    4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes:     1
+UBI: available PEBs:             0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 2/1
+
+
+Now that the UBI device is attached, this device can be modified
+using the following commands:
+
+ubi info	Display volume and ubi layout information
+ubi createvol	Create UBI volume on UBI device
+ubi removevol	Remove UBI volume from UBI device
+ubi read	Read data from UBI volume to memory
+ubi write	Write data from memory to UBI volume
+
+
+Here a few examples on the usage:
+
+=> ubi create testvol
+Creating dynamic volume testvol of size 1048064
+
+=> ubi info l
+UBI: volume information dump:
+UBI: vol_id          0
+UBI: reserved_pebs   4
+UBI: alignment       1
+UBI: data_pad        0
+UBI: vol_type        3
+UBI: name_len        7
+UBI: usable_leb_size 262016
+UBI: used_ebs        4
+UBI: used_bytes      1048064
+UBI: last_eb_bytes   262016
+UBI: corrupted       0
+UBI: upd_marker      0
+UBI: name            testvol
+
+UBI: volume information dump:
+UBI: vol_id          2147479551
+UBI: reserved_pebs   2
+UBI: alignment       1
+UBI: data_pad        0
+UBI: vol_type        3
+UBI: name_len        13
+UBI: usable_leb_size 262016
+UBI: used_ebs        2
+UBI: used_bytes      524032
+UBI: last_eb_bytes   2
+UBI: corrupted       0
+UBI: upd_marker      0
+UBI: name            layout volume
+
+=> ubi info
+UBI: MTD device name:            "mtd=2"
+UBI: MTD device size:            2 MiB
+UBI: physical eraseblock size:   262144 bytes (256 KiB)
+UBI: logical eraseblock size:    262016 bytes
+UBI: number of good PEBs:        8
+UBI: number of bad PEBs:         0
+UBI: smallest flash I/O unit:    1
+UBI: VID header offset:          64 (aligned 64)
+UBI: data offset:                128
+UBI: max. allowed volumes:       128
+UBI: wear-leveling threshold:    4096
+UBI: number of internal volumes: 1
+UBI: number of user volumes:     1
+UBI: available PEBs:             0
+UBI: total number of reserved PEBs: 8
+UBI: number of PEBs reserved for bad PEB handling: 0
+UBI: max/mean erase counter: 4/1
+
+=> ubi write 800000 testvol 80000
+Volume "testvol" found at volume id 0
+
+=> ubi read 900000 testvol 80000
+Volume testvol found at volume id 0
+read 524288 bytes from volume 0 to 900000(buf address)
+
+=> cmp.b 800000 900000 80000
+Total of 524288 bytes were the same
diff --git a/u-boot/doc/README.update b/u-boot/doc/README.update
new file mode 100644
index 0000000..48f03b7
--- /dev/null
+++ b/u-boot/doc/README.update
@@ -0,0 +1,90 @@
+Automatic software update from a TFTP server
+============================================
+
+Overview
+--------
+
+This feature allows to automatically store software updates present on a TFTP
+server in NOR Flash. In more detail: a TFTP transfer of a file given in
+environment variable 'updatefile' from server 'serverip' is attempted during
+boot. The update file should be a FIT file, and can contain one or more
+updates. Each update in the update file has an address in NOR Flash where it
+should be placed, updates are also protected with a SHA-1 checksum. If the
+TFTP transfer is successful, the hash of each update is verified, and if the
+verification is positive, the update is stored in Flash.
+
+The auto-update feature is enabled by the CONFIG_UPDATE_TFTP macro:
+
+#define CONFIG_UPDATE_TFTP		1
+
+
+Note that when enabling auto-update, Flash support must be turned on.  Also,
+one must enable FIT and LIBFDT support:
+
+#define CONFIG_FIT		1
+#define CONFIG_OF_LIBFDT	1
+
+The auto-update feature uses the following configuration knobs:
+
+- CONFIG_UPDATE_LOAD_ADDR
+
+  Normally, TFTP transfer of the update file is done to the address specified
+  in environment variable 'loadaddr'. If this variable is not present, the
+  transfer is made to the address given in CONFIG_UPDATE_LOAD_ADDR (0x100000
+  by default).
+
+- CONFIG_UPDATE_TFTP_CNT_MAX
+  CONFIG_UPDATE_TFTP_MSEC_MAX
+
+  These knobs control the timeouts during initial connection to the TFTP
+  server. Since a transfer is attempted during each boot, it is undesirable to
+  have a long delay when a TFTP server is not present.
+  CONFIG_UPDATE_TFTP_MSEC_MAX specifies the number of milliseconds to wait for
+  the server to respond to initial connection, and CONFIG_UPDATE_TFTP_CNT_MAX
+  gives the number of such connection retries. CONFIG_UPDATE_TFTP_CNT_MAX must
+  be non-negative and is 0 by default, CONFIG_UPDATE_TFTP_MSEC_MAX must be
+  positive and is 100 by default.
+
+Since the update file is in FIT format, it is created from an *.its file using
+the mkimage tool. dtc tool with support for binary includes, e.g. in version
+1.2.0 or later, must also be available on the system where the update file is
+to be prepared. Refer to the doc/uImage.FIT/ directory for more details on FIT
+images.
+
+
+Example .its files
+------------------
+
+- doc/uImage.FIT/update_uboot.its
+
+  A simple example that can be used to create an update file for automatically
+  replacing U-Boot image on a system.
+
+  Assuming that an U-Boot image u-boot.bin is present in the current working
+  directory, and that the address given in the 'load' property in the
+  'update_uboot.its' file is where the U-Boot is stored in Flash, the
+  following command will create the actual update file 'update_uboot.itb':
+
+  mkimage -f update_uboot.its update_uboot.itb
+
+  Place 'update_uboot.itb' on a TFTP server, for example as
+  '/tftpboot/update_uboot.itb', and set the 'updatefile' variable
+  appropriately, for example in the U-Boot prompt:
+
+  setenv updatefile /tftpboot/update_uboot.itb
+  saveenv
+
+  Now, when the system boots up and the update TFTP server specified in the
+  'serverip' environment variable is accessible, the new U-Boot image will be
+  automatically stored in Flash.
+
+  NOTE: do make sure that the 'u-boot.bin' image used to create the update
+  file is a good, working image. Also make sure that the address in Flash
+  where the update will be placed is correct. Making mistake here and
+  attempting the auto-update can render the system unusable.
+
+- doc/uImage.FIT/update3.its
+
+  An example containing three updates. It can be used to update Linux kernel,
+  ramdisk and FDT blob stored in Flash. The procedure for preparing the update
+  file is similar to the example above.
diff --git a/u-boot/doc/README.usb b/u-boot/doc/README.usb
new file mode 100644
index 0000000..9aa4f62
--- /dev/null
+++ b/u-boot/doc/README.usb
@@ -0,0 +1,82 @@
+/*
+ * (C) Copyright 2001
+ * Denis Peter, MPL AG Switzerland
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+USB Support for PIP405 and MIP405 (UHCI)
+========================================
+
+The USB support is implemented on the base of the UHCI Host
+controller.
+
+Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
+flash sticks and USB network adaptors.
+Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
+
+How it works:
+-------------
+
+The USB (at least the USB UHCI) needs a frame list (4k), transfer
+descripor and queue headers which are all located in the main memory.
+The UHCI allocates every milisecond the PCI bus and reads the current
+frame pointer. This may cause to crash the OS during boot. So the USB
+_MUST_ be stopped during OS boot. This is the reason, why the USB is
+NOT automatically started during start-up. If someone needs the USB
+he has to start it and should therefore be aware that he had to stop
+it before booting the OS.
+
+For USB keyboards this can be done by a script which is automatically
+started after the U-Boot is up and running. To boot an OS with a an
+USB keyboard another script is necessary, which first disables the
+USB and then executes the boot command. If the boot command fails,
+the script can reenable the USB kbd.
+
+Common USB Commands:
+- usb start:
+- usb reset:	    (re)starts the USB. All USB devices will be
+		    initialized and a device tree is build for them.
+- usb tree:	    shows all USB devices in a tree like display
+- usb info [dev]:   shows all USB infos of the device dev, or of all
+		    the devices
+- usb stop [f]:	    stops the USB. If f==1 the USB will also stop if
+		    an USB keyboard is assigned as stdin. The stdin
+		    is then switched to serial input.
+Storage USB Commands:
+- usb scan:	    scans the USB for storage devices.The USB must be
+		    running for this command (usb start)
+- usb device [dev]: show or set current USB staorage device
+- usb part [dev]:   print partition table of one or all USB storage
+		    devices
+- usb read addr blk# cnt:
+		    read `cnt' blocks starting at block `blk#'to
+		    memory address `addr'
+- usbboot addr dev:part:
+		    boot from USB device
+
+Config Switches:
+----------------
+CONFIG_CMD_USB	    enables basic USB support and the usb command
+CONFIG_USB_UHCI	    defines the lowlevel part.A lowlevel part must be defined
+		    if using CONFIG_CMD_USB
+CONFIG_USB_KEYBOARD enables the USB Keyboard
+CONFIG_USB_STORAGE  enables the USB storage devices
+CONFIG_USB_HOST_ETHER	enables USB ethernet dongle support
diff --git a/u-boot/doc/README.video b/u-boot/doc/README.video
new file mode 100644
index 0000000..34e199c
--- /dev/null
+++ b/u-boot/doc/README.video
@@ -0,0 +1,30 @@
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio@tin.it
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+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
diff --git a/u-boot/doc/README.xpedite1k b/u-boot/doc/README.xpedite1k
new file mode 100644
index 0000000..1da8b80
--- /dev/null
+++ b/u-boot/doc/README.xpedite1k
@@ -0,0 +1,82 @@
+			   XES XPedite1000 Board
+
+		    Last Update: December 29, 2003
+=======================================================================
+
+This file contains some handy info regarding U-Boot and the XES
+XPedite1000 PPC440GX PrPMC board. See the README.ppc440 for additional
+information.
+
+
+SWITCH SETTINGS & JUMPERS
+==========================
+
+Jumpers selected for AMD29LV040B flash part as the boot flash.
+
+
+I2C Strap EEPROM & Environment Settings
+=======================================
+
+The XPedite1000 uses a single I2C eeprom for the 440 strappings and for
+the environment variables.  The first page (256 bytes) contains the
+strappings and the 2 EMAC HW Ethernet addresses.  Be careful not to
+change the 1st page of the EEPROM!  Unpopulated jumper J560 can get you
+out of trouble as it disables the strapping read from EEPROM.
+
+I2C probe
+=====================
+
+The i2c utilities work and have been tested on Rev B. of the 440GX. See
+README.ebony for more information about i2c probing with the 440.
+
+
+GETTING OUT OF I2C TROUBLE
+===========================
+
+(Direct quote from README.ebony)
+If you're like me ... you may have screwed up your bootstrap serial
+eeprom ... or worse, your SPD eeprom when experimenting with the
+i2c commands. If so, here are some ideas on how to get out of
+trouble:
+
+Serial bootstrap eeprom corruption:
+-----------------------------------
+Power down the board and set the following straps:
+
+J560 - closed
+
+This will select the default sys0 and sys1 settings (the serial
+eeproms are not used). Then power up the board and fix the serial
+eeprom using the 'i2c mm' command. Here are the values I currently
+use:
+
+=> i2c md 50 0 10
+
+0000: 85 7d 42 06 07 80 11 00 00 00 00 00 00 00 00 00    .}B.............
+
+Once you have the eeproms set correctly change the
+J560 straps as you desire.
+
+
+PPC440GX Ethernet EMACs
+=======================
+
+The XES XPedite1000 uses emac 2 & 3 and ignores emac 0 & 1.  PHYs are connected
+only to emac 2 & 3.  The HW Ethernet addresses are read from the i2c eeprom and
+placed in the bd info structure for enet2addr and enet3addr.  The ethernet driver
+senses that enetaddr and enet1addr are 0's and does not use them.
+
+As of this writing gigabit ethernet and the TCPIP acceleration hardware is not
+supported.
+
+
+Flash Support
+=============
+
+As of this writing, there is support for the 1/2mb boot flash only.  User flash
+is not yet supported.
+
+
+Regards,
+--Travis
+<travis.sawyer@sandburst.com>
diff --git a/u-boot/doc/README.zeus b/u-boot/doc/README.zeus
new file mode 100644
index 0000000..1848d8c
--- /dev/null
+++ b/u-boot/doc/README.zeus
@@ -0,0 +1,73 @@
+
+Storage of the board specific values (ethaddr...)
+-------------------------------------------------
+
+The board specific environment variables that should be unique
+for each individual board, can be stored in the I2C EEPROM. This
+will be done from offset 0x80 with the length of 0x80 bytes. The
+following command can be used to store the values here:
+
+=> setdef de:20:6a:ed:e2:72 de:20:6a:ed:e2:73 AB0001
+
+	  ethaddr           eth1addr          serial#
+
+Now those 3 values are stored into the I2C EEPROM. A CRC is added
+to make sure that the values get not corrupted.
+
+
+SW-Reset Pushbutton handling:
+-----------------------------
+
+The SW-reset push button is connected to a GPIO input too. This
+way U-Boot can "see" how long the SW-reset was pressed, and a
+specific action can be taken. Two different actions are supported:
+
+a) Release after more than 5 seconds and less then 10 seconds:
+   -> Run POST
+
+   Please note, that the POST test will take a while (approx. 1 min
+   on the 128MByte board). This is mainly due to the system memory
+   test.
+
+b) Release after more than 10 seconds:
+   -> Restore factory default settings
+
+   The factory default values are restored. The default environment
+   variables are restored (ipaddr, serverip...) and the board
+   specific values (ethaddr, eth1addr and serial#) are restored
+   to the environment from the I2C EEPROM. Also a bootline parameter
+   is added to the Linux bootline to signal the Linux kernel upon
+   the next startup, that the factory defaults should be restored.
+
+The command to check this sw-reset status and act accordingly is
+
+=> chkreset
+
+This command is added to the default "bootcmd", so that it is called
+automatically upon startup.
+
+Also, the 2 LED's are used to indicate the current status of this
+command (time passed since pushing the button). When the POST test
+will be run, the green LED will be switched off, and when the
+factory restore will be initiated, the reg LED will be switched off.
+
+
+Loggin of POST results:
+-----------------------
+
+The results of the POST tests are logged in a logbuffer located at the end
+of the onboard memory. It can be accessed with the U-Boot command "log":
+
+=> log show
+<4>POST memory PASSED
+<4>POST cache PASSED
+<4>POST cpu PASSED
+<4>POST uart PASSED
+<4>POST ethernet PASSED
+
+The DENX Linux kernel tree has support for this log buffer included. Exactly
+this buffer is used for logging of all kernel messages too. By enabling the
+compile time option "CONFIG_LOGBUFFER" this support is enabled. This way you
+can access the U-Boot log messages from Linux too.
+
+2007-08-10, Stefan Roese <sr@denx.de>
diff --git a/u-boot/doc/TODO-i386 b/u-boot/doc/TODO-i386
new file mode 100644
index 0000000..9b6c5d4
--- /dev/null
+++ b/u-boot/doc/TODO-i386
@@ -0,0 +1,29 @@
+i386 port missing features:
+* i386 cleaness (wbinvld is 486+ ... )
+* Pentium TSC timer/udelay
+* setup the BIOS data area and BIOS equipment word to reflect machine config. 
+* Make reset work (from Linux and from the boot prompt)
+* DMA, FDC, RTC, KBC initialization
+* split of part of arch/i386/cpu/interrupt.c to cpu/i385/entry.c?
+* re-entry of protected mode from real mode, should be added to realmode_switch.S 
+  (and used by INT 10h and INT 16h handlers for console I/O during early
+   linux boot...) 
+* missing functions in arch/i386/lib and arch/i386/cpu
+* speaker beep interface
+
+
+SC520 missing features:
+* Watchdog
+* SC520 timer/udelay
+* SC520 3rd PIC
+* SC520 ICE serial
+* SC520 MMCR reset 
+
+SC520 CDP board support missing features:
+* environment in sram
+
+SC520 CDP board support bugs:
+* SPI EEPROM support does not work
+* 0x680 LEDS dos not work for me
+* is it possible to make both the internal serial ports and the 
+  ports on the sio work at the same time?
diff --git a/u-boot/doc/feature-removal-schedule.txt b/u-boot/doc/feature-removal-schedule.txt
new file mode 100644
index 0000000..180ead5
--- /dev/null
+++ b/u-boot/doc/feature-removal-schedule.txt
@@ -0,0 +1,39 @@
+The following is a list of files and features that are going to be
+removed from the U-Boot source tree.  Every entry should contain what
+exactly is going away, when it will be gone, why it is being removed,
+and who is going to be doing the work.	When the feature is removed
+from U-Boot, its corresponding entry should also be removed from this
+file.
+
+---------------------------
+
+What:	CONFIG_NET_MULTI option
+When:	Release 2009-11
+
+Why:	U-boot currently implements two network driver APIs.  New drivers with
+	the older-style implementation have not been accepted for a while, and
+	this parallel system makes the code confusing and hard to augment.
+
+	All existing in-tree boards will be converted to use CONFIG_NET_MULTI
+	over the span of two releases (2009-07 and 2009-09).
+	In the 2009-11 release, all code that is compiled when CONFIG_NET_MULTI
+	is not set will be removed, and all references to CONFIG_NET_MULTI
+	will be removed, effectively making it the only API.  This should
+	provide ample time for out-of-tree users to adjust, and for tools on
+	all architectures to be made to work with weak functions.
+
+Who:	Ben Warren <biggerbadderben@gmail.com>
+
+---------------------------
+
+What:	GPL cleanup
+When:	August 2009
+Why:	Over time, a couple of files have sneaked in into the U-Boot
+	source code that are either missing a valid GPL license
+	header or that carry a license that is incompatible with the
+	GPL.
+	Such files shall be removed from the U-Boot source tree.
+	See http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files
+	for an old and probably incomplete list of such files.
+
+Who:	Wolfgang Denk <wd@denx.de> and board maintainers
diff --git a/u-boot/doc/mkimage.1 b/u-boot/doc/mkimage.1
new file mode 100644
index 0000000..f27da6b
--- /dev/null
+++ b/u-boot/doc/mkimage.1
@@ -0,0 +1,118 @@
+.TH MKIMAGE 1 "2010-05-16"
+
+.SH NAME
+mkimage \- Generate image for U-Boot
+.SH SYNOPSIS
+.B mkimage
+.RB [\fIoptions\fP]
+.SH "DESCRIPTION"
+The
+.B mkimage
+command is used to create images for use with the U-Boot boot loader.
+Thes eimages can contain the linux kernel, device tree blob, root file
+system image, firmware images etc., either separate or combined.
+
+.B mkimage
+supports two different formats:
+
+The old,
+.I legacy image
+format concatenates the individual parts (for example, kernel image,
+device tree blob and ramdisk image) and adds a 64 bytes header
+containing information about target architecture, operating system,
+image type, compression method, entry points, time stamp, checksums,
+etc.
+
+The new,
+.I FIT (Flattened Image Tree) format
+allows for more flexibility in handling images of various and also
+enhances integrity protection of images with stronger checksums.
+
+.SH "OPTIONS"
+
+.B List image information:
+
+.TP
+.BI "\-l [" "uimage file name" "]"
+mkimage lists the information contained in the header of an existing U-Boot image.
+
+.P
+.B Create old legacy image:
+
+.TP
+.BI "\-A [" "architecture" "]"
+Set architecture. Pass \-h as the architecture to see the list of supported architectures.
+
+.TP
+.BI "\-O [" "os" "]"
+Set operating system. bootm command of u-boot changes boot method by os type.
+Pass \-h as the OS to see the list of supported OS.
+
+.TP
+.BI "\-T [" "image type" "]"
+Set image type.
+Pass \-h as the image to see the list of supported image type.
+
+.TP
+.BI "\-C [" "compression type" "]"
+Set compression type.
+Pass \-h as the compression to see the list of supported compression type.
+
+.TP
+.BI "\-a [" "load addess" "]"
+Set load address with a hex number.
+
+.TP
+.BI "\-e [" "entry point" "]"
+Set entry point with a hex number.
+
+.TP
+.BI "\-n [" "image name" "]"
+Set image name to 'image name'.
+
+.TP
+.BI "\-d [" "image data file" "]"
+Use image data from 'image data file'.
+
+.TP
+.BI "\-x"
+Set XIP (execute in place) flag.
+
+.P
+.B Create FIT image:
+
+.TP
+.BI "\-D "dtc option"
+Provide special options to the device tree compiler that is used to
+create the image.
+
+.TP
+.BI "\-f "fit-image.its"
+Image tree source fine that descbres the structure and contents of the
+FIT image.
+
+.SH EXMAPLES
+
+List image information:
+.nf
+.B mkimage -l uImage
+.fi
+.P
+Create legacy image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -A powerpc -O linux -T kernel -C gzip \\\\
+.br
+.B -a 0 -e 0 -n Linux -d vmlinux.gz uImage
+.fi
+.P
+Create FIT image with compressed PowerPC Linux kernel:
+.nf
+.B mkimage -f kernel.its kernel.itb
+.fi
+
+.SH HOMEPAGE
+http://www.denx.de/wiki/U-Boot/WebHome
+.PP
+.SH AUTHOR
+This manual page was written by Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+and Wolfgang Denk <wd@denx.de>
diff --git a/u-boot/doc/uImage.FIT/command_syntax_extensions.txt b/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
new file mode 100644
index 0000000..002818c
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/command_syntax_extensions.txt
@@ -0,0 +1,191 @@
+Command syntax extensions for the new uImage format
+===================================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+With the introduction of the new uImage format, bootm command (and other
+commands as well) have to understand new syntax of the arguments. This is
+necessary in order to specify objects contained in the new uImage, on which
+bootm has to operate. This note attempts to first summarize bootm usage
+scenarios, and then introduces new argument syntax.
+
+
+bootm usage scenarios
+---------------------
+
+Below is a summary of bootm usage scenarios, focused on booting a PowerPC
+Linux kernel. The purpose of the following list is to document a complete list
+of supported bootm usages.
+
+Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
+i.e., without passing the Flattened Device Tree (FDT), and new way, where the
+kernel is passed a pointer to the FDT. The boot method is indicated for each
+scenario.
+
+
+1.  bootm		boot image at the current address, equivalent to 2,3,8
+
+Old uImage:
+2.  bootm <addr1>		    /* single image at <addr1> */
+3.  bootm <addr1>		    /* multi-image at <addr1>  */
+4.  bootm <addr1> -		    /* multi-image at <addr1>  */
+5.  bootm <addr1> <addr2>	    /* single image at <addr1> */
+6.  bootm <addr1> <addr2> <addr3>   /* single image at <addr1> */
+7.  bootm <addr1> -	  <addr3>   /* single image at <addr1> */
+
+New uImage:
+8.  bootm <addr1>
+9.  bootm [<addr1>]:<subimg1>
+10. bootm [<addr1>]#<conf>
+11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
+12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
+13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
+14. bootm [<addr1>]:<subimg1> -			  [<addr3>]:<subimg3>
+15. bootm [<addr1>]:<subimg1> -			  <addr3>
+
+
+Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
+the current image address.
+- boot method: see cases 2,3,8
+
+Ad. 2. Boot kernel image located at <addr1>.
+- boot method: non-FDT
+
+Ad. 3. First and second components of the image at <addr1> are assumed to be a
+kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
+with the ramdisk from the image.
+- boot method: depends on the number of components at <addr1>, and on whether
+  U-Boot is compiled with OF support:
+
+		    |	       2 components |	       3 components |
+		    |	   (kernel, initrd) | (kernel, initrd, fdt) |
+---------------------------------------------------------------------
+#ifdef CONFIG_OF_*  |		    non-FDT |			FDT |
+#ifndef CONFIG_OF_* |		    non-FDT |		    non-FDT |
+
+Ad. 4. Similar to case 3, but the kernel is booted without initrd.  Second
+component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
+- boot method: see case 3
+
+Ad. 5. Boot kernel image located at <addr1> with initrd loaded with ramdisk
+from the image at <addr2>.
+- boot method: non-FDT
+
+Ad. 6. <addr1> is the address of a kernel image, <addr2> is the address of a
+ramdisk image, and <addr3> is the address of a FDT binary blob.  Kernel is
+booted with initrd loaded with ramdisk from the image at <addr2>.
+- boot method: FDT
+
+Ad. 7. <addr1> is the address of a kernel image and <addr3> is the address of
+a FDT binary blob. Kernel is booted without initrd.
+- boot method: FDT
+
+Ad. 8. Image at <addr1> is assumed to contain a default configuration, which
+is booted.
+- boot method: FDT or non-FDT, depending on whether the default configuration
+  defines FDT
+
+Ad. 9. Similar to case 2: boot kernel stored in <subimg1> from the image at
+address <addr1>.
+- boot method: non-FDT
+
+Ad. 10. Boot configuration <conf> from the image at <addr1>.
+- boot method: FDT or non-FDT, depending on whether the configuration given
+  defines FDT
+
+Ad. 11. Equivalent to case 5: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>.
+- boot method: non-FDT
+
+Ad. 12. Equivalent to case 6: boot kernel stored in <subimg1> from the image
+at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
+<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
+- boot method: FDT
+
+Ad. 13. Similar to case 12, the difference being that <addr3> is the address
+of FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+Ad. 14. Equivalent to case 7: boot kernel stored in <subimg1> from the image
+at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
+<addr3>.
+- boot method: FDT
+
+Ad. 15. Similar to case 14, the difference being that <addr3> is the address
+of the FDT binary blob that is to be passed to the kernel.
+- boot method: FDT
+
+
+New uImage argument syntax
+--------------------------
+
+New uImage support introduces two new forms for bootm arguments, with the
+following syntax:
+
+- new uImage sub-image specification
+<addr>:<sub-image unit_name>
+
+- new uImage configuration specification
+<addr>#<configuration unit_name>
+
+
+Examples:
+
+- boot kernel "kernel@1" stored in a new uImage located at 200000:
+bootm 200000:kernel@1
+
+- boot configuration "cfg@1" from a new uImage located at 200000:
+bootm 200000#cfg@1
+
+- boot "kernel@1" from a new uImage at 200000 with initrd "ramdisk@2" found in
+  some other new uImage stored at address 800000:
+bootm 200000:kernel@1 800000:ramdisk@2
+
+- boot "kernel@2" from a new uImage at 200000, with initrd "ramdisk@1" and FDT
+  "fdt@1", both stored in some other new uImage located at 800000:
+bootm 200000:kernel@1 800000:ramdisk@1 800000:fdt@1
+
+- boot kernel "kernel@2" with initrd "ramdisk@2", both stored in a new uImage
+  at address 200000, with a raw FDT blob stored at address 600000:
+bootm 200000:kernel@2 200000:ramdisk@2 600000
+
+- boot kernel "kernel@2" from new uImage at 200000 with FDT "fdt@1" from the
+  same new uImage:
+bootm 200000:kernel@2 - 200000:fdt@1
+
+
+Note on current image address
+-----------------------------
+
+When bootm is called without arguments, the image at current image address is
+booted. The current image address is the address set most recently by a load
+command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example, consider
+the following commands:
+
+tftp 200000 /tftpboot/kernel
+bootm
+Last command is equivalent to:
+bootm 200000
+
+In case of the new uImage argument syntax, the address portion of any argument
+can be omitted. If <addr3> is omitted, then it is assumed that image at
+<addr2> should be used. Similarly, when <addr2> is omitted, is is assumed that
+image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
+current image address is to be used. For example, consider the following
+commands:
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel@1
+Last command is equivalent to:
+bootm 200000:kernel@1
+
+tftp 200000 /tftpboot/uImage
+bootm 400000:kernel@1 :ramdisk@1
+Last command is equivalent to:
+bootm 400000:kernel@1 400000:ramdisk@1
+
+tftp 200000 /tftpboot/uImage
+bootm :kernel@1 400000:ramdisk@1 :fdt@1
+Last command is equivalent to:
+bootm 200000:kernel@1 400000:ramdisk@1 400000:fdt@1
diff --git a/u-boot/doc/uImage.FIT/howto.txt b/u-boot/doc/uImage.FIT/howto.txt
new file mode 100644
index 0000000..59e21e9
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/howto.txt
@@ -0,0 +1,297 @@
+How to use images in the new image format
+=========================================
+
+Author: Bartlomiej Sieka <tur@semihalf.com>
+
+
+Overview
+--------
+
+The new uImage format allows more flexibility in handling images of various
+types (kernel, ramdisk, etc.), it also enhances integrity protection of images
+with sha1 and md5 checksums.
+
+Two auxiliary tools are needed on the development host system in order to
+create an uImage in the new format: mkimage and dtc, although only one
+(mkimage) is invoked directly. dtc is called from within mkimage and operates
+behind the scenes, but needs to be present in the $PATH nevertheless. It is
+important that the dtc used has support for binary includes -- refer to
+www.jdl.com for its latest version. mkimage (together with dtc) takes as input
+an image source file, which describes the contents of the image and defines
+its various properties used during booting. By convention, image source file
+has the ".its" extension, also, the details of its format are given in
+doc/source_file_format.txt. The actual data that is to be included in the
+uImage (kernel, ramdisk, etc.) is specified in the image source file in the
+form of paths to appropriate data files. The outcome of the image creation
+process is a binary file (by convention with the ".itb" extension) that
+contains all the referenced data (kernel, ramdisk, etc.) and other information
+needed by U-Boot to handle the uImage properly. The uImage file is then
+transferred to the target (e.g., via tftp) and booted using the bootm command.
+
+To summarize the prerequisites needed for new uImage creation:
+- mkimage
+- dtc (with support for binary includes)
+- image source file (*.its)
+- image data file(s)
+
+
+Here's a graphical overview of the image creation and booting process:
+
+image source file     mkimage + dtc		  transfer to target
+	+	     ---------------> image file --------------------> bootm
+image data files(s)
+
+
+Example 1 -- old-style (non-FDT) kernel booting
+-----------------------------------------------
+
+Consider a simple scenario, where a PPC Linux kernel built from sources on the
+development host is to be booted old-style (non-FDT) by U-Boot on an embedded
+target. Assume that the outcome of the build is vmlinux.bin.gz, a file which
+contains a gzip-compressed PPC Linux kernel (the only data file in this case).
+The uImage can be produced using the image source file
+doc/uImage.FIT/kernel.its (note that kernel.its assumes that vmlinux.bin.gz is
+in the current working directory; if desired, an alternative path can be
+specified in the kernel.its file). Here's how to create the image and inspect
+its contents:
+
+[on the host system]
+$ mkimage -f kernel.its kernel.itb
+DTC: dts->dtb  on file "kernel.its"
+$
+$ mkimage -l kernel.itb
+FIT description: Simple image with single Linux kernel
+Created:	 Tue Mar 11 17:26:15 2008
+ Image 0 (kernel@1)
+  Description:	Vanilla Linux kernel
+  Type:		Kernel Image
+  Compression:	gzip compressed
+  Data Size:	943347 Bytes = 921.24 kB = 0.90 MB
+  Architecture: PowerPC
+  OS:		Linux
+  Load Address: 0x00000000
+  Entry Point:	0x00000000
+  Hash algo:	crc32
+  Hash value:	2ae2bb40
+  Hash algo:	sha1
+  Hash value:	3c200f34e2c226ddc789240cca0c59fc54a67cf4
+ Default Configuration: 'config@1'
+ Configuration 0 (config@1)
+  Description:	Boot Linux kernel
+  Kernel:	kernel@1
+
+
+The resulting image file kernel.itb can be now transferred to the target,
+inspected and booted (note that first three U-Boot commands below are shown
+for completeness -- they are part of the standard booting procedure and not
+specific to the new image format).
+
+[on the target system]
+=> print nfsargs
+nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
+=> print addip
+addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
+=> run nfsargs addip
+=> tftp 900000 /path/to/tftp/location/kernel.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel.itb'.
+Load address: 0x900000
+Loading: #################################################################
+done
+Bytes transferred = 944464 (e6950 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+   FIT image found
+   FIT description: Simple image with single Linux kernel
+   Created:	    2008-03-11	16:26:15 UTC
+    Image 0 (kernel@1)
+     Description:  Vanilla Linux kernel
+     Type:	   Kernel Image
+     Compression:  gzip compressed
+     Data Start:   0x009000e0
+     Data Size:    943347 Bytes = 921.2 kB
+     Architecture: PowerPC
+     OS:	   Linux
+     Load Address: 0x00000000
+     Entry Point:  0x00000000
+     Hash algo:    crc32
+     Hash value:   2ae2bb40
+     Hash algo:    sha1
+     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+    Default Configuration: 'config@1'
+    Configuration 0 (config@1)
+     Description:  Boot Linux kernel
+     Kernel:	   kernel@1
+
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+   Using 'config@1' configuration
+   Trying 'kernel@1' kernel subimage
+     Description:  Vanilla Linux kernel
+     Type:	   Kernel Image
+     Compression:  gzip compressed
+     Data Start:   0x009000e0
+     Data Size:    943347 Bytes = 921.2 kB
+     Architecture: PowerPC
+     OS:	   Linux
+     Load Address: 0x00000000
+     Entry Point:  0x00000000
+     Hash algo:    crc32
+     Hash value:   2ae2bb40
+     Hash algo:    sha1
+     Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+   Verifying Hash Integrity ... crc32+ sha1+ OK
+   Uncompressing Kernel Image ... OK
+Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
+Linux version 2.4.25 (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #2 czw lip 5 17:56:18 CEST 2007
+On node 0 totalpages: 65536
+zone(0): 65536 pages.
+zone(1): 0 pages.
+zone(2): 0 pages.
+Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_6xx ip=192.168.160.5:192.168.1.1::255.255.0.0:lite5200b:eth0:off panic=1
+Calibrating delay loop... 307.20 BogoMIPS
+
+
+Example 2 -- new-style (FDT) kernel booting
+-------------------------------------------
+
+Consider another simple scenario, where a PPC Linux kernel is to be booted
+new-style, i.e., with a FDT blob. In this case there are two prerequisite data
+files: vmlinux.bin.gz (Linux kernel) and target.dtb (FDT blob). The uImage can
+be produced using image source file doc/uImage.FIT/kernel_fdt.its like this
+(note again, that both prerequisite data files are assumed to be present in
+the current working directory -- image source file kernel_fdt.its can be
+modified to take the files from some other location if needed):
+
+[on the host system]
+$ mkimage -f kernel_fdt.its kernel_fdt.itb
+DTC: dts->dtb  on file "kernel_fdt.its"
+$
+$ mkimage -l kernel_fdt.itb
+FIT description: Simple image with single Linux kernel and FDT blob
+Created:	 Tue Mar 11 16:29:22 2008
+ Image 0 (kernel@1)
+  Description:	Vanilla Linux kernel
+  Type:		Kernel Image
+  Compression:	gzip compressed
+  Data Size:	1092037 Bytes = 1066.44 kB = 1.04 MB
+  Architecture: PowerPC
+  OS:		Linux
+  Load Address: 0x00000000
+  Entry Point:	0x00000000
+  Hash algo:	crc32
+  Hash value:	2c0cc807
+  Hash algo:	sha1
+  Hash value:	264b59935470e42c418744f83935d44cdf59a3bb
+ Image 1 (fdt@1)
+  Description:	Flattened Device Tree blob
+  Type:		Flat Device Tree
+  Compression:	uncompressed
+  Data Size:	16384 Bytes = 16.00 kB = 0.02 MB
+  Architecture: PowerPC
+  Hash algo:	crc32
+  Hash value:	0d655d71
+  Hash algo:	sha1
+  Hash value:	25ab4e15cd4b8a5144610394560d9c318ce52def
+ Default Configuration: 'conf@1'
+ Configuration 0 (conf@1)
+  Description:	Boot Linux kernel with FDT blob
+  Kernel:	kernel@1
+  FDT:		fdt@1
+
+
+The resulting image file kernel_fdt.itb can be now transferred to the target,
+inspected and booted:
+
+[on the target system]
+=> tftp 900000 /path/to/tftp/location/kernel_fdt.itb
+Using FEC device
+TFTP from server 192.168.1.1; our IP address is 192.168.160.5
+Filename '/path/to/tftp/location/kernel_fdt.itb'.
+Load address: 0x900000
+Loading: #################################################################
+	 ###########
+done
+Bytes transferred = 1109776 (10ef10 hex)
+=> iminfo
+
+## Checking Image at 00900000 ...
+   FIT image found
+   FIT description: Simple image with single Linux kernel and FDT blob
+   Created:	    2008-03-11	15:29:22 UTC
+    Image 0 (kernel@1)
+     Description:  Vanilla Linux kernel
+     Type:	   Kernel Image
+     Compression:  gzip compressed
+     Data Start:   0x009000ec
+     Data Size:    1092037 Bytes =  1 MB
+     Architecture: PowerPC
+     OS:	   Linux
+     Load Address: 0x00000000
+     Entry Point:  0x00000000
+     Hash algo:    crc32
+     Hash value:   2c0cc807
+     Hash algo:    sha1
+     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+    Image 1 (fdt@1)
+     Description:  Flattened Device Tree blob
+     Type:	   Flat Device Tree
+     Compression:  uncompressed
+     Data Start:   0x00a0abdc
+     Data Size:    16384 Bytes = 16 kB
+     Architecture: PowerPC
+     Hash algo:    crc32
+     Hash value:   0d655d71
+     Hash algo:    sha1
+     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+    Default Configuration: 'conf@1'
+    Configuration 0 (conf@1)
+     Description:  Boot Linux kernel with FDT blob
+     Kernel:	   kernel@1
+     FDT:	   fdt@1
+=> bootm
+## Booting kernel from FIT Image at 00900000 ...
+   Using 'conf@1' configuration
+   Trying 'kernel@1' kernel subimage
+     Description:  Vanilla Linux kernel
+     Type:	   Kernel Image
+     Compression:  gzip compressed
+     Data Start:   0x009000ec
+     Data Size:    1092037 Bytes =  1 MB
+     Architecture: PowerPC
+     OS:	   Linux
+     Load Address: 0x00000000
+     Entry Point:  0x00000000
+     Hash algo:    crc32
+     Hash value:   2c0cc807
+     Hash algo:    sha1
+     Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+   Verifying Hash Integrity ... crc32+ sha1+ OK
+   Uncompressing Kernel Image ... OK
+## Flattened Device Tree from FIT Image at 00900000
+   Using 'conf@1' configuration
+   Trying 'fdt@1' FDT blob subimage
+     Description:  Flattened Device Tree blob
+     Type:	   Flat Device Tree
+     Compression:  uncompressed
+     Data Start:   0x00a0abdc
+     Data Size:    16384 Bytes = 16 kB
+     Architecture: PowerPC
+     Hash algo:    crc32
+     Hash value:   0d655d71
+     Hash algo:    sha1
+     Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+   Verifying Hash Integrity ... crc32+ sha1+ OK
+   Booting using the fdt blob at 0xa0abdc
+   Loading Device Tree to 007fc000, end 007fffff ... OK
+[    0.000000] Using lite5200 machine description
+[    0.000000] Linux version 2.6.24-rc6-gaebecdfc (m8@hekate) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 Sat Jan 12 15:38:48 CET 2008
+
+
+Example 3 -- advanced booting
+-----------------------------
+
+Refer to doc/uImage.FIT/multi.its for an image source file that allows more
+sophisticated booting scenarios (multiple kernels, ramdisks and fdt blobs).
diff --git a/u-boot/doc/uImage.FIT/kernel.its b/u-boot/doc/uImage.FIT/kernel.its
new file mode 100644
index 0000000..ef3ab8f
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/kernel.its
@@ -0,0 +1,37 @@
+/*
+ * Simple U-boot uImage source file containing a single kernel
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Simple image with single Linux kernel";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = "Vanilla Linux kernel";
+			data = /incbin/("./vmlinux.bin.gz");
+			type = "kernel";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "crc32";
+			};
+			hash@2 {
+				algo = "sha1";
+			};
+		};
+	};
+
+	configurations {
+		default = "config@1";
+		config@1 {
+			description = "Boot Linux kernel";
+			kernel = "kernel@1";
+		};
+	};
+};
diff --git a/u-boot/doc/uImage.FIT/kernel_fdt.its b/u-boot/doc/uImage.FIT/kernel_fdt.its
new file mode 100644
index 0000000..7e940d2
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/kernel_fdt.its
@@ -0,0 +1,51 @@
+/*
+ * Simple U-boot uImage source file containing a single kernel and FDT blob
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Simple image with single Linux kernel and FDT blob";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = "Vanilla Linux kernel";
+			data = /incbin/("./vmlinux.bin.gz");
+			type = "kernel";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "crc32";
+			};
+			hash@2 {
+				algo = "sha1";
+			};
+		};
+		fdt@1 {
+			description = "Flattened Device Tree blob";
+			data = /incbin/("./target.dtb");
+			type = "flat_dt";
+			arch = "ppc";
+			compression = "none";
+			hash@1 {
+				algo = "crc32";
+			};
+			hash@2 {
+				algo = "sha1";
+			};
+		};
+	};
+
+	configurations {
+		default = "conf@1";
+		conf@1 {
+			description = "Boot Linux kernel with FDT blob";
+			kernel = "kernel@1";
+			fdt = "fdt@1";
+		};
+	};
+};
diff --git a/u-boot/doc/uImage.FIT/multi.its b/u-boot/doc/uImage.FIT/multi.its
new file mode 100644
index 0000000..881b749
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/multi.its
@@ -0,0 +1,133 @@
+/*
+ * U-boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Various kernels, ramdisks and FDT blobs";
+	#address-cells = <1>;
+
+	images {
+		kernel@1 {
+			description = "vanilla-2.6.23";
+			data = /incbin/("./vmlinux.bin.gz");
+			type = "kernel";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "md5";
+			};
+			hash@2 {
+				algo = "sha1";
+			};
+		};
+
+		kernel@2 {
+			description = "2.6.23-denx";
+			data = /incbin/("./2.6.23-denx.bin.gz");
+			type = "kernel";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+
+		kernel@3 {
+			description = "2.4.25-denx";
+			data = /incbin/("./2.4.25-denx.bin.gz");
+			type = "kernel";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "md5";
+			};
+		};
+
+		ramdisk@1 {
+			description = "eldk-4.2-ramdisk";
+			data = /incbin/("./eldk-4.2-ramdisk");
+			type = "ramdisk";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+
+		ramdisk@2 {
+			description = "eldk-3.1-ramdisk";
+			data = /incbin/("./eldk-3.1-ramdisk");
+			type = "ramdisk";
+			arch = "ppc";
+			os = "linux";
+			compression = "gzip";
+			load = <00000000>;
+			entry = <00000000>;
+			hash@1 {
+				algo = "crc32";
+			};
+		};
+
+		fdt@1 {
+			description = "tqm5200-fdt";
+			data = /incbin/("./tqm5200.dtb");
+			type = "flat_dt";
+			arch = "ppc";
+			compression = "none";
+			hash@1 {
+				algo = "crc32";
+			};
+		};
+
+		fdt@2 {
+			description = "tqm5200s-fdt";
+			data = /incbin/("./tqm5200s.dtb");
+			type = "flat_dt";
+			arch = "ppc";
+			compression = "none";
+			load = <00700000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+
+	};
+
+	configurations {
+		default = "config@1";
+
+		config@1 {
+			description = "tqm5200 vanilla-2.6.23 configuration";
+			kernel = "kernel@1";
+			ramdisk = "ramdisk@1";
+			fdt = "fdt@1";
+		};
+
+		config@2 {
+			description = "tqm5200s denx-2.6.23 configuration";
+			kernel = "kernel@2";
+			ramdisk = "ramdisk@1";
+			fdt = "fdt@2";
+		};
+
+		config@3 {
+			description = "tqm5200s denx-2.4.25 configuration";
+			kernel = "kernel@3";
+			ramdisk = "ramdisk@2";
+		};
+	};
+};
diff --git a/u-boot/doc/uImage.FIT/source_file_format.txt b/u-boot/doc/uImage.FIT/source_file_format.txt
new file mode 100644
index 0000000..6d20707
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/source_file_format.txt
@@ -0,0 +1,261 @@
+U-boot new uImage source file format (bindings definition)
+==========================================================
+
+Author: Marian Balakowicz <m8@semihalf.com>
+
+1) Introduction
+---------------
+
+Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new
+booting method which requires that hardware description is available to the
+kernel in the form of Flattened Device Tree.
+
+Booting with a Flattened Device Tree is much more flexible and is intended to
+replace direct passing of 'struct bd_info' which was used to boot pre-FDT
+kernels.
+
+However, U-boot needs to support both techniques to provide backward
+compatibility for platforms which are not FDT ready. Number of elements
+playing role in the booting process has increased and now includes the FDT
+blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
+in the system memory and passed to bootm as a arguments. Some of them may be
+missing: FDT is not present for legacy platforms, ramdisk is always optional.
+Additionally, old uImage format has been extended to support multi sub-images
+but the support is limited by simple format of the legacy uImage structure.
+Single binary header 'struct image_header' is not flexible enough to cover all
+possible scenarios.
+
+All those factors combined clearly show that there is a need for new, more
+flexible, multi component uImage format.
+
+
+2) New uImage format assumptions
+--------------------------------
+
+a) Implementation
+
+Libfdt has been selected for the new uImage format implementation as (1) it
+provides needed functionality, (2) is actively maintained and developed and
+(3) increases code reuse as it is already part of the U-boot source tree.
+
+b) Terminology
+
+This document defines new uImage structure by providing FDT bindings for new
+uImage internals. Bindings are defined from U-boot perspective, i.e. describe
+final form of the uImage at the moment when it reaches U-boot. User
+perspective may be simpler, as some of the properties (like timestamps and
+hashes) will need to be filled in automatically by the U-boot mkimage tool.
+
+To avoid confusion with the kernel FDT the following naming convention is
+proposed for the new uImage format related terms:
+
+FIT	- Flattened uImage Tree
+
+FIT is formally a flattened device tree (in the libfdt meaning), which
+conforms to bindings defined in this document.
+
+.its	- image tree source
+.itb	- image tree blob
+
+c) Image building procedure
+
+The following picture shows how the new uImage is prepared. Input consists of
+image source file (.its) and a set of data files. Image is created with the
+help of standard U-boot mkimage tool which in turn uses dtc (device tree
+compiler) to produce image tree blob (.itb).  Resulting .itb file is is the
+actual binary of a new uImage.
+
+
+tqm5200.its
++
+vmlinux.bin.gz	   mkimage + dtc	       xfer to target
+eldk-4.2-ramdisk  --------------> tqm5200.itb --------------> bootm
+tqm5200.dtb			     /|\
+...				      |
+				 'new uImage'
+
+	- create .its file, automatically filled-in properties are omitted
+	- call mkimage tool on a .its file
+	- mkimage calls dtc to create .itb image and assures that
+	  missing properties are added
+	- .itb (new uImage) is uploaded onto the target and used therein
+
+
+d) Unique identifiers
+
+To identify FIT sub-nodes representing images, hashes, configurations (which
+are defined in the following sections), the "unit name" of the given sub-node
+is used as it's identifier as it assures uniqueness without additional
+checking required.
+
+
+3) Root node properties
+-----------------------
+
+Root node of the uImage Tree should have the following layout:
+
+/ o image-tree
+    |- description = "image description"
+    |- timestamp = <12399321>
+    |- #address-cells = <1>
+    |
+    o images
+    | |
+    | o img@1 {...}
+    | o img@2 {...}
+    | ...
+    |
+    o configurations
+      |- default = "cfg@1"
+      |
+      o cfg@1 {...}
+      o cfg@2 {...}
+      ...
+
+
+  Optional property:
+  - description : Textual description of the uImage
+
+  Mandatory property:
+  - timestamp : Last image modification time being counted in seconds since
+    1970-01-01 00:00:00 - to be automatically calculated by mkimage tool.
+
+  Conditionally mandatory property:
+  - #address-cells : Number of 32bit cells required to represent entry and
+    load addresses supplied within sub-image nodes. May be omitted when no
+    entry or load addresses are used.
+
+  Mandatory node:
+  - images : This node contains a set of sub-nodes, each of them representing
+    single component sub-image (like kernel, ramdisk, etc.). At least one
+    sub-image is required.
+
+  Optional node:
+  - configurations : Contains a set of available configuration nodes and
+    defines a default configuration.
+
+
+4) '/images' node
+-----------------
+
+This node is a container node for component sub-image nodes. Each sub-node of
+the '/images' node should have the following layout:
+
+ o image@1
+   |- description = "component sub-image description"
+   |- data = /incbin/("path/to/data/file.bin")
+   |- type = "sub-image type name"
+   |- arch = "ARCH name"
+   |- os = "OS name"
+   |- compression = "compression name"
+   |- load = <00000000>
+   |- entry = <00000000>
+   |
+   o hash@1 {...}
+   o hash@2 {...}
+   ...
+
+  Mandatory properties:
+  - description : Textual description of the component sub-image
+  - type : Name of component sub-image type, supported types are:
+    "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
+    "fdt".
+  - data : Path to the external file which contains this node's binary data.
+  - compression : Compression used by included data. Supported compressions
+    are "gzip" and "bzip2". If no compression is used compression property
+    should be set to "none".
+
+  Conditionally mandatory property:
+  - os : OS name, mandatory for type="kernel", valid OS names are: "openbsd",
+    "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", "solaris", "irix",
+    "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx", "u_boot",
+    "rtems", "unity", "integrity".
+  - arch : Architecture name, mandatory for types: "standalone", "kernel",
+    "firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
+    "arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
+    "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200".
+  - entry : entry point address, address size is determined by
+    '#address-cells' property of the root node. Mandatory for for types:
+    "standalone" and "kernel".
+  - load : load address, address size is determined by '#address-cells'
+    property of the root node. Mandatory for types: "standalone" and "kernel".
+
+  Optional nodes:
+  - hash@1 : Each hash sub-node represents separate hash or checksum
+    calculated for node's data according to specified algorithm.
+
+
+5) Hash nodes
+-------------
+
+o hash@1
+  |- algo = "hash or checksum algorithm name"
+  |- value = [hash or checksum value]
+
+  Mandatory properties:
+  - algo : Algorithm name, supported are "crc32", "md5" and "sha1".
+  - value : Actual checksum or hash value, correspondingly 4, 16 or 20 bytes
+    long.
+
+
+6) '/configurations' node
+-------------------------
+
+The 'configurations' node is optional. If present, it allows to create a
+convenient, labeled boot configurations, which combine together kernel images
+with their ramdisks and fdt blobs.
+
+The 'configurations' node has has the following structure:
+
+o configurations
+  |- default = "default configuration sub-node unit name"
+  |
+  o config@1 {...}
+  o config@2 {...}
+  ...
+
+
+  Optional property:
+  - default : Selects one of the configuration sub-nodes as a default
+    configuration.
+
+  Mandatory nodes:
+  - configuration-sub-node-unit-name : At least one of the configuration
+    sub-nodes is required.
+
+
+7) Configuration nodes
+----------------------
+
+Each configuration has the following structure:
+
+o config@1
+  |- description = "configuration description"
+  |- kernel = "kernel sub-node unit name"
+  |- ramdisk = "ramdisk sub-node unit name"
+  |- fdt = "fdt sub-node unit-name"
+
+
+  Mandatory properties:
+  - description : Textual configuration description.
+  - kernel : Unit name of the corresponding kernel image (image sub-node of a
+    "kernel" type).
+
+  Optional properties:
+  - ramdisk : Unit name of the corresponding ramdisk image (component image
+    node of a "ramdisk" type).
+  - fdt : Unit name of the corresponding fdt blob (component image node of a
+    "fdt type").
+
+The FDT blob is required to properly boot FDT based kernel, so the minimal
+configuration for 2.6 FDT kernel is (kernel, fdt) pair.
+
+Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
+'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
+not* be specified in a configuration node.
+
+
+8) Examples
+-----------
+
+Please see doc/uImage.FIT/*.its for actual image source files.
diff --git a/u-boot/doc/uImage.FIT/update3.its b/u-boot/doc/uImage.FIT/update3.its
new file mode 100644
index 0000000..a6eaef6
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/update3.its
@@ -0,0 +1,44 @@
+/*
+ * Example Automatic software update file.
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Automatic software updates: kernel, ramdisk, FDT";
+	#address-cells = <1>;
+
+	images {
+		update@1 {
+			description = "Linux kernel binary";
+			data = /incbin/("./vmlinux.bin.gz");
+			compression = "none";
+			type = "firmware";
+			load = <FF700000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+		update@2 {
+			description = "Ramdisk image";
+			data = /incbin/("./ramdisk_image.gz");
+			compression = "none";
+			type = "firmware";
+			load = <FF8E0000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+
+		update@3 {
+			description = "FDT blob";
+			data = /incbin/("./blob.fdt");
+			compression = "none";
+			type = "firmware";
+			load = <FFAC0000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+	};
+};
diff --git a/u-boot/doc/uImage.FIT/update_uboot.its b/u-boot/doc/uImage.FIT/update_uboot.its
new file mode 100644
index 0000000..846723e
--- /dev/null
+++ b/u-boot/doc/uImage.FIT/update_uboot.its
@@ -0,0 +1,24 @@
+/*
+ * Automatic software update for U-Boot
+ * Make sure the flashing addresses ('load' prop) is correct for your board!
+ */
+
+/dts-v1/;
+
+/ {
+	description = "Automatic U-Boot update";
+	#address-cells = <1>;
+
+	images {
+		update@1 {
+			description = "U-Boot binary";
+			data = /incbin/("./u-boot.bin");
+			compression = "none";
+			type = "firmware";
+			load = <FFFC0000>;
+			hash@1 {
+				algo = "sha1";
+			};
+		};
+	};
+};