README

                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 delte
		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 like `name=value'. To access a local
                variable later on, you have write `$name' or
                `${name}'; variable directly by typing say `$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, expoerted
                interface! Although it is unlikely that this format
                will change soon, 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 board]

- 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

- 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

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 failur 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_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 now 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 "setenv" command to modify / delete / add any environment
variable [even when you try to delete a non-existing variable!].

Note2: you must edit your u-boot.lds file to reflect this
configuration.


Many of the options are named exactly as the corresponding Linux
kernel configuration options. The intention is to make it easier to
build a config tool - later.

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.

- 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_INIT_DATA_OFFSET:

		Offset of the initial data structure in the memory
		area defined by CFG_INIT_RAM_ADDR. Usually
		CFG_INIT_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_INIT_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!

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

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", using the existing entries as examples.
2.  Create a new directory to hold your board specific code. Add any
    files you need.
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 config_name" with your new name.
5.  Type "make", and you should get a working "u-boot.srec" file
    to be installed on your target system.
    [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")

  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
		  does not overwrite the U-Boot stack and data).

		  For instance, when you have a system with 16 MB
		  RAM, and want to reseve 4 MB from use by Linux,
		  you can do this by adding "mem=12M" to the value of
		  the "bootargs" variable. However, now you must make
		  sure, that the initrd image is placed in the first
		  12 MB as well - this can be done with

		  setenv initrd_high 00c00000

  ipaddr	- IP address; needed for tftpboot command

  loadaddr	- Default load address for commands like "bootp",
		  "rarpboot", "tftpboot" or "diskboot"

  loads_echo	- see CONFIG_LOADS_ECHO

  serverip	- TFTP server IP address; needed for tftpboot command

  bootretry	- see CONFIG_BOOT_RETRY_TIME

  bootdelaykey	- see CONFIG_AUTOBOOT_DELAY_STR

  bootstopkey	- see CONFIG_AUTOBOOT_STOP_STR


The following environment variables may be used and automatically
updated by the network boot commands ("bootp" and "rarpboot"),
depending the information provided by your boot server:

  bootfile	- see above
  dnsip		- IP address of your Domain Name Server
  gatewayip	- IP address of the Gateway (Router) to use
  hostname	- Target hostname
  ipaddr	- see above
  netmask	- Subnet Mask
  rootpath	- Pathname of the root filesystem on the NFS server
  serverip	- see above


There are two special Environment Variables:

  serial#	- contains hardware identification information such
		  as type string and/or serial number
  ethaddr	- Ethernet address

These variables can be set only once (usually during manufacturing of
the board). U-Boot refuses to delete or overwrite these variables
once they have been set once.


Please note that changes to some configuration parameters may take
only effect after the next boot (yes, that's just like Windoze :-).


Note for Redundant Ethernet Interfaces:
=======================================

Some boards come with redundand ethernet interfaces; U-Boot supports
such configurations and is capable of automatic selection of a
"working" interface when needed. MAC assignemnt works as follows:

Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
"eth1addr" (=>eth1), "eth2addr", ...

If the network interface stores some valid MAC address (for instance
in SROM), this is used as default address if there is NO correspon-
ding setting in the environment; if the corresponding environment
variable is set, this overrides the settings in the card; that means:

o If the SROM has a valid MAC address, and there is no address in the
  environment, the SROM's address is used.

o If there is no valid address in the SROM, and a definition in the
  environment exists, then the value from the environment variable is
  used.

o If both the SROM and the environment contain a MAC address, and
  both addresses are the same, this MAC address is used.

o If both the SROM and the environment contain a MAC address, and the
  addresses differ, the value from the environment is used and a
  warning is printed.

o If neither SROM nor the environment contain a MAC address, an error
  is raised.



Image Formats:
==============

The "boot" commands of this monitor operate on "image" files which
can be basicly anything, preceeded by a special header; see the
definitions in include/image.h for details; basicly, the header
defines the following image properties:

* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
  4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
  LynxOS, pSOS, QNX;
  Currently supported: Linux, NetBSD, VxWorks, QNX).
* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
  IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
  Currently supported: PowerPC).
* Compression Type (Provisions for uncompressed, gzip, bzip2;
  Currently supported: uncompressed, gzip).
* Load Address
* Entry Point
* Image Name
* Image Timestamp

The header is marked by a special Magic Number, and both the header
and the data portions of the image are secured against corruption by
CRC32 checksums.


Linux Support:
==============

Although U-Boot should support any OS or standalone application
easily, Linux has always been in the focus during the design of
U-Boot.

U-Boot includes many features that so far have been part of some
special "boot loader" code within the Linux kernel. Also, any
"initrd" images to be used are no longer part of one big Linux image;
instead, kernel and "initrd" are separate images. This implementation
serves serveral purposes:

- the same features can be used for other OS or standalone
  applications (for instance: using compressed images to reduce the
  Flash memory footprint)

- it becomes much easier to port new Linux kernel versions because
  lots of low-level, hardware dependend stuff are done by U-Boot