README

		Enable printing of hash marks during FPGA
		configuration.

		CFG_FPGA_CHECK_BUSY

		Enable checks on FPGA configuration interface busy
		status by the configuration function. This option
		will require a board or device specific function to
		be written.

		CONFIG_FPGA_DELAY

		If defined, a function that provides delays in the
		FPGA configuration driver.

		CFG_FPGA_CHECK_CTRLC

		Allow Control-C to interrupt FPGA configuration

		CFG_FPGA_CHECK_ERROR

		Check for configuration errors during FPGA bitfile
		loading. For example, abort during Virtex II
		configuration if the INIT_B line goes low (which
		indicated a CRC error).

		CFG_FPGA_WAIT_INIT

		Maximum time to wait for the INIT_B line to deassert
		after PROB_B has been deasserted during a Virtex II
		FPGA configuration sequence. The default time is 500 mS.

		CFG_FPGA_WAIT_BUSY

		Maximum time to wait for BUSY to deassert during
		Virtex II FPGA configuration. The default is 5 mS.

		CFG_FPGA_WAIT_CONFIG

		Time to wait after FPGA configuration. The default is
		200 mS.

- FPGA Support:	CONFIG_FPGA_COUNT

 		Specify the number of FPGA devices to support.

 		CONFIG_FPGA

 		Used to specify the types of FPGA devices.  For example,
 		#define CONFIG_FPGA  CFG_XILINX_VIRTEX2

 		CFG_FPGA_PROG_FEEDBACK

 		Enable printing of hash marks during FPGA configuration.

		CFG_FPGA_CHECK_BUSY

		Enable checks on FPGA configuration interface busy
		status by the configuration function. This option
		will require a board or device specific function to
		be written.

		CONFIG_FPGA_DELAY

		If defined, a function that provides delays in the FPGA
		configuration driver.

		CFG_FPGA_CHECK_CTRLC
		Allow Control-C to interrupt FPGA configuration

		CFG_FPGA_CHECK_ERROR

		Check for configuration errors during FPGA bitfile
		loading. For example, abort during Virtex II
		configuration if the INIT_B line goes low (which
		indicated a CRC error).

		CFG_FPGA_WAIT_INIT

		Maximum time to wait for the INIT_B line to deassert
		after PROB_B has been deasserted during a Virtex II
		FPGA configuration sequence. The default time is 500
		mS.

		CFG_FPGA_WAIT_BUSY

		Maximum time to wait for BUSY to deassert during
		Virtex II FPGA configuration. The default is 5 mS.

		CFG_FPGA_WAIT_CONFIG

		Time to wait after FPGA configuration. The default is
		200 mS.

- Configuration Management:
		CONFIG_IDENT_STRING

		If defined, this string will be added to the U-Boot
		version information (U_BOOT_VERSION)

- Vendor Parameter Protection:

		U-Boot considers the values of the environment
		variables "serial#" (Board Serial Number) and
		"ethaddr" (Ethernet Address) to bb parameters that
		are set once by the board vendor / manufacturer, and
		protects these variables from casual modification by
		the user. Once set, these variables are read-only,
		and write or delete attempts are rejected. You can
		change this behviour:

		If CONFIG_ENV_OVERWRITE is #defined in your config
		file, the write protection for vendor parameters is
		completely disabled. Anybody can change or delete
		these parameters.

		Alternatively, if you #define _both_ CONFIG_ETHADDR
		_and_ CONFIG_OVERWRITE_ETHADDR_ONCE, a default
		ethernet address is installed in the environment,
		which can be changed exactly ONCE by the user. [The
		serial# is unaffected by this, i. e. it remains
		read-only.]

- Protected RAM:
		CONFIG_PRAM

		Define this variable to enable the reservation of
		"protected RAM", i. e. RAM which is not overwritten
		by U-Boot. Define CONFIG_PRAM to hold the number of
		kB you want to reserve for pRAM. You can overwrite
		this default value by defining an environment
		variable "pram" to the number of kB you want to
		reserve. Note that the board info structure will
		still show the full amount of RAM. If pRAM is
		reserved, a new environment variable "mem" will
		automatically be defined to hold the amount of
		remaining RAM in a form that can be passed as boot
		argument to Linux, for instance like that:

			setenv bootargs ... mem=\$(mem)
			saveenv

		This way you can tell Linux not to use this memory,
		either, which results in a memory region that will
		not be affected by reboots.

		*WARNING* If your board configuration uses automatic
		detection of the RAM size, you must make sure that
		this memory test is non-destructive. So far, the
		following board configurations are known to be
		"pRAM-clean":

			ETX094, IVMS8, IVML24, SPD8xx, TQM8xxL,
			HERMES, IP860, RPXlite, LWMON, LANTEC,
			PCU_E, FLAGADM, TQM8260

- Error Recovery:
		CONFIG_PANIC_HANG

		Define this variable to stop the system in case of a
		fatal error, so that you have to reset it manually.
		This is probably NOT a good idea for an embedded
		system where you want to system to reboot
		automatically as fast as possible, but it may be
		useful during development since you can try to debug
		the conditions that lead to the situation.

		CONFIG_NET_RETRY_COUNT

		This variable defines the number of retries for
		network operations like ARP, RARP, TFTP, or BOOTP
		before giving up the operation. If not defined, a
		default value of 5 is used.

- Command Interpreter:
		CFG_HUSH_PARSER

		Define this variable to enable the "hush" shell (from
		Busybox) as command line interpreter, thus enabling
		powerful command line syntax like
		if...then...else...fi conditionals or `&&' and '||'
		constructs ("shell scripts").

		If undefined, you get the old, much simpler behaviour
		with a somewhat smaller memory footprint.


		CFG_PROMPT_HUSH_PS2

		This defines the secondary prompt string, which is
		printed when the command interpreter needs more input
		to complete a command. Usually "> ".

	Note:

                In the current implementation, the local variables
                space and global environment variables space are
                separated. Local variables are those you define by
                simply typing `name=value'. To access a local
                variable later on, you have write `$name' or
                `${name}'; to execute the contents of a variable
                directly type `$name' at the command prompt.

		Global environment variables are those you use
		setenv/printenv to work with. To run a command stored
		in such a variable, you need to use the run command,
		and you must not use the '$' sign to access them.

		To store commands and special characters in a
		variable, please use double quotation marks
		surrounding the whole text of the variable, instead
		of the backslashes before semicolons and special
		symbols.

- Default Environment
		CONFIG_EXTRA_ENV_SETTINGS

		Define this to contain any number of null terminated
		strings (variable = value pairs) that will be part of
		the default enviroment compiled into the boot image.

		For example, place something like this in your
		board's config file:

		#define CONFIG_EXTRA_ENV_SETTINGS \
			"myvar1=value1\0" \
			"myvar2=value2\0"

		Warning: This method is based on knowledge about the
		internal format how the environment is stored by the
		U-Boot code. This is NOT an official, exported
		interface! Although it is unlikely that this format
		will change soon, but there is no guarantee either.
		You better know what you are doing here.

		Note: overly (ab)use of the default environment is
		discouraged. Make sure to check other ways to preset
		the environment like the autoscript function or the
		boot command first.

- Show boot progress
		CONFIG_SHOW_BOOT_PROGRESS

		Defining this option allows to add some board-
		specific code (calling a user-provided function
		"show_boot_progress(int)") that enables you to show
		the system's boot progress on some display (for
		example, some LED's) on your board. At the moment,
		the following checkpoints are implemented:

  Arg	Where			When
    1	common/cmd_bootm.c	before attempting to boot an image
   -1	common/cmd_bootm.c	Image header has bad     magic number
    2	common/cmd_bootm.c	Image header has correct magic number
   -2	common/cmd_bootm.c	Image header has bad     checksum
    3	common/cmd_bootm.c	Image header has correct checksum
   -3	common/cmd_bootm.c	Image data   has bad     checksum
    4	common/cmd_bootm.c	Image data   has correct checksum
   -4	common/cmd_bootm.c	Image is for unsupported architecture
    5	common/cmd_bootm.c	Architecture check OK
   -5	common/cmd_bootm.c	Wrong Image Type (not kernel, multi, standalone)
    6	common/cmd_bootm.c	Image Type check OK
   -6	common/cmd_bootm.c	gunzip uncompression error
   -7	common/cmd_bootm.c	Unimplemented compression type
    7	common/cmd_bootm.c	Uncompression OK
   -8	common/cmd_bootm.c	Wrong Image Type (not kernel, multi, standalone)
    8	common/cmd_bootm.c	Image Type check OK
   -9	common/cmd_bootm.c	Unsupported OS (not Linux, BSD, VxWorks, QNX)
    9	common/cmd_bootm.c	Start initial ramdisk verification
  -10	common/cmd_bootm.c	Ramdisk header has bad     magic number
  -11	common/cmd_bootm.c	Ramdisk header has bad     checksum
   10	common/cmd_bootm.c	Ramdisk header is OK
  -12	common/cmd_bootm.c	Ramdisk data   has bad     checksum
   11	common/cmd_bootm.c	Ramdisk data   has correct checksum
   12	common/cmd_bootm.c	Ramdisk verification complete, start loading
  -13	common/cmd_bootm.c	Wrong Image Type (not PPC Linux Ramdisk)
   13	common/cmd_bootm.c	Start multifile image verification
   14	common/cmd_bootm.c	No initial ramdisk, no multifile, continue.
   15	common/cmd_bootm.c	All preparation done, transferring control to OS

   -1	common/cmd_doc.c	Bad usage of "doc" command
   -1	common/cmd_doc.c	No boot device
   -1	common/cmd_doc.c	Unknown Chip ID on boot device
   -1	common/cmd_doc.c	Read Error on boot device
   -1	common/cmd_doc.c	Image header has bad magic number

   -1	common/cmd_ide.c	Bad usage of "ide" command
   -1	common/cmd_ide.c	No boot device
   -1	common/cmd_ide.c	Unknown boot device
   -1	common/cmd_ide.c	Unknown partition table
   -1	common/cmd_ide.c	Invalid partition type
   -1	common/cmd_ide.c	Read Error on boot device
   -1	common/cmd_ide.c	Image header has bad magic number

   -1	common/cmd_nvedit.c	Environment not changable, but has bad CRC


Modem Support:
--------------

[so far only for SMDK2400 and TRAB boards]

- Modem support endable:
		CONFIG_MODEM_SUPPORT

- RTS/CTS Flow control enable:
		CONFIG_HWFLOW

- Modem debug support:
		CONFIG_MODEM_SUPPORT_DEBUG

		Enables debugging stuff (char screen[1024], dbg())
		for modem support. Useful only with BDI2000.

- General:

		In the target system modem support is enabled when a
		specific key (key combination) is pressed during
		power-on. Otherwise U-Boot will boot normally
		(autoboot). The key_pressed() fuction is called from
		board_init(). Currently key_pressed() is a dummy
		function, returning 1 and thus enabling modem
		initialization.

		If there are no modem init strings in the
		environment, U-Boot proceed to autoboot; the
		previous output (banner, info printfs) will be
		supressed, though.

		See also: doc/README.Modem




Configuration Settings:
-----------------------

- CFG_LONGHELP: Defined when you want long help messages included;
		undefine this when you're short of memory.

- CFG_PROMPT:	This is what U-Boot prints on the console to
		prompt for user input.

- CFG_CBSIZE:	Buffer size for input from the Console

- CFG_PBSIZE:	Buffer size for Console output

- CFG_MAXARGS:	max. Number of arguments accepted for monitor commands

- CFG_BARGSIZE: Buffer size for Boot Arguments which are passed to
		the application (usually a Linux kernel) when it is
		booted

- CFG_BAUDRATE_TABLE:
		List of legal baudrate settings for this board.

- CFG_CONSOLE_INFO_QUIET
 		Suppress display of console information at boot.

- CFG_CONSOLE_IS_IN_ENV
 		If the board specific function
 			extern int overwrite_console (void);
 		returns 1, the stdin, stderr and stdout are switched to the
		serial port, else the settings in the environment are used.

- CFG_CONSOLE_OVERWRITE_ROUTINE
 		Enable the call to overwrite_console().

- CFG_CONSOLE_ENV_OVERWRITE
		Enable overwrite of previous console environment settings.

- CFG_MEMTEST_START, CFG_MEMTEST_END:
		Begin and End addresses of the area used by the
		simple memory test.

- CFG_ALT_MEMTEST:
 		Enable an alternate, more extensive memory test.

- CFG_TFTP_LOADADDR:
		Default load address for network file downloads

- CFG_LOADS_BAUD_CHANGE:
		Enable temporary baudrate change while serial download

- CFG_SDRAM_BASE:
		Physical start address of SDRAM. _Must_ be 0 here.

- CFG_MBIO_BASE:
		Physical start address of Motherboard I/O (if using a
		Cogent motherboard)

- CFG_FLASH_BASE:
		Physical start address of Flash memory.

- CFG_MONITOR_BASE:
		Physical start address of boot monitor code (set by
		make config files to be same as the text base address
		(TEXT_BASE) used when linking) - same as
		CFG_FLASH_BASE when booting from flash.

- CFG_MONITOR_LEN:
                Size of memory reserved for monitor code, used to
                determine _at_compile_time_ (!) if the environment is
                embedded within the U-Boot image, or in a separate
                flash sector.

- CFG_MALLOC_LEN:
		Size of DRAM reserved for malloc() use.

- CFG_BOOTMAPSZ:
		Maximum size of memory mapped by the startup code of
		the Linux kernel; all data that must be processed by
		the Linux kernel (bd_info, boot arguments, eventually
		initrd image) must be put below this limit.

- CFG_MAX_FLASH_BANKS:
		Max number of Flash memory banks

- CFG_MAX_FLASH_SECT:
		Max number of sectors on a Flash chip

- CFG_FLASH_ERASE_TOUT:
		Timeout for Flash erase operations (in ms)

- CFG_FLASH_WRITE_TOUT:
		Timeout for Flash write operations (in ms)

- CFG_DIRECT_FLASH_TFTP:

		Enable TFTP transfers directly to flash memory;
		without this option such a download has to be
		performed in two steps: (1) download to RAM, and (2)
		copy from RAM to flash.

		The two-step approach is usually more reliable, since
		you can check if the download worked before you erase
		the flash, but in some situations (when sytem RAM is
		too limited to allow for a tempory copy of the
		downloaded image) this option may be very useful.

- CFG_FLASH_CFI:
		Define if the flash driver uses extra elements in the
		common flash structure for storing flash geometry

- CFG_RX_ETH_BUFFER:
		Defines the number of ethernet receive buffers. On some
		ethernet controllers it is recommended to set this value
		to 8 or even higher (EEPRO100 or 405 EMAC), since all
		buffers can be full shortly after enabling the interface
		on high ethernet traffic.
		Defaults to 4 if not defined.

The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:

- CFG_ENV_IS_IN_FLASH:

	Define this if the environment is in flash memory.

	a) The environment occupies one whole flash sector, which is
	   "embedded" in the text segment with the U-Boot code. This
	   happens usually with "bottom boot sector" or "top boot
	   sector" type flash chips, which have several smaller
	   sectors at the start or the end. For instance, such a
	   layout can have sector sizes of 8, 2x4, 16, Nx32 kB. In
	   such a case you would place the environment in one of the
	   4 kB sectors - with U-Boot code before and after it. With
	   "top boot sector" type flash chips, you would put the
	   environment in one of the last sectors, leaving a gap
	   between U-Boot and the environment.

	- CFG_ENV_OFFSET:

	   Offset of environment data (variable area) to the
	   beginning of flash memory; for instance, with bottom boot
	   type flash chips the second sector can be used: the offset
	   for this sector is given here.

	   CFG_ENV_OFFSET is used relative to CFG_FLASH_BASE.

	- CFG_ENV_ADDR:

	   This is just another way to specify the start address of
	   the flash sector containing the environment (instead of
	   CFG_ENV_OFFSET).

	- CFG_ENV_SECT_SIZE:

	   Size of the sector containing the environment.


	b) Sometimes flash chips have few, equal sized, BIG sectors.
	   In such a case you don't want to spend a whole sector for
	   the environment.

	- CFG_ENV_SIZE:

	   If you use this in combination with CFG_ENV_IS_IN_FLASH
	   and CFG_ENV_SECT_SIZE, you can specify to use only a part
	   of this flash sector for the environment. This saves
	   memory for the RAM copy of the environment.

	   It may also save flash memory if you decide to use this
	   when your environment is "embedded" within U-Boot code,
	   since then the remainder of the flash sector could be used
	   for U-Boot code. It should be pointed out that this is
	   STRONGLY DISCOURAGED from a robustness point of view:
	   updating the environment in flash makes it always
	   necessary to erase the WHOLE sector. If something goes
	   wrong before the contents has been restored from a copy in
	   RAM, your target system will be dead.

	- CFG_ENV_ADDR_REDUND
	  CFG_ENV_SIZE_REDUND

	   These settings describe a second storage area used to hold
	   a redundand copy of the environment data, so that there is
	   a valid backup copy in case there is a power failure during
	   a "saveenv" operation.

BE CAREFUL! Any changes to the flash layout, and some changes to the
source code will make it necessary to adapt <board>/u-boot.lds*
accordingly!


- CFG_ENV_IS_IN_NVRAM:

	Define this if you have some non-volatile memory device
	(NVRAM, battery buffered SRAM) which you want to use for the
	environment.

	- CFG_ENV_ADDR:
	- CFG_ENV_SIZE:

	  These two #defines are used to determin the memory area you
	  want to use for environment. It is assumed that this memory
	  can just be read and written to, without any special
	  provision.

BE CAREFUL! The first access to the environment happens quite early
in U-Boot initalization (when we try to get the setting of for the
console baudrate). You *MUST* have mappend your NVRAM area then, or
U-Boot will hang.

Please note that even with NVRAM we still use a copy of the
environment in RAM: we could work on NVRAM directly, but we want to
keep settings there always unmodified except somebody uses "saveenv"
to save the current settings.


- CFG_ENV_IS_IN_EEPROM:

	Use this if you have an EEPROM or similar serial access
	device and a driver for it.

	- CFG_ENV_OFFSET:
	- CFG_ENV_SIZE:

	  These two #defines specify the offset and size of the
	  environment area within the total memory of your EEPROM.

	- CFG_I2C_EEPROM_ADDR:
	  If defined, specified the chip address of the EEPROM device.
	  The default address is zero.

	- CFG_EEPROM_PAGE_WRITE_BITS:
	  If defined, the number of bits used to address bytes in a
	  single page in the EEPROM device.  A 64 byte page, for example
	  would require six bits.

	- CFG_EEPROM_PAGE_WRITE_DELAY_MS:
	  If defined, the number of milliseconds to delay between
	  page writes.  The default is zero milliseconds.

	- CFG_I2C_EEPROM_ADDR_LEN:
	  The length in bytes of the EEPROM memory array address.  Note
	  that this is NOT the chip address length!

	- CFG_EEPROM_SIZE:
	  The size in bytes of the EEPROM device.


- CFG_SPI_INIT_OFFSET

	Defines offset to the initial SPI buffer area in DPRAM. The
	area is used at an early stage (ROM part) if the environment
	is configured to reside in the SPI EEPROM: We need a 520 byte
	scratch DPRAM area. It is used between the two initialization
	calls (spi_init_f() and spi_init_r()). A value of 0xB00 seems
	to be a good choice since it makes it far enough from the
	start of the data area as well as from the stack pointer.

Please note that the environment is read-only as long as the monitor
has been relocated to RAM and a RAM copy of the environment has been
created; also, when using EEPROM you will have to use getenv_r()
until then to read environment variables.

The environment is protected by a CRC32 checksum. Before the monitor
is relocated into RAM, as a result of a bad CRC you will be working
with the compiled-in default environment - *silently*!!! [This is
necessary, because the first environment variable we need is the
"baudrate" setting for the console - if we have a bad CRC, we don't
have any device yet where we could complain.]

Note: once the monitor has been relocated, then it will complain if
the default environment is used; a new CRC is computed as soon as you
use the "saveenv" command to store a valid environment.


Low Level (hardware related) configuration options:
---------------------------------------------------

- CFG_CACHELINE_SIZE:
		Cache Line Size of the CPU.

- CFG_DEFAULT_IMMR:
		Default address of the IMMR after system reset.
		Needed on some 8260 systems (MPC8260ADS and RPXsuper)
		to be able to adjust the position of the IMMR
		register after a reset.

- Floppy Disk Support:
		CFG_FDC_DRIVE_NUMBER

		the default drive number (default value 0)

		CFG_ISA_IO_STRIDE

		defines the spacing between fdc chipset registers
		(default value 1)

		CFG_ISA_IO_OFFSET

		defines the offset of register from address. It
		depends on which part of the data bus is connected to
		the fdc chipset. (default value 0)

		If CFG_ISA_IO_STRIDE CFG_ISA_IO_OFFSET and
		CFG_FDC_DRIVE_NUMBER are undefined, they take their
		default value.

		if CFG_FDC_HW_INIT is defined, then the function
		fdc_hw_init() is called at the beginning of the FDC
		setup. fdc_hw_init() must be provided by the board
		source code. It is used to make hardware dependant
		initializations.

- CFG_IMMR:	Physical address of the Internal Memory Mapped
		Register; DO NOT CHANGE! (11-4)
		[MPC8xx systems only]

- CFG_INIT_RAM_ADDR:

		Start address of memory area tha can be used for
		initial data and stack; please note that this must be
		writable memory that is working WITHOUT special
		initialization, i. e. you CANNOT use normal RAM which
		will become available only after programming the
		memory controller and running certain initialization
		sequences.

		U-Boot uses the following memory types:
		- MPC8xx and MPC8260: IMMR (internal memory of the CPU)
		- MPC824X: data cache
		- PPC4xx:  data cache

- CFG_GBL_DATA_OFFSET:

		Offset of the initial data structure in the memory
		area defined by CFG_INIT_RAM_ADDR. Usually
		CFG_GBL_DATA_OFFSET is chosen such that the initial
		data is located at the end of the available space
		(sometimes written as (CFG_INIT_RAM_END -
		CFG_INIT_DATA_SIZE), and the initial stack is just
		below that area (growing from (CFG_INIT_RAM_ADDR +
		CFG_GBL_DATA_OFFSET) downward.

	Note:
		On the MPC824X (or other systems that use the data
		cache for initial memory) the address chosen for
		CFG_INIT_RAM_ADDR is basically arbitrary - it must
		point to an otherwise UNUSED address space between
		the top of RAM and the start of the PCI space.

- CFG_SIUMCR:	SIU Module Configuration (11-6)

- CFG_SYPCR:	System Protection Control (11-9)

- CFG_TBSCR:	Time Base Status and Control (11-26)

- CFG_PISCR:	Periodic Interrupt Status and Control (11-31)

- CFG_PLPRCR:	PLL, Low-Power, and Reset Control Register (15-30)

- CFG_SCCR:	System Clock and reset Control Register (15-27)

- CFG_OR_TIMING_SDRAM:
		SDRAM timing

- CFG_MAMR_PTA:
		periodic timer for refresh

- CFG_DER:	Debug Event Register (37-47)

- FLASH_BASE0_PRELIM, FLASH_BASE1_PRELIM, CFG_REMAP_OR_AM,
  CFG_PRELIM_OR_AM, CFG_OR_TIMING_FLASH, CFG_OR0_REMAP,
  CFG_OR0_PRELIM, CFG_BR0_PRELIM, CFG_OR1_REMAP, CFG_OR1_PRELIM,
  CFG_BR1_PRELIM:
		Memory Controller Definitions: BR0/1 and OR0/1 (FLASH)

- SDRAM_BASE2_PRELIM, SDRAM_BASE3_PRELIM, SDRAM_MAX_SIZE,
  CFG_OR_TIMING_SDRAM, CFG_OR2_PRELIM, CFG_BR2_PRELIM,
  CFG_OR3_PRELIM, CFG_BR3_PRELIM:
		Memory Controller Definitions: BR2/3 and OR2/3 (SDRAM)

- CFG_MAMR_PTA, CFG_MPTPR_2BK_4K, CFG_MPTPR_1BK_4K, CFG_MPTPR_2BK_8K,
  CFG_MPTPR_1BK_8K, CFG_MAMR_8COL, CFG_MAMR_9COL:
		Machine Mode Register and Memory Periodic Timer
		Prescaler definitions (SDRAM timing)

- CFG_I2C_UCODE_PATCH, CFG_I2C_DPMEM_OFFSET [0x1FC0]:
		enable I2C microcode relocation patch (MPC8xx);
		define relocation offset in DPRAM [DSP2]

- CFG_SPI_UCODE_PATCH, CFG_SPI_DPMEM_OFFSET [0x1FC0]:
		enable SPI microcode relocation patch (MPC8xx);
		define relocation offset in DPRAM [SCC4]

- CFG_USE_OSCCLK:
		Use OSCM clock mode on MBX8xx board. Be careful,
		wrong setting might damage your board. Read
		doc/README.MBX before setting this variable!

- CFG_CPM_POST_WORD_ADDR: (MPC8xx, MPC8260 only)
		Offset of the bootmode word in DPRAM used by post
		(Power On Self Tests). This definition overrides
		#define'd default value in commproc.h resp.
		cpm_8260.h.

- CFG_PCI_SLV_MEM_LOCAL, CFG_PCI_SLV_MEM_BUS, CFG_PICMR0_MASK_ATTRIB,
  CFG_PCI_MSTR0_LOCAL, CFG_PCIMSK0_MASK, CFG_PCI_MSTR1_LOCAL,
  CFG_PCIMSK1_MASK, CFG_PCI_MSTR_MEM_LOCAL, CFG_PCI_MSTR_MEM_BUS,
  CFG_CPU_PCI_MEM_START, CFG_PCI_MSTR_MEM_SIZE, CFG_POCMR0_MASK_ATTRIB,
  CFG_PCI_MSTR_MEMIO_LOCAL, CFG_PCI_MSTR_MEMIO_BUS, CPU_PCI_MEMIO_START,
  CFG_PCI_MSTR_MEMIO_SIZE, CFG_POCMR1_MASK_ATTRIB, CFG_PCI_MSTR_IO_LOCAL,
  CFG_PCI_MSTR_IO_BUS, CFG_CPU_PCI_IO_START, CFG_PCI_MSTR_IO_SIZE,
  CFG_POCMR2_MASK_ATTRIB: (MPC826x only)
		Overrides the default PCI memory map in cpu/mpc8260/pci.c if set.

Building the Software:
======================

Building U-Boot has been tested in native PPC environments (on a
PowerBook G3 running LinuxPPC 2000) and in cross environments
(running RedHat 6.x and 7.x Linux on x86, Solaris 2.6 on a SPARC, and
NetBSD 1.5 on x86).

If you are not using a native PPC environment, it is assumed that you
have the GNU cross compiling tools available in your path and named
with a prefix of "powerpc-linux-". If this is not the case, (e.g. if
you are using Monta Vista's Hard Hat Linux CDK 1.2) you must change
the definition of CROSS_COMPILE in Makefile. For HHL on a 4xx CPU,
change it to:

	CROSS_COMPILE = ppc_4xx-


U-Boot is intended to be  simple  to  build.  After  installing  the
sources	 you must configure U-Boot for one specific board type. This
is done by typing:

	make NAME_config

where "NAME_config" is the name of one of the existing
configurations; the following names are supported:

    ADCIOP_config	  GTH_config		TQM850L_config
    ADS860_config	  IP860_config		TQM855L_config
    AR405_config	  IVML24_config		TQM860L_config
    CANBT_config	  IVMS8_config		WALNUT405_config
    CPCI405_config	  LANTEC_config		cogent_common_config
    CPCIISER4_config	  MBX_config		cogent_mpc8260_config
    CU824_config	  MBX860T_config	cogent_mpc8xx_config
    ESTEEM192E_config	  RPXlite_config	hermes_config
    ETX094_config	  RPXsuper_config	hymod_config
    FADS823_config	  SM850_config		lwmon_config
    FADS850SAR_config	  SPD823TS_config	pcu_e_config
    FADS860T_config	  SXNI855T_config	rsdproto_config
    FPS850L_config	  Sandpoint8240_config	sbc8260_config
    GENIETV_config	  TQM823L_config	PIP405_config
    GEN860T_config	  EBONY_config		FPS860L_config
    ELPT860_config	  cmi_mpc5xx_config	NETVIA_config

Note: for some board special configuration names may exist; check  if
      additional  information is available from the board vendor; for
      instance, the TQM8xxL systems run normally at 50 MHz and use  a
      SCC  for	10baseT	 ethernet; there are also systems with 80 MHz
      CPU clock, and an optional Fast Ethernet	module	is  available
      for  CPU's  with FEC. You can select such additional "features"
      when chosing the configuration, i. e.

      make TQM860L_config
	- will configure for a plain TQM860L, i. e. 50MHz, no FEC

      make TQM860L_FEC_config
	- will configure for a TQM860L at 50MHz with FEC for ethernet

      make TQM860L_80MHz_config
	- will configure for a TQM860L at 80 MHz, with normal 10baseT
	  interface

      make TQM860L_FEC_80MHz_config
	- will configure for a TQM860L at 80 MHz with FEC for ethernet

      make TQM823L_LCD_config
	- will configure for a TQM823L with U-Boot console on LCD

      make TQM823L_LCD_80MHz_config
	- will configure for a TQM823L at 80 MHz with U-Boot console on LCD

      etc.



Finally, type "make all", and you should get some working U-Boot
images ready for downlod to / installation on your system:

- "u-boot.bin" is a raw binary image
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format


Please be aware that the Makefiles assume you are using GNU make, so
for instance on NetBSD you might need to use "gmake" instead of
native "make".


If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:

1.  Add a new configuration option for your board to the toplevel
    "Makefile" and to the "MAKEALL" script, using the existing
    entries as examples. Note that here and at many other places
    boards and other names are listed alphabetically sorted. Please
    keep this order.
2.  Create a new directory to hold your board specific code. Add any
    files you need. In your board directory, you will need at least
    the "Makefile", a "<board>.c", "flash.c" and "u-boot.lds".
3.  Create a new configuration file "include/configs/<board>.h" for
    your board
3.  If you're porting U-Boot to a new CPU, then also create a new
    directory to hold your CPU specific code. Add any files you need.
4.  Run "make <board>_config" with your new name.
5.  Type "make", and you should get a working "u-boot.srec" file
    to be installed on your target system.
6.  Debug and solve any problems that might arise.
    [Of course, this last step is much harder than it sounds.]


Testing of U-Boot Modifications, Ports to New Hardware, etc.:
==============================================================

If you have modified U-Boot sources (for instance added a new	board
or  support  for  new  devices,	 a new CPU, etc.) you are expected to
provide feedback to the other developers. The feedback normally takes
the form of a "patch", i. e. a context diff against a certain (latest
official or latest in CVS) version of U-Boot sources.

But before you submit such a patch, please verify that	your  modifi-
cation	did not break existing code. At least make sure that *ALL* of
the supported boards compile WITHOUT ANY compiler warnings. To do so,
just run the "MAKEALL" script, which will configure and build U-Boot
for ALL supported system. Be warned, this will take a while. You  can
select	which  (cross)	compiler  to use py passing a `CROSS_COMPILE'
environment variable to the script, i. e. to use the cross tools from
MontaVista's Hard Hat Linux you can type

	CROSS_COMPILE=ppc_8xx- MAKEALL

or to build on a native PowerPC system you can type

	CROSS_COMPILE=' ' MAKEALL

See also "U-Boot Porting Guide" below.



Monitor Commands - Overview:
============================

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"
	       (and eventually "gatewayip")
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd   - 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
imd     - i2c memory display
imm     - i2c memory modify (auto-incrementing)
inm     - i2c memory modify (constant address)
imw     - i2c memory write (fill)
icrc32  - i2c checksum calculation
iprobe  - probe to discover valid I2C chip addresses
iloop   - infinite loop on address range
isdram  - print SDRAM configuration information
sspi    - SPI utility commands
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
ide	- IDE 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'


Monitor Commands - Detailed Description:
========================================

TODO.

For now: just type "help <command>".


Environment Variables:
======================

U-Boot supports user configuration using Environment Variables which
can be made persistent by saving to Flash memory.

Environment Variables are set using "setenv", printed using
"printenv", and saved to Flash using "saveenv". Using "setenv"
without a value can be used to delete a variable from the
environment. As long as you don't save the environment you are
working with an in-memory copy. In case the Flash area containing the
environment is erased by accident, a default environment is provided.

Some configuration options can be set using Environment Variables:

  baudrate	- see CONFIG_BAUDRATE

  bootdelay	- see CONFIG_BOOTDELAY

  bootcmd	- see CONFIG_BOOTCOMMAND

  bootargs	- Boot arguments when booting an RTOS image

  bootfile	- Name of the image to load with TFTP

  autoload	- if set to "no" (any string beginning with 'n'),
		  "bootp" will just load perform a lookup of the
		  configuration from the BOOTP server, but not try to
		  load any image using TFTP

  autostart	- if set to "yes", an image loaded using the "bootp",
		  "rarpboot", "tftpboot" or "diskboot" commands will
		  be automatically started (by internally calling
		  "bootm")

		  If set to "no", a standalone image passed to the
		  "bootm" command will be copied to the load address
		  (and eventually uncompressed), but NOT be started.
		  This can be used to load and uncompress arbitrary
		  data.

  initrd_high	- restrict positioning of initrd images:
		  If this variable is not set, initrd images will be
		  copied to the highest possible address in RAM; this
		  is usually what you want since it allows for
		  maximum initrd size. If for some reason you want to
		  make sure that the initrd image is loaded below the
		  CFG_BOOTMAPSZ limit, you can set this environment
		  variable to a value of "no" or "off" or "0".
		  Alternatively, you can set it to a maximum upper
		  address to use (U-Boot will still check that it