Summary:
========
-This directory contains the source code for U-Boot, a monitor for
-Embedded PowerPC boards, which can be installed in a boot ROM and
-used to test the hardware or download and run application code.
+This directory contains the source code for U-Boot, a boot loader for
+Embedded boards based on PowerPC and ARM processors, which can be
+installed in a boot ROM and used to initialize and test the hardware
+or to download and run application code.
The development of U-Boot is closely related to Linux: some parts of
-the source code originate in the Linux source tree, we still have
-some header files in common, and special provision has been made to
+the source code originate in the Linux source tree, we have some
+header files in common, and special provision has been made to
support booting of Linux images.
Some attention has been paid to make this software easily
=======
In general, all boards for which a configuration option exists in the
-Makefile have been tested to some extent and can be considered
+Makefile have been tested to some extent and can be considered
"working". In fact, many of them are used in production systems.
-In case of problems see the CHANGELOG and CREDITS files to find out
+In case of problems see the CHANGELOG and CREDITS files to find out
who contributed the specific port.
-Exception from this rule: the port to the Sandpoint 8240 has not been
-completed yet.
-
Where to get help:
==================
-In case you have questions about, problems with or contributions for
-U-Boot you should send a message to the U-Boot mailing list at
-<u-boot-users@lists.sourceforge.net>. There is also an archive of
-previous traffic on the mailing list - please search the archive
+In case you have questions about, problems with or contributions for
+U-Boot you should send a message to the U-Boot mailing list at
+<u-boot-users@lists.sourceforge.net>. There is also an archive of
+previous traffic on the mailing list - please search the archive
before asking FAQ's. Please see
http://lists.sourceforge.net/lists/listinfo/u-boot-users/
===================
- start from 8xxrom sources
+- create PPCBoot project (http://sourceforge.net/projects/ppcboot)
- clean up code
- make it easier to add custom boards
- make it possible to add other [PowerPC] CPUs
* S-Record download
* network boot
* PCMCIA / CompactFLash / ATA disk / SCSI ... boot
+- create ARMBoot project (http://sourceforge.net/projects/armboot)
- add other CPU families (starting with ARM)
+- create U-Boot project (http://sourceforge.net/projects/u-boot)
+
+
+Names and Spelling:
+===================
+
+The "official" name of this project is "Das U-Boot". The spelling
+"U-Boot" shall be used in all written text (documentation, comments
+in source files etc.). Example:
+
+ This is the README file for the U-Boot project.
+
+File names etc. shall be based on the string "u-boot". Examples:
+
+ include/asm-ppc/u-boot.h
+
+ #include <asm/u-boot.h>
+
+Variable names, preprocessor constants etc. shall be either based on
+the string "u_boot" or on "U_BOOT". Example:
+
+ U_BOOT_VERSION u_boot_logo
+ IH_OS_U_BOOT u_boot_hush_start
+
+
+Versioning:
+===========
+
+U-Boot uses a 3 level version number containing a version, a
+sub-version, and a patchlevel: "U-Boot-2.34.5" means version "2",
+sub-version "34", and patchlevel "4".
+
+The patchlevel is used to indicate certain stages of development
+between released versions, i. e. officially released versions of
+U-Boot will always have a patchlevel of "0".
Directory Hierarchy:
"include/configs/TQM823L.h".
+Many of the options are named exactly as the corresponding Linux
+kernel configuration options. The intention is to make it easier to
+build a config tool - later.
+
+
The following options need to be configured:
- CPU Type: Define exactly one of
CONFIG_GENIETV, CONFIG_PM826, CONFIG_ppmc8260,
CONFIG_GTH, CONFIG_RPXClassic, CONFIG_rsdproto,
CONFIG_IAD210, CONFIG_RPXlite, CONFIG_sbc8260,
- CONFIG_EBONY, CONFIG_sacsng
+ CONFIG_EBONY, CONFIG_sacsng, CONFIG_FPS860L,
+ CONFIG_V37
ARM based boards:
-----------------
default environment.
- Console Interface:
- Depending on board, define exactly one serial port
- (like CONFIG_8xx_CONS_SMC1, CONFIG_8xx_CONS_SMC2,
- CONFIG_8xx_CONS_SCC1, ...), or switch off the serial
- console by defining CONFIG_8xx_CONS_NONE
+ Depending on board, define exactly one serial port
+ (like CONFIG_8xx_CONS_SMC1, CONFIG_8xx_CONS_SMC2,
+ CONFIG_8xx_CONS_SCC1, ...), or switch off the serial
+ console by defining CONFIG_8xx_CONS_NONE
Note: if CONFIG_8xx_CONS_NONE is defined, the serial
port routines must be defined elsewhere
(requires CFG_CMD_DATE)
CONFIG_VIDEO_LOGO display Linux logo in
upper left corner
+ CONFIG_VIDEO_BMP_LOGO use bmp_logo.h instead of
+ linux_logo.h for logo.
+ Requires CONFIG_VIDEO_LOGO
CONFIG_CONSOLE_EXTRA_INFO
addional board info beside
the logo
- When CONFIG_CFB_CONSOLE is defined, video console is
- default i/o. Serial console can be forced with
- environment 'console=serial'.
+ When CONFIG_CFB_CONSOLE is defined, video console is
+ default i/o. Serial console can be forced with
+ environment 'console=serial'.
- Console Baudrate:
CONFIG_BAUDRATE - in bps
within "Boot Delay" after reset.
CONFIG_BOOTARGS
- This can be used to pass arguments to the bootm
- command. The value of CONFIG_BOOTARGS goes into the
- environment value "bootargs".
+ This can be used to pass arguments to the bootm
+ command. The value of CONFIG_BOOTARGS goes into the
+ environment value "bootargs".
CONFIG_RAMBOOT and CONFIG_NFSBOOT
- The value of these goes into the environment as
- "ramboot" and "nfsboot" respectively, and can be used
- as a convenience, when switching between booting from
- ram and nfs.
+ The value of these goes into the environment as
+ "ramboot" and "nfsboot" respectively, and can be used
+ as a convenience, when switching between booting from
+ ram and nfs.
- Pre-Boot Commands:
CONFIG_PREBOOT
CFG_CMD_ELF bootelf, bootvx
CFG_CMD_ENV saveenv
CFG_CMD_FDC * Floppy Disk Support
+ CFG_CMD_FDOS * Dos diskette Support
CFG_CMD_FLASH flinfo, erase, protect
CFG_CMD_FPGA FPGA device initialization support
CFG_CMD_I2C * I2C serial bus support
Note: Don't enable the "icache" and "dcache" commands
- (configuration option CFG_CMD_CACHE) unless you know
- what you (and your U-Boot users) are doing. Data
- cache cannot be enabled on systems like the 8xx or
- 8260 (where accesses to the IMMR region must be
- uncached), and it cannot be disabled on all other
- systems where we (mis-) use the data cache to hold an
- initial stack and some data.
+ (configuration option CFG_CMD_CACHE) unless you know
+ what you (and your U-Boot users) are doing. Data
+ cache cannot be enabled on systems like the 8xx or
+ 8260 (where accesses to the IMMR region must be
+ uncached), and it cannot be disabled on all other
+ systems where we (mis-) use the data cache to hold an
+ initial stack and some data.
XXX - this list needs to get updated!
- Timestamp Support:
- When CONFIG_TIMESTAMP is selected, the timestamp
- (date and time) of an image is printed by image
- commands like bootm or iminfo. This option is
- automatically enabled when you select CFG_CMD_DATE .
+ When CONFIG_TIMESTAMP is selected, the timestamp
+ (date and time) of an image is printed by image
+ commands like bootm or iminfo. This option is
+ automatically enabled when you select CFG_CMD_DATE .
- Partition Support:
CONFIG_MAC_PARTITION and/or CONFIG_DOS_PARTITION
standard LiLo mode numbers.
Following modes are supported (* is default):
- 800x600 1024x768 1280x1024
- 256 (8bit) 303* 305 307
- 65536 (16bit) 314 317 31a
- 16,7 Mill (24bit) 315 318 31b
+ 800x600 1024x768 1280x1024
+ 256 (8bit) 303* 305 307
+ 65536 (16bit) 314 317 31a
+ 16,7 Mill (24bit) 315 318 31b
(i.e. setenv videomode 317; saveenv; reset;)
+ CONFIG_VIDEO_SED13806
+ Enable Epson SED13806 driver. This driver supports 8bpp
+ and 16bpp modes defined by CONFIG_VIDEO_SED13806_8BPP
+ or CONFIG_VIDEO_SED13806_16BPP
+
+
- LCD Support: CONFIG_LCD
Define this to enable LCD support (for output to LCD
either CONFIG_HARD_I2C or CONFIG_SOFT_I2C must be defined
to include the appropriate I2C driver.
- See also: common/cmd_i2c.c for a description of the
- command line interface.
+ See also: common/cmd_i2c.c for a description of the
+ command line interface.
CONFIG_HARD_I2C
I2C_INIT
- (Optional). Any commands necessary to enable I2C
- controller or configure ports.
+ (Optional). Any commands necessary to enable I2C
+ controller or configure ports.
I2C_PORT
- (Only for MPC8260 CPU). The I/O port to use (the code
- assumes both bits are on the same port). Valid values
- are 0..3 for ports A..D.
+ (Only for MPC8260 CPU). The I/O port to use (the code
+ assumes both bits are on the same port). Valid values
+ are 0..3 for ports A..D.
I2C_ACTIVE
CONFIG_SOFT_SPI
- Enables a software (bit-bang) SPI driver rather than
- using hardware support. This is a general purpose
- driver that only requires three general I/O port pins
- (two outputs, one input) to function. If this is
- defined, the board configuration must define several
- SPI configuration items (port pins to use, etc). For
- an example, see include/configs/sacsng.h.
+ Enables a software (bit-bang) SPI driver rather than
+ using hardware support. This is a general purpose
+ driver that only requires three general I/O port pins
+ (two outputs, one input) to function. If this is
+ defined, the board configuration must define several
+ SPI configuration items (port pins to use, etc). For
+ an example, see include/configs/sacsng.h.
- FPGA Support: CONFIG_FPGA_COUNT
- Specify the number of FPGA devices to support.
+ Specify the number of FPGA devices to support.
- CONFIG_FPGA
+ CONFIG_FPGA
- Used to specify the types of FPGA devices. For
+ Used to specify the types of FPGA devices. For
example,
#define CONFIG_FPGA CFG_XILINX_VIRTEX2
CFG_FPGA_PROG_FEEDBACK
- Enable printing of hash marks during FPGA
+ Enable printing of hash marks during FPGA
configuration.
CFG_FPGA_CHECK_BUSY
- Enable checks on FPGA configuration interface busy
- status by the configuration function. This option
- will require a board or device specific function to
- be written.
+ Enable checks on FPGA configuration interface busy
+ status by the configuration function. This option
+ will require a board or device specific function to
+ be written.
CONFIG_FPGA_DELAY
- If defined, a function that provides delays in the
- FPGA configuration driver.
+ If defined, a function that provides delays in the
+ FPGA configuration driver.
CFG_FPGA_CHECK_CTRLC
CFG_FPGA_CHECK_ERROR
- Check for configuration errors during FPGA bitfile
- loading. For example, abort during Virtex II
- configuration if the INIT_B line goes low (which
- indicated a CRC error).
+ Check for configuration errors during FPGA bitfile
+ loading. For example, abort during Virtex II
+ configuration if the INIT_B line goes low (which
+ indicated a CRC error).
CFG_FPGA_WAIT_INIT
- Maximum time to wait for the INIT_B line to deassert
- after PROB_B has been deasserted during a Virtex II
- FPGA configuration sequence. The default time is 500 mS.
+ Maximum time to wait for the INIT_B line to deassert
+ after PROB_B has been deasserted during a Virtex II
+ FPGA configuration sequence. The default time is 500 mS.
CFG_FPGA_WAIT_BUSY
- Maximum time to wait for BUSY to deassert during
- Virtex II FPGA configuration. The default is 5 mS.
+ Maximum time to wait for BUSY to deassert during
+ Virtex II FPGA configuration. The default is 5 mS.
CFG_FPGA_WAIT_CONFIG
- Time to wait after FPGA configuration. The default is
+ Time to wait after FPGA configuration. The default is
200 mS.
- FPGA Support: CONFIG_FPGA_COUNT
CFG_FPGA_CHECK_BUSY
- Enable checks on FPGA configuration interface busy
- status by the configuration function. This option
- will require a board or device specific function to
- be written.
+ Enable checks on FPGA configuration interface busy
+ status by the configuration function. This option
+ will require a board or device specific function to
+ be written.
CONFIG_FPGA_DELAY
CFG_FPGA_CHECK_ERROR
- Check for configuration errors during FPGA bitfile
- loading. For example, abort during Virtex II
- configuration if the INIT_B line goes low (which
- indicated a CRC error).
+ Check for configuration errors during FPGA bitfile
+ loading. For example, abort during Virtex II
+ configuration if the INIT_B line goes low (which
+ indicated a CRC error).
CFG_FPGA_WAIT_INIT
- Maximum time to wait for the INIT_B line to deassert
- after PROB_B has been deasserted during a Virtex II
- FPGA configuration sequence. The default time is 500
- mS.
+ Maximum time to wait for the INIT_B line to deassert
+ after PROB_B has been deasserted during a Virtex II
+ FPGA configuration sequence. The default time is 500
+ mS.
CFG_FPGA_WAIT_BUSY
- Maximum time to wait for BUSY to deassert during
- Virtex II FPGA configuration. The default is 5 mS.
+ Maximum time to wait for BUSY to deassert during
+ Virtex II FPGA configuration. The default is 5 mS.
CFG_FPGA_WAIT_CONFIG
- Time to wait after FPGA configuration. The default is
- 200 mS.
+ Time to wait after FPGA configuration. The default is
+ 200 mS.
- Configuration Management:
CONFIG_IDENT_STRING
- If defined, this string will be added to the U-Boot
- version information (U_BOOT_VERSION)
+ If defined, this string will be added to the U-Boot
+ version information (U_BOOT_VERSION)
- Vendor Parameter Protection:
- U-Boot considers the values of the environment
- variables "serial#" (Board Serial Number) and
- "ethaddr" (Ethernet Address) to bb parameters that
- are set once by the board vendor / manufacturer, and
- protects these variables from casual modification by
- the user. Once set, these variables are read-only,
- and write or delete attempts are rejected. You can
- change this behviour:
+ U-Boot considers the values of the environment
+ variables "serial#" (Board Serial Number) and
+ "ethaddr" (Ethernet Address) to bb parameters that
+ are set once by the board vendor / manufacturer, and
+ protects these variables from casual modification by
+ the user. Once set, these variables are read-only,
+ and write or delete attempts are rejected. You can
+ change this behviour:
If CONFIG_ENV_OVERWRITE is #defined in your config
file, the write protection for vendor parameters is
CONFIG_NET_RETRY_COUNT
- This variable defines the number of retries for
- network operations like ARP, RARP, TFTP, or BOOTP
- before giving up the operation. If not defined, a
- default value of 5 is used.
+ This variable defines the number of retries for
+ network operations like ARP, RARP, TFTP, or BOOTP
+ before giving up the operation. If not defined, a
+ default value of 5 is used.
- Command Interpreter:
CFG_HUSH_PARSER
Note:
- In the current implementation, the local variables
- space and global environment variables space are
- separated. Local variables are those you define by
- simply typing like `name=value'. To access a local
- variable later on, you have write `$name' or
- `${name}'; variable directly by typing say `$name' at
- the command prompt.
+ In the current implementation, the local variables
+ space and global environment variables space are
+ separated. Local variables are those you define by
+ simply typing like `name=value'. To access a local
+ variable later on, you have write `$name' or
+ `${name}'; variable directly by typing say `$name' at
+ the command prompt.
- Global environment variables are those you use
- setenv/printenv to work with. To run a command stored
- in such a variable, you need to use the run command,
- and you must not use the '$' sign to access them.
+ Global environment variables are those you use
+ setenv/printenv to work with. To run a command stored
+ in such a variable, you need to use the run command,
+ and you must not use the '$' sign to access them.
To store commands and special characters in a
variable, please use double quotation marks
- Default Environment
CONFIG_EXTRA_ENV_SETTINGS
- Define this to contain any number of null terminated
- strings (variable = value pairs) that will be part of
- the default enviroment compiled into the boot image.
- For example, place something like this in your
- board's config file:
+ Define this to contain any number of null terminated
+ strings (variable = value pairs) that will be part of
+ the default enviroment compiled into the boot image.
+
+ For example, place something like this in your
+ board's config file:
#define CONFIG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
- Warning: This method is based on knowledge about the
- internal format how the environment is stored by the
- U-Boot code. This is NOT an official, expoerted
- interface! Although it is unlikely that this format
- will change soon, there is no guarantee either.
+ Warning: This method is based on knowledge about the
+ internal format how the environment is stored by the
+ U-Boot code. This is NOT an official, exported
+ interface! Although it is unlikely that this format
+ will change soon, but there is no guarantee either.
You better know what you are doing here.
- Note: overly (ab)use of the default environment is
- discouraged. Make sure to check other ways to preset
- the environment like the autoscript function or the
- boot command first.
+ Note: overly (ab)use of the default environment is
+ discouraged. Make sure to check other ways to preset
+ the environment like the autoscript function or the
+ boot command first.
- Show boot progress
CONFIG_SHOW_BOOT_PROGRESS
- Defining this option allows to add some board-
- specific code (calling a user-provided function
- "show_boot_progress(int)") that enables you to show
- the system's boot progress on some display (for
- example, some LED's) on your board. At the moment,
- the following checkpoints are implemented:
+ Defining this option allows to add some board-
+ specific code (calling a user-provided function
+ "show_boot_progress(int)") that enables you to show
+ the system's boot progress on some display (for
+ example, some LED's) on your board. At the moment,
+ the following checkpoints are implemented:
Arg Where When
1 common/cmd_bootm.c before attempting to boot an image
- Modem debug support:
CONFIG_MODEM_SUPPORT_DEBUG
- Enables debugging stuff (char screen[1024], dbg())
- for modem support. Useful only with BDI2000.
+ Enables debugging stuff (char screen[1024], dbg())
+ for modem support. Useful only with BDI2000.
- General:
- In the target system modem support is enabled when a
- specific key (key combination) is pressed during
- power-on. Otherwise U-Boot will boot normally
- (autoboot). The key_pressed() fuction is called from
- board_init(). Currently key_pressed() is a dummy
- function, returning 1 and thus enabling modem
- initialization.
+ In the target system modem support is enabled when a
+ specific key (key combination) is pressed during
+ power-on. Otherwise U-Boot will boot normally
+ (autoboot). The key_pressed() fuction is called from
+ board_init(). Currently key_pressed() is a dummy
+ function, returning 1 and thus enabling modem
+ initialization.
- If there are no modem init strings in the
- environment, U-Boot proceed to autoboot; the
- previous output (banner, info printfs) will be
- supressed, though.
+ If there are no modem init strings in the
+ environment, U-Boot proceed to autoboot; the
+ previous output (banner, info printfs) will be
+ supressed, though.
See also: doc/README.Modem
downloaded image) this option may be very useful.
- CFG_FLASH_CFI:
- Define if the flash driver uses extra elements in the
- common flash structure for storing flash geometry
+ Define if the flash driver uses extra elements in the
+ common flash structure for storing flash geometry
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
- CFG_ENV_ADDR_REDUND
CFG_ENV_SIZE_REDUND
- These settings describe a second storage area used to hold
- a redundand copy of the environment data, so that there is
- a valid backup copy in case there is a power failur during
- a "saveenv" operation.
+ These settings describe a second storage area used to hold
+ a redundand copy of the environment data, so that there is
+ a valid backup copy in case there is a power failur during
+ a "saveenv" operation.
BE CAREFUL! Any changes to the flash layout, and some changes to the
source code will make it necessary to adapt <board>/u-boot.lds*
- CFG_EEPROM_SIZE:
The size in bytes of the EEPROM device.
- - CFG_I2C_EEPROM_ADDR:
- If defined, specified the chip address of the EEPROM device.
- The default address is zero.
-
- - CFG_EEPROM_PAGE_WRITE_BITS:
- If defined, the number of bits used to address bytes in a
- single page in the EEPROM device. A 64 byte page, for example
- would require six bits.
-
- - CFG_EEPROM_PAGE_WRITE_DELAY_MS:
- If defined, the number of milliseconds to delay between
- page writes. The default is zero milliseconds.
-
- - CFG_I2C_EEPROM_ADDR_LEN:
- The length in bytes of the EEPROM memory array address. Note
- that this is NOT the chip address length!
-
- - CFG_EEPROM_SIZE:
- The size in bytes of the EEPROM device.
- CFG_SPI_INIT_OFFSET
configuration.
-Many of the options are named exactly as the corresponding Linux
-kernel configuration options. The intention is to make it easier to
-build a config tool - later.
-
Low Level (hardware related) configuration options:
- CFG_CACHELINE_SIZE:
to be able to adjust the position of the IMMR
register after a reset.
+- Floppy Disk Support:
+ CFG_FDC_DRIVE_NUMBER
+
+ the default drive number (default value 0)
+
+ CFG_ISA_IO_STRIDE
+
+ defines the spacing between fdc chipset registers
+ (default value 1)
+
+ CFG_ISA_IO_OFFSET
+
+ defines the offset of register from address. It
+ depends on which part of the data bus is connected to
+ the fdc chipset. (default value 0)
+
+ If CFG_ISA_IO_STRIDE CFG_ISA_IO_OFFSET and
+ CFG_FDC_DRIVE_NUMBER are undefined, they take their
+ default value.
+
+ if CFG_FDC_HW_INIT is defined, then the function
+ fdc_hw_init() is called at the beginning of the FDC
+ setup. fdc_hw_init() must be provided by the board
+ source code. It is used to make hardware dependant
+ initializations.
+
- CFG_IMMR: Physical address of the Internal Memory Mapped
Register; DO NOT CHANGE! (11-4)
[MPC8xx systems only]
wrong setting might damage your board. Read
doc/README.MBX before setting this variable!
+- CFG_CPM_POST_WORD_ADDR: (MPC8xx, MPC8260 only)
+ Offset of the bootmode word in DPRAM used by post
+ (Power On Self Tests). This definition overrides
+ #define'd default value in commproc.h resp.
+ cpm_8260.h.
+
Building the Software:
======================
FADS860T_config SXNI855T_config rsdproto_config
FPS850L_config Sandpoint8240_config sbc8260_config
GENIETV_config TQM823L_config PIP405_config
- GEN860T_config EBONY_config
+ GEN860T_config EBONY_config FPS860L_config
Note: for some board special configuration names may exist; check if
additional information is available from the board vendor; for
-Finally, type "make all", and you should get some working U-Boot
+Finally, type "make all", and you should get some working U-Boot
images ready for downlod to / installation on your system:
- "u-boot.bin" is a raw binary image
Building a Linux Image:
-----------------------
-No specific requirements for U-Boot. There is no need to add a
-"ramdisk.image.gz" file when building the kernel, even when you
-intend to run it with initial ramdisk.
+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 zImage
+ 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:
-However, we don't use the 'zImage' (= 'arch/ppc/mbxboot/zvmlinux') we
-build this way. The 'zImage' includes the old boot loader code which
-we don't ned any more. Instead, we use the raw (compressed) Linux
-kernel image in 'arch/ppc/coffboot/vmlinux.gz'.
+* build a standard "vmlinux" kernel image (in ELF binary format):
-There is a special tool (in 'tools/mkimage') to encapsulate this
-image with header information, CRC32 checksum etc. for use with
-U-Boot:
+* convert the kernel into a raw binary image:
-In the first form (with "-l" option) mkimage lists the information
-contained in the header of an existing U-Boot image; this includes
+ ${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.
+
+"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:
tools/mkimage -l image
but the entry point address depends on the kernel version:
- 2.2.x kernels have the entry point at 0x0000000C,
-- 2.3.x and 2.4.x kernels have the entry point at 0x00000000.
+- 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.2.13 for initrd on TQM850L' \
- > -A ppc -O linux -T kernel -C gzip -a 00000000 -e 0000000C \
- > -d /opt/mpc8xx/src/linux-2.2.13/arch/ppc/coffboot/vmlinux.gz \
- > examples/image-2.2.13-initrd
- Image Name: 2.2.13 for initrd on TQM850L
+ -> 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: 0x0000000c
+ Entry Point: 0x00000000
To verify the contents of the image (or check for corruption):
- -> tools/mkimage -l examples/image-2.2.13-initrd
- Image Name: 2.2.13 for initrd on TQM850L
+ -> 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: 0x0000000c
+ Entry Point: 0x00000000
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/mpc8xx/src/linux-2.2.13/arch/ppc/coffboot/vmlinux.gz
- -> tools/mkimage -n '2.2.13 for initrd on TQM850L' \
- > -A ppc -O linux -T kernel -C none -a 00000000 -e 0000000C \
- > -d /opt/mpc8xx/src/linux-2.2.13/arch/ppc/coffboot/vmlinux \
- > examples/image-2.2.13-initrd-uncompressed
- Image Name: 2.2.13 for initrd on TQM850L
+ -> 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: 0x0000000c
+ Entry Point: 0x00000000
Similar you can build U-Boot images from a 'ramdisk.image.gz' file
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:
=================
MPC826x processors), on others (parts of) the data cache can be
locked as (mis-) used as memory, etc.
+ Chris Hallinan posted a good summy 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:
----------------------
[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
-list, Octover 2002]
+list, October 2002]
int main (int argc, char *argv[])
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?");
}
Create your own board support subdirectory;
+ Create your own board config file;
+
while (!running) {
do {
Add / modify source code;