#
-# (C) Copyright 2000 - 2004
+# (C) Copyright 2000 - 2005
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
#
# See file CREDITS for list of people who contributed to this
========
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.
+Embedded boards based on PowerPC, ARM, MIPS and several other
+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 have some
- board Board dependent files
- common Misc architecture independent functions
- cpu CPU specific files
- - 74xx_7xx Files specific to Motorola MPC74xx and 7xx CPUs
+ - 74xx_7xx Files specific to Freescale MPC74xx and 7xx CPUs
- arm720t Files specific to ARM 720 CPUs
- arm920t Files specific to ARM 920 CPUs
+ - at91rm9200 Files specific to Atmel AT91RM9200 CPU
+ - imx Files specific to Freescale MC9328 i.MX CPUs
+ - s3c24x0 Files specific to Samsung S3C24X0 CPUs
- arm925t Files specific to ARM 925 CPUs
- arm926ejs Files specific to ARM 926 CPUs
- - at91rm9200 Files specific to Atmel AT91RM9200 CPUs
+ - arm1136 Files specific to ARM 1136 CPUs
+ - at32ap Files specific to Atmel AVR32 AP CPUs
- i386 Files specific to i386 CPUs
- ixp Files specific to Intel XScale IXP CPUs
- - mcf52x2 Files specific to Motorola ColdFire MCF52x2 CPUs
+ - mcf52x2 Files specific to Freescale ColdFire MCF52x2 CPUs
- mips Files specific to MIPS CPUs
- - mpc5xx Files specific to Motorola MPC5xx CPUs
- - mpc5xxx Files specific to Motorola MPC5xxx CPUs
- - mpc8xx Files specific to Motorola MPC8xx CPUs
- - mpc824x Files specific to Motorola MPC824x CPUs
- - mpc8260 Files specific to Motorola MPC8260 CPUs
- - mpc85xx Files specific to Motorola MPC85xx CPUs
+ - mpc5xx Files specific to Freescale MPC5xx CPUs
+ - mpc5xxx Files specific to Freescale MPC5xxx CPUs
+ - mpc8xx Files specific to Freescale MPC8xx CPUs
+ - mpc8220 Files specific to Freescale MPC8220 CPUs
+ - mpc824x Files specific to Freescale MPC824x CPUs
+ - mpc8260 Files specific to Freescale MPC8260 CPUs
+ - mpc85xx Files specific to Freescale MPC85xx CPUs
- nios Files specific to Altera NIOS CPUs
- - ppc4xx Files specific to IBM PowerPC 4xx CPUs
+ - nios2 Files specific to Altera Nios-II CPUs
+ - ppc4xx Files specific to AMCC PowerPC 4xx CPUs
- pxa Files specific to Intel XScale PXA CPUs
- s3c44b0 Files specific to Samsung S3C44B0 CPUs
- sa1100 Files specific to Intel StrongARM SA1100 CPUs
- examples Example code for standalone applications, etc.
- include Header Files
- lib_arm Files generic to ARM architecture
+- lib_avr32 Files generic to AVR32 architecture
- lib_generic Files generic to all architectures
- lib_i386 Files generic to i386 architecture
- lib_m68k Files generic to m68k architecture
-------------------
CONFIG_MPC823, CONFIG_MPC850, CONFIG_MPC855, CONFIG_MPC860
or CONFIG_MPC5xx
+ or CONFIG_MPC8220
or CONFIG_MPC824X, CONFIG_MPC8260
or CONFIG_MPC85xx
or CONFIG_IOP480
CONFIG_SA1110
CONFIG_ARM7
CONFIG_PXA250
+ CONFIG_CPU_MONAHANS
MicroBlaze based CPUs:
----------------------
- CONFIG_MICROBLZE
+ CONFIG_MICROBLAZE
+ Nios-2 based CPUs:
+ ----------------------
+ CONFIG_NIOS2
+
+ AVR32 based CPUs:
+ ----------------------
+ CONFIG_AT32AP
- Board Type: Define exactly one of
PowerPC based boards:
---------------------
- 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,
+ CONFIG_ADCIOP CONFIG_FPS860L CONFIG_OXC
+ CONFIG_ADS860 CONFIG_GEN860T CONFIG_PCI405
+ CONFIG_AMX860 CONFIG_GENIETV CONFIG_PCIPPC2
+ CONFIG_AP1000 CONFIG_GTH CONFIG_PCIPPC6
+ CONFIG_AR405 CONFIG_gw8260 CONFIG_pcu_e
+ CONFIG_BAB7xx CONFIG_hermes CONFIG_PIP405
+ CONFIG_BC3450 CONFIG_hymod CONFIG_PM826
+ CONFIG_c2mon CONFIG_IAD210 CONFIG_ppmc8260
+ CONFIG_CANBT CONFIG_ICU862 CONFIG_QS823
+ CONFIG_CCM CONFIG_IP860 CONFIG_QS850
+ CONFIG_CMI CONFIG_IPHASE4539 CONFIG_QS860T
+ CONFIG_cogent_mpc8260 CONFIG_IVML24 CONFIG_RBC823
+ CONFIG_cogent_mpc8xx CONFIG_IVML24_128 CONFIG_RPXClassic
+ CONFIG_CPCI405 CONFIG_IVML24_256 CONFIG_RPXlite
+ CONFIG_CPCI4052 CONFIG_IVMS8 CONFIG_RPXsuper
+ CONFIG_CPCIISER4 CONFIG_IVMS8_128 CONFIG_rsdproto
+ CONFIG_CPU86 CONFIG_IVMS8_256 CONFIG_sacsng
+ CONFIG_CRAYL1 CONFIG_JSE CONFIG_Sandpoint8240
+ CONFIG_CSB272 CONFIG_LANTEC CONFIG_Sandpoint8245
+ CONFIG_CU824 CONFIG_LITE5200B CONFIG_sbc8260
+ CONFIG_DASA_SIM CONFIG_lwmon CONFIG_sbc8560
+ CONFIG_DB64360 CONFIG_MBX CONFIG_SM850
+ CONFIG_DB64460 CONFIG_MBX860T CONFIG_SPD823TS
+ CONFIG_DU405 CONFIG_MHPC CONFIG_STXGP3
+ CONFIG_DUET_ADS CONFIG_MIP405 CONFIG_SXNI855T
+ CONFIG_EBONY CONFIG_MOUSSE CONFIG_TQM823L
+ CONFIG_ELPPC CONFIG_MPC8260ADS CONFIG_TQM8260
+ CONFIG_ELPT860 CONFIG_MPC8540ADS CONFIG_TQM850L
+ CONFIG_ep8260 CONFIG_MPC8540EVAL CONFIG_TQM855L
+ CONFIG_ERIC CONFIG_MPC8560ADS CONFIG_TQM860L
+ CONFIG_ESTEEM192E CONFIG_MUSENKI CONFIG_TTTech
+ CONFIG_ETX094 CONFIG_MVS1 CONFIG_UTX8245
+ CONFIG_EVB64260 CONFIG_NETPHONE CONFIG_V37
+ CONFIG_FADS823 CONFIG_NETTA CONFIG_W7OLMC
+ CONFIG_FADS850SAR CONFIG_NETVIA CONFIG_W7OLMG
+ CONFIG_FADS860T CONFIG_NX823 CONFIG_WALNUT
+ CONFIG_FLAGADM CONFIG_OCRTC CONFIG_ZPC1900
+ CONFIG_FPS850L CONFIG_ORSG CONFIG_ZUMA
ARM based boards:
-----------------
- 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,
+ CONFIG_ARMADILLO, CONFIG_AT91RM9200DK, CONFIG_CERF250,
+ CONFIG_CSB637, CONFIG_DELTA, CONFIG_DNP1110,
+ CONFIG_EP7312, CONFIG_H2_OMAP1610, CONFIG_HHP_CRADLE,
+ CONFIG_IMPA7, CONFIG_INNOVATOROMAP1510, CONFIG_INNOVATOROMAP1610,
+ CONFIG_KB9202, CONFIG_LART, CONFIG_LPD7A400,
+ CONFIG_LUBBOCK, CONFIG_OSK_OMAP5912, CONFIG_OMAP2420H4,
+ CONFIG_PLEB2, CONFIG_SHANNON, CONFIG_P2_OMAP730,
+ CONFIG_SMDK2400, CONFIG_SMDK2410, CONFIG_TRAB,
+ CONFIG_VCMA9
MicroBlaze based boards:
------------------------
CONFIG_SUZAKU
+ Nios-2 based boards:
+ ------------------------
+
+ CONFIG_PCI5441 CONFIG_PK1C20
+ CONFIG_EP1C20 CONFIG_EP1S10 CONFIG_EP1S40
+
+ AVR32 based boards:
+ -------------------
+
+ CONFIG_ATSTK1000
+
+- CPU Daughterboard Type: (if CONFIG_ATSTK1000 is defined)
+ Define exactly one of
+ CONFIG_ATSTK1002
+
- CPU Module Type: (if CONFIG_COGENT is defined)
Define exactly one of
CONFIG_MPC8240, CONFIG_MPC8245
- 8xx CPU Options: (if using an MPC8xx cpu)
- Define one or more of
- CONFIG_8xx_GCLK_FREQ - if get_gclk_freq() cannot work
+ CONFIG_8xx_GCLK_FREQ - deprecated: CPU clock if
+ get_gclk_freq() cannot work
e.g. if there is no 32KHz
reference PIT/RTC clock
+ CONFIG_8xx_OSCLK - PLL input clock (either EXTCLK
+ or XTAL/EXTAL)
-- 859/866 CPU options: (if using a MPC859 or MPC866 CPU):
- CFG_866_OSCCLK
- CFG_866_CPUCLK_MIN
- CFG_866_CPUCLK_MAX
- CFG_866_CPUCLK_DEFAULT
+- 859/866/885 CPU options: (if using a MPC859 or MPC866 or MPC885 CPU):
+ CFG_8xx_CPUCLK_MIN
+ CFG_8xx_CPUCLK_MAX
+ CONFIG_8xx_CPUCLK_DEFAULT
See doc/README.MPC866
CFG_MEASURE_CPUCLK
values. Mostly useful for board bringup to make sure
the PLL is locked at the intended frequency. Note
that this requires a (stable) reference clock (32 kHz
- RTC clock),
+ RTC clock or CFG_8XX_XIN)
+
+- Intel Monahans options:
+ CFG_MONAHANS_RUN_MODE_OSC_RATIO
+
+ Defines the Monahans run mode to oscillator
+ ratio. Valid values are 8, 16, 24, 31. The core
+ frequency is this value multiplied by 13 MHz.
+
+ CFG_MONAHANS_TURBO_RUN_MODE_RATIO
+
+ Defines the Monahans turbo mode to oscillator
+ ratio. Valid values are 1 (default if undefined) and
+ 2. The core frequency as calculated above is multiplied
+ by this value.
- Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
expect it to be in bytes, others in MB.
Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes.
+ CONFIG_OF_FLAT_TREE
+
+ New kernel versions are expecting firmware settings to be
+ passed using flat open firmware trees.
+ The environment variable "disable_of", when set, disables this
+ functionality.
+
+ CONFIG_OF_FLAT_TREE_MAX_SIZE
+
+ The maximum size of the constructed OF tree.
+
+ OF_CPU - The proper name of the cpus node.
+ OF_SOC - The proper name of the soc node.
+ OF_TBCLK - The timebase frequency.
+ OF_STDOUT_PATH - The path to the console device
+
+ CONFIG_OF_HAS_BD_T
+
+ The resulting flat device tree will have a copy of the bd_t.
+ Space should be pre-allocated in the dts for the bd_t.
+
+ CONFIG_OF_HAS_UBOOT_ENV
+
+ The resulting flat device tree will have a copy of u-boot's
+ environment variables
+
+ CONFIG_OF_BOARD_SETUP
+
+ Board code has addition modification that it wants to make
+ to the flat device tree before handing it off to the kernel
+
+ CONFIG_OF_BOOT_CPU
+
+ This define fills in the correct boot cpu in the boot
+ param header, the default value is zero if undefined.
+
+- Serial Ports:
+ CFG_PL010_SERIAL
+
+ Define this if you want support for Amba PrimeCell PL010 UARTs.
+
+ CFG_PL011_SERIAL
+
+ Define this if you want support for Amba PrimeCell PL011 UARTs.
+
+ CONFIG_PL011_CLOCK
+
+ If you have Amba PrimeCell PL011 UARTs, set this variable to
+ the clock speed of the UARTs.
+
+ CONFIG_PL01x_PORTS
+
+ If you have Amba PrimeCell PL010 or PL011 UARTs on your board,
+ define this to a list of base addresses for each (supported)
+ port. See e.g. include/configs/versatile.h
+
+
- Console Interface:
Depending on board, define exactly one serial port
(like CONFIG_8xx_CONS_SMC1, CONFIG_8xx_CONS_SMC2,
- Console UART Number:
CONFIG_UART1_CONSOLE
- IBM PPC4xx only.
+ AMCC PPC4xx only.
If defined internal UART1 (and not UART0) is used
as default U-Boot console.
CFG_CMD_ASKENV * ask for env variable
CFG_CMD_AUTOSCRIPT Autoscript Support
CFG_CMD_BDI bdinfo
- CFG_CMD_BEDBUG Include BedBug Debugger
+ CFG_CMD_BEDBUG * Include BedBug Debugger
CFG_CMD_BMP * BMP support
+ CFG_CMD_BSP * Board specific commands
CFG_CMD_BOOTD bootd
- CFG_CMD_CACHE icache, dcache
+ CFG_CMD_CACHE * icache, dcache
CFG_CMD_CONSOLE coninfo
CFG_CMD_DATE * support for RTC, date/time...
- CFG_CMD_DHCP DHCP support
+ CFG_CMD_DHCP * DHCP support
CFG_CMD_DIAG * Diagnostics
CFG_CMD_DOC * Disk-On-Chip Support
- CFG_CMD_DTT Digital Therm and Thermostat
- CFG_CMD_ECHO * echo arguments
+ CFG_CMD_DTT * Digital Therm and Thermostat
+ CFG_CMD_ECHO echo arguments
CFG_CMD_EEPROM * EEPROM read/write support
- CFG_CMD_ELF bootelf, bootvx
+ CFG_CMD_ELF * bootelf, bootvx
CFG_CMD_ENV saveenv
CFG_CMD_FDC * Floppy Disk Support
- CFG_CMD_FAT FAT partition support
+ CFG_CMD_FAT * FAT partition support
CFG_CMD_FDOS * Dos diskette Support
CFG_CMD_FLASH flinfo, erase, protect
CFG_CMD_FPGA FPGA device initialization support
CFG_CMD_IMLS List all found images
CFG_CMD_IMMAP * IMMR dump support
CFG_CMD_IRQ * irqinfo
- CFG_CMD_ITEST * Integer/string test of 2 values
+ CFG_CMD_ITEST Integer/string test of 2 values
CFG_CMD_JFFS2 * JFFS2 Support
CFG_CMD_KGDB * kgdb
CFG_CMD_LOADB loadb
CFG_CMD_LOADS loads
CFG_CMD_MEMORY md, mm, nm, mw, cp, cmp, crc, base,
- loop, mtest
+ loop, loopw, mtest
CFG_CMD_MISC Misc functions like sleep etc
- CFG_CMD_MMC MMC memory mapped support
- CFG_CMD_MII MII utility commands
+ CFG_CMD_MMC * MMC memory mapped support
+ CFG_CMD_MII * MII utility commands
CFG_CMD_NAND * NAND support
CFG_CMD_NET bootp, tftpboot, rarpboot
CFG_CMD_PCI * pciinfo
CFG_CMD_PORTIO * Port I/O
CFG_CMD_REGINFO * Register dump
CFG_CMD_RUN run command in env variable
- CFG_CMD_SAVES save S record dump
+ CFG_CMD_SAVES * save S record dump
CFG_CMD_SCSI * SCSI Support
CFG_CMD_SDRAM * print SDRAM configuration information
+ (requires CFG_CMD_I2C)
CFG_CMD_SETGETDCR Support for DCR Register access (4xx only)
CFG_CMD_SPI * SPI serial bus support
CFG_CMD_USB * USB support
-----------------------------------------------
CFG_CMD_ALL all
- CFG_CMD_DFL Default configuration; at the moment
+ CONFIG_CMD_DFL Default configuration; at the moment
this is includes all commands, except
the ones marked with "*" in the list
above.
If you don't define CONFIG_COMMANDS it defaults to
- CFG_CMD_DFL in include/cmd_confdefs.h. A board can
+ CONFIG_CMD_DFL in include/cmd_confdefs.h. A board can
override the default settings in the respective
include file.
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC
CONFIG_RTC_DS164x - use Dallas DS164x RTC
+ CONFIG_RTC_MAX6900 - use Maxim, Inc. MAX6900 RTC
Note that if the RTC uses I2C, then the I2C interface
must also be configured. See I2C Support, below.
CONFIG_LAN91C96_USE_32_BIT
Define this to enable 32 bit addressing
+ CONFIG_DRIVER_SMC91111
+ Support for SMSC's LAN91C111 chip
+
+ CONFIG_SMC91111_BASE
+ Define this to hold the physical address
+ of the device (I/O space)
+
+ CONFIG_SMC_USE_32_BIT
+ Define this if data bus is 32 bits
+
+ CONFIG_SMC_USE_IOFUNCS
+ Define this to use i/o functions instead of macros
+ (some hardware wont work with macros)
+
- USB Support:
At the moment only the UHCI host controller is
supported (PIP405, MIP405, MPC5200); define
CONFIG_USB_UHCI to enable it.
define CONFIG_USB_KEYBOARD to enable the USB Keyboard
- end define CONFIG_USB_STORAGE to enable the USB
+ and define CONFIG_USB_STORAGE to enable the USB
storage devices.
Note:
Supported are USB Keyboards and USB Floppy drives
for differential drivers: 0x00001000
for single ended drivers: 0x00005000
+- USB Device:
+ Define the below if you wish to use the USB console.
+ Once firmware is rebuilt from a serial console issue the
+ command "setenv stdin usbtty; setenv stdout usbtty" and
+ attach your usb cable. The Unix command "dmesg" should print
+ it has found a new device. The environment variable usbtty
+ can be set to gserial or cdc_acm to enable your device to
+ appear to a USB host as a Linux gserial device or a
+ Common Device Class Abstract Control Model serial device.
+ If you select usbtty = gserial you should be able to enumerate
+ a Linux host by
+ # modprobe usbserial vendor=0xVendorID product=0xProductID
+ else if using cdc_acm, simply setting the environment
+ variable usbtty to be cdc_acm should suffice. The following
+ might be defined in YourBoardName.h
+
+ CONFIG_USB_DEVICE
+ Define this to build a UDC device
+
+ CONFIG_USB_TTY
+ Define this to have a tty type of device available to
+ talk to the UDC device
+
+ CFG_CONSOLE_IS_IN_ENV
+ Define this if you want stdin, stdout &/or stderr to
+ be set to usbtty.
+
+ mpc8xx:
+ CFG_USB_EXTC_CLK 0xBLAH
+ Derive USB clock from external clock "blah"
+ - CFG_USB_EXTC_CLK 0x02
+
+ CFG_USB_BRG_CLK 0xBLAH
+ Derive USB clock from brgclk
+ - CFG_USB_BRG_CLK 0x04
+
+ If you have a USB-IF assigned VendorID then you may wish to
+ define your own vendor specific values either in BoardName.h
+ or directly in usbd_vendor_info.h. If you don't define
+ CONFIG_USBD_MANUFACTURER, CONFIG_USBD_PRODUCT_NAME,
+ CONFIG_USBD_VENDORID and CONFIG_USBD_PRODUCTID, then U-Boot
+ should pretend to be a Linux device to it's target host.
+
+ CONFIG_USBD_MANUFACTURER
+ Define this string as the name of your company for
+ - CONFIG_USBD_MANUFACTURER "my company"
+
+ CONFIG_USBD_PRODUCT_NAME
+ Define this string as the name of your product
+ - CONFIG_USBD_PRODUCT_NAME "acme usb device"
+
+ CONFIG_USBD_VENDORID
+ Define this as your assigned Vendor ID from the USB
+ Implementors Forum. This *must* be a genuine Vendor ID
+ to avoid polluting the USB namespace.
+ - CONFIG_USBD_VENDORID 0xFFFF
+
+ CONFIG_USBD_PRODUCTID
+ Define this as the unique Product ID
+ for your device
+ - CONFIG_USBD_PRODUCTID 0xFFFF
+
- MMC Support:
The MMC controller on the Intel PXA is supported. To
enabled with CFG_CMD_MMC. The MMC driver also works with
the FAT fs. This is enabled with CFG_CMD_FAT.
+- Journaling Flash filesystem support:
+ CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, CONFIG_JFFS2_NAND_SIZE,
+ CONFIG_JFFS2_NAND_DEV
+ Define these for a default partition on a NAND device
+
+ CFG_JFFS2_FIRST_SECTOR,
+ CFG_JFFS2_FIRST_BANK, CFG_JFFS2_NUM_BANKS
+ Define these for a default partition on a NOR device
+
+ CFG_JFFS_CUSTOM_PART
+ Define this to create an own partition. You have to provide a
+ function struct part_info* jffs2_part_info(int part_num)
+
+ If you define only one JFFS2 partition you may also want to
+ #define CFG_JFFS_SINGLE_PART 1
+ to disable the command chpart. This is the default when you
+ have not defined a custom partition
+
- Keyboard Support:
CONFIG_ISA_KEYBOARD
If this option is set, the environment is checked for
a variable "splashimage". If found, the usual display
of logo, copyright and system information on the LCD
- is supressed and the BMP image at the address
+ is suppressed and the BMP image at the address
specified in "splashimage" is loaded instead. The
console is redirected to the "nulldev", too. This
allows for a "silent" boot where a splash screen is
loaded very quickly after power-on.
+- Gzip compressed BMP image support: CONFIG_VIDEO_BMP_GZIP
+
+ If this option is set, additionally to standard BMP
+ images, gzipped BMP images can be displayed via the
+ splashscreen support or the bmp command.
+
- Compression support:
CONFIG_BZIP2
the malloc area (as defined by CFG_MALLOC_LEN) should
be at least 4MB.
+- MII/PHY support:
+ CONFIG_PHY_ADDR
+
+ The address of PHY on MII bus.
+
+ CONFIG_PHY_CLOCK_FREQ (ppc4xx)
+
+ The clock frequency of the MII bus
+
+ CONFIG_PHY_GIGE
+
+ If this option is set, support for speed/duplex
+ detection of Gigabit PHY is included.
+
+ CONFIG_PHY_RESET_DELAY
+
+ Some PHY like Intel LXT971A need extra delay after
+ reset before any MII register access is possible.
+ For such PHY, set this option to the usec delay
+ required. (minimum 300usec for LXT971A)
+
+ CONFIG_PHY_CMD_DELAY (ppc4xx)
+
+ Some PHY like Intel LXT971A need extra delay after
+ command issued before MII status register can be read
+
- Ethernet address:
CONFIG_ETHADDR
CONFIG_ETH2ADDR
custom i2c_init_board() routine in boards/xxx/board.c
is run early in the boot sequence.
+ CONFIG_I2CFAST (PPC405GP|PPC405EP only)
+
+ This option enables configuration of bi_iic_fast[] flags
+ in u-boot bd_info structure based on u-boot environment
+ variable "i2cfast". (see also i2cfast)
+
- SPI Support: CONFIG_SPI
Enables SPI driver (so far only tested with
remaining RAM in a form that can be passed as boot
argument to Linux, for instance like that:
- setenv bootargs ... mem=\$(mem)
+ setenv bootargs ... mem=\${mem}
saveenv
This way you can tell Linux not to use this memory,
default value of 5 is used.
- Command Interpreter:
- CFG_AUTO_COMPLETE
+ CONFIG_AUTO_COMPLETE
Enable auto completion of commands using TAB.
+ Note that this feature has NOT been implemented yet
+ for the "hush" shell.
+
+
CFG_HUSH_PARSER
Define this variable to enable the "hush" shell (from
of the backslashes before semicolons and special
symbols.
+- Commandline Editing and History:
+ CONFIG_CMDLINE_EDITING
+
+ Enable editiong and History functions for interactive
+ commandline input operations
+
- Default Environment:
CONFIG_EXTRA_ENV_SETTINGS
When SystemACE support is added, the "ace" device type
becomes available to the fat commands, i.e. fatls.
+- TFTP Fixed UDP Port:
+ CONFIG_TFTP_PORT
+
+ If this is defined, the environment variable tftpsrcp
+ is used to supply the TFTP UDP source port value.
+ If tftpsrcp isn't defined, the normal pseudo-random port
+ number generator is used.
+
+ Also, the environment variable tftpdstp is used to supply
+ the TFTP UDP destination port value. If tftpdstp isn't
+ defined, the normal port 69 is used.
+
+ The purpose for tftpsrcp is to allow a TFTP server to
+ blindly start the TFTP transfer using the pre-configured
+ target IP address and UDP port. This has the effect of
+ "punching through" the (Windows XP) firewall, allowing
+ the remainder of the TFTP transfer to proceed normally.
+ A better solution is to properly configure the firewall,
+ but sometimes that is not allowed.
+
- Show boot progress:
CONFIG_SHOW_BOOT_PROGRESS
- CFG_MALLOC_LEN:
Size of DRAM reserved for malloc() use.
+- CFG_BOOTM_LEN:
+ Normally compressed uImages are limited to an
+ uncompressed size of 8 MBytes. If this is not enough,
+ you can define CFG_BOOTM_LEN in your board config file
+ to adjust this setting to your needs.
+
- CFG_BOOTMAPSZ:
Maximum size of memory mapped by the startup code of
the Linux kernel; all data that must be processed by
This option also enables the building of the cfi_flash driver
in the drivers directory
+- CFG_FLASH_QUIET_TEST
+ If this option is defined, the common CFI flash doesn't
+ print it's warning upon not recognized FLASH banks. This
+ is useful, if some of the configured banks are only
+ optionally available.
+
- CFG_RX_ETH_BUFFER:
Defines the number of ethernet receive buffers. On some
ethernet controllers it is recommended to set this value
The length in bytes of the EEPROM memory array address. Note
that this is NOT the chip address length!
+ - CFG_I2C_EEPROM_ADDR_OVERFLOW:
+ EEPROM chips that implement "address overflow" are ones
+ like Catalyst 24WC04/08/16 which has 9/10/11 bits of
+ address and the extra bits end up in the "chip address" bit
+ slots. This makes a 24WC08 (1Kbyte) chip look like four 256
+ byte chips.
+
+ Note that we consider the length of the address field to
+ still be one byte because the extra address bits are hidden
+ in the chip address.
+
- CFG_EEPROM_SIZE:
The size in bytes of the EEPROM device.
environment area within the total memory of your DataFlash placed
at the specified address.
+- CFG_ENV_IS_IN_NAND:
+
+ Define this if you have a NAND device which you want to use
+ for the environment.
+
+ - CFG_ENV_OFFSET:
+ - CFG_ENV_SIZE:
+
+ These two #defines specify the offset and size of the environment
+ area within the first NAND device.
+
+ - CFG_ENV_OFFSET_REDUND
+
+ This setting describes a second storage area of CFG_ENV_SIZE
+ size used to hold a redundant copy of the environment data,
+ so that there is a valid backup copy in case there is a
+ power failure during a "saveenv" operation.
+
+ Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned
+ to a block boundary, and CFG_ENV_SIZE must be a multiple of
+ the NAND devices block size.
- CFG_SPI_INIT_OFFSET
source code. It is used to make hardware dependant
initializations.
-- CFG_IMMR: Physical address of the Internal Memory Mapped
- Register; DO NOT CHANGE! (11-4)
- [MPC8xx systems only]
+- CFG_IMMR: Physical address of the Internal Memory.
+ DO NOT CHANGE unless you know exactly what you're
+ doing! (11-4) [MPC8xx/82xx systems only]
- CFG_INIT_RAM_ADDR:
Note that this is a global option, we can't
have one FEC in standard MII mode and another in RMII mode.
+- CONFIG_CRC32_VERIFY
+ Add a verify option to the crc32 command.
+ The syntax is:
+
+ => crc32 -v <address> <count> <crc32>
+
+ Where address/count indicate a memory area
+ and crc32 is the correct crc32 which the
+ area should have.
+
+- CONFIG_LOOPW
+ Add the "loopw" memory command. This only takes effect if
+ the memory commands are activated globally (CFG_CMD_MEM).
+
+- CONFIG_MX_CYCLIC
+ Add the "mdc" and "mwc" memory commands. These are cyclic
+ "md/mw" commands.
+ Examples:
+
+ => mdc.b 10 4 500
+ This command will print 4 bytes (10,11,12,13) each 500 ms.
+
+ => mwc.l 100 12345678 10
+ This command will write 12345678 to address 100 all 10 ms.
+
+ This only takes effect if the memory commands are activated
+ globally (CFG_CMD_MEM).
+
+- CONFIG_SKIP_LOWLEVEL_INIT
+- CONFIG_SKIP_RELOCATE_UBOOT
+
+ [ARM only] If these variables are defined, then
+ certain low level initializations (like setting up
+ the memory controller) are omitted and/or U-Boot does
+ not relocate itself into RAM.
+ Normally these variables MUST NOT be defined. The
+ only exception is when U-Boot is loaded (to RAM) by
+ some other boot loader or by a debugger which
+ performs these intializations itself.
+
+
Building the Software:
======================
where "NAME_config" is the name of one of the existing
configurations; the following names are supported:
- 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
-
- 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.
+ ADCIOP_config FPS860L_config omap730p2_config
+ ADS860_config GEN860T_config pcu_e_config
+ Alaska8220_config
+ AR405_config GENIETV_config PIP405_config
+ at91rm9200dk_config GTH_config QS823_config
+ CANBT_config hermes_config QS850_config
+ cmi_mpc5xx_config hymod_config QS860T_config
+ cogent_common_config IP860_config RPXlite_config
+ cogent_mpc8260_config IVML24_config RPXlite_DW_config
+ cogent_mpc8xx_config IVMS8_config RPXsuper_config
+ CPCI405_config JSE_config rsdproto_config
+ CPCIISER4_config LANTEC_config Sandpoint8240_config
+ csb272_config lwmon_config sbc8260_config
+ CU824_config MBX860T_config sbc8560_33_config
+ DUET_ADS_config MBX_config sbc8560_66_config
+ EBONY_config MPC8260ADS_config SM850_config
+ ELPT860_config MPC8540ADS_config SPD823TS_config
+ ESTEEM192E_config MPC8540EVAL_config stxgp3_config
+ ETX094_config MPC8560ADS_config SXNI855T_config
+ FADS823_config NETVIA_config TQM823L_config
+ FADS850SAR_config omap1510inn_config TQM850L_config
+ FADS860T_config omap1610h2_config TQM855L_config
+ FPS850L_config omap1610inn_config TQM860L_config
+ omap5912osk_config walnut_config
+ omap2420h4_config Yukon8220_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 TQM823L systems are available without (standard)
+ or with LCD support. You can select such additional "features"
+ when chosing the configuration, i. e.
+
+ make TQM823L_config
+ - will configure for a plain TQM823L, i. e. no LCD support
+
+ make TQM823L_LCD_config
+ - will configure for a TQM823L 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
+
+By default the build is performed locally and the objects are saved
+in the source directory. One of the two methods can be used to change
+this behavior and build U-Boot to some external directory:
+
+1. Add O= to the make command line invocations:
+
+ make O=/tmp/build distclean
+ make O=/tmp/build NAME_config
+ make O=/tmp/build all
+
+2. Set environment variable BUILD_DIR to point to the desired location:
+
+ export BUILD_DIR=/tmp/build
+ make distclean
+ make NAME_config
+ make all
+
+Note that the command line "O=" setting overrides the BUILD_DIR environment
+variable.
+
+
+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
+
+When using the MAKEALL script, the default behaviour is to build U-Boot
+in the source directory. This location can be changed by setting the
+BUILD_DIR environment variable. Also, for each target built, the MAKEALL
+script saves two log files (<target>.ERR and <target>.MAKEALL) in the
+<source dir>/LOG directory. This default location can be changed by
+setting the MAKEALL_LOGDIR environment variable. For example:
+
+ export BUILD_DIR=/tmp/build
+ export MAKEALL_LOGDIR=/tmp/log
+ CROSS_COMPILE=ppc_8xx- MAKEALL
+
+With the above settings build objects are saved in the /tmp/build, log
+files are saved in the /tmp/log and the source tree remains clean during
+the whole build process.
+
+
+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
+loopw - infinite write 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.
- ipaddr - IP address; needed for tftpboot command
+Some configuration options can be set using Environment Variables:
- loadaddr - Default load address for commands like "bootp",
- "rarpboot", "tftpboot", "loadb" or "diskboot"
+ baudrate - see CONFIG_BAUDRATE
- loads_echo - see CONFIG_LOADS_ECHO
+ bootdelay - see CONFIG_BOOTDELAY
- serverip - TFTP server IP address; needed for tftpboot command
+ bootcmd - see CONFIG_BOOTCOMMAND
- bootretry - see CONFIG_BOOT_RETRY_TIME
+ bootargs - Boot arguments when booting an RTOS image
- bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR
+ bootfile - Name of the image to load with TFTP
- bootstopkey - see CONFIG_AUTOBOOT_STOP_STR
+ 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
- ethprime - When CONFIG_NET_MULTI is enabled controls which
- interface is used first.
+ autostart - if set to "yes", an image loaded using the "bootp",
+ "rarpboot", "tftpboot" or "diskboot" commands will
+ be automatically started (by internally calling
+ "bootm")
- ethact - When CONFIG_NET_MULTI is enabled controls which
- interface is currently active. For example you
- can do the following
+ 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.
- => 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
+ i2cfast - (PPC405GP|PPC405EP only)
+ if set to 'y' configures Linux I2C driver for fast
+ mode (400kHZ). This environment variable is used in
+ initialization code. So, for changes to be effective
+ it must be saved and board must be reset.
- netretry - When set to "no" each network operation will
- either succeed or fail without retrying.
- When set to "once" the network operation will
- fail when all the available network interfaces
- are tried once without success.
- Useful on scripts which control the retry operation
- themselves.
+ 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).
- vlan - When set to a value < 4095 the traffic over
- ethernet is encapsulated/received over 802.1q
- VLAN tagged frames.
+ 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
- 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:
+ setenv initrd_high 00c00000
- 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
+ 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.
+ ipaddr - IP address; needed for tftpboot command
- There are two special Environment Variables:
+ loadaddr - Default load address for commands like "bootp",
+ "rarpboot", "tftpboot", "loadb" or "diskboot"
- serial# - contains hardware identification information such
- as type string and/or serial number
- ethaddr - Ethernet address
+ loads_echo - see CONFIG_LOADS_ECHO
- 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.
+ serverip - TFTP server IP address; needed for tftpboot command
+ bootretry - see CONFIG_BOOT_RETRY_TIME
- Further special Environment Variables:
+ bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR
- ver - Contains the U-Boot version string as printed
- with the "version" command. This variable is
- readonly (see CONFIG_VERSION_VARIABLE).
+ bootstopkey - see CONFIG_AUTOBOOT_STOP_STR
+ ethprime - When CONFIG_NET_MULTI is enabled controls which
+ interface is used first.
- Please note that changes to some configuration parameters may take
- only effect after the next boot (yes, that's just like Windoze :-).
-
+ ethact - When CONFIG_NET_MULTI is enabled controls which
+ interface is currently active. For example you
+ can do the following
- Command Line Parsing:
- =====================
+ => 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
- There are two different command line parsers available with U-Boot:
- the old "simple" one, and the much more powerful "hush" shell:
+ netretry - When set to "no" each network operation will
+ either succeed or fail without retrying.
+ When set to "once" the network operation will
+ fail when all the available network interfaces
+ are tried once without success.
+ Useful on scripts which control the retry operation
+ themselves.
- Old, simple command line parser:
- --------------------------------
+ tftpsrcport - If this is set, the value is used for TFTP's
+ UDP source port.
- - 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'
+ tftpdstport - If this is set, the value is used for TFTP's UDP
+ destination port instead of the Well Know Port 69.
- Hush shell:
- -----------
+ vlan - When set to a value < 4095 the traffic over
+ ethernet is encapsulated/received over 802.1q
+ VLAN tagged frames.
- - 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
+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:
- General rules:
- --------------
+ 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
- (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.
+There are two special Environment Variables:
- Note for Redundant Ethernet Interfaces:
- =======================================
+ serial# - contains hardware identification information such
+ as type string and/or serial number
+ ethaddr - Ethernet address
- 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:
+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.
- 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:
+Further special Environment Variables:
- o If the SROM has a valid MAC address, and there is no address in the
- environment, the SROM's address is used.
+ ver - Contains the U-Boot version string as printed
+ with the "version" command. This variable is
+ readonly (see CONFIG_VERSION_VARIABLE).
- o If there is no valid address in the SROM, and a definition in the
- environment exists, then the value from the environment variable is
- used.
- o If both the SROM and the environment contain a MAC address, and
- both addresses are the same, this MAC address is used.
+Please note that changes to some configuration parameters may take
+only effect after the next boot (yes, that's just like Windoze :-).
- 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.
+Command Line Parsing:
+=====================
+There are two different command line parsers available with U-Boot:
+the old "simple" one, and the much more powerful "hush" shell:
- Image Formats:
- ==============
+Old, simple command line parser:
+--------------------------------
- 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:
+- 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'
- * 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
+Hush shell:
+-----------
- 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.
+- 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:
+--------------
+(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.
- Linux Support:
- ==============
+(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.
- 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.
+Note for Redundant Ethernet Interfaces:
+=======================================
- 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:
+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:
- - the same features can be used for other OS or standalone
- applications (for instance: using compressed images to reduce the
- Flash memory footprint)
+Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
+MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
+"eth1addr" (=>eth1), "eth2addr", ...
- - it becomes much easier to port new Linux kernel versions because
- lots of low-level, hardware dependent stuff are done by U-Boot
+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:
- - 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.
+o If the SROM has a valid MAC address, and there is no address in the
+ environment, the SROM's address is used.
+o If there is no valid address in the SROM, and a definition in the
+ environment exists, then the value from the environment variable is
+ used.
- Linux HOWTO:
- ============
+o If both the SROM and the environment contain a MAC address, and
+ both addresses are the same, this MAC address is used.
- Porting Linux to U-Boot based systems:
- ---------------------------------------
+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.
- 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 :-).
+o If neither SROM nor the environment contain a MAC address, an error
+ is raised.
- But now you can ignore ALL boot loader code (in arch/ppc/mbxboot).
- 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.
+Image Formats:
+==============
+The "boot" commands of this monitor operate on "image" files which
+can be basicly anything, preceeded by a special header; see the
+definitions in include/image.h for details; basicly, the header
+defines the following image properties:
- Configuring the Linux kernel:
- -----------------------------
+* 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, AVR32, Intel x86,
+ IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
+ Currently supported: ARM, AVR32, Intel x86, MIPS, NIOS, PowerPC).
+* Compression Type (uncompressed, gzip, bzip2)
+* Load Address
+* Entry Point
+* Image Name
+* Image Timestamp
- No specific requirements for U-Boot. Make sure you have some root
- device (initial ramdisk, NFS) for your target system.
+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.
- Building a Linux Image:
- -----------------------
+Linux Support:
+==============
- 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.
+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.
- Example:
+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:
- make TQM850L_config
- make oldconfig
- make dep
- make uImage
+- the same features can be used for other OS or standalone
+ applications (for instance: using compressed images to reduce the
+ Flash memory footprint)
- 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:
+- it becomes much easier to port new Linux kernel versions because
+ lots of low-level, hardware dependent stuff are done by U-Boot
- * 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
+- 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.
- * 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
+Linux HOWTO:
+============
+Porting Linux to U-Boot based systems:
+---------------------------------------
- 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.
+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 :-).
- "mkimage" can be called in two ways: to verify existing images and
- print the header information, or to build new images.
+But now you can ignore ALL boot loader code (in arch/ppc/mbxboot).
- 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:
+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.
- tools/mkimage -l image
- -l ==> list image header information
- The second form (with "-d" option) is used to build a U-Boot image
- from a "data file" which is used as image payload:
+Configuring the Linux kernel:
+-----------------------------
- 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'
+No specific requirements for U-Boot. Make sure you have some root
+device (initial ramdisk, NFS) for your target system.
- 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.
+Building a Linux Image:
+-----------------------
+
+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.
+
+"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
+ -l ==> list image header information
+
+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'
+
+Right now, all Linux kernels for PowerPC systems 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
+
+To verify the contents of the image (or check for corruption):
+
+ -> 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
+
+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#
+
+Boot Linux and pass a flat device tree:
+-----------
+
+First, U-Boot must be compiled with the appropriate defines. See the section
+titled "Linux Kernel Interface" above for a more in depth explanation. The
+following is an example of how to start a kernel and pass an updated
+flat device tree:
+
+=> print oftaddr
+oftaddr=0x300000
+=> print oft
+oft=oftrees/mpc8540ads.dtb
+=> tftp $oftaddr $oft
+Speed: 1000, full duplex
+Using TSEC0 device
+TFTP from server 192.168.1.1; our IP address is 192.168.1.101
+Filename 'oftrees/mpc8540ads.dtb'.
+Load address: 0x300000
+Loading: #
+done
+Bytes transferred = 4106 (100a hex)
+=> tftp $loadaddr $bootfile
+Speed: 1000, full duplex
+Using TSEC0 device
+TFTP from server 192.168.1.1; our IP address is 192.168.1.2
+Filename 'uImage'.
+Load address: 0x200000
+Loading:############
+done
+Bytes transferred = 1029407 (fb51f hex)
+=> print loadaddr
+loadaddr=200000
+=> print oftaddr
+oftaddr=0x300000
+=> bootm $loadaddr - $oftaddr
+## Booting image at 00200000 ...
+ Image Name: Linux-2.6.17-dirty
+ Image Type: PowerPC Linux Kernel Image (gzip compressed)
+ Data Size: 1029343 Bytes = 1005.2 kB
+ Load Address: 00000000
+ Entry Point: 00000000
+ Verifying Checksum ... OK
+ Uncompressing Kernel Image ... OK
+Booting using flat device tree at 0x300000
+Using MPC85xx ADS machine description
+Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
+[snip]
+
+
+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, see ftp://ftp.denx.de/pub/u-boot/ppcboot_stage2.tar.gz
+
+
+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
+ walnut.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
+
+NOTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope,
+or current versions of GCC may "optimize" the code too much.
+
+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:
+----------------------
- So a typical call to build a U-Boot image would read:
+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:
+----------------------
- -> 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
+[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
+list, October 2002]
- To verify the contents of the image (or check for corruption):
- -> 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
+int main (int argc, char *argv[])
+{
+ sighandler_t no_more_time;
- 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;
+ signal (SIGALRM, no_more_time);
+ alarm (PROJECT_DEADLINE - toSec (3 * WEEK));
+ if (available_money > available_manpower) {
+ pay consultant to port U-Boot;
return 0;
}
- void no_more_time (int sig)
- {
- hire_a_guru();
+ 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;
+
+ return 0;
+}
+
+void no_more_time (int sig)
+{
+ hire_a_guru();
+}
+
+
+Coding Standards:
+-----------------
+
+All contributions to U-Boot should conform to the Linux kernel
+coding style; see the file "Documentation/CodingStyle" and the script
+"scripts/Lindent" in your Linux kernel source directory. In sources
+originating from U-Boot a style corresponding to "Lindent -pcs" (adding
+spaces before parameters to function calls) is actually used.
- Coding Standards:
- -----------------
+Source files originating from a different project (for example the
+MTD subsystem) are generally exempt from these guidelines and are not
+reformated to ease subsequent migration to newer versions of those
+sources.
- 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.
+Patches shall be sent to the u-boot-users mailing list.
+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.
+* Remember that there is a size limit of 40 kB per message on the
+ u-boot-users mailing list. Compression may help.