* Patch by Stephen Williams, 01 Apr 2004:

  Add support for Picture Elements JSE board

* Patch by Christian Pell, 01 Apr 2004:
  Add CompactFlash support for PXA systems.

1 files changed, 1191 insertions, 1191 deletions

diff --git a/README b/README
index d1816262c9..051620ea02 100644
--- a/README
+++ b/README
@@ -246,52 +246,51 @@ The following options need to be configured:
 		PowerPC based boards:
 		---------------------
 
-		CONFIG_ADCIOP,	   CONFIG_ICU862      CONFIG_RPXsuper,
-		CONFIG_ADS860,	   CONFIG_IP860,      CONFIG_SM850,
-		CONFIG_AMX860,	   CONFIG_IPHASE4539, CONFIG_SPD823TS,
-		CONFIG_AR405,	   CONFIG_IVML24,     CONFIG_SXNI855T,
-		CONFIG_BAB7xx,	   CONFIG_IVML24_128, CONFIG_Sandpoint8240,
-		CONFIG_CANBT,	   CONFIG_IVML24_256, CONFIG_Sandpoint8245,
-		CONFIG_CCM,	   CONFIG_IVMS8,      CONFIG_TQM823L,
-		CONFIG_CPCI405,	   CONFIG_IVMS8_128,  CONFIG_TQM850L,
-		CONFIG_CPCI4052,   CONFIG_IVMS8_256,  CONFIG_TQM855L,
-		CONFIG_CPCIISER4,  CONFIG_LANTEC,     CONFIG_TQM860L,
-		CONFIG_CPU86,	   CONFIG_MBX,	      CONFIG_TQM8260,
-		CONFIG_CRAYL1,	   CONFIG_MBX860T,    CONFIG_TTTech,
-		CONFIG_CU824,	   CONFIG_MHPC,	      CONFIG_UTX8245,
-		CONFIG_DASA_SIM,   CONFIG_MIP405,     CONFIG_W7OLMC,
-		CONFIG_DU405,	   CONFIG_MOUSSE,     CONFIG_W7OLMG,
-		CONFIG_ELPPC,	   CONFIG_MPC8260ADS, CONFIG_WALNUT405,
-		CONFIG_ERIC,	   CONFIG_MUSENKI,    CONFIG_ZUMA,
-		CONFIG_ESTEEM192E, CONFIG_MVS1,	      CONFIG_c2mon,
-		CONFIG_ETX094,	   CONFIG_NX823,      CONFIG_cogent_mpc8260,
-		CONFIG_EVB64260,   CONFIG_OCRTC,      CONFIG_cogent_mpc8xx,
-		CONFIG_FADS823,	   CONFIG_ORSG,	      CONFIG_ep8260,
-		CONFIG_FADS850SAR, CONFIG_OXC,	      CONFIG_gw8260,
-		CONFIG_FADS860T,   CONFIG_PCI405,     CONFIG_hermes,
-		CONFIG_FLAGADM,	   CONFIG_PCIPPC2,    CONFIG_hymod,
-		CONFIG_FPS850L,	   CONFIG_PCIPPC6,    CONFIG_lwmon,
-		CONFIG_GEN860T,	   CONFIG_PIP405,     CONFIG_pcu_e,
-		CONFIG_GENIETV,	   CONFIG_PM826,      CONFIG_ppmc8260,
-		CONFIG_GTH,	   CONFIG_RPXClassic, CONFIG_rsdproto,
-		CONFIG_IAD210,	   CONFIG_RPXlite,    CONFIG_sbc8260,
-		CONFIG_EBONY,	   CONFIG_sacsng,     CONFIG_FPS860L,
-		CONFIG_V37,	   CONFIG_ELPT860,    CONFIG_CMI,
-		CONFIG_NETVIA,	   CONFIG_RBC823,     CONFIG_ZPC1900,
-		CONFIG_MPC8540ADS, CONFIG_MPC8560ADS, CONFIG_QS850,
-		CONFIG_QS823,	   CONFIG_QS860T,     CONFIG_DB64360,
-		CONFIG_DB64460,	   CONFIG_DUET_ADS    CONFIG_NETTA
-		CONFIG_NETPHONE
+		CONFIG_ADCIOP,		CONFIG_ADS860,		CONFIG_AMX860,
+		CONFIG_AR405,		CONFIG_BAB7xx,		CONFIG_c2mon,
+		CONFIG_CANBT,		CONFIG_CCM,		CONFIG_CMI,
+		CONFIG_cogent_mpc8260,	CONFIG_cogent_mpc8xx,	CONFIG_CPCI405,
+		CONFIG_CPCI4052,	CONFIG_CPCIISER4,	CONFIG_CPU86,
+		CONFIG_CRAYL1,		CONFIG_CU824,		CONFIG_DASA_SIM,
+		CONFIG_DB64360,		CONFIG_DB64460,		CONFIG_DU405,
+		CONFIG_DUET_ADS,	CONFIG_EBONY,		CONFIG_ELPPC,
+		CONFIG_ELPT860,		CONFIG_ep8260,		CONFIG_ERIC,
+		CONFIG_ESTEEM192E,	CONFIG_ETX094,		CONFIG_EVB64260,
+		CONFIG_FADS823,		CONFIG_FADS850SAR,	CONFIG_FADS860T,
+		CONFIG_FLAGADM,		CONFIG_FPS850L,		CONFIG_FPS860L,
+		CONFIG_GEN860T,		CONFIG_GENIETV,		CONFIG_GTH,
+		CONFIG_gw8260,		CONFIG_hermes,		CONFIG_hymod,
+		CONFIG_IAD210,		CONFIG_ICU862,		CONFIG_IP860,
+		CONFIG_IPHASE4539,	CONFIG_IVML24,		CONFIG_IVML24_128,
+		CONFIG_IVML24_256,	CONFIG_IVMS8,		CONFIG_IVMS8_128,
+		CONFIG_IVMS8_256,	CONFIG_JSE,		CONFIG_LANTEC,
+		CONFIG_lwmon,		CONFIG_MBX,		CONFIG_MBX860T,
+		CONFIG_MHPC,		CONFIG_MIP405,		CONFIG_MOUSSE,
+		CONFIG_MPC8260ADS,	CONFIG_MPC8540ADS,	CONFIG_MPC8560ADS,
+		CONFIG_MUSENKI,		CONFIG_MVS1,		CONFIG_NETPHONE,
+		CONFIG_NETTA,		CONFIG_NETVIA,		CONFIG_NX823,
+		CONFIG_OCRTC,		CONFIG_ORSG,		CONFIG_OXC,
+		CONFIG_PCI405,		CONFIG_PCIPPC2,		CONFIG_PCIPPC6,
+		CONFIG_pcu_e,		CONFIG_PIP405,		CONFIG_PM826,
+		CONFIG_ppmc8260,	CONFIG_QS823,		CONFIG_QS850,
+		CONFIG_QS860T,		CONFIG_RBC823,		CONFIG_RPXClassic,
+		CONFIG_RPXlite,		CONFIG_RPXsuper,	CONFIG_rsdproto,
+		CONFIG_sacsng,		CONFIG_Sandpoint8240,	CONFIG_Sandpoint8245,
+		CONFIG_sbc8260,		CONFIG_SM850,		CONFIG_SPD823TS,
+		CONFIG_SXNI855T,	CONFIG_TQM823L,		CONFIG_TQM8260,
+		CONFIG_TQM850L,		CONFIG_TQM855L,		CONFIG_TQM860L,
+		CONFIG_TTTech,		CONFIG_UTX8245,		CONFIG_V37,
+		CONFIG_W7OLMC,		CONFIG_W7OLMG,		CONFIG_WALNUT405,
+		CONFIG_ZPC1900,		CONFIG_ZUMA,
 
 		ARM based boards:
 		-----------------
 
-		CONFIG_HHP_CRADLE,  CONFIG_DNP1110,	CONFIG_EP7312,
-		CONFIG_IMPA7,	    CONFIG_LART,	CONFIG_LUBBOCK,
-		CONFIG_INNOVATOROMAP1510,      CONFIG_INNOVATOROMAP1610,
-		CONFIG_H2_OMAP1610, CONFIG_SHANNON,	CONFIG_SMDK2400,
-		CONFIG_SMDK2410,    CONFIG_TRAB,	CONFIG_VCMA9,
-		CONFIG_AT91RM9200DK
+		CONFIG_AT91RM9200DK,		CONFIG_DNP1110,		CONFIG_EP7312,
+		CONFIG_H2_OMAP1610,		CONFIG_HHP_CRADLE,	CONFIG_IMPA7,
+		CONFIG_INNOVATOROMAP1510,   CONFIG_INNOVATOROMAP1610,	CONFIG_LART,
+		CONFIG_LUBBOCK,			CONFIG_SHANNON,		CONFIG_SMDK2400,
+		CONFIG_SMDK2410,		CONFIG_TRAB,		CONFIG_VCMA9,
 
 
 - CPU Module Type: (if CONFIG_COGENT is defined)
@@ -1971,1271 +1970,1272 @@ is done by typing:
 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
-    at91rm9200dk_config	  omap1510inn_config	MPC8260ADS_config
-    omap1610inn_config	  ZPC1900_config	MPC8540ADS_config
-    MPC8560ADS_config	  QS850_config		QS823_config
-    QS860T_config	  DUET_ADS_config	omap1610h2_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 download 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 in alphabetical sort order. 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 by 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
+	ADCIOP_config		ADS860_config		AR405_config
+	at91rm9200dk_config	CANBT_config		cmi_mpc5xx_config
+	cogent_common_config	cogent_mpc8260_config	cogent_mpc8xx_config
+	CPCI405_config		CPCIISER4_config	CU824_config
+	DUET_ADS_config		EBONY_config		ELPT860_config
+	ESTEEM192E_config	ETX094_config		FADS823_config
+	FADS850SAR_config	FADS860T_config		FPS850L_config
+	FPS860L_config		GEN860T_config		GENIETV_config
+	GTH_config		hermes_config		hymod_config
+	IP860_config		IVML24_config		IVMS8_config
+	JSE_config		LANTEC_config		lwmon_config
+	MBX860T_config		MBX_config		MPC8260ADS_config
+	MPC8540ADS_config	MPC8560ADS_config	NETVIA_config
+	omap1510inn_config	omap1610h2_config	omap1610inn_config
+	pcu_e_config		PIP405_config		QS823_config
+	QS850_config		QS860T_config		RPXlite_config
+	RPXsuper_config		rsdproto_config		Sandpoint8240_config
+	sbc8260_config		SM850_config		SPD823TS_config
+	SXNI855T_config		TQM823L_config		TQM850L_config
+	TQM855L_config		TQM860L_config		WALNUT405_config
+	ZPC1900_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 download 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 in alphabetical sort order. 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 by 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
+			  does not overwrite the U-Boot stack and data).
+
+			  For instance, when you have a system with 16 MB
+			  RAM, and want to reserve 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
 
-  bootcmd	- see CONFIG_BOOTCOMMAND
+			  If you set initrd_high to 0xFFFFFFFF, this is an
+			  indication to U-Boot that all addresses are legal
+			  for the Linux kernel, including addresses in flash
+			  memory. In this case U-Boot will NOT COPY the
+			  ramdisk at all. This may be useful to reduce the
+			  boot time on your system, but requires that this
+			  feature is supported by your Linux kernel.
 
-  bootargs	- Boot arguments when booting an RTOS image
+	  ipaddr	- IP address; needed for tftpboot command
 
-  bootfile	- Name of the image to load with TFTP
+	  loadaddr	- Default load address for commands like "bootp",
+			  "rarpboot", "tftpboot", "loadb" or "diskboot"
 
-  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
+	  loads_echo	- see CONFIG_LOADS_ECHO
 
-  autostart	- if set to "yes", an image loaded using the "bootp",
-		  "rarpboot", "tftpboot" or "diskboot" commands will
-		  be automatically started (by internally calling
-		  "bootm")
+	  serverip	- TFTP server IP address; needed for tftpboot command
 
-		  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.
+	  bootretry	- see CONFIG_BOOT_RETRY_TIME
 
-  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).
+	  bootdelaykey	- see CONFIG_AUTOBOOT_DELAY_STR
 
-		  For instance, when you have a system with 16 MB
-		  RAM, and want to reserve 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
+	  bootstopkey	- see CONFIG_AUTOBOOT_STOP_STR
 
-		  setenv initrd_high 00c00000
+	  ethprime	- When CONFIG_NET_MULTI is enabled controls which
+			  interface is used first.
 
-		  If you set initrd_high to 0xFFFFFFFF, this is an
-		  indication to U-Boot that all addresses are legal
-		  for the Linux kernel, including addresses in flash
-		  memory. In this case U-Boot will NOT COPY the
-		  ramdisk at all. This may be useful to reduce the
-		  boot time on your system, but requires that this
-		  feature is supported by your Linux kernel.
+	  ethact	- When CONFIG_NET_MULTI is enabled controls which
+			  interface is currently active. For example you
+			  can do the following
 
-  ipaddr	- IP address; needed for tftpboot command
+			  => setenv ethact FEC ETHERNET
+			  => ping 192.168.0.1 # traffic sent on FEC ETHERNET
+			  => setenv ethact SCC ETHERNET
+			  => ping 10.0.0.1 # traffic sent on SCC ETHERNET
 
-  loadaddr	- Default load address for commands like "bootp",
-		  "rarpboot", "tftpboot", "loadb" or "diskboot"
+	   netretry	- When set to "no" each network operation will
+			  either succeed or fail without retrying.
+			  Useful on scripts which control the retry operation
+			  themselves.
 
-  loads_echo	- see CONFIG_LOADS_ECHO
+	   vlan		- When set to a value < 4095 the traffic over
+			  ethernet is encapsulated/received over 802.1q
+			  VLAN tagged frames.
 
-  serverip	- TFTP server IP address; needed for tftpboot command
+	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:
 
-  bootretry	- see CONFIG_BOOT_RETRY_TIME
+	  bootfile	- see above
+	  dnsip		- IP address of your Domain Name Server
+	  dnsip2	- IP address of your secondary 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
 
-  bootdelaykey	- see CONFIG_AUTOBOOT_DELAY_STR
 
-  bootstopkey	- see CONFIG_AUTOBOOT_STOP_STR
+	There are two special Environment Variables:
 
-  ethprime	- When CONFIG_NET_MULTI is enabled controls which
-  		  interface is used first.
+	  serial#	- contains hardware identification information such
+			  as type string and/or serial number
+	  ethaddr	- Ethernet address
 
-  ethact	- When CONFIG_NET_MULTI is enabled controls which
-  		  interface is currently active. For example you
-		  can do the following
+	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.
 
-		  => setenv ethact FEC ETHERNET
-		  => ping 192.168.0.1 # traffic sent on FEC ETHERNET
-		  => setenv ethact SCC ETHERNET
-		  => ping 10.0.0.1 # traffic sent on SCC ETHERNET
 
-   netretry	- When set to "no" each network operation will
-   		  either succeed or fail without retrying.
-		  Useful on scripts which control the retry operation
-		  themselves.
+	Further special Environment Variables:
 
-   vlan		- When set to a value < 4095 the traffic over
-   		  ethernet is encapsulated/received over 802.1q
-		  VLAN tagged frames.
+	  ver		- Contains the U-Boot version string as printed
+			  with the "version" command. This variable is
+			  readonly (see CONFIG_VERSION_VARIABLE).
 
-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
-  dnsip2	- IP address of your secondary 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
+	Please note that changes to some configuration parameters may take
+	only effect after the next boot (yes, that's just like Windoze :-).
 
 
-There are two special Environment Variables:
+	Command Line Parsing:
+	=====================
 
-  serial#	- contains hardware identification information such
-		  as type string and/or serial number
-  ethaddr	- Ethernet address
+	There are two different command line parsers available with U-Boot:
+	the old "simple" one, and the much more powerful "hush" shell:
 
-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.
+	Old, simple command line parser:
+	--------------------------------
 
+	- supports environment variables (through setenv / saveenv commands)
+	- several commands on one line, separated by ';'
+	- variable substitution using "... $(name) ..." syntax
+	- special characters ('$', ';') can be escaped by prefixing with '\',
+	  for example:
+		setenv bootcmd bootm \$(address)
+	- You can also escape text by enclosing in single apostrophes, for example:
+		setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off'
 
-Further special Environment Variables:
+	Hush shell:
+	-----------
 
-  ver		- Contains the U-Boot version string as printed
-		  with the "version" command. This variable is
-		  readonly (see CONFIG_VERSION_VARIABLE).
+	- similar to Bourne shell, with control structures like
+	  if...then...else...fi, for...do...done; while...do...done,
+	  until...do...done, ...
+	- supports environment ("global") variables (through setenv / saveenv
+	  commands) and local shell variables (through standard shell syntax
+	  "name=value"); only environment variables can be used with "run"
+	  command
 
+	General rules:
+	--------------
 
-Please note that changes to some configuration parameters may take
-only effect after the next boot (yes, that's just like Windoze :-).
+	(1) If a command line (or an environment variable executed by a "run"
+	    command) contains several commands separated by semicolon, and
+	    one of these commands fails, then the remaining commands will be
+	    executed anyway.
 
+	(2) If you execute several variables with one call to run (i. e.
+	    calling run with a list af variables as arguments), any failing
+	    command will cause "run" to terminate, i. e. the remaining
+	    variables are not executed.
 
-Command Line Parsing:
-=====================
+	Note for Redundant Ethernet Interfaces:
+	=======================================
 
-There are two different command line parsers available with U-Boot:
-the old "simple" one, and the much more powerful "hush" shell:
+	Some boards come with redundant ethernet interfaces; U-Boot supports
+	such configurations and is capable of automatic selection of a
+	"working" interface when needed. MAC assignment works as follows:
 
-Old, simple command line parser:
---------------------------------
+	Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
+	MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
+	"eth1addr" (=>eth1), "eth2addr", ...
 
-- supports environment variables (through setenv / saveenv commands)
-- several commands on one line, separated by ';'
-- variable substitution using "... $(name) ..." syntax
-- special characters ('$', ';') can be escaped by prefixing with '\',
-  for example:
-	setenv bootcmd bootm \$(address)
-- You can also escape text by enclosing in single apostrophes, for example:
-	setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off'
+	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:
 
-Hush shell:
------------
+	o If the SROM has a valid MAC address, and there is no address in the
+	  environment, the SROM's address is used.
 
-- similar to Bourne shell, with control structures like
-  if...then...else...fi, for...do...done; while...do...done,
-  until...do...done, ...
-- supports environment ("global") variables (through setenv / saveenv
-  commands) and local shell variables (through standard shell syntax
-  "name=value"); only environment variables can be used with "run"
-  command
+	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.
 
-General rules:
---------------
-
-(1) If a command line (or an environment variable executed by a "run"
-    command) contains several commands separated by semicolon, and
-    one of these commands fails, then the remaining commands will be
-    executed anyway.
-
-(2) If you execute several variables with one call to run (i. e.
-    calling run with a list af variables as arguments), any failing
-    command will cause "run" to terminate, i. e. the remaining
-    variables are not executed.
+	o If both the SROM and the environment contain a MAC address, and
+	  both addresses are the same, this MAC address is used.
 
-Note for Redundant Ethernet Interfaces:
-=======================================
+	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.
 
-Some boards come with redundant ethernet interfaces; U-Boot supports
-such configurations and is capable of automatic selection of a
-"working" interface when needed. MAC assignment works as follows:
+	o If neither SROM nor the environment contain a MAC address, an error
+	  is raised.
 
-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:
+	Image Formats:
+	==============
 
-o If the SROM has a valid MAC address, and there is no address in the
-  environment, the SROM's address is used.
+	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:
 
-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.
+	* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
+	  4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
+	  LynxOS, pSOS, QNX, RTEMS, ARTOS;
+	  Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS).
+	* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
+	  IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
+	  Currently supported: ARM, Intel x86, MIPS, NIOS, PowerPC).
+	* Compression Type (uncompressed, gzip, bzip2)
+	* Load Address
+	* Entry Point
+	* Image Name
+	* Image Timestamp
 
-o If both the SROM and the environment contain a MAC address, and
-  both addresses are the same, this MAC address is used.
+	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.
 
-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.
+	Linux Support:
+	==============
 
+	Although U-Boot should support any OS or standalone application
+	easily, the main focus has always been on Linux during the design of
+	U-Boot.
 
-Image Formats:
-==============
+	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 several purposes:
 
-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:
+	- the same features can be used for other OS or standalone
+	  applications (for instance: using compressed images to reduce the
+	  Flash memory footprint)
 
-* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
-  4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
-  LynxOS, pSOS, QNX, RTEMS, ARTOS;
-  Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS).
-* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
-  IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
-  Currently supported: ARM, Intel x86, MIPS, NIOS, PowerPC).
-* Compression Type (uncompressed, gzip, bzip2)
-* Load Address
-* Entry Point
-* Image Name
-* Image Timestamp
+	- it becomes much easier to port new Linux kernel versions because
+	  lots of low-level, hardware dependent stuff are done by U-Boot
 
-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.
+	- the same Linux kernel image can now be used with different "initrd"
+	  images; of course this also means that different kernel images can
+	  be run with the same "initrd". This makes testing easier (you don't
+	  have to build a new "zImage.initrd" Linux image when you just
+	  change a file in your "initrd"). Also, a field-upgrade of the
+	  software is easier now.
 
 
-Linux Support:
-==============
+	Linux HOWTO:
+	============
 
-Although U-Boot should support any OS or standalone application
-easily, the main focus has always been on Linux during the design of
-U-Boot.
+	Porting Linux to U-Boot based systems:
+	---------------------------------------
 
-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 several purposes:
+	U-Boot cannot save you from doing all the necessary modifications to
+	configure the Linux device drivers for use with your target hardware
+	(no, we don't intend to provide a full virtual machine interface to
+	Linux :-).
 
-- the same features can be used for other OS or standalone
-  applications (for instance: using compressed images to reduce the
-  Flash memory footprint)
+	But now you can ignore ALL boot loader code (in arch/ppc/mbxboot).
 
-- it becomes much easier to port new Linux kernel versions because
-  lots of low-level, hardware dependent stuff are done by U-Boot
+	Just make sure your machine specific header file (for instance
+	include/asm-ppc/tqm8xx.h) includes the same definition of the Board
+	Information structure as we define in include/u-boot.h, and make
+	sure that your definition of IMAP_ADDR uses the same value as your
+	U-Boot configuration in CFG_IMMR.
 
-- the same Linux kernel image can now be used with different "initrd"
-  images; of course this also means that different kernel images can
-  be run with the same "initrd". This makes testing easier (you don't
-  have to build a new "zImage.initrd" Linux image when you just
-  change a file in your "initrd"). Also, a field-upgrade of the
-  software is easier now.
 
+	Configuring the Linux kernel:
+	-----------------------------
 
-Linux HOWTO:
-============
+	No specific requirements for U-Boot. Make sure you have some root
+	device (initial ramdisk, NFS) for your target system.
 
-Porting Linux to U-Boot based systems:
----------------------------------------
 
-U-Boot cannot save you from doing all the necessary modifications to
-configure the Linux device drivers for use with your target hardware
-(no, we don't intend to provide a full virtual machine interface to
-Linux :-).
+	Building a Linux Image:
+	-----------------------
 
-But now you can ignore ALL boot loader code (in arch/ppc/mbxboot).
+	With U-Boot, "normal" build targets like "zImage" or "bzImage" are
+	not used. If you use recent kernel source, a new build target
+	"uImage" will exist which automatically builds an image usable by
+	U-Boot. Most older kernels also have support for a "pImage" target,
+	which was introduced for our predecessor project PPCBoot and uses a
+	100% compatible format.
 
-Just make sure your machine specific header file (for instance
-include/asm-ppc/tqm8xx.h) includes the same definition of the Board
-Information structure as we define in include/u-boot.h, and make
-sure that your definition of IMAP_ADDR uses the same value as your
-U-Boot configuration in CFG_IMMR.
+	Example:
 
+		make TQM850L_config
+		make oldconfig
+		make dep
+		make uImage
 
-Configuring the Linux kernel:
------------------------------
+	The "uImage" build target uses a special tool (in 'tools/mkimage') to
+	encapsulate a compressed Linux kernel image with header	 information,
+	CRC32 checksum etc. for use with U-Boot. This is what we are doing:
 
-No specific requirements for U-Boot. Make sure you have some root
-device (initial ramdisk, NFS) for your target system.
+	* build a standard "vmlinux" kernel image (in ELF binary format):
+
+	* convert the kernel into a raw binary image:
+
+		${CROSS_COMPILE}-objcopy -O binary \
+					 -R .note -R .comment \
+					 -S vmlinux linux.bin
+
+	* compress the binary image:
+
+		gzip -9 linux.bin
 
+	* package compressed binary image for U-Boot:
 
-Building a Linux Image:
------------------------
+		mkimage -A ppc -O linux -T kernel -C gzip \
+			-a 0 -e 0 -n "Linux Kernel Image" \
+			-d linux.bin.gz uImage
 
-With U-Boot, "normal" build targets like "zImage" or "bzImage" are
-not used. If you use recent kernel source, a new build target
-"uImage" will exist which automatically builds an image usable by
-U-Boot. Most older kernels also have support for a "pImage" target,
-which was introduced for our predecessor project PPCBoot and uses a
-100% compatible format.
-
-Example:
-
-	make TQM850L_config
-	make oldconfig
-	make dep
-	make uImage
-
-The "uImage" build target uses a special tool (in 'tools/mkimage') to
-encapsulate a compressed Linux kernel image with header	 information,
-CRC32 checksum etc. for use with U-Boot. This is what we are doing:
-
-* build a standard "vmlinux" kernel image (in ELF binary format):
-
-* convert the kernel into a raw binary image:
-
-	${CROSS_COMPILE}-objcopy -O binary \
-				 -R .note -R .comment \
-				 -S vmlinux linux.bin
-
-* compress the binary image:
-
-	gzip -9 linux.bin
-
-* package compressed binary image for U-Boot:
-
-	mkimage -A ppc -O linux -T kernel -C gzip \
-		-a 0 -e 0 -n "Linux Kernel Image" \
-		-d linux.bin.gz uImage
 
+	The "mkimage" tool can also be used to create ramdisk images for use
+	with U-Boot, either separated from the Linux kernel image, or
+	combined into one file. "mkimage" encapsulates the images with a 64
+	byte header containing information about target architecture,
+	operating system, image type, compression method, entry points, time
+	stamp, CRC32 checksums, etc.
 
-The "mkimage" tool can also be used to create ramdisk images for use
-with U-Boot, either separated from the Linux kernel image, or
-combined into one file. "mkimage" encapsulates the images with a 64
-byte header containing information about target architecture,
-operating system, image type, compression method, entry points, time
-stamp, CRC32 checksums, etc.
-
-"mkimage" can be called in two ways: to verify existing images and
-print the header information, or to build new images.
-
-In the first form (with "-l" option) mkimage lists the information
-contained in the header of an existing U-Boot image; this includes
-checksum verification:
+	"mkimage" can be called in two ways: to verify existing images and
+	print the header information, or to build new images.
 
-	tools/mkimage -l image
-	  -l ==> list image header information
+	In the first form (with "-l" option) mkimage lists the information
+	contained in the header of an existing U-Boot image; this includes
+	checksum verification:
 
-The second form (with "-d" option) is used to build a U-Boot image
-from a "data file" which is used as image payload:
-
-	tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \
-		      -n name -d data_file image
-	  -A ==> set architecture to 'arch'
-	  -O ==> set operating system to 'os'
-	  -T ==> set image type to 'type'
-	  -C ==> set compression type 'comp'
-	  -a ==> set load address to 'addr' (hex)
-	  -e ==> set entry point to 'ep' (hex)
-	  -n ==> set image name to 'name'
-	  -d ==> use image data from 'datafile'
+		tools/mkimage -l image
+		  -l ==> list image header information
 
-Right now, all Linux kernels use the same load address	(0x00000000),
-but the entry point address depends on the kernel version:
-
-- 2.2.x kernels have the entry point at 0x0000000C,
-- 2.3.x and later kernels have the entry point at 0x00000000.
-
-So a typical call to build a U-Boot image would read:
-
-	-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
-	> -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \
-	> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux.gz \
-	> examples/uImage.TQM850L
-	Image Name:   2.4.4 kernel for TQM850L
-	Created:      Wed Jul 19 02:34:59 2000
-	Image Type:   PowerPC Linux Kernel Image (gzip compressed)
-	Data Size:    335725 Bytes = 327.86 kB = 0.32 MB
-	Load Address: 0x00000000
-	Entry Point:  0x00000000
+	The second form (with "-d" option) is used to build a U-Boot image
+	from a "data file" which is used as image payload:
 
-To verify the contents of the image (or check for corruption):
+		tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \
+			      -n name -d data_file image
+		  -A ==> set architecture to 'arch'
+		  -O ==> set operating system to 'os'
+		  -T ==> set image type to 'type'
+		  -C ==> set compression type 'comp'
+		  -a ==> set load address to 'addr' (hex)
+		  -e ==> set entry point to 'ep' (hex)
+		  -n ==> set image name to 'name'
+		  -d ==> use image data from 'datafile'
 
-	-> tools/mkimage -l examples/uImage.TQM850L
-	Image Name:   2.4.4 kernel for TQM850L
-	Created:      Wed Jul 19 02:34:59 2000
-	Image Type:   PowerPC Linux Kernel Image (gzip compressed)
-	Data Size:    335725 Bytes = 327.86 kB = 0.32 MB
-	Load Address: 0x00000000
-	Entry Point:  0x00000000
+	Right now, all Linux kernels use the same load address	(0x00000000),
+	but the entry point address depends on the kernel version:
 
-NOTE: for embedded systems where boot time is critical you can trade
-speed for memory and install an UNCOMPRESSED image instead: this
-needs more space in Flash, but boots much faster since it does not
-need to be uncompressed:
-
-	-> gunzip /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux.gz
-	-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
-	> -A ppc -O linux -T kernel -C none -a 0 -e 0 \
-	> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux \
-	> examples/uImage.TQM850L-uncompressed
-	Image Name:   2.4.4 kernel for TQM850L
-	Created:      Wed Jul 19 02:34:59 2000
-	Image Type:   PowerPC Linux Kernel Image (uncompressed)
-	Data Size:    792160 Bytes = 773.59 kB = 0.76 MB
-	Load Address: 0x00000000
-	Entry Point:  0x00000000
-
-
-Similar you can build U-Boot images from a 'ramdisk.image.gz' file
-when your kernel is intended to use an initial ramdisk:
-
-	-> tools/mkimage -n 'Simple Ramdisk Image' \
-	> -A ppc -O linux -T ramdisk -C gzip \
-	> -d /LinuxPPC/images/SIMPLE-ramdisk.image.gz examples/simple-initrd
-	Image Name:   Simple Ramdisk Image
-	Created:      Wed Jan 12 14:01:50 2000
-	Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
-	Data Size:    566530 Bytes = 553.25 kB = 0.54 MB
-	Load Address: 0x00000000
-	Entry Point:  0x00000000
-
-
-Installing a Linux Image:
--------------------------
-
-To downloading a U-Boot image over the serial (console) interface,
-you must convert the image to S-Record format:
-
-	objcopy -I binary -O srec examples/image examples/image.srec
-
-The 'objcopy' does not understand the information in the U-Boot
-image header, so the resulting S-Record file will be relative to
-address 0x00000000. To load it to a given address, you need to
-specify the target address as 'offset' parameter with the 'loads'
-command.
-
-Example: install the image to address 0x40100000 (which on the
-TQM8xxL is in the first Flash bank):
-
-	=> erase 40100000 401FFFFF
-
-	.......... done
-	Erased 8 sectors
-
-	=> loads 40100000
-	## Ready for S-Record download ...
-	~>examples/image.srec
-	1 2 3 4 5 6 7 8 9 10 11 12 13 ...
-	...
-	15989 15990 15991 15992
-	[file transfer complete]
-	[connected]
-	## Start Addr = 0x00000000
-
-
-You can check the success of the download using the 'iminfo' command;
-this includes a checksum verification so you  can  be  sure  no	 data
-corruption happened:
-
-	=> imi 40100000
-
-	## Checking Image at 40100000 ...
-	   Image Name:	 2.2.13 for initrd on TQM850L
-	   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
-	   Data Size:	 335725 Bytes = 327 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 0000000c
-	   Verifying Checksum ... OK
-
-
-Boot Linux:
------------
-
-The "bootm" command is used to boot an application that is stored in
-memory (RAM or Flash). In case of a Linux kernel image, the contents
-of the "bootargs" environment variable is passed to the kernel as
-parameters. You can check and modify this variable using the
-"printenv" and "setenv" commands:
-
-
-	=> printenv bootargs
-	bootargs=root=/dev/ram
-
-	=> setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
-
-	=> printenv bootargs
-	bootargs=root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
-
-	=> bootm 40020000
-	## Booting Linux kernel at 40020000 ...
-	   Image Name:	 2.2.13 for NFS on TQM850L
-	   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
-	   Data Size:	 381681 Bytes = 372 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 0000000c
-	   Verifying Checksum ... OK
-	   Uncompressing Kernel Image ... OK
-	Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:35:17 MEST 2000
-	Boot arguments: root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
-	time_init: decrementer frequency = 187500000/60
-	Calibrating delay loop... 49.77 BogoMIPS
-	Memory: 15208k available (700k kernel code, 444k data, 32k init) [c0000000,c1000000]
-	...
-
-If you want to boot a Linux kernel with initial ram disk, you pass
-the memory addresses of both the kernel and the initrd image (PPBCOOT
-format!) to the "bootm" command:
-
-	=> imi 40100000 40200000
-
-	## Checking Image at 40100000 ...
-	   Image Name:	 2.2.13 for initrd on TQM850L
-	   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
-	   Data Size:	 335725 Bytes = 327 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 0000000c
-	   Verifying Checksum ... OK
-
-	## Checking Image at 40200000 ...
-	   Image Name:	 Simple Ramdisk Image
-	   Image Type:	 PowerPC Linux RAMDisk Image (gzip compressed)
-	   Data Size:	 566530 Bytes = 553 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 00000000
-	   Verifying Checksum ... OK
-
-	=> bootm 40100000 40200000
-	## Booting Linux kernel at 40100000 ...
-	   Image Name:	 2.2.13 for initrd on TQM850L
-	   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
-	   Data Size:	 335725 Bytes = 327 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 0000000c
-	   Verifying Checksum ... OK
-	   Uncompressing Kernel Image ... OK
-	## Loading RAMDisk Image at 40200000 ...
-	   Image Name:	 Simple Ramdisk Image
-	   Image Type:	 PowerPC Linux RAMDisk Image (gzip compressed)
-	   Data Size:	 566530 Bytes = 553 kB = 0 MB
-	   Load Address: 00000000
-	   Entry Point:	 00000000
-	   Verifying Checksum ... OK
-	   Loading Ramdisk ... OK
-	Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:32:08 MEST 2000
-	Boot arguments: root=/dev/ram
-	time_init: decrementer frequency = 187500000/60
-	Calibrating delay loop... 49.77 BogoMIPS
-	...
-	RAMDISK: Compressed image found at block 0
-	VFS: Mounted root (ext2 filesystem).
-
-	bash#
-
-More About U-Boot Image Types:
-------------------------------
-
-U-Boot supports the following image types:
-
-   "Standalone Programs" are directly runnable in the environment
-	provided by U-Boot; it is expected that (if they behave
-	well) you can continue to work in U-Boot after return from
-	the Standalone Program.
-   "OS Kernel Images" are usually images of some Embedded OS which
-	will take over control completely. Usually these programs
-	will install their own set of exception handlers, device
-	drivers, set up the MMU, etc. - this means, that you cannot
-	expect to re-enter U-Boot except by resetting the CPU.
-   "RAMDisk Images" are more or less just data blocks, and their
-	parameters (address, size) are passed to an OS kernel that is
-	being started.
-   "Multi-File Images" contain several images, typically an OS
-	(Linux) kernel image and one or more data images like
-	RAMDisks. This construct is useful for instance when you want
-	to boot over the network using BOOTP etc., where the boot
-	server provides just a single image file, but you want to get
-	for instance an OS kernel and a RAMDisk image.
-
-	"Multi-File Images" start with a list of image sizes, each
-	image size (in bytes) specified by an "uint32_t" in network
-	byte order. This list is terminated by an "(uint32_t)0".
-	Immediately after the terminating 0 follow the images, one by
-	one, all aligned on "uint32_t" boundaries (size rounded up to
-	a multiple of 4 bytes).
-
-   "Firmware Images" are binary images containing firmware (like
-	U-Boot or FPGA images) which usually will be programmed to
-	flash memory.
-
-   "Script files" are command sequences that will be executed by
-	U-Boot's command interpreter; this feature is especially
-	useful when you configure U-Boot to use a real shell (hush)
-	as command interpreter.
-
-
-Standalone HOWTO:
-=================
-
-One of the features of U-Boot is that you can dynamically load and
-run "standalone" applications, which can use some resources of
-U-Boot like console I/O functions or interrupt services.
-
-Two simple examples are included with the sources:
-
-"Hello World" Demo:
--------------------
-
-'examples/hello_world.c' contains a small "Hello World" Demo
-application; it is automatically compiled when you build U-Boot.
-It's configured to run at address 0x00040004, so you can play with it
-like that:
-
-	=> loads
-	## Ready for S-Record download ...
-	~>examples/hello_world.srec
-	1 2 3 4 5 6 7 8 9 10 11 ...
-	[file transfer complete]
-	[connected]
-	## Start Addr = 0x00040004
-
-	=> go 40004 Hello World! This is a test.
-	## Starting application at 0x00040004 ...
-	Hello World
-	argc = 7
-	argv[0] = "40004"
-	argv[1] = "Hello"
-	argv[2] = "World!"
-	argv[3] = "This"
-	argv[4] = "is"
-	argv[5] = "a"
-	argv[6] = "test."
-	argv[7] = "<NULL>"
-	Hit any key to exit ...
-
-	## Application terminated, rc = 0x0
-
-Another example, which demonstrates how to register a CPM interrupt
-handler with the U-Boot code, can be found in 'examples/timer.c'.
-Here, a CPM timer is set up to generate an interrupt every second.
-The interrupt service routine is trivial, just printing a '.'
-character, but this is just a demo program. The application can be
-controlled by the following keys:
-
-	? - print current values og the CPM Timer registers
-	b - enable interrupts and start timer
-	e - stop timer and disable interrupts
-	q - quit application
-
-	=> loads
-	## Ready for S-Record download ...
-	~>examples/timer.srec
-	1 2 3 4 5 6 7 8 9 10 11 ...
-	[file transfer complete]
-	[connected]
-	## Start Addr = 0x00040004
-
-	=> go 40004
-	## Starting application at 0x00040004 ...
-	TIMERS=0xfff00980
-	Using timer 1
-	  tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998, tcn @ 0xfff0099c, ter @ 0xfff009b0
-
-Hit 'b':
-	[q, b, e, ?] Set interval 1000000 us
-	Enabling timer
-Hit '?':
-	[q, b, e, ?] ........
-	tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0
-Hit '?':
-	[q, b, e, ?] .
-	tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0
-Hit '?':
-	[q, b, e, ?] .
-	tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0
-Hit '?':
-	[q, b, e, ?] .
-	tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0
-Hit 'e':
-	[q, b, e, ?] ...Stopping timer
-Hit 'q':
-	[q, b, e, ?] ## Application terminated, rc = 0x0
-
-
-Minicom warning:
-================
-
-Over time, many people have reported problems when trying to use the
-"minicom" terminal emulation program for serial download. I (wd)
-consider minicom to be broken, and recommend not to use it. Under
-Unix, I recommend to use C-Kermit for general purpose use (and
-especially for kermit binary protocol download ("loadb" command), and
-use "cu" for S-Record download ("loads" command).
-
-Nevertheless, if you absolutely want to use it try adding this
-configuration to your "File transfer protocols" section:
-
-	   Name	   Program			Name U/D FullScr IO-Red. Multi
-	X  kermit  /usr/bin/kermit -i -l %l -s	 Y    U	   Y	   N	  N
-	Y  kermit  /usr/bin/kermit -i -l %l -r	 N    D	   Y	   N	  N
-
-
-NetBSD Notes:
-=============
-
-Starting at version 0.9.2, U-Boot supports NetBSD both as host
-(build U-Boot) and target system (boots NetBSD/mpc8xx).
-
-Building requires a cross environment; it is known to work on
-NetBSD/i386 with the cross-powerpc-netbsd-1.3 package (you will also
-need gmake since the Makefiles are not compatible with BSD make).
-Note that the cross-powerpc package does not install include files;
-attempting to build U-Boot will fail because <machine/ansi.h> is
-missing.  This file has to be installed and patched manually:
-
-	# cd /usr/pkg/cross/powerpc-netbsd/include
-	# mkdir powerpc
-	# ln -s powerpc machine
-	# cp /usr/src/sys/arch/powerpc/include/ansi.h powerpc/ansi.h
-	# ${EDIT} powerpc/ansi.h	## must remove __va_list, _BSD_VA_LIST
-
-Native builds *don't* work due to incompatibilities between native
-and U-Boot include files.
-
-Booting assumes that (the first part of) the image booted is a
-stage-2 loader which in turn loads and then invokes the kernel
-proper. Loader sources will eventually appear in the NetBSD source
-tree (probably in sys/arc/mpc8xx/stand/u-boot_stage2/); in the
-meantime, send mail to bruno@exet-ag.de and/or wd@denx.de for
-details.
-
-
-Implementation Internals:
-=========================
-
-The following is not intended to be a complete description of every
-implementation detail. However, it should help to understand the
-inner workings of U-Boot and make it easier to port it to custom
-hardware.
-
-
-Initial Stack, Global Data:
----------------------------
-
-The implementation of U-Boot is complicated by the fact that U-Boot
-starts running out of ROM (flash memory), usually without access to
-system RAM (because the memory controller is not initialized yet).
-This means that we don't have writable Data or BSS segments, and BSS
-is not initialized as zero. To be able to get a C environment working
-at all, we have to allocate at least a minimal stack. Implementation
-options for this are defined and restricted by the CPU used: Some CPU
-models provide on-chip memory (like the IMMR area on MPC8xx and
-MPC826x processors), on others (parts of) the data cache can be
-locked as (mis-) used as memory, etc.
-
-	Chris Hallinan posted a good summary of	 these	issues	to  the
-	u-boot-users mailing list:
-
-	Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
-	From: "Chris Hallinan" <clh@net1plus.com>
-	Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
-	...
-
-	Correct me if I'm wrong, folks, but the way I understand it
-	is this: Using DCACHE as initial RAM for Stack, etc, does not
-	require any physical RAM backing up the cache. The cleverness
-	is that the cache is being used as a temporary supply of
-	necessary storage before the SDRAM controller is setup. It's
-	beyond the scope of this list to expain the details, but you
-	can see how this works by studying the cache architecture and
-	operation in the architecture and processor-specific manuals.
-
-	OCM is On Chip Memory, which I believe the 405GP has 4K. It
-	is another option for the system designer to use as an
-	initial stack/ram area prior to SDRAM being available. Either
-	option should work for you. Using CS 4 should be fine if your
-	board designers haven't used it for something that would
-	cause you grief during the initial boot! It is frequently not
-	used.
-
-	CFG_INIT_RAM_ADDR should be somewhere that won't interfere
-	with your processor/board/system design. The default value
-	you will find in any recent u-boot distribution in
-	Walnut405.h should work for you. I'd set it to a value larger
-	than your SDRAM module. If you have a 64MB SDRAM module, set
-	it above 400_0000. Just make sure your board has no resources
-	that are supposed to respond to that address! That code in
-	start.S has been around a while and should work as is when
-	you get the config right.
-
-	-Chris Hallinan
-	DS4.COM, Inc.
-
-It is essential to remember this, since it has some impact on the C
-code for the initialization procedures:
-
-* Initialized global data (data segment) is read-only. Do not attempt
-  to write it.
-
-* Do not use any unitialized global data (or implicitely initialized
-  as zero data - BSS segment) at all - this is undefined, initiali-
-  zation is performed later (when relocating to RAM).
-
-* Stack space is very limited. Avoid big data buffers or things like
-  that.
-
-Having only the stack as writable memory limits means we cannot use
-normal global data to share information beween the code. But it
-turned out that the implementation of U-Boot can be greatly
-simplified by making a global data structure (gd_t) available to all
-functions. We could pass a pointer to this data as argument to _all_
-functions, but this would bloat the code. Instead we use a feature of
-the GCC compiler (Global Register Variables) to share the data: we
-place a pointer (gd) to the global data into a register which we
-reserve for this purpose.
-
-When choosing a register for such a purpose we are restricted by the
-relevant  (E)ABI  specifications for the current architecture, and by
-GCC's implementation.
-
-For PowerPC, the following registers have specific use:
-	R1:	stack pointer
-	R2:	TOC pointer
-	R3-R4:	parameter passing and return values
-	R5-R10: parameter passing
-	R13:	small data area pointer
-	R30:	GOT pointer
-	R31:	frame pointer
-
-	(U-Boot also uses R14 as internal GOT pointer.)
-
-    ==> U-Boot will use R29 to hold a pointer to the global data
-
-    Note: on PPC, we could use a static initializer (since the
-    address of the global data structure is known at compile time),
-    but it turned out that reserving a register results in somewhat
-    smaller code - although the code savings are not that big (on
-    average for all boards 752 bytes for the whole U-Boot image,
-    624 text + 127 data).
-
-On ARM, the following registers are used:
-
-	R0:	function argument word/integer result
-	R1-R3:	function argument word
-	R9:	GOT pointer
-	R10:	stack limit (used only if stack checking if enabled)
-	R11:	argument (frame) pointer
-	R12:	temporary workspace
-	R13:	stack pointer
-	R14:	link register
-	R15:	program counter
-
-    ==> U-Boot will use R8 to hold a pointer to the global data
-
-
-Memory Management:
-------------------
-
-U-Boot runs in system state and uses physical addresses, i.e. the
-MMU is not used either for address mapping nor for memory protection.
-
-The available memory is mapped to fixed addresses using the memory
-controller. In this process, a contiguous block is formed for each
-memory type (Flash, SDRAM, SRAM), even when it consists of several
-physical memory banks.
-
-U-Boot is installed in the first 128 kB of the first Flash bank (on
-TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
-booting and sizing and initializing DRAM, the code relocates itself
-to the upper end of DRAM. Immediately below the U-Boot code some
-memory is reserved for use by malloc() [see CFG_MALLOC_LEN
-configuration setting]. Below that, a structure with global Board
-Info data is placed, followed by the stack (growing downward).
-
-Additionally, some exception handler code is copied to the low 8 kB
-of DRAM (0x00000000 ... 0x00001FFF).
-
-So a typical memory configuration with 16 MB of DRAM could look like
-this:
-
-	0x0000 0000	Exception Vector code
-	      :
-	0x0000 1FFF
-	0x0000 2000	Free for Application Use
-	      :
-	      :
-
-	      :
-	      :
-	0x00FB FF20	Monitor Stack (Growing downward)
-	0x00FB FFAC	Board Info Data and permanent copy of global data
-	0x00FC 0000	Malloc Arena
-	      :
-	0x00FD FFFF
-	0x00FE 0000	RAM Copy of Monitor Code
-	...		eventually: LCD or video framebuffer
-	...		eventually: pRAM (Protected RAM - unchanged by reset)
-	0x00FF FFFF	[End of RAM]
-
-
-System Initialization:
-----------------------
+	- 2.2.x kernels have the entry point at 0x0000000C,
+	- 2.3.x and later kernels have the entry point at 0x00000000.
 
-In the reset configuration, U-Boot starts at the reset entry point
-(on most PowerPC systens at address 0x00000100). Because of the reset
-configuration for CS0# this is a mirror of the onboard Flash memory.
-To be able to re-map memory U-Boot then jumps to its link address.
-To be able to implement the initialization code in C, a (small!)
-initial stack is set up in the internal Dual Ported RAM (in case CPUs
-which provide such a feature like MPC8xx or MPC8260), or in a locked
-part of the data cache. After that, U-Boot initializes the CPU core,
-the caches and the SIU.
-
-Next, all (potentially) available memory banks are mapped using a
-preliminary mapping. For example, we put them on 512 MB boundaries
-(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
-on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
-programmed for SDRAM access. Using the temporary configuration, a
-simple memory test is run that determines the size of the SDRAM
-banks.
-
-When there is more than one SDRAM bank, and the banks are of
-different size, the largest is mapped first. For equal size, the first
-bank (CS2#) is mapped first. The first mapping is always for address
-0x00000000, with any additional banks following immediately to create
-contiguous memory starting from 0.
-
-Then, the monitor installs itself at the upper end of the SDRAM area
-and allocates memory for use by malloc() and for the global Board
-Info data; also, the exception vector code is copied to the low RAM
-pages, and the final stack is set up.
-
-Only after this relocation will you have a "normal" C environment;
-until that you are restricted in several ways, mostly because you are
-running from ROM, and because the code will have to be relocated to a
-new address in RAM.
-
-
-U-Boot Porting Guide:
-----------------------
+	So a typical call to build a U-Boot image would read:
 
-[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
-list, October 2002]
+		-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
+		> -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \
+		> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux.gz \
+		> examples/uImage.TQM850L
+		Image Name:   2.4.4 kernel for TQM850L
+		Created:      Wed Jul 19 02:34:59 2000
+		Image Type:   PowerPC Linux Kernel Image (gzip compressed)
+		Data Size:    335725 Bytes = 327.86 kB = 0.32 MB
+		Load Address: 0x00000000
+		Entry Point:  0x00000000
 
+	To verify the contents of the image (or check for corruption):
 
-int main (int argc, char *argv[])
-{
-	sighandler_t no_more_time;
+		-> tools/mkimage -l examples/uImage.TQM850L
+		Image Name:   2.4.4 kernel for TQM850L
+		Created:      Wed Jul 19 02:34:59 2000
+		Image Type:   PowerPC Linux Kernel Image (gzip compressed)
+		Data Size:    335725 Bytes = 327.86 kB = 0.32 MB
+		Load Address: 0x00000000
+		Entry Point:  0x00000000
 
-	signal (SIGALRM, no_more_time);
-	alarm (PROJECT_DEADLINE - toSec (3 * WEEK));
+	NOTE: for embedded systems where boot time is critical you can trade
+	speed for memory and install an UNCOMPRESSED image instead: this
+	needs more space in Flash, but boots much faster since it does not
+	need to be uncompressed:
+
+		-> gunzip /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux.gz
+		-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
+		> -A ppc -O linux -T kernel -C none -a 0 -e 0 \
+		> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux \
+		> examples/uImage.TQM850L-uncompressed
+		Image Name:   2.4.4 kernel for TQM850L
+		Created:      Wed Jul 19 02:34:59 2000
+		Image Type:   PowerPC Linux Kernel Image (uncompressed)
+		Data Size:    792160 Bytes = 773.59 kB = 0.76 MB
+		Load Address: 0x00000000
+		Entry Point:  0x00000000
+
+
+	Similar you can build U-Boot images from a 'ramdisk.image.gz' file
+	when your kernel is intended to use an initial ramdisk:
+
+		-> tools/mkimage -n 'Simple Ramdisk Image' \
+		> -A ppc -O linux -T ramdisk -C gzip \
+		> -d /LinuxPPC/images/SIMPLE-ramdisk.image.gz examples/simple-initrd
+		Image Name:   Simple Ramdisk Image
+		Created:      Wed Jan 12 14:01:50 2000
+		Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
+		Data Size:    566530 Bytes = 553.25 kB = 0.54 MB
+		Load Address: 0x00000000
+		Entry Point:  0x00000000
+
+
+	Installing a Linux Image:
+	-------------------------
+
+	To downloading a U-Boot image over the serial (console) interface,
+	you must convert the image to S-Record format:
+
+		objcopy -I binary -O srec examples/image examples/image.srec
+
+	The 'objcopy' does not understand the information in the U-Boot
+	image header, so the resulting S-Record file will be relative to
+	address 0x00000000. To load it to a given address, you need to
+	specify the target address as 'offset' parameter with the 'loads'
+	command.
+
+	Example: install the image to address 0x40100000 (which on the
+	TQM8xxL is in the first Flash bank):
+
+		=> erase 40100000 401FFFFF
+
+		.......... done
+		Erased 8 sectors
+
+		=> loads 40100000
+		## Ready for S-Record download ...
+		~>examples/image.srec
+		1 2 3 4 5 6 7 8 9 10 11 12 13 ...
+		...
+		15989 15990 15991 15992
+		[file transfer complete]
+		[connected]
+		## Start Addr = 0x00000000
+
+
+	You can check the success of the download using the 'iminfo' command;
+	this includes a checksum verification so you  can  be  sure  no	 data
+	corruption happened:
+
+		=> imi 40100000
+
+		## Checking Image at 40100000 ...
+		   Image Name:	 2.2.13 for initrd on TQM850L
+		   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
+		   Data Size:	 335725 Bytes = 327 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 0000000c
+		   Verifying Checksum ... OK
+
+
+	Boot Linux:
+	-----------
+
+	The "bootm" command is used to boot an application that is stored in
+	memory (RAM or Flash). In case of a Linux kernel image, the contents
+	of the "bootargs" environment variable is passed to the kernel as
+	parameters. You can check and modify this variable using the
+	"printenv" and "setenv" commands:
+
+
+		=> printenv bootargs
+		bootargs=root=/dev/ram
+
+		=> setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
+
+		=> printenv bootargs
+		bootargs=root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
+
+		=> bootm 40020000
+		## Booting Linux kernel at 40020000 ...
+		   Image Name:	 2.2.13 for NFS on TQM850L
+		   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
+		   Data Size:	 381681 Bytes = 372 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 0000000c
+		   Verifying Checksum ... OK
+		   Uncompressing Kernel Image ... OK
+		Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:35:17 MEST 2000
+		Boot arguments: root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
+		time_init: decrementer frequency = 187500000/60
+		Calibrating delay loop... 49.77 BogoMIPS
+		Memory: 15208k available (700k kernel code, 444k data, 32k init) [c0000000,c1000000]
+		...
+
+	If you want to boot a Linux kernel with initial ram disk, you pass
+	the memory addresses of both the kernel and the initrd image (PPBCOOT
+	format!) to the "bootm" command:
+
+		=> imi 40100000 40200000
+
+		## Checking Image at 40100000 ...
+		   Image Name:	 2.2.13 for initrd on TQM850L
+		   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
+		   Data Size:	 335725 Bytes = 327 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 0000000c
+		   Verifying Checksum ... OK
+
+		## Checking Image at 40200000 ...
+		   Image Name:	 Simple Ramdisk Image
+		   Image Type:	 PowerPC Linux RAMDisk Image (gzip compressed)
+		   Data Size:	 566530 Bytes = 553 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 00000000
+		   Verifying Checksum ... OK
+
+		=> bootm 40100000 40200000
+		## Booting Linux kernel at 40100000 ...
+		   Image Name:	 2.2.13 for initrd on TQM850L
+		   Image Type:	 PowerPC Linux Kernel Image (gzip compressed)
+		   Data Size:	 335725 Bytes = 327 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 0000000c
+		   Verifying Checksum ... OK
+		   Uncompressing Kernel Image ... OK
+		## Loading RAMDisk Image at 40200000 ...
+		   Image Name:	 Simple Ramdisk Image
+		   Image Type:	 PowerPC Linux RAMDisk Image (gzip compressed)
+		   Data Size:	 566530 Bytes = 553 kB = 0 MB
+		   Load Address: 00000000
+		   Entry Point:	 00000000
+		   Verifying Checksum ... OK
+		   Loading Ramdisk ... OK
+		Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:32:08 MEST 2000
+		Boot arguments: root=/dev/ram
+		time_init: decrementer frequency = 187500000/60
+		Calibrating delay loop... 49.77 BogoMIPS
+		...
+		RAMDISK: Compressed image found at block 0
+		VFS: Mounted root (ext2 filesystem).
+
+		bash#
+
+	More About U-Boot Image Types:
+	------------------------------
+
+	U-Boot supports the following image types:
+
+	   "Standalone Programs" are directly runnable in the environment
+		provided by U-Boot; it is expected that (if they behave
+		well) you can continue to work in U-Boot after return from
+		the Standalone Program.
+	   "OS Kernel Images" are usually images of some Embedded OS which
+		will take over control completely. Usually these programs
+		will install their own set of exception handlers, device
+		drivers, set up the MMU, etc. - this means, that you cannot
+		expect to re-enter U-Boot except by resetting the CPU.
+	   "RAMDisk Images" are more or less just data blocks, and their
+		parameters (address, size) are passed to an OS kernel that is
+		being started.
+	   "Multi-File Images" contain several images, typically an OS
+		(Linux) kernel image and one or more data images like
+		RAMDisks. This construct is useful for instance when you want
+		to boot over the network using BOOTP etc., where the boot
+		server provides just a single image file, but you want to get
+		for instance an OS kernel and a RAMDisk image.
+
+		"Multi-File Images" start with a list of image sizes, each
+		image size (in bytes) specified by an "uint32_t" in network
+		byte order. This list is terminated by an "(uint32_t)0".
+		Immediately after the terminating 0 follow the images, one by
+		one, all aligned on "uint32_t" boundaries (size rounded up to
+		a multiple of 4 bytes).
+
+	   "Firmware Images" are binary images containing firmware (like
+		U-Boot or FPGA images) which usually will be programmed to
+		flash memory.
+
+	   "Script files" are command sequences that will be executed by
+		U-Boot's command interpreter; this feature is especially
+		useful when you configure U-Boot to use a real shell (hush)
+		as command interpreter.
+
+
+	Standalone HOWTO:
+	=================
+
+	One of the features of U-Boot is that you can dynamically load and
+	run "standalone" applications, which can use some resources of
+	U-Boot like console I/O functions or interrupt services.
+
+	Two simple examples are included with the sources:
+
+	"Hello World" Demo:
+	-------------------
+
+	'examples/hello_world.c' contains a small "Hello World" Demo
+	application; it is automatically compiled when you build U-Boot.
+	It's configured to run at address 0x00040004, so you can play with it
+	like that:
+
+		=> loads
+		## Ready for S-Record download ...
+		~>examples/hello_world.srec
+		1 2 3 4 5 6 7 8 9 10 11 ...
+		[file transfer complete]
+		[connected]
+		## Start Addr = 0x00040004
+
+		=> go 40004 Hello World! This is a test.
+		## Starting application at 0x00040004 ...
+		Hello World
+		argc = 7
+		argv[0] = "40004"
+		argv[1] = "Hello"
+		argv[2] = "World!"
+		argv[3] = "This"
+		argv[4] = "is"
+		argv[5] = "a"
+		argv[6] = "test."
+		argv[7] = "<NULL>"
+		Hit any key to exit ...
+
+		## Application terminated, rc = 0x0
+
+	Another example, which demonstrates how to register a CPM interrupt
+	handler with the U-Boot code, can be found in 'examples/timer.c'.
+	Here, a CPM timer is set up to generate an interrupt every second.
+	The interrupt service routine is trivial, just printing a '.'
+	character, but this is just a demo program. The application can be
+	controlled by the following keys:
+
+		? - print current values og the CPM Timer registers
+		b - enable interrupts and start timer
+		e - stop timer and disable interrupts
+		q - quit application
+
+		=> loads
+		## Ready for S-Record download ...
+		~>examples/timer.srec
+		1 2 3 4 5 6 7 8 9 10 11 ...
+		[file transfer complete]
+		[connected]
+		## Start Addr = 0x00040004
+
+		=> go 40004
+		## Starting application at 0x00040004 ...
+		TIMERS=0xfff00980
+		Using timer 1
+		  tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998, tcn @ 0xfff0099c, ter @ 0xfff009b0
+
+	Hit 'b':
+		[q, b, e, ?] Set interval 1000000 us
+		Enabling timer
+	Hit '?':
+		[q, b, e, ?] ........
+		tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0
+	Hit '?':
+		[q, b, e, ?] .
+		tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0
+	Hit '?':
+		[q, b, e, ?] .
+		tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0
+	Hit '?':
+		[q, b, e, ?] .
+		tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0
+	Hit 'e':
+		[q, b, e, ?] ...Stopping timer
+	Hit 'q':
+		[q, b, e, ?] ## Application terminated, rc = 0x0
+
+
+	Minicom warning:
+	================
+
+	Over time, many people have reported problems when trying to use the
+	"minicom" terminal emulation program for serial download. I (wd)
+	consider minicom to be broken, and recommend not to use it. Under
+	Unix, I recommend to use C-Kermit for general purpose use (and
+	especially for kermit binary protocol download ("loadb" command), and
+	use "cu" for S-Record download ("loads" command).
+
+	Nevertheless, if you absolutely want to use it try adding this
+	configuration to your "File transfer protocols" section:
+
+		   Name	   Program			Name U/D FullScr IO-Red. Multi
+		X  kermit  /usr/bin/kermit -i -l %l -s	 Y    U	   Y	   N	  N
+		Y  kermit  /usr/bin/kermit -i -l %l -r	 N    D	   Y	   N	  N
+
+
+	NetBSD Notes:
+	=============
+
+	Starting at version 0.9.2, U-Boot supports NetBSD both as host
+	(build U-Boot) and target system (boots NetBSD/mpc8xx).
+
+	Building requires a cross environment; it is known to work on
+	NetBSD/i386 with the cross-powerpc-netbsd-1.3 package (you will also
+	need gmake since the Makefiles are not compatible with BSD make).
+	Note that the cross-powerpc package does not install include files;
+	attempting to build U-Boot will fail because <machine/ansi.h> is
+	missing.  This file has to be installed and patched manually:
+
+		# cd /usr/pkg/cross/powerpc-netbsd/include
+		# mkdir powerpc
+		# ln -s powerpc machine
+		# cp /usr/src/sys/arch/powerpc/include/ansi.h powerpc/ansi.h
+		# ${EDIT} powerpc/ansi.h	## must remove __va_list, _BSD_VA_LIST
+
+	Native builds *don't* work due to incompatibilities between native
+	and U-Boot include files.
+
+	Booting assumes that (the first part of) the image booted is a
+	stage-2 loader which in turn loads and then invokes the kernel
+	proper. Loader sources will eventually appear in the NetBSD source
+	tree (probably in sys/arc/mpc8xx/stand/u-boot_stage2/); in the
+	meantime, send mail to bruno@exet-ag.de and/or wd@denx.de for
+	details.
+
+
+	Implementation Internals:
+	=========================
+
+	The following is not intended to be a complete description of every
+	implementation detail. However, it should help to understand the
+	inner workings of U-Boot and make it easier to port it to custom
+	hardware.
+
+
+	Initial Stack, Global Data:
+	---------------------------
+
+	The implementation of U-Boot is complicated by the fact that U-Boot
+	starts running out of ROM (flash memory), usually without access to
+	system RAM (because the memory controller is not initialized yet).
+	This means that we don't have writable Data or BSS segments, and BSS
+	is not initialized as zero. To be able to get a C environment working
+	at all, we have to allocate at least a minimal stack. Implementation
+	options for this are defined and restricted by the CPU used: Some CPU
+	models provide on-chip memory (like the IMMR area on MPC8xx and
+	MPC826x processors), on others (parts of) the data cache can be
+	locked as (mis-) used as memory, etc.
+
+		Chris Hallinan posted a good summary of	 these	issues	to  the
+		u-boot-users mailing list:
+
+		Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
+		From: "Chris Hallinan" <clh@net1plus.com>
+		Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
+		...
+
+		Correct me if I'm wrong, folks, but the way I understand it
+		is this: Using DCACHE as initial RAM for Stack, etc, does not
+		require any physical RAM backing up the cache. The cleverness
+		is that the cache is being used as a temporary supply of
+		necessary storage before the SDRAM controller is setup. It's
+		beyond the scope of this list to expain the details, but you
+		can see how this works by studying the cache architecture and
+		operation in the architecture and processor-specific manuals.
+
+		OCM is On Chip Memory, which I believe the 405GP has 4K. It
+		is another option for the system designer to use as an
+		initial stack/ram area prior to SDRAM being available. Either
+		option should work for you. Using CS 4 should be fine if your
+		board designers haven't used it for something that would
+		cause you grief during the initial boot! It is frequently not
+		used.
+
+		CFG_INIT_RAM_ADDR should be somewhere that won't interfere
+		with your processor/board/system design. The default value
+		you will find in any recent u-boot distribution in
+		Walnut405.h should work for you. I'd set it to a value larger
+		than your SDRAM module. If you have a 64MB SDRAM module, set
+		it above 400_0000. Just make sure your board has no resources
+		that are supposed to respond to that address! That code in
+		start.S has been around a while and should work as is when
+		you get the config right.
+
+		-Chris Hallinan
+		DS4.COM, Inc.
+
+	It is essential to remember this, since it has some impact on the C
+	code for the initialization procedures:
+
+	* Initialized global data (data segment) is read-only. Do not attempt
+	  to write it.
+
+	* Do not use any unitialized global data (or implicitely initialized
+	  as zero data - BSS segment) at all - this is undefined, initiali-
+	  zation is performed later (when relocating to RAM).
+
+	* Stack space is very limited. Avoid big data buffers or things like
+	  that.
+
+	Having only the stack as writable memory limits means we cannot use
+	normal global data to share information beween the code. But it
+	turned out that the implementation of U-Boot can be greatly
+	simplified by making a global data structure (gd_t) available to all
+	functions. We could pass a pointer to this data as argument to _all_
+	functions, but this would bloat the code. Instead we use a feature of
+	the GCC compiler (Global Register Variables) to share the data: we
+	place a pointer (gd) to the global data into a register which we
+	reserve for this purpose.
+
+	When choosing a register for such a purpose we are restricted by the
+	relevant  (E)ABI  specifications for the current architecture, and by
+	GCC's implementation.
+
+	For PowerPC, the following registers have specific use:
+		R1:	stack pointer
+		R2:	TOC pointer
+		R3-R4:	parameter passing and return values
+		R5-R10: parameter passing
+		R13:	small data area pointer
+		R30:	GOT pointer
+		R31:	frame pointer
+
+		(U-Boot also uses R14 as internal GOT pointer.)
+
+	    ==> U-Boot will use R29 to hold a pointer to the global data
+
+	    Note: on PPC, we could use a static initializer (since the
+	    address of the global data structure is known at compile time),
+	    but it turned out that reserving a register results in somewhat
+	    smaller code - although the code savings are not that big (on
+	    average for all boards 752 bytes for the whole U-Boot image,
+	    624 text + 127 data).
+
+	On ARM, the following registers are used:
+
+		R0:	function argument word/integer result
+		R1-R3:	function argument word
+		R9:	GOT pointer
+		R10:	stack limit (used only if stack checking if enabled)
+		R11:	argument (frame) pointer
+		R12:	temporary workspace
+		R13:	stack pointer
+		R14:	link register
+		R15:	program counter
+
+	    ==> U-Boot will use R8 to hold a pointer to the global data
+
+
+	Memory Management:
+	------------------
+
+	U-Boot runs in system state and uses physical addresses, i.e. the
+	MMU is not used either for address mapping nor for memory protection.
+
+	The available memory is mapped to fixed addresses using the memory
+	controller. In this process, a contiguous block is formed for each
+	memory type (Flash, SDRAM, SRAM), even when it consists of several
+	physical memory banks.
+
+	U-Boot is installed in the first 128 kB of the first Flash bank (on
+	TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
+	booting and sizing and initializing DRAM, the code relocates itself
+	to the upper end of DRAM. Immediately below the U-Boot code some
+	memory is reserved for use by malloc() [see CFG_MALLOC_LEN
+	configuration setting]. Below that, a structure with global Board
+	Info data is placed, followed by the stack (growing downward).
+
+	Additionally, some exception handler code is copied to the low 8 kB
+	of DRAM (0x00000000 ... 0x00001FFF).
+
+	So a typical memory configuration with 16 MB of DRAM could look like
+	this:
+
+		0x0000 0000	Exception Vector code
+		      :
+		0x0000 1FFF
+		0x0000 2000	Free for Application Use
+		      :
+		      :
+
+		      :
+		      :
+		0x00FB FF20	Monitor Stack (Growing downward)
+		0x00FB FFAC	Board Info Data and permanent copy of global data
+		0x00FC 0000	Malloc Arena
+		      :
+		0x00FD FFFF
+		0x00FE 0000	RAM Copy of Monitor Code
+		...		eventually: LCD or video framebuffer
+		...		eventually: pRAM (Protected RAM - unchanged by reset)
+		0x00FF FFFF	[End of RAM]
+
+
+	System Initialization:
+	----------------------
+
+	In the reset configuration, U-Boot starts at the reset entry point
+	(on most PowerPC systens at address 0x00000100). Because of the reset
+	configuration for CS0# this is a mirror of the onboard Flash memory.
+	To be able to re-map memory U-Boot then jumps to its link address.
+	To be able to implement the initialization code in C, a (small!)
+	initial stack is set up in the internal Dual Ported RAM (in case CPUs
+	which provide such a feature like MPC8xx or MPC8260), or in a locked
+	part of the data cache. After that, U-Boot initializes the CPU core,
+	the caches and the SIU.
+
+	Next, all (potentially) available memory banks are mapped using a
+	preliminary mapping. For example, we put them on 512 MB boundaries
+	(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
+	on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
+	programmed for SDRAM access. Using the temporary configuration, a
+	simple memory test is run that determines the size of the SDRAM
+	banks.
+
+	When there is more than one SDRAM bank, and the banks are of
+	different size, the largest is mapped first. For equal size, the first
+	bank (CS2#) is mapped first. The first mapping is always for address
+	0x00000000, with any additional banks following immediately to create
+	contiguous memory starting from 0.
+
+	Then, the monitor installs itself at the upper end of the SDRAM area
+	and allocates memory for use by malloc() and for the global Board
+	Info data; also, the exception vector code is copied to the low RAM
+	pages, and the final stack is set up.
+
+	Only after this relocation will you have a "normal" C environment;
+	until that you are restricted in several ways, mostly because you are
+	running from ROM, and because the code will have to be relocated to a
+	new address in RAM.
+
+
+	U-Boot Porting Guide:
+	----------------------
+
+	[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
+	list, October 2002]
+
+
+	int main (int argc, char *argv[])
+	{
+		sighandler_t no_more_time;
+
+		signal (SIGALRM, no_more_time);
+		alarm (PROJECT_DEADLINE - toSec (3 * WEEK));
+
+		if (available_money > available_manpower) {
+			pay consultant to port U-Boot;
+			return 0;
+		}
+
+		Download latest U-Boot source;
+
+		Subscribe to u-boot-users mailing list;
+
+		if (clueless) {
+			email ("Hi, I am new to U-Boot, how do I get started?");
+		}
+
+		while (learning) {
+			Read the README file in the top level directory;
+			Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
+			Read the source, Luke;
+		}
+
+		if (available_money > toLocalCurrency ($2500)) {
+			Buy a BDI2000;
+		} else {
+			Add a lot of aggravation and time;
+		}
+
+		Create your own board support subdirectory;
+
+		Create your own board config file;
+
+		while (!running) {
+			do {
+				Add / modify source code;
+			} until (compiles);
+			Debug;
+			if (clueless)
+				email ("Hi, I am having problems...");
+		}
+		Send patch file to Wolfgang;
 
-	if (available_money > available_manpower) {
-		pay consultant to port U-Boot;
 		return 0;
 	}
 
-	Download latest U-Boot source;
-
-	Subscribe to u-boot-users mailing list;
-
-	if (clueless) {
-		email ("Hi, I am new to U-Boot, how do I get started?");
-	}
-
-	while (learning) {
-		Read the README file in the top level directory;
-		Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
-		Read the source, Luke;
-	}
-
-	if (available_money > toLocalCurrency ($2500)) {
-		Buy a BDI2000;
-	} else {
-		Add a lot of aggravation and time;
+	void no_more_time (int sig)
+	{
+	      hire_a_guru();
 	}
 
-	Create your own board support subdirectory;
-
-	Create your own board config file;
-
-	while (!running) {
-		do {
-			Add / modify source code;
-		} until (compiles);
-		Debug;
-		if (clueless)
-			email ("Hi, I am having problems...");
-	}
-	Send patch file to Wolfgang;
-
-	return 0;
-}
-
-void no_more_time (int sig)
-{
-      hire_a_guru();
-}
-
 
-Coding Standards:
------------------
+	Coding Standards:
+	-----------------
 
-All contributions to U-Boot should conform to the Linux kernel
-coding style; see the file "Documentation/CodingStyle" in your Linux
-kernel source directory.
+	All contributions to U-Boot should conform to the Linux kernel
+	coding style; see the file "Documentation/CodingStyle" in your Linux
+	kernel source directory.
 
-Please note that U-Boot is implemented in C (and to some small parts
-in Assembler); no C++ is used, so please do not use C++ style
-comments (//) in your code.
+	Please note that U-Boot is implemented in C (and to some small parts
+	in Assembler); no C++ is used, so please do not use C++ style
+	comments (//) in your code.
 
-Please also stick to the following formatting rules:
-- remove any trailing white space
-- use TAB characters for indentation, not spaces
-- make sure NOT to use DOS '\r\n' line feeds
-- do not add more than 2 empty lines to source files
-- do not add trailing empty lines to source files
+	Please also stick to the following formatting rules:
+	- remove any trailing white space
+	- use TAB characters for indentation, not spaces
+	- make sure NOT to use DOS '\r\n' line feeds
+	- do not add more than 2 empty lines to source files
+	- do not add trailing empty lines to source files
 
-Submissions which do not conform to the standards may be returned
-with a request to reformat the changes.
+	Submissions which do not conform to the standards may be returned
+	with a request to reformat the changes.
 
 
-Submitting Patches:
--------------------
+	Submitting Patches:
+	-------------------
 
-Since the number of patches for U-Boot is growing, we need to
-establish some rules. Submissions which do not conform to these rules
-may be rejected, even when they contain important and valuable stuff.
+	Since the number of patches for U-Boot is growing, we need to
+	establish some rules. Submissions which do not conform to these rules
+	may be rejected, even when they contain important and valuable stuff.
 
 
-When you send a patch, please include the following information with
-it:
+	When you send a patch, please include the following information with
+	it:
 
-* For bug fixes: a description of the bug and how your patch fixes
-  this bug. Please try to include a way of demonstrating that the
-  patch actually fixes something.
+	* For bug fixes: a description of the bug and how your patch fixes
+	  this bug. Please try to include a way of demonstrating that the
+	  patch actually fixes something.
 
-* For new features: a description of the feature and your
-  implementation.
+	* For new features: a description of the feature and your
+	  implementation.
 
-* A CHANGELOG entry as plaintext (separate from the patch)
+	* A CHANGELOG entry as plaintext (separate from the patch)
 
-* For major contributions, your entry to the CREDITS file
+	* For major contributions, your entry to the CREDITS file
 
-* When you add support for a new board, don't forget to add this
-  board to the MAKEALL script, too.
+	* When you add support for a new board, don't forget to add this
+	  board to the MAKEALL script, too.
 
-* If your patch adds new configuration options, don't forget to
-  document these in the README file.
+	* If your patch adds new configuration options, don't forget to
+	  document these in the README file.
 
-* The patch itself. If you are accessing the CVS repository use "cvs
-  update; cvs diff -puRN"; else, use "diff -purN OLD NEW". If your
-  version of diff does not support these options, then get the latest
-  version of GNU diff.
+	* The patch itself. If you are accessing the CVS repository use "cvs
+	  update; cvs diff -puRN"; else, use "diff -purN OLD NEW". If your
+	  version of diff does not support these options, then get the latest
+	  version of GNU diff.
 
-  The current directory when running this command shall be the top
-  level directory of the U-Boot source tree, or it's parent directory
-  (i. e. please make sure that your patch includes sufficient
-  directory information for the affected files).
+	  The current directory when running this command shall be the top
+	  level directory of the U-Boot source tree, or it's parent directory
+	  (i. e. please make sure that your patch includes sufficient
+	  directory information for the affected files).
 
-  We accept patches as plain text, MIME attachments or as uuencoded
-  gzipped text.
+	  We accept patches as plain text, MIME attachments or as uuencoded
+	  gzipped text.
 
-* If one logical set of modifications affects or creates several
-  files, all these changes shall be submitted in a SINGLE patch file.
+	* If one logical set of modifications affects or creates several
+	  files, all these changes shall be submitted in a SINGLE patch file.
 
-* Changesets that contain different, unrelated modifications shall be
-  submitted as SEPARATE patches, one patch per changeset.
+	* Changesets that contain different, unrelated modifications shall be
+	  submitted as SEPARATE patches, one patch per changeset.
 
 
-Notes:
+	Notes:
 
-* Before sending the patch, run the MAKEALL script on your patched
-  source tree and make sure that no errors or warnings are reported
-  for any of the boards.
+	* Before sending the patch, run the MAKEALL script on your patched
+	  source tree and make sure that no errors or warnings are reported
+	  for any of the boards.
 
-* Keep your modifications to the necessary minimum: A patch
-  containing several unrelated changes or arbitrary reformats will be
-  returned with a request to re-formatting / split it.
+	* Keep your modifications to the necessary minimum: A patch
+	  containing several unrelated changes or arbitrary reformats will be
+	  returned with a request to re-formatting / split it.
 
-* If you modify existing code, make sure that your new code does not
-  add to the memory footprint of the code ;-) Small is beautiful!
-  When adding new features, these should compile conditionally only
-  (using #ifdef), and the resulting code with the new feature
-  disabled must not need more memory than the old code without your
-  modification.
+	* If you modify existing code, make sure that your new code does not
+	  add to the memory footprint of the code ;-) Small is beautiful!
+	  When adding new features, these should compile conditionally only
+	  (using #ifdef), and the resulting code with the new feature
+	  disabled must not need more memory than the old code without your
+	  modification.