Initial revision
diff --git a/doc/README.JFFS2 b/doc/README.JFFS2
new file mode 100644
index 0000000..0d39c46
--- /dev/null
+++ b/doc/README.JFFS2
@@ -0,0 +1,68 @@
+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 CFG_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
+
+
+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.
+
+CFG_JFFS2_FIRST_BANK
+ defined the first flash bank to use
+
+CFG_JFFS2_FIRST_SECTOR
+ defines the first sector to use
+
+
+The second way is to define CFG_JFFS_CUSTOM_PART and implement the
+jffs2_part_info(int part_num) function in your board specific files.
+In this mode CFG_JFFS2_FIRST_BANK and CFG_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 CFG_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 ∂
+
+ 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 ∂
+ }
+ return 0;
+}
+#endif
+---
+
+TODO.
+
+ Add a new command so it's actually possible to change
+ partition.
+
+ 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/doc/README.Modem b/doc/README.Modem
new file mode 100644
index 0000000..a3ba7b7
--- /dev/null
+++ b/doc/README.Modem
@@ -0,0 +1,73 @@
+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/doc/README.commands b/doc/README.commands
new file mode 100644
index 0000000..576186e
--- /dev/null
+++ b/doc/README.commands
@@ -0,0 +1,99 @@
+#
+# The commands in this table are sorted alphabetically by the
+# command name and in descending order by the command name string
+# length. This is to prevent conflicts in command name parsing.
+# Please ensure that new commands are added according to that rule.
+# See $(TOPDIR)/common/command.c
+#
+########################
+#
+# command length
+#
+########################
+askenv 8
+as 2
+autoscr 5
+base 2
+bdinfo 2
+bootelf 7
+bootm 5
+bootp 5
+bootvx 6
+bootd 4
+break 2
+brginfo 3
+carinfo 3
+chpart 6
+cmp 3
+coninfo 5
+continue 4
+cp 2
+crc32 3
+date 3
+dcache 2
+dhcp 4
+dmainfo 3
+ds 2
+dtt 3
+echo 4
+eeprom 3
+erase 3
+fccinfo 3
+fdcboot 4
+flinfo 3
+fpga 4
+fsinfo 5
+fsload 5
+getdcr 6 # IBM 4XX DCR registers
+go 2
+help 1
+i2cinfo 4
+i2c 3
+icache 2
+icinfo 3
+ide 3
+iminfo 3
+iopinfo 3
+irqinfo 3
+kgdb 4
+loadb 5
+loads 5
+loop 4
+ls 2
+mccinfo 3
+md 2
+memcinfo 4
+mii 3
+mm 2
+mtest 5
+muxinfo 3
+mw 2
+next 4
+nm 2
+pciinfo 3
+pinit 4
+printenv 8
+protect 4
+rarpboot 4
+rdump 5
+reginfo 3
+reset 5
+run 3
+saveenv 4
+sccinfo 3
+scsiboot 5
+scsi 4
+siiinfo 3
+sitinfo 3
+siuinfo 3
+setdcr 6 # IBM 4XX DCR registers
+setenv 6
+smcinfo 3
+spiinfo 3
+stack 5
+step 4
+tftpboot 4
+usbboot 5
+usb 4
+version 4
+? 1
diff --git a/doc/README.ebony b/doc/README.ebony
new file mode 100644
index 0000000..12a0d70
--- /dev/null
+++ b/doc/README.ebony
@@ -0,0 +1,138 @@
+ IBM Ebony Board
+
+ Last Update: September 12, 2002
+=======================================================================
+
+This file contains some handy info regarding U-Boot and the IBM
+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 iprobe
+=====================
+
+The i2c utilities have been tested on both Rev B. and Rev C. and
+look good. The CFG_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
+iprobe should look like this (assuming you are only using a single
+SO-DIMM:
+
+=> iprobe
+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 imm command. Here are the values I currently
+use:
+
+=> imd 50 0 10
+0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................
+
+=> imd 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 iprobe, then
+use imd 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 imm 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.
+
+=> imd 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/doc/README.ppc440 b/doc/README.ppc440
new file mode 100644
index 0000000..acb0c6f
--- /dev/null
+++ b/doc/README.ppc440
@@ -0,0 +1,204 @@
+ 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 IBM 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 ;-)
+
+CFG_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)
+
+CFG_FLASH_BASE - The virtual address where FLASH is mapped.
+
+CFG_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
+ This mapping provides access to PCI-bus memory.
+
+CFG_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
+ peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).
+
+CFG_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.
+
+CFG_PCI_BASE - The virtual address where the 440 PCI-x bridge config
+ registers are mapped.
+
+CFG_PCI_TARGBASE - The PCI address that is mapped to the virtual address
+ defined by CFG_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 CFG_EXT_SERIAL_CLOCK flag. When using
+internal clocking, the "ideal baud rate" settings in the 440GP
+user manual are automatically calculated.
+
+CONFIG_SERIAL_SOFTWARE_FIFO enables interrupt-driven serial operation.
+But the last time I checked, interrupts were initialized after the
+serial port causing the interrupt handler to be removed from the
+handler table. This will probably be fixed soon ... or fix it
+yourself and submit a patch :-)
+
+
+I2C
+=================
+
+The i2c utilities have been tested on both Rev B. and Rev C. and
+look good. The iprobe 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
+CFG_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 iprobe command.
+
+For example, to prevent probing address 0x69, define the macro as
+follows:
+
+#define CFG_I2C_NOPROBES {0x69}
+
+Similarly, to prevent probing addresses 0x69 and 0x70, define the
+macro a:
+
+#define CFG_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 CFG_PCI_TARGBASE. After the
+pci_controller structure is initialized, the cpu-specific code will
+call the routine pci_pre_init() if the CFG_PCI_PRE_INIT flag is
+defined. This routine is implemented by board-specific code & is where
+the board can over-ride/extend the default pci_controller structure
+settings 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 CFG_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 CFG_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>
+