X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;ds=sidebyside;f=README;h=a9c052c0592ff4aaa5e1ba03e992ee9d6a6b7adb;hb=256d31c046a6e6280d5a03e9ffc5b994ddaff591;hp=051620ea02b5ed576c343fbd453f885576dad691;hpb=db01a2ea991b539ffbd36ab952fcf2e754789a83;p=u-boot diff --git a/README b/README index 051620ea02..a9c052c059 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ # -# (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 @@ -25,9 +25,10 @@ Summary: ======== 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 @@ -122,23 +123,28 @@ Directory Hierarchy: - 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 + - 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 + - arm1136 Files specific to ARM 1136 CPUs - at91rm9200 Files specific to Atmel AT91RM9200 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 + - nios2 Files specific to Altera Nios-II CPUs - ppc4xx Files specific to IBM PowerPC 4xx CPUs - pxa Files specific to Intel XScale PXA CPUs - s3c44b0 Files specific to Samsung S3C44B0 CPUs @@ -225,6 +231,7 @@ The following options need to be configured: ------------------- 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 @@ -240,57 +247,78 @@ The following options need to be configured: CONFIG_ARM7 CONFIG_PXA250 + MicroBlaze based CPUs: + ---------------------- + CONFIG_MICROBLAZE + + Nios-2 based CPUs: + ---------------------- + CONFIG_NIOS2 + - 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_GEN860T CONFIG_PCI405 + CONFIG_ADS860 CONFIG_GENIETV CONFIG_PCIPPC2 + CONFIG_AMX860 CONFIG_GTH CONFIG_PCIPPC6 + CONFIG_AR405 CONFIG_gw8260 CONFIG_pcu_e + CONFIG_BAB7xx CONFIG_hermes CONFIG_PIP405 + CONFIG_c2mon CONFIG_hymod CONFIG_PM826 + CONFIG_CANBT CONFIG_IAD210 CONFIG_ppmc8260 + CONFIG_CCM CONFIG_ICU862 CONFIG_QS823 + CONFIG_CMI CONFIG_IP860 CONFIG_QS850 + CONFIG_cogent_mpc8260 CONFIG_IPHASE4539 CONFIG_QS860T + CONFIG_cogent_mpc8xx CONFIG_IVML24 CONFIG_RBC823 + CONFIG_CPCI405 CONFIG_IVML24_128 CONFIG_RPXClassic + CONFIG_CPCI4052 CONFIG_IVML24_256 CONFIG_RPXlite + CONFIG_CPCIISER4 CONFIG_IVMS8 CONFIG_RPXsuper + CONFIG_CPU86 CONFIG_IVMS8_128 CONFIG_rsdproto + CONFIG_CRAYL1 CONFIG_IVMS8_256 CONFIG_sacsng + CONFIG_CSB272 CONFIG_JSE CONFIG_Sandpoint8240 + CONFIG_CU824 CONFIG_LANTEC CONFIG_Sandpoint8245 + CONFIG_DASA_SIM CONFIG_lwmon CONFIG_sbc8260 + CONFIG_DB64360 CONFIG_MBX CONFIG_sbc8560 + CONFIG_DB64460 CONFIG_MBX860T CONFIG_SM850 + CONFIG_DU405 CONFIG_MHPC CONFIG_SPD823TS + CONFIG_DUET_ADS CONFIG_MIP405 CONFIG_STXGP3 + CONFIG_EBONY CONFIG_MOUSSE CONFIG_SXNI855T + CONFIG_ELPPC CONFIG_MPC8260ADS CONFIG_TQM823L + CONFIG_ELPT860 CONFIG_MPC8540ADS CONFIG_TQM8260 + CONFIG_ep8260 CONFIG_MPC8560ADS CONFIG_TQM850L + CONFIG_ERIC CONFIG_MUSENKI CONFIG_TQM855L + CONFIG_ESTEEM192E CONFIG_MVS1 CONFIG_TQM860L + CONFIG_ETX094 CONFIG_NETPHONE CONFIG_TTTech + CONFIG_EVB64260 CONFIG_NETTA CONFIG_UTX8245 + CONFIG_FADS823 CONFIG_NETVIA CONFIG_V37 + CONFIG_FADS850SAR CONFIG_NX823 CONFIG_W7OLMC + CONFIG_FADS860T CONFIG_OCRTC CONFIG_W7OLMG + CONFIG_FLAGADM CONFIG_ORSG CONFIG_WALNUT405 + CONFIG_FPS850L CONFIG_OXC CONFIG_ZPC1900 + CONFIG_FPS860L 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_AT91RM9200DK, CONFIG_CERF250, CONFIG_DNP1110, + CONFIG_EP7312, CONFIG_H2_OMAP1610, CONFIG_HHP_CRADLE, + CONFIG_IMPA7, CONFIG_INNOVATOROMAP1510, CONFIG_INNOVATOROMAP1610, + CONFIG_LART, CONFIG_LPD7A400 CONFIG_LUBBOCK, + CONFIG_OSK_OMAP5912, CONFIG_OMAP2420H4, 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 - CPU Module Type: (if CONFIG_COGENT is defined) @@ -327,16 +355,17 @@ The following options need to be configured: 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 @@ -346,7 +375,7 @@ The following options need to be configured: 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) - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ @@ -368,6 +397,27 @@ The following options need to be configured: expect it to be in bytes, others in MB. Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes. +- 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, @@ -529,22 +579,23 @@ The following options need to be configured: 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_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 @@ -555,16 +606,16 @@ The following options need to be configured: 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 @@ -573,7 +624,7 @@ The following options need to be configured: 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 CFG_CMD_SETGETDCR Support for DCR Register access (4xx only) @@ -585,13 +636,13 @@ The following options need to be configured: ----------------------------------------------- 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. @@ -641,6 +692,7 @@ The following options need to be configured: 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. @@ -730,12 +782,26 @@ The following options need to be configured: 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 @@ -756,6 +822,24 @@ The following options need to be configured: 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 @@ -788,7 +872,7 @@ The following options need to be configured: selected via environment 'videomode'. Two diferent ways are possible: - "videomode=num" 'num' is a standard LiLo mode numbers. - Following standard modes are supported (* is default): + Following standard modes are supported (* is default): Colors 640x480 800x600 1024x768 1152x864 1280x1024 -------------+--------------------------------------------- @@ -869,7 +953,7 @@ The following options need to be configured: 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 @@ -886,6 +970,32 @@ The following options need to be configured: 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 @@ -951,7 +1061,7 @@ The following options need to be configured: the DHCP server. - CDP Options: - CONFIG_CDP_DEVICE_ID + CONFIG_CDP_DEVICE_ID The device id used in CDP trigger frames. @@ -1120,6 +1230,12 @@ The following options need to be configured: 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 @@ -1742,6 +1858,17 @@ to save the current settings. 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. @@ -1759,6 +1886,16 @@ to save the current settings. 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_SPI_INIT_OFFSET @@ -1841,9 +1978,9 @@ Low Level (hardware related) configuration options: 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: @@ -1943,6 +2080,54 @@ Low Level (hardware related) configuration options: CFG_POCMR2_MASK_ATTRIB: (MPC826x only) Overrides the default PCI memory map in cpu/mpc8260/pci.c if set. +- CONFIG_ETHER_ON_FEC[12] + Define to enable FEC[12] on a 8xx series processor. + +- CONFIG_FEC[12]_PHY + Define to the hardcoded PHY address which corresponds + to the given FEC; i. e. + #define CONFIG_FEC1_PHY 4 + means that the PHY with address 4 is connected to FEC1 + + When set to -1, means to probe for first available. + +- CONFIG_FEC[12]_PHY_NORXERR + The PHY does not have a RXERR line (RMII only). + (so program the FEC to ignore it). + +- CONFIG_RMII + Enable RMII mode for all FECs. + 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
+ + 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). + Building the Software: ====================== @@ -1970,1272 +2155,1273 @@ is done by typing: 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 ".c", "flash.c" and "u-boot.lds". - 3. Create a new configuration file "include/configs/.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 _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 ". - - - 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 + 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 MPC8560ADS_config stxgp3_config + ETX094_config NETVIA_config SXNI855T_config + FADS823_config omap1510inn_config TQM823L_config + FADS850SAR_config omap1610h2_config TQM850L_config + FADS860T_config omap1610inn_config TQM855L_config + FPS850L_config omap5912osk_config TQM860L_config + omap2420h4_config WALNUT405_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 + + +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 ".c", "flash.c" and "u-boot.lds". +3. Create a new configuration file "include/configs/.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 _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 +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 ". + + +Environment Variables: +====================== - 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. +U-Boot supports user configuration using Environment Variables which +can be made persistent by saving to Flash memory. - ipaddr - IP address; needed for tftpboot command +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. - loadaddr - Default load address for commands like "bootp", - "rarpboot", "tftpboot", "loadb" or "diskboot" +Some configuration options can be set using Environment Variables: - loads_echo - see CONFIG_LOADS_ECHO + baudrate - see CONFIG_BAUDRATE - serverip - TFTP server IP address; needed for tftpboot command + bootdelay - see CONFIG_BOOTDELAY - bootretry - see CONFIG_BOOT_RETRY_TIME + bootcmd - see CONFIG_BOOTCOMMAND - bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR + bootargs - Boot arguments when booting an RTOS image - bootstopkey - see CONFIG_AUTOBOOT_STOP_STR + bootfile - Name of the image to load with TFTP - ethprime - When CONFIG_NET_MULTI is enabled controls which - interface is used first. + 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 - ethact - When CONFIG_NET_MULTI is enabled controls which - interface is currently active. For example you - can do the following + autostart - if set to "yes", an image loaded using the "bootp", + "rarpboot", "tftpboot" or "diskboot" commands will + be automatically started (by internally calling + "bootm") - => 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 + 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. - netretry - When set to "no" each network operation will - either succeed or fail without retrying. - Useful on scripts which control the retry operation - themselves. + 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. - vlan - When set to a value < 4095 the traffic over - ethernet is encapsulated/received over 802.1q - VLAN tagged frames. + 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). - 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: + 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 - 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 + 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. - There are two special Environment Variables: + ipaddr - IP address; needed for tftpboot command - serial# - contains hardware identification information such - as type string and/or serial number - ethaddr - Ethernet address + loadaddr - Default load address for commands like "bootp", + "rarpboot", "tftpboot", "loadb" or "diskboot" - 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. + loads_echo - see CONFIG_LOADS_ECHO + serverip - TFTP server IP address; needed for tftpboot command - Further special Environment Variables: + bootretry - see CONFIG_BOOT_RETRY_TIME - ver - Contains the U-Boot version string as printed - with the "version" command. This variable is - readonly (see CONFIG_VERSION_VARIABLE). + bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR + bootstopkey - see CONFIG_AUTOBOOT_STOP_STR - Please note that changes to some configuration parameters may take - only effect after the next boot (yes, that's just like Windoze :-). + ethprime - When CONFIG_NET_MULTI is enabled controls which + interface is used first. + 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: - -------------------------------- + vlan - When set to a value < 4095 the traffic over + ethernet is encapsulated/received over 802.1q + VLAN tagged frames. - - 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' +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: - Hush shell: - ----------- + 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 - - 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: - -------------- +There are two special Environment Variables: - (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. + serial# - contains hardware identification information such + as type string and/or serial number + ethaddr - Ethernet address - (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. +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. - Note for Redundant Ethernet Interfaces: - ======================================= - 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: +Further special Environment Variables: - Network interfaces are numbered eth0, eth1, eth2, ... Corresponding - MAC addresses can be stored in the environment as "ethaddr" (=>eth0), - "eth1addr" (=>eth1), "eth2addr", ... + ver - Contains the U-Boot version string as printed + with the "version" command. This variable is + readonly (see CONFIG_VERSION_VARIABLE). - If the network interface stores some valid MAC address (for instance - in SROM), this is used as default address if there is NO correspon- - ding setting in the environment; if the corresponding environment - variable is set, this overrides the settings in the card; that means: - o If the SROM has a valid MAC address, and there is no address in the - environment, the SROM's address is used. +Please note that changes to some configuration parameters may take +only effect after the next boot (yes, that's just like Windoze :-). - 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. +Command Line Parsing: +===================== - 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. +There are two different command line parsers available with U-Boot: +the old "simple" one, and the much more powerful "hush" shell: - o If neither SROM nor the environment contain a MAC address, an error - is raised. +Old, simple command line parser: +-------------------------------- +- supports environment variables (through setenv / saveenv commands) +- several commands on one line, separated by ';' +- variable substitution using "... $(name) ..." syntax +- special characters ('$', ';') can be escaped by prefixing with '\', + for example: + setenv bootcmd bootm \$(address) +- You can also escape text by enclosing in single apostrophes, for example: + setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off' - Image Formats: - ============== +Hush shell: +----------- - 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: +- 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 - * 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 +General rules: +-------------- - 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. +(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. - Linux Support: - ============== +Note for Redundant Ethernet Interfaces: +======================================= - 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. +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: - 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: +Network interfaces are numbered eth0, eth1, eth2, ... Corresponding +MAC addresses can be stored in the environment as "ethaddr" (=>eth0), +"eth1addr" (=>eth1), "eth2addr", ... - - the same features can be used for other OS or standalone - applications (for instance: using compressed images to reduce the - Flash memory footprint) +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: - - it becomes much easier to port new Linux kernel versions because - lots of low-level, hardware dependent stuff are done by U-Boot +o If the SROM has a valid MAC address, and there is no address in the + environment, the SROM's address is used. - - 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 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. - Linux HOWTO: - ============ +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. - Porting Linux to U-Boot based systems: - --------------------------------------- +o If neither SROM nor the environment contain a MAC address, an error + is raised. - 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 :-). - But now you can ignore ALL boot loader code (in arch/ppc/mbxboot). +Image Formats: +============== - Just make sure your machine specific header file (for instance - include/asm-ppc/tqm8xx.h) includes the same definition of the Board - Information structure as we define in include/u-boot.h, and make - sure that your definition of IMAP_ADDR uses the same value as your - U-Boot configuration in CFG_IMMR. +The "boot" commands of this monitor operate on "image" files which +can be basicly anything, preceeded by a special header; see the +definitions in include/image.h for details; basicly, the header +defines the following image properties: +* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, + 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, + LynxOS, pSOS, QNX, 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 - Configuring the Linux kernel: - ----------------------------- +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. - No specific requirements for U-Boot. Make sure you have some root - device (initial ramdisk, NFS) for your target system. +Linux Support: +============== - Building a Linux Image: - ----------------------- +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. - 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. +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: - Example: +- the same features can be used for other OS or standalone + applications (for instance: using compressed images to reduce the + Flash memory footprint) - make TQM850L_config - make oldconfig - make dep - make uImage +- it becomes much easier to port new Linux kernel versions because + lots of low-level, hardware dependent stuff are done by U-Boot - 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: +- 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. - * 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: +Linux HOWTO: +============ - mkimage -A ppc -O linux -T kernel -C gzip \ - -a 0 -e 0 -n "Linux Kernel Image" \ - -d linux.bin.gz uImage +Porting Linux to U-Boot based systems: +--------------------------------------- +U-Boot cannot save you from doing all the necessary modifications to +configure the Linux device drivers for use with your target hardware +(no, we don't intend to provide a full virtual machine interface to +Linux :-). - 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. +But now you can ignore ALL boot loader code (in arch/ppc/mbxboot). - "mkimage" can be called in two ways: to verify existing images and - print the header information, or to build new images. +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. - 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 +Configuring the Linux kernel: +----------------------------- - The second form (with "-d" option) is used to build a U-Boot image - from a "data file" which is used as image payload: +No specific requirements for U-Boot. Make sure you have some root +device (initial ramdisk, NFS) for your target system. - 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 use the same load address (0x00000000), - but the entry point address depends on the kernel version: +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 - - 2.2.x kernels have the entry point at 0x0000000C, - - 2.3.x and later kernels have the entry point at 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# + +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] = "" + 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 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" + 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: +---------------------- - 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] = "" - 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 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" - 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: - ----------------- +Coding Standards: +----------------- - All contributions to U-Boot should conform to the Linux kernel - coding style; see the file "Documentation/CodingStyle" in your Linux - kernel source directory. +All contributions to U-Boot should conform to the Linux kernel +coding style; see the file "Documentation/CodingStyle" in your Linux +kernel source directory. - Please note that U-Boot is implemented in C (and to some small parts - in Assembler); no C++ is used, so please do not use C++ style - comments (//) in your code. +Please note that U-Boot is implemented in C (and to some small parts +in Assembler); no C++ is used, so please do not use C++ style +comments (//) in your code. - Please also stick to the following formatting rules: - - remove any trailing white space - - use TAB characters for indentation, not spaces - - make sure NOT to use DOS '\r\n' line feeds - - do not add more than 2 empty lines to source files - - do not add trailing empty lines to source files +Please also stick to the following formatting rules: +- remove any trailing white space +- use TAB characters for indentation, not spaces +- make sure NOT to use DOS '\r\n' line feeds +- do not add more than 2 empty lines to source files +- do not add trailing empty lines to source files - Submissions which do not conform to the standards may be returned - with a request to reformat the changes. +Submissions which do not conform to the standards may be returned +with a request to reformat the changes. - Submitting Patches: - ------------------- +Submitting Patches: +------------------- - Since the number of patches for U-Boot is growing, we need to - establish some rules. Submissions which do not conform to these rules - may be rejected, even when they contain important and valuable stuff. +Since the number of patches for U-Boot is growing, we need to +establish some rules. Submissions which do not conform to these rules +may be rejected, even when they contain important and valuable stuff. - When you send a patch, please include the following information with - it: +When you send a patch, please include the following information with +it: - * For bug fixes: a description of the bug and how your patch fixes - this bug. Please try to include a way of demonstrating that the - patch actually fixes something. +* For bug fixes: a description of the bug and how your patch fixes + this bug. Please try to include a way of demonstrating that the + patch actually fixes something. - * For new features: a description of the feature and your - implementation. +* For new features: a description of the feature and your + implementation. - * A CHANGELOG entry as plaintext (separate from the patch) +* A CHANGELOG entry as plaintext (separate from the patch) - * For major contributions, your entry to the CREDITS file +* For major contributions, your entry to the CREDITS file - * When you add support for a new board, don't forget to add this - board to the MAKEALL script, too. +* When you add support for a new board, don't forget to add this + board to the MAKEALL script, too. - * If your patch adds new configuration options, don't forget to - document these in the README file. +* If your patch adds new configuration options, don't forget to + document these in the README file. - * The patch itself. If you are accessing the CVS repository use "cvs - update; cvs diff -puRN"; else, use "diff -purN OLD NEW". If your - version of diff does not support these options, then get the latest - version of GNU diff. +* The patch itself. If you are accessing the CVS repository use "cvs + update; cvs diff -puRN"; else, use "diff -purN OLD NEW". If your + version of diff does not support these options, then get the latest + version of GNU diff. - The current directory when running this command shall be the top - level directory of the U-Boot source tree, or it's parent directory - (i. e. please make sure that your patch includes sufficient - directory information for the affected files). + The current directory when running this command shall be the top + level directory of the U-Boot source tree, or it's parent directory + (i. e. please make sure that your patch includes sufficient + directory information for the affected files). - We accept patches as plain text, MIME attachments or as uuencoded - gzipped text. + We accept patches as plain text, MIME attachments or as uuencoded + gzipped text. - * If one logical set of modifications affects or creates several - files, all these changes shall be submitted in a SINGLE patch file. +* If one logical set of modifications affects or creates several + files, all these changes shall be submitted in a SINGLE patch file. - * Changesets that contain different, unrelated modifications shall be - submitted as SEPARATE patches, one patch per changeset. +* Changesets that contain different, unrelated modifications shall be + submitted as SEPARATE patches, one patch per changeset. - Notes: +Notes: - * Before sending the patch, run the MAKEALL script on your patched - source tree and make sure that no errors or warnings are reported - for any of the boards. +* Before sending the patch, run the MAKEALL script on your patched + source tree and make sure that no errors or warnings are reported + for any of the boards. - * Keep your modifications to the necessary minimum: A patch - containing several unrelated changes or arbitrary reformats will be - returned with a request to re-formatting / split it. +* Keep your modifications to the necessary minimum: A patch + containing several unrelated changes or arbitrary reformats will be + returned with a request to re-formatting / split it. - * If you modify existing code, make sure that your new code does not - add to the memory footprint of the code ;-) Small is beautiful! - When adding new features, these should compile conditionally only - (using #ifdef), and the resulting code with the new feature - disabled must not need more memory than the old code without your - modification. +* If you modify existing code, make sure that your new code does not + add to the memory footprint of the code ;-) Small is beautiful! + When adding new features, these should compile conditionally only + (using #ifdef), and the resulting code with the new feature + disabled must not need more memory than the old code without your + modification.