Merge with /home/wd/git/u-boot/master

5 files changed, 279 insertions, 14 deletions

diff --git a/doc/README.AVR32 b/doc/README.AVR32
new file mode 100644
index 0000000..abec872
--- /dev/null
+++ b/doc/README.AVR32
@@ -0,0 +1,33 @@
+From: Haavard Skinnemoen <hskinnemoen@atmel.com>
+Date: Wed, 30 Aug 2006 17:01:46 +0200
+Subject: [PATCH] AVR32 architecture support
+
+This patch adds common infrastructure code for the Atmel AVR32
+architecture.
+
+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 is included with the ATSTK1000
+BSP, which can be downloaded as an ISO image from
+
+http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918
+
+Alternatively, you can build it yourself by following the
+Getting Started guide at avr32linux.org, which also provides links
+to the necessary sources and patches you need to download:
+
+http://avr32linux.org/twiki/bin/view/Main/GettingStarted
+
+The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and
+other associated software are actively supported by Atmel Corporation.
+
+Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
diff --git a/doc/README.mpc85xxads b/doc/README.mpc85xxads
index f0cf782..ae8202b 100644
--- a/doc/README.mpc85xxads
+++ b/doc/README.mpc85xxads
@@ -100,6 +100,9 @@ Updated 13-July-2004 Jon Loeliger
 	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
 
diff --git a/doc/README.mpc8641hpcn b/doc/README.mpc8641hpcn
new file mode 100644
index 0000000..4a650ce
--- /dev/null
+++ b/doc/README.mpc8641hpcn
@@ -0,0 +1,123 @@
+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	CFG_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		CFG_SYSCLK	= 000	:: SYSCLK = 33MHz
+						  001	:: SYSCLK = 40MHz
+
+	SW2(1-4) = 1100		CFG_CCBPLL	= 0010	:: 2X
+						  0100	:: 4X
+						  0110	:: 6X
+						  1000	:: 8X
+						  1010	:: 10X
+						  1100	:: 12X
+						  1110	:: 14X
+						  0000	:: 16X
+	SW2(5-8) = 1110		CFG_BOOTLOC	= 1110	:: boot 16-bit localbus
+
+	SW3(1-7) = 0011000	CFG_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		CFG_HOSTMODE	= 11	:: both prots host/root
+	SW4(3-4) = 11		CFG_BOOTSEQ	= 11	:: no boot seq
+	SW4(5-8) = 0011		CFG_IOPORT	= 0011	:: both PEX
+
+	SW5(1)	 = 1		CFG_FLASHMAP	= 1	:: boot from flash
+						  0	:: boot from PromJet
+	SW5(2)	 = 1		CFG_FLASHBANK	= 1	:: swap upper/lower
+							 halves (virtual banks)
+						  0	:: normal
+	SW5(3)	 = 0		CFG_FLASHWP	= 0	:: not protected
+	SW5(4)	 = 0 		CFG_PORTDIV	= 1	:: 2:1 for PD4
+							   1:1 for PD6
+	SW5(5-6) = 11		CFG_PIXISOPT	= 11	:: s/w determined
+	SW5(7-8) = 11		CFG_LADOPT	= 11	:: s/w determined
+
+	SW6(1)	 = 1		CFG_CPUBOOT	= 1	:: no boot holdoff
+	SW6(2)	 = 1		CFG_BOOTADDR	= 1	:: no traslation
+	SW6(3-5) = 000		CFG_REFCLKSEL	= 000	:: 100MHZ
+	SW6(6)	 = 1		CFG_SERROM_ADDR= 1	::
+	SW6(7)	 = 1		CFG_MEMDEBUG	= 1	::
+	SW6(8)	 = 1		CFG_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		CFG_IDWP	= 0	:: write enable
+
+
+3. Flash U-Boot
+---------------
+The flash range 0xFF800000 to 0xFFFFFFFF 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.
+
+0xFF800000 to 0xFFBFFFFF - 4MB
+0xFFC00000 to 0xFFFFFFFF - 4MB
+When this bit is 0, U-Boot is at 0xFFF00000.
+When this bit is 1, U-Boot is at 0xFFB00000.
+
+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 0xFFF00000.
+
+To Flash U-Boot into the booting bank (0xFFC00000 - 0xFFFFFFFF):
+
+	tftp 1000000 u-boot.bin
+	protect off all
+	erase fff00000 ffffffff
+	cp.b 1000000 fff00100 80000
+
+To Flash U-boot into the alternative bank (0xFF800000 - 0xFFBFFFFF):
+
+	tftp 1000000 u-boot.bin
+	erase ffb00000 ffbfffff
+	cp.b 1000000 ffb00100 80000
+
+
+4. Memory Map
+-------------
+
+	Memory Range			Device		Size
+	------------			------		----
+	0x0000_0000	0x7fff_ffff	DDR		2G
+	0x8000_0000	0x9fff_ffff	PCI1/PEX1 MEM	512M
+	0xa000_0000	0xafff_ffff	PCI2/PEX2 MEM	512M
+	0xf800_0000	0xf80f_ffff	CCSR		1M
+	0xf810_0000	0xf81f_ffff	PIXIS		1M
+	0xf840_0000	0xf840_3fff	Stack space	32K
+	0xe200_0000	0xe2ff_ffff	PCI1/PEX1 IO	16M
+	0xe300_0000	0xe3ff_ffff	PCI2/PEX2 IO	16M
+	0xfe00_0000	0xfeff_ffff	Flash(alternate)16M
+	0xff00_0000	0xffff_ffff	Flash(boot bank)16M
diff --git a/doc/README.nand b/doc/README.nand
index f2d6a5b..b5171f4 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -1,9 +1,7 @@
 NAND FLASH commands and notes
 
-
 See NOTE below!!!
 
-
 # (C) Copyright 2003
 # Dave Ellis, SIXNET, dge@sixnetio.com
 #
@@ -36,14 +34,19 @@ Commands:
    nand device num
       Make device `num' the current device and print information about it.
 
-   nand erase off size
-   nand erase clean [off size]
-      Erase `size' bytes starting at offset `off'.  Only complete erase
-      blocks can be erased.
+   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. If `clean' is specified without an
-      offset or size, the entire flash is erased.
+      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.
@@ -53,28 +56,28 @@ Commands:
    nand info
       Print information about all of the NAND devices found.
 
-   nand read addr ofs size
+   nand read addr ofs|partition size
       Read `size' bytes from `ofs' in NAND flash to `addr'. If a page
       cannot be read because it is marked bad or an uncorrectable data
       error is found the command stops with an error.
 
-   nand read.jffs2 addr ofs size
+   nand read.jffs2 addr ofs|partition size
       Like `read', but the data for blocks that are marked bad is read as
       0xff. This gives a readable JFFS2 image that can be processed by
       the JFFS2 commands such as ls and fsload.
 
-   nand read.oob addr ofs size
+   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 size
+   nand write addr ofs|partition size
       Write `size' bytes from `addr' to `ofs' in NAND flash. If a page
       cannot be written because it is marked bad or the write fails the
       command stops with an error.
 
-   nand write.jffs2 addr ofs size
+   nand write.jffs2 addr ofs|partition size
       Like `write', but blocks that are marked bad are skipped and the
       is written to the next block instead. This allows writing writing
       a JFFS2 image, as long as the image is short enough to fit even
@@ -82,7 +85,7 @@ Commands:
       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 size
+   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
@@ -207,3 +210,46 @@ As mentioned above, the legacy code is still used by the DoC subsystem.
 The consequence of this is that the legacy NAND can't be removed  from
 the tree until the DoC is ported to use the new NAND support (or boards
 with DoC will break).
+
+
+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.
+
+  "nand write.jffs2"
+  like "nand write" but skip found bad eraseblocks
+
+  "nand read.jffs2"
+  like "nand read" but skip found bad eraseblocks
+
+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/doc/README.nand-boot-ppc440 b/doc/README.nand-boot-ppc440
new file mode 100644
index 0000000..a1c1d8c
--- /dev/null
+++ b/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 desciption 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>