X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=README;h=df2c29531e6033e914b151fcc6a967de1227156c;hb=7abf0c5886c395a3cc7e11f191d67be9a964a1bf;hp=6a011cb38c87dca00c02ea72bdcdc38d384fa34f;hpb=43d9616cffb4a130e1620e3e33fc9bc1bcabe399;p=platform%2Fkernel%2Fu-boot.git diff --git a/README b/README index 6a011cb..df2c295 100644 --- a/README +++ b/README @@ -1,5 +1,5 @@ # -# (C) Copyright 2000 - 2002 +# (C) Copyright 2000 - 2004 # Wolfgang Denk, DENX Software Engineering, wd@denx.de. # # See file CREDITS for list of people who contributed to this @@ -119,114 +119,48 @@ U-Boot will always have a patchlevel of "0". Directory Hierarchy: ==================== -- board Board dependend files -- common Misc architecture independend functions +- board Board dependent files +- common Misc architecture independent functions - cpu CPU specific files + - 74xx_7xx Files specific to Motorola MPC74xx and 7xx CPUs + - arm720t Files specific to ARM 720 CPUs + - arm920t Files specific to ARM 920 CPUs + - arm925t Files specific to ARM 925 CPUs + - arm926ejs Files specific to ARM 926 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 + - 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 + - nios Files specific to Altera NIOS CPUs + - ppc4xx Files specific to IBM PowerPC 4xx CPUs + - pxa Files specific to Intel XScale PXA CPUs + - s3c44b0 Files specific to Samsung S3C44B0 CPUs + - sa1100 Files specific to Intel StrongARM SA1100 CPUs - disk Code for disk drive partition handling - doc Documentation (don't expect too much) -- drivers Common used device drivers +- drivers Commonly used device drivers - dtt Digital Thermometer and Thermostat drivers - examples Example code for standalone applications, etc. - include Header Files -- disk Harddisk interface code +- lib_arm Files generic to ARM architecture +- lib_generic Files generic to all architectures +- lib_i386 Files generic to i386 architecture +- lib_m68k Files generic to m68k architecture +- lib_mips Files generic to MIPS architecture +- lib_nios Files generic to NIOS architecture +- lib_ppc Files generic to PowerPC architecture - net Networking code -- ppc Files generic to PowerPC architecture - post Power On Self Test -- post/arch Symlink to architecture specific Power On Self Test -- post/arch-ppc PowerPC architecture specific Power On Self Test -- post/cpu/mpc8260 MPC8260 CPU specific Power On Self Test -- post/cpu/mpc8xx MPC8xx CPU specific Power On Self Test - rtc Real Time Clock drivers - tools Tools to build S-Record or U-Boot images, etc. -- cpu/74xx_7xx Files specific to Motorola MPC74xx and 7xx CPUs -- cpu/mpc8xx Files specific to Motorola MPC8xx CPUs -- cpu/mpc824x Files specific to Motorola MPC824x CPUs -- cpu/mpc8260 Files specific to Motorola MPC8260 CPU -- cpu/ppc4xx Files specific to IBM 4xx CPUs - -- board/RPXClassic - Files specific to RPXClassic boards -- board/RPXlite Files specific to RPXlite boards -- board/c2mon Files specific to c2mon boards -- board/cogent Files specific to Cogent boards - (need further configuration) - Files specific to CPCIISER4 boards -- board/cpu86 Files specific to CPU86 boards -- board/cray/ Files specific to boards manufactured by Cray -- board/cray/L1 Files specific to L1 boards -- board/cu824 Files specific to CU824 boards -- board/ebony Files specific to IBM Ebony board -- board/eric Files specific to ERIC boards -- board/esd/ Files specific to boards manufactured by ESD -- board/esd/adciop Files specific to ADCIOP boards -- board/esd/ar405 Files specific to AR405 boards -- board/esd/canbt Files specific to CANBT boards -- board/esd/cpci405 Files specific to CPCI405 boards -- board/esd/cpciiser4 Files specific to CPCIISER4 boards -- board/esd/common Common files for ESD boards -- board/esd/dasa_sim Files specific to DASA_SIM boards -- board/esd/du405 Files specific to DU405 boards -- board/esd/ocrtc Files specific to OCRTC boards -- board/esd/pci405 Files specific to PCI405 boards -- board/esteem192e - Files specific to ESTEEM192E boards -- board/etx094 Files specific to ETX_094 boards -- board/evb64260 - Files specific to EVB64260 boards -- board/fads Files specific to FADS boards -- board/flagadm Files specific to FLAGADM boards -- board/gen860t Files specific to GEN860T boards -- board/genietv Files specific to GENIETV boards -- board/gth Files specific to GTH boards -- board/hermes Files specific to HERMES boards -- board/hymod Files specific to HYMOD boards -- board/icu862 Files specific to ICU862 boards -- board/ip860 Files specific to IP860 boards -- board/iphase4539 - Files specific to Interphase4539 boards -- board/ivm Files specific to IVMS8/IVML24 boards -- board/lantec Files specific to LANTEC boards -- board/lwmon Files specific to LWMON boards -- board/mbx8xx Files specific to MBX boards -- board/mpc8260ads - Files specific to MMPC8260ADS boards -- board/mpl/ Files specific to boards manufactured by MPL -- board/mpl/common Common files for MPL boards -- board/mpl/pip405 Files specific to PIP405 boards -- board/mpl/mip405 Files specific to MIP405 boards -- board/musenki Files specific to MUSEKNI boards -- board/mvs1 Files specific to MVS1 boards -- board/nx823 Files specific to NX823 boards -- board/oxc Files specific to OXC boards -- board/pcippc2 Files specific to PCIPPC2/PCIPPC6 boards -- board/pm826 Files specific to PM826 boards -- board/ppmc8260 - Files specific to PPMC8260 boards -- board/rpxsuper - Files specific to RPXsuper boards -- board/rsdproto - Files specific to RSDproto boards -- board/sandpoint - Files specific to Sandpoint boards -- board/sbc8260 Files specific to SBC8260 boards -- board/sacsng Files specific to SACSng boards -- board/siemens Files specific to boards manufactured by Siemens AG -- board/siemens/CCM Files specific to CCM boards -- board/siemens/IAD210 Files specific to IAD210 boards -- board/siemens/SCM Files specific to SCM boards -- board/siemens/pcu_e Files specific to PCU_E boards -- board/sixnet Files specific to SIXNET boards -- board/spd8xx Files specific to SPD8xxTS boards -- board/tqm8260 Files specific to TQM8260 boards -- board/tqm8xx Files specific to TQM8xxL boards -- board/w7o Files specific to W7O boards -- board/walnut405 - Files specific to Walnut405 boards -- board/westel/ Files specific to boards manufactured by Westel Wireless -- board/westel/amx860 Files specific to AMX860 boards -- board/utx8245 Files specific to UTX8245 boards - Software Configuration: ======================= @@ -290,11 +224,15 @@ The following options need to be configured: PowerPC based CPUs: ------------------- CONFIG_MPC823, CONFIG_MPC850, CONFIG_MPC855, CONFIG_MPC860 + or CONFIG_MPC5xx or CONFIG_MPC824X, CONFIG_MPC8260 + or CONFIG_MPC85xx or CONFIG_IOP480 or CONFIG_405GP + or CONFIG_405EP or CONFIG_440 or CONFIG_MPC74xx + or CONFIG_750FX ARM based CPUs: --------------- @@ -302,51 +240,66 @@ The following options need to be configured: CONFIG_ARM7 CONFIG_PXA250 + MicroBlaze based CPUs: + ---------------------- + CONFIG_MICROBLZE + - Board Type: Define exactly one of PowerPC based boards: --------------------- - CONFIG_ADCIOP, CONFIG_ICU862 CONFIG_RPXsuper, - CONFIG_ADS860, CONFIG_IP860, CONFIG_SM850, - CONFIG_AMX860, CONFIG_IPHASE4539, CONFIG_SPD823TS, - CONFIG_AR405, CONFIG_IVML24, CONFIG_SXNI855T, - CONFIG_BAB7xx, CONFIG_IVML24_128, CONFIG_Sandpoint8240, - CONFIG_CANBT, CONFIG_IVML24_256, CONFIG_Sandpoint8245, - CONFIG_CCM, CONFIG_IVMS8, CONFIG_TQM823L, - CONFIG_CPCI405, CONFIG_IVMS8_128, CONFIG_TQM850L, - CONFIG_CPCI4052, CONFIG_IVMS8_256, CONFIG_TQM855L, - CONFIG_CPCIISER4, CONFIG_LANTEC, CONFIG_TQM860L, - CONFIG_CPU86, CONFIG_MBX, CONFIG_TQM8260, - CONFIG_CRAYL1, CONFIG_MBX860T, CONFIG_TTTech, - CONFIG_CU824, CONFIG_MHPC, CONFIG_UTX8245, - CONFIG_DASA_SIM, CONFIG_MIP405, CONFIG_W7OLMC, - CONFIG_DU405, CONFIG_MOUSSE, CONFIG_W7OLMG, - CONFIG_ELPPC, CONFIG_MPC8260ADS, CONFIG_WALNUT405, - CONFIG_ERIC, CONFIG_MUSENKI, CONFIG_ZUMA, - CONFIG_ESTEEM192E, CONFIG_MVS1, CONFIG_c2mon, - CONFIG_ETX094, CONFIG_NX823, CONFIG_cogent_mpc8260, - CONFIG_EVB64260, CONFIG_OCRTC, CONFIG_cogent_mpc8xx, - CONFIG_FADS823, CONFIG_ORSG, CONFIG_ep8260, - CONFIG_FADS850SAR, CONFIG_OXC, CONFIG_gw8260, - CONFIG_FADS860T, CONFIG_PCI405, CONFIG_hermes, - CONFIG_FLAGADM, CONFIG_PCIPPC2, CONFIG_hymod, - CONFIG_FPS850L, CONFIG_PCIPPC6, CONFIG_lwmon, - CONFIG_GEN860T, CONFIG_PIP405, CONFIG_pcu_e, - CONFIG_GENIETV, CONFIG_PM826, CONFIG_ppmc8260, - CONFIG_GTH, CONFIG_RPXClassic, CONFIG_rsdproto, - CONFIG_IAD210, CONFIG_RPXlite, CONFIG_sbc8260, - CONFIG_EBONY, CONFIG_sacsng, CONFIG_FPS860L, - CONFIG_V37 + CONFIG_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_STXGP3, CONFIG_SXNI855T, CONFIG_TQM823L, + CONFIG_TQM8260, CONFIG_TQM850L, CONFIG_TQM855L, + CONFIG_TQM860L, CONFIG_TTTech, CONFIG_UTX8245, + CONFIG_V37, CONFIG_W7OLMC, CONFIG_W7OLMG, + CONFIG_WALNUT405, CONFIG_ZPC1900, CONFIG_ZUMA, ARM based boards: ----------------- - CONFIG_HHP_CRADLE, CONFIG_DNP1110, CONFIG_EP7312, - CONFIG_IMPA7, CONFIG_LART, CONFIG_LUBBOCK, - CONFIG_SHANNON, CONFIG_SMDK2400, CONFIG_SMDK2410, - CONFIG_TRAB + 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, + + MicroBlaze based boards: + ------------------------ + + CONFIG_SUZAKU - CPU Module Type: (if CONFIG_COGENT is defined) @@ -370,16 +323,41 @@ The following options need to be configured: the lcd display every second with a "rotator" |\-/|\-/ +- Board flavour: (if CONFIG_MPC8260ADS is defined) + CONFIG_ADSTYPE + Possible values are: + CFG_8260ADS - original MPC8260ADS + CFG_8266ADS - MPC8266ADS + CFG_PQ2FADS - PQ2FADS-ZU or PQ2FADS-VR + CFG_8272ADS - MPC8272ADS + - MPC824X Family Member (if CONFIG_MPC824X is defined) - Define exactly one of - CONFIG_MPC8240, CONFIG_MPC8245 + Define exactly one of + CONFIG_MPC8240, CONFIG_MPC8245 -- 8xx CPU Options: (if using an 8xx cpu) +- 8xx CPU Options: (if using an MPC8xx cpu) Define one or more of - CONFIG_8xx_GCLK_FREQ - if get_gclk_freq() can not work e.g. - no 32KHz reference PIT/RTC clock - -- Clock Interface: + CONFIG_8xx_GCLK_FREQ - if get_gclk_freq() cannot work + e.g. if there is no 32KHz + reference PIT/RTC clock + +- 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 + See doc/README.MPC866 + + CFG_MEASURE_CPUCLK + + Define this to measure the actual CPU clock instead + of relying on the correctness of the 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), + +- Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ U-Boot stores all clock information in Hz @@ -389,11 +367,16 @@ The following options need to be configured: "clocks_in_mhz" can be defined so that U-Boot converts clock data to MHZ before passing it to the Linux kernel. - When CONFIG_CLOCKS_IN_MHZ is defined, a definition of "clocks_in_mhz=1" is automatically included in the default environment. + CONFIG_MEMSIZE_IN_BYTES [relevant for MIPS only] + + When transfering memsize parameter to linux, some versions + expect it to be in bytes, others in MB. + Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes. + - Console Interface: Depending on board, define exactly one serial port (like CONFIG_8xx_CONS_SMC1, CONFIG_8xx_CONS_SMC2, @@ -416,11 +399,11 @@ The following options need to be configured: bit-blit (cf. smiLynxEM) VIDEO_VISIBLE_COLS visible pixel columns (cols=pitch) - VIDEO_VISIBLE_ROWS visible pixel rows - VIDEO_PIXEL_SIZE bytes per pixel + VIDEO_VISIBLE_ROWS visible pixel rows + VIDEO_PIXEL_SIZE bytes per pixel VIDEO_DATA_FORMAT graphic data format (0-5, cf. cfb_console.c) - VIDEO_FB_ADRS framebuffer address + VIDEO_FB_ADRS framebuffer address VIDEO_KBD_INIT_FCT keyboard int fct (i.e. i8042_kbd_init()) VIDEO_TSTC_FCT test char fct @@ -447,10 +430,16 @@ The following options need to be configured: default i/o. Serial console can be forced with environment 'console=serial'. + When CONFIG_SILENT_CONSOLE is defined, all console + messages (by U-Boot and Linux!) can be silenced with + the "silent" environment variable. See + doc/README.silent for more information. + - Console Baudrate: CONFIG_BAUDRATE - in bps Select one of the baudrates listed in CFG_BAUDRATE_TABLE, see below. + CFG_BRGCLK_PRESCALE, baudrate prescale - Interrupt driven serial port input: CONFIG_SERIAL_SOFTWARE_FIFO @@ -461,8 +450,15 @@ The following options need to be configured: (RTS/CTS) and UART's built-in FIFO. Set the number of bytes the interrupt driven input buffer should have. - Set to 0 to disable this feature (this is the default). - This will also disable hardware handshake. + Leave undefined to disable this feature, including + disable the buffer and hardware handshake. + +- Console UART Number: + CONFIG_UART1_CONSOLE + + IBM PPC4xx only. + If defined internal UART1 (and not UART0) is used + as default U-Boot console. - Boot Delay: CONFIG_BOOTDELAY - in seconds Delay before automatically booting the default image; @@ -540,42 +536,61 @@ The following options need to be configured: #define enables commands: ------------------------- CFG_CMD_ASKENV * ask for env variable + CFG_CMD_AUTOSCRIPT Autoscript Support CFG_CMD_BDI bdinfo CFG_CMD_BEDBUG Include BedBug Debugger + CFG_CMD_BMP * BMP support CFG_CMD_BOOTD bootd CFG_CMD_CACHE icache, dcache CFG_CMD_CONSOLE coninfo CFG_CMD_DATE * support for RTC, date/time... CFG_CMD_DHCP DHCP support + CFG_CMD_DIAG * Diagnostics + CFG_CMD_DOC * Disk-On-Chip Support + CFG_CMD_DTT Digital Therm and Thermostat CFG_CMD_ECHO * echo arguments CFG_CMD_EEPROM * EEPROM read/write support CFG_CMD_ELF bootelf, bootvx CFG_CMD_ENV saveenv CFG_CMD_FDC * Floppy Disk Support + CFG_CMD_FAT FAT partition support CFG_CMD_FDOS * Dos diskette Support CFG_CMD_FLASH flinfo, erase, protect CFG_CMD_FPGA FPGA device initialization support + CFG_CMD_HWFLOW * RTS/CTS hw flow control CFG_CMD_I2C * I2C serial bus support CFG_CMD_IDE * IDE harddisk support CFG_CMD_IMI iminfo + 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_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 + CFG_CMD_MISC Misc functions like sleep etc + CFG_CMD_MMC MMC memory mapped support CFG_CMD_MII MII utility commands + CFG_CMD_NAND * NAND support CFG_CMD_NET bootp, tftpboot, rarpboot CFG_CMD_PCI * pciinfo CFG_CMD_PCMCIA * PCMCIA support + CFG_CMD_PING * send ICMP ECHO_REQUEST to network host + 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_SCSI * SCSI Support + CFG_CMD_SDRAM * print SDRAM configuration information CFG_CMD_SETGETDCR Support for DCR Register access (4xx only) CFG_CMD_SPI * SPI serial bus support CFG_CMD_USB * USB support + CFG_CMD_VFD * VFD support (TRAB) CFG_CMD_BSP * Board SPecific functions + CFG_CMD_CDP * Cisco Discover Protocol support ----------------------------------------------- CFG_CMD_ALL all @@ -610,11 +625,18 @@ The following options need to be configured: - Watchdog: CONFIG_WATCHDOG If this variable is defined, it enables watchdog - support. There must support in the platform specific + support. There must be support in the platform specific code for a watchdog. For the 8xx and 8260 CPUs, the SIU Watchdog feature is enabled in the SYPCR register. +- U-Boot Version: + CONFIG_VERSION_VARIABLE + If this variable is defined, an environment variable + named "ver" is created by U-Boot showing the U-Boot + version as printed by the "version" command. + This variable is readonly. + - Real-Time Clock: When CFG_CMD_DATE is selected, the type of the RTC @@ -624,7 +646,13 @@ The following options need to be configured: CONFIG_RTC_MPC8xx - use internal RTC of MPC8xx CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC CONFIG_RTC_MC146818 - use MC146818 RTC + CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC + CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC + CONFIG_RTC_DS164x - use Dallas DS164x RTC + + Note that if the RTC uses I2C, then the I2C interface + must also be configured. See I2C Support, below. - Timestamp Support: @@ -642,16 +670,31 @@ The following options need to be configured: one partition type as well. - IDE Reset method: - CONFIG_IDE_RESET_ROUTINE + CONFIG_IDE_RESET_ROUTINE - this is defined in several + board configurations files but used nowhere! - Set this to define that instead of a reset Pin, the - routine ide_set_reset(int idereset) will be used. + CONFIG_IDE_RESET - is this is defined, IDE Reset will + be performed by calling the function + ide_set_reset(int reset) + which has to be defined in a board specific file - ATAPI Support: CONFIG_ATAPI Set this to enable ATAPI support. +- LBA48 Support + CONFIG_LBA48 + + Set this to enable support for disks larger than 137GB + Also look at CFG_64BIT_LBA ,CFG_64BIT_VSPRINTF and CFG_64BIT_STRTOUL + Whithout these , LBA48 support uses 32bit variables and will 'only' + support disks up to 2.1TB. + + CFG_64BIT_LBA: + When enabled, makes the IDE subsystem use 64bit sector addresses. + Default is 32bit. + - SCSI Support: At the moment only there is only support for the SYM53C8XX SCSI controller; define @@ -665,6 +708,9 @@ The following options need to be configured: CFG_SCSI_SYM53C8XX_CCF to fix clock timing (80Mhz) - NETWORK Support (PCI): + CONFIG_E1000 + Support for Intel 8254x gigabit chips. + CONFIG_EEPRO100 Support for Intel 82557/82559/82559ER chips. Optional CONFIG_EEPRO100_SROM_WRITE enables eeprom @@ -681,9 +727,21 @@ The following options need to be configured: CONFIG_NS8382X Support for National dp8382[01] gigabit chips. +- NETWORK Support (other): + + CONFIG_DRIVER_LAN91C96 + Support for SMSC's LAN91C96 chips. + + CONFIG_LAN91C96_BASE + Define this to hold the physical address + of the LAN91C96's I/O space + + CONFIG_LAN91C96_USE_32_BIT + Define this to enable 32 bit addressing + - USB Support: At the moment only the UHCI host controller is - supported (PIP405, MIP405); define + 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 @@ -691,6 +749,21 @@ The following options need to be configured: Note: Supported are USB Keyboards and USB Floppy drives (TEAC FD-05PUB). + MPC5200 USB requires additional defines: + CONFIG_USB_CLOCK + for 528 MHz Clock: 0x0001bbbb + CONFIG_USB_CONFIG + for differential drivers: 0x00001000 + for single ended drivers: 0x00005000 + + +- MMC Support: + The MMC controller on the Intel PXA is supported. To + enable this define CONFIG_MMC. The MMC can be + accessed from the boot prompt by mapping the device + to physical memory similar to flash. Command line is + enabled with CFG_CMD_MMC. The MMC driver also works with + the FAT fs. This is enabled with CFG_CMD_FAT. - Keyboard Support: CONFIG_ISA_KEYBOARD @@ -715,22 +788,42 @@ The following options need to be configured: Enable Chips & Technologies 69000 Video chip CONFIG_VIDEO_SMI_LYNXEM - Enable Silicon Motion SMI 712/710/810 Video chip - Videomode are selected via environment 'videomode' with - standard LiLo mode numbers. - Following modes are supported (* is default): - - 800x600 1024x768 1280x1024 - 256 (8bit) 303* 305 307 - 65536 (16bit) 314 317 31a - 16,7 Mill (24bit) 315 318 31b + Enable Silicon Motion SMI 712/710/810 Video chip. The + video output is selected via environment 'videoout' + (1 = LCD and 2 = CRT). If videoout is undefined, CRT is + assumed. + + For the CT69000 and SMI_LYNXEM drivers, videomode is + 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): + + Colors 640x480 800x600 1024x768 1152x864 1280x1024 + -------------+--------------------------------------------- + 8 bits | 0x301* 0x303 0x305 0x161 0x307 + 15 bits | 0x310 0x313 0x316 0x162 0x319 + 16 bits | 0x311 0x314 0x317 0x163 0x31A + 24 bits | 0x312 0x315 0x318 ? 0x31B + -------------+--------------------------------------------- (i.e. setenv videomode 317; saveenv; reset;) - CONFIG_VIDEO_SED13806 + - "videomode=bootargs" all the video parameters are parsed + from the bootargs. (See drivers/videomodes.c) + + + CONFIG_VIDEO_SED13806 Enable Epson SED13806 driver. This driver supports 8bpp and 16bpp modes defined by CONFIG_VIDEO_SED13806_8BPP or CONFIG_VIDEO_SED13806_16BPP +- Keyboard Support: + CONFIG_KEYBOARD + + Define this to enable a custom keyboard support. + This simply calls drv_keyboard_init() which must be + defined in your board-specific files. + The only board using this so far is RBC823. - LCD Support: CONFIG_LCD @@ -738,13 +831,18 @@ The following options need to be configured: display); also select one of the supported displays by defining one of these: - CONFIG_NEC_NL6648AC33: + CONFIG_NEC_NL6448AC33: + + NEC NL6448AC33-18. Active, color, single scan. - NEC NL6648AC33-18. Active, color, single scan. + CONFIG_NEC_NL6448BC20 + + NEC NL6448BC20-08. 6.5", 640x480. + Active, color, single scan. - CONFIG_NEC_NL6648BC20 + CONFIG_NEC_NL6448BC33_54 - NEC NL6648BC20-08. 6.5", 640x480. + NEC NL6448BC33-54. 10.4", 640x480. Active, color, single scan. CONFIG_SHARP_16x9 @@ -775,6 +873,28 @@ The following options need to be configured: Normally display is black on white background; define CFG_WHITE_ON_BLACK to get it inverted. +- Splash Screen Support: CONFIG_SPLASH_SCREEN + + 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 + specified in "splashimage" is loaded instead. The + console is redirected to the "nulldev", too. This + allows for a "silent" boot where a splash screen is + loaded very quickly after power-on. + +- Compression support: + CONFIG_BZIP2 + + If this option is set, support for bzip2 compressed + images is included. If not, only uncompressed and gzip + compressed images are supported. + + NOTE: the bzip2 algorithm requires a lot of RAM, so + the malloc area (as defined by CFG_MALLOC_LEN) should + be at least 4MB. + - Ethernet address: CONFIG_ETHADDR CONFIG_ETH2ADDR @@ -816,6 +936,71 @@ The following options need to be configured: 4th and following BOOTP requests: delay 0 ... 8 sec +- DHCP Advanced Options: + CONFIG_BOOTP_MASK + + You can fine tune the DHCP functionality by adding + these flags to the CONFIG_BOOTP_MASK define: + + CONFIG_BOOTP_DNS2 - If a DHCP client requests the DNS + serverip from a DHCP server, it is possible that more + than one DNS serverip is offered to the client. + If CONFIG_BOOTP_DNS2 is enabled, the secondary DNS + serverip will be stored in the additional environment + variable "dnsip2". The first DNS serverip is always + stored in the variable "dnsip", when CONFIG_BOOTP_DNS + is added to the CONFIG_BOOTP_MASK. + + CONFIG_BOOTP_SEND_HOSTNAME - Some DHCP servers are capable + to do a dynamic update of a DNS server. To do this, they + need the hostname of the DHCP requester. + If CONFIG_BOOP_SEND_HOSTNAME is added to the + CONFIG_BOOTP_MASK, the content of the "hostname" + environment variable is passed as option 12 to + the DHCP server. + + - CDP Options: + CONFIG_CDP_DEVICE_ID + + The device id used in CDP trigger frames. + + CONFIG_CDP_DEVICE_ID_PREFIX + + A two character string which is prefixed to the MAC address + of the device. + + CONFIG_CDP_PORT_ID + + A printf format string which contains the ascii name of + the port. Normally is set to "eth%d" which sets + eth0 for the first ethernet, eth1 for the second etc. + + CONFIG_CDP_CAPABILITIES + + A 32bit integer which indicates the device capabilities; + 0x00000010 for a normal host which does not forwards. + + CONFIG_CDP_VERSION + + An ascii string containing the version of the software. + + CONFIG_CDP_PLATFORM + + An ascii string containing the name of the platform. + + CONFIG_CDP_TRIGGER + + A 32bit integer sent on the trigger. + + CONFIG_CDP_POWER_CONSUMPTION + + A 16bit integer containing the power consumption of the + device in .1 of milliwatts. + + CONFIG_CDP_APPLIANCE_VLAN_TYPE + + A byte containing the id of the VLAN. + - Status LED: CONFIG_STATUS_LED Several configurations allow to display the current @@ -835,29 +1020,48 @@ The following options need to be configured: - I2C Support: CONFIG_HARD_I2C | CONFIG_SOFT_I2C - Enables I2C serial bus commands. If this is selected, - either CONFIG_HARD_I2C or CONFIG_SOFT_I2C must be defined - to include the appropriate I2C driver. + These enable I2C serial bus commands. Defining either of + (but not both of) CONFIG_HARD_I2C or CONFIG_SOFT_I2C will + include the appropriate I2C driver for the selected cpu. - See also: common/cmd_i2c.c for a description of the + This will allow you to use i2c commands at the u-boot + command line (as long as you set CFG_CMD_I2C in + CONFIG_COMMANDS) and communicate with i2c based realtime + clock chips. See common/cmd_i2c.c for a description of the command line interface. + CONFIG_HARD_I2C selects the CPM hardware driver for I2C. + + CONFIG_SOFT_I2C configures u-boot to use a software (aka + bit-banging) driver instead of CPM or similar hardware + support for I2C. - CONFIG_HARD_I2C + There are several other quantities that must also be + defined when you define CONFIG_HARD_I2C or CONFIG_SOFT_I2C. - Selects the CPM hardware driver for I2C. + In both cases you will need to define CFG_I2C_SPEED + to be the frequency (in Hz) at which you wish your i2c bus + to run and CFG_I2C_SLAVE to be the address of this node (ie + the cpu's i2c node address). - CONFIG_SOFT_I2C + Now, the u-boot i2c code for the mpc8xx (cpu/mpc8xx/i2c.c) + sets the cpu up as a master node and so its address should + therefore be cleared to 0 (See, eg, MPC823e User's Manual + p.16-473). So, set CFG_I2C_SLAVE to 0. - Use software (aka bit-banging) driver instead of CPM - or similar hardware support for I2C. This is configured - via the following defines. + That's all that's required for CONFIG_HARD_I2C. + + If you use the software i2c interface (CONFIG_SOFT_I2C) + then the following macros need to be defined (examples are + from include/configs/lwmon.h): I2C_INIT - (Optional). Any commands necessary to enable I2C + (Optional). Any commands necessary to enable the I2C controller or configure ports. + eg: #define I2C_INIT (immr->im_cpm.cp_pbdir |= PB_SCL) + I2C_PORT (Only for MPC8260 CPU). The I/O port to use (the code @@ -870,32 +1074,60 @@ The following options need to be configured: (driven). If the data line is open collector, this define can be null. + eg: #define I2C_ACTIVE (immr->im_cpm.cp_pbdir |= PB_SDA) + I2C_TRISTATE The code necessary to make the I2C data line tri-stated (inactive). If the data line is open collector, this define can be null. + eg: #define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA) + I2C_READ Code that returns TRUE if the I2C data line is high, FALSE if it is low. + eg: #define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0) + I2C_SDA(bit) If is TRUE, sets the I2C data line high. If it is FALSE, it clears it (low). + eg: #define I2C_SDA(bit) \ + if(bit) immr->im_cpm.cp_pbdat |= PB_SDA; \ + else immr->im_cpm.cp_pbdat &= ~PB_SDA + I2C_SCL(bit) If is TRUE, sets the I2C clock line high. If it is FALSE, it clears it (low). + eg: #define I2C_SCL(bit) \ + if(bit) immr->im_cpm.cp_pbdat |= PB_SCL; \ + else immr->im_cpm.cp_pbdat &= ~PB_SCL + I2C_DELAY This delay is invoked four times per clock cycle so this controls the rate of data transfer. The data rate thus - is 1 / (I2C_DELAY * 4). + is 1 / (I2C_DELAY * 4). Often defined to be something + like: + + #define I2C_DELAY udelay(2) + + CFG_I2C_INIT_BOARD + + When a board is reset during an i2c bus transfer + chips might think that the current transfer is still + in progress. On some boards it is possible to access + the i2c SCLK line directly, either by using the + processor pin as a GPIO or by having a second pin + connected to the bus. If this option is defined a + custom i2c_init_board() routine in boards/xxx/board.c + is run early in the boot sequence. - SPI Support: CONFIG_SPI @@ -924,66 +1156,12 @@ The following options need to be configured: CONFIG_FPGA - Used to specify the types of FPGA devices. For - example, - #define CONFIG_FPGA CFG_XILINX_VIRTEX2 - - CFG_FPGA_PROG_FEEDBACK - - Enable printing of hash marks during FPGA - configuration. - - CFG_FPGA_CHECK_BUSY - - Enable checks on FPGA configuration interface busy - status by the configuration function. This option - will require a board or device specific function to - be written. - - CONFIG_FPGA_DELAY - - If defined, a function that provides delays in the - FPGA configuration driver. + Used to specify the types of FPGA devices. For example, + #define CONFIG_FPGA CFG_XILINX_VIRTEX2 - CFG_FPGA_CHECK_CTRLC - - Allow Control-C to interrupt FPGA configuration - - CFG_FPGA_CHECK_ERROR - - Check for configuration errors during FPGA bitfile - loading. For example, abort during Virtex II - configuration if the INIT_B line goes low (which - indicated a CRC error). - - CFG_FPGA_WAIT_INIT - - Maximum time to wait for the INIT_B line to deassert - after PROB_B has been deasserted during a Virtex II - FPGA configuration sequence. The default time is 500 mS. - - CFG_FPGA_WAIT_BUSY - - Maximum time to wait for BUSY to deassert during - Virtex II FPGA configuration. The default is 5 mS. + CFG_FPGA_PROG_FEEDBACK - CFG_FPGA_WAIT_CONFIG - - Time to wait after FPGA configuration. The default is - 200 mS. - -- FPGA Support: CONFIG_FPGA_COUNT - - Specify the number of FPGA devices to support. - - CONFIG_FPGA - - Used to specify the types of FPGA devices. For example, - #define CONFIG_FPGA CFG_XILINX_VIRTEX2 - - CFG_FPGA_PROG_FEEDBACK - - Enable printing of hash marks during FPGA configuration. + Enable printing of hash marks during FPGA configuration. CFG_FPGA_CHECK_BUSY @@ -1034,7 +1212,7 @@ The following options need to be configured: U-Boot considers the values of the environment variables "serial#" (Board Serial Number) and - "ethaddr" (Ethernet Address) to bb parameters that + "ethaddr" (Ethernet Address) to be parameters that are set once by the board vendor / manufacturer, and protects these variables from casual modification by the user. Once set, these variables are read-only, @@ -1043,7 +1221,7 @@ The following options need to be configured: If CONFIG_ENV_OVERWRITE is #defined in your config file, the write protection for vendor parameters is - completely disabled. Anybody can change or delte + completely disabled. Anybody can change or delete these parameters. Alternatively, if you #define _both_ CONFIG_ETHADDR @@ -1105,6 +1283,10 @@ The following options need to be configured: default value of 5 is used. - Command Interpreter: + CFG_AUTO_COMPLETE + + Enable auto completion of commands using TAB. + CFG_HUSH_PARSER Define this variable to enable the "hush" shell (from @@ -1128,10 +1310,10 @@ The following options need to be configured: In the current implementation, the local variables space and global environment variables space are separated. Local variables are those you define by - simply typing like `name=value'. To access a local + simply typing `name=value'. To access a local variable later on, you have write `$name' or - `${name}'; variable directly by typing say `$name' at - the command prompt. + `${name}'; to execute the contents of a variable + directly type `$name' at the command prompt. Global environment variables are those you use setenv/printenv to work with. To run a command stored @@ -1144,12 +1326,12 @@ The following options need to be configured: of the backslashes before semicolons and special symbols. -- Default Environment +- Default Environment: CONFIG_EXTRA_ENV_SETTINGS Define this to contain any number of null terminated strings (variable = value pairs) that will be part of - the default enviroment compiled into the boot image. + the default environment compiled into the boot image. For example, place something like this in your board's config file: @@ -1162,7 +1344,7 @@ The following options need to be configured: internal format how the environment is stored by the U-Boot code. This is NOT an official, exported interface! Although it is unlikely that this format - will change soon, but there is no guarantee either. + will change soon, there is no guarantee either. You better know what you are doing here. Note: overly (ab)use of the default environment is @@ -1170,7 +1352,28 @@ The following options need to be configured: the environment like the autoscript function or the boot command first. -- Show boot progress +- DataFlash Support: + CONFIG_HAS_DATAFLASH + + Defining this option enables DataFlash features and + allows to read/write in Dataflash via the standard + commands cp, md... + +- SystemACE Support: + CONFIG_SYSTEMACE + + Adding this option adds support for Xilinx SystemACE + chips attached via some sort of local bus. The address + of the chip must alsh be defined in the + CFG_SYSTEMACE_BASE macro. For example: + + #define CONFIG_SYSTEMACE + #define CFG_SYSTEMACE_BASE 0xf0000000 + + When SystemACE support is added, the "ace" device type + becomes available to the fat commands, i.e. fatls. + +- Show boot progress: CONFIG_SHOW_BOOT_PROGRESS Defining this option allows to add some board- @@ -1182,11 +1385,11 @@ The following options need to be configured: Arg Where When 1 common/cmd_bootm.c before attempting to boot an image - -1 common/cmd_bootm.c Image header has bad magic number + -1 common/cmd_bootm.c Image header has bad magic number 2 common/cmd_bootm.c Image header has correct magic number - -2 common/cmd_bootm.c Image header has bad checksum + -2 common/cmd_bootm.c Image header has bad checksum 3 common/cmd_bootm.c Image header has correct checksum - -3 common/cmd_bootm.c Image data has bad checksum + -3 common/cmd_bootm.c Image data has bad checksum 4 common/cmd_bootm.c Image data has correct checksum -4 common/cmd_bootm.c Image is for unsupported architecture 5 common/cmd_bootm.c Architecture check OK @@ -1199,10 +1402,10 @@ The following options need to be configured: 8 common/cmd_bootm.c Image Type check OK -9 common/cmd_bootm.c Unsupported OS (not Linux, BSD, VxWorks, QNX) 9 common/cmd_bootm.c Start initial ramdisk verification - -10 common/cmd_bootm.c Ramdisk header has bad magic number - -11 common/cmd_bootm.c Ramdisk header has bad checksum + -10 common/cmd_bootm.c Ramdisk header has bad magic number + -11 common/cmd_bootm.c Ramdisk header has bad checksum 10 common/cmd_bootm.c Ramdisk header is OK - -12 common/cmd_bootm.c Ramdisk data has bad checksum + -12 common/cmd_bootm.c Ramdisk data has bad checksum 11 common/cmd_bootm.c Ramdisk data has correct checksum 12 common/cmd_bootm.c Ramdisk verification complete, start loading -13 common/cmd_bootm.c Wrong Image Type (not PPC Linux Ramdisk) @@ -1210,6 +1413,10 @@ The following options need to be configured: 14 common/cmd_bootm.c No initial ramdisk, no multifile, continue. 15 common/cmd_bootm.c All preparation done, transferring control to OS + -30 lib_ppc/board.c Fatal error, hang the system + -31 post/post.c POST test failed, detected by post_output_backlog() + -32 post/post.c POST test failed, detected by post_run_single() + -1 common/cmd_doc.c Bad usage of "doc" command -1 common/cmd_doc.c No boot device -1 common/cmd_doc.c Unknown Chip ID on boot device @@ -1224,13 +1431,19 @@ The following options need to be configured: -1 common/cmd_ide.c Read Error on boot device -1 common/cmd_ide.c Image header has bad magic number - -1 common/cmd_nvedit.c Environment not changable, but has bad CRC + -1 common/cmd_nand.c Bad usage of "nand" command + -1 common/cmd_nand.c No boot device + -1 common/cmd_nand.c Unknown Chip ID on boot device + -1 common/cmd_nand.c Read Error on boot device + -1 common/cmd_nand.c Image header has bad magic number + + -1 common/env_common.c Environment has a bad CRC, using default Modem Support: -------------- -[so far only for SMDK2400 board] +[so far only for SMDK2400 and TRAB boards] - Modem support endable: CONFIG_MODEM_SUPPORT @@ -1244,6 +1457,19 @@ Modem Support: Enables debugging stuff (char screen[1024], dbg()) for modem support. Useful only with BDI2000. +- Interrupt support (PPC): + + There are common interrupt_init() and timer_interrupt() + for all PPC archs. interrupt_init() calls interrupt_init_cpu() + for cpu specific initialization. interrupt_init_cpu() + should set decrementer_count to appropriate value. If + cpu resets decrementer automatically after interrupt + (ppc4xx) it should set decrementer_count to zero. + timer_interrupt() calls timer_interrupt_cpu() for cpu + specific handling. If board has watchdog / status_led + / other_activity_monitor it works automatically from + general timer_interrupt(). + - General: In the target system modem support is enabled when a @@ -1262,8 +1488,6 @@ Modem Support: See also: doc/README.Modem - - Configuration Settings: ----------------------- @@ -1287,16 +1511,16 @@ Configuration Settings: List of legal baudrate settings for this board. - CFG_CONSOLE_INFO_QUIET - Suppress display of console information at boot. + Suppress display of console information at boot. - CFG_CONSOLE_IS_IN_ENV - If the board specific function - extern int overwrite_console (void); - returns 1, the stdin, stderr and stdout are switched to the + If the board specific function + extern int overwrite_console (void); + returns 1, the stdin, stderr and stdout are switched to the serial port, else the settings in the environment are used. - CFG_CONSOLE_OVERWRITE_ROUTINE - Enable the call to overwrite_console(). + Enable the call to overwrite_console(). - CFG_CONSOLE_ENV_OVERWRITE Enable overwrite of previous console environment settings. @@ -1306,7 +1530,11 @@ Configuration Settings: simple memory test. - CFG_ALT_MEMTEST: - Enable an alternate, more extensive memory test. + Enable an alternate, more extensive memory test. + +- CFG_MEMTEST_SCRATCH: + Scratch address used by the alternate memory test + You only need to set this if address zero isn't writeable - CFG_TFTP_LOADADDR: Default load address for network file downloads @@ -1331,7 +1559,10 @@ Configuration Settings: CFG_FLASH_BASE when booting from flash. - CFG_MONITOR_LEN: - Size of memory reserved for monitor code + Size of memory reserved for monitor code, used to + determine _at_compile_time_ (!) if the environment is + embedded within the U-Boot image, or in a separate + flash sector. - CFG_MALLOC_LEN: Size of DRAM reserved for malloc() use. @@ -1354,6 +1585,16 @@ Configuration Settings: - CFG_FLASH_WRITE_TOUT: Timeout for Flash write operations (in ms) +- CFG_FLASH_LOCK_TOUT + Timeout for Flash set sector lock bit operation (in ms) + +- CFG_FLASH_UNLOCK_TOUT + Timeout for Flash clear lock bits operation (in ms) + +- CFG_FLASH_PROTECTION + If defined, hardware flash sectors protection is used + instead of U-Boot software protection. + - CFG_DIRECT_FLASH_TFTP: Enable TFTP transfers directly to flash memory; @@ -1369,7 +1610,19 @@ Configuration Settings: - CFG_FLASH_CFI: Define if the flash driver uses extra elements in the - common flash structure for storing flash geometry + common flash structure for storing flash geometry. + +- CFG_FLASH_CFI_DRIVER + This option also enables the building of the cfi_flash driver + in the drivers directory + +- CFG_RX_ETH_BUFFER: + Defines the number of ethernet receive buffers. On some + ethernet controllers it is recommended to set this value + to 8 or even higher (EEPRO100 or 405 EMAC), since all + buffers can be full shortly after enabling the interface + on high ethernet traffic. + Defaults to 4 if not defined. The following definitions that deal with the placement and management of environment data (variable area); in general, we support the @@ -1437,7 +1690,7 @@ following configurations: These settings describe a second storage area used to hold a redundand copy of the environment data, so that there is - a valid backup copy in case there is a power failur during + a valid backup copy in case there is a power failure during a "saveenv" operation. BE CAREFUL! Any changes to the flash layout, and some changes to the @@ -1492,7 +1745,7 @@ to save the current settings. - CFG_EEPROM_PAGE_WRITE_DELAY_MS: If defined, the number of milliseconds to delay between - page writes. The default is zero milliseconds. + page writes. The default is zero milliseconds. - CFG_I2C_EEPROM_ADDR_LEN: The length in bytes of the EEPROM memory array address. Note @@ -1502,6 +1755,20 @@ to save the current settings. The size in bytes of the EEPROM device. +- CFG_ENV_IS_IN_DATAFLASH: + + Define this if you have a DataFlash memory device which you + want to use for the environment. + + - CFG_ENV_OFFSET: + - CFG_ENV_ADDR: + - CFG_ENV_SIZE: + + These three #defines specify the offset and size of the + environment area within the total memory of your DataFlash placed + at the specified address. + + - CFG_SPI_INIT_OFFSET Defines offset to the initial SPI buffer area in DPRAM. The @@ -1517,32 +1784,45 @@ has been relocated to RAM and a RAM copy of the environment has been created; also, when using EEPROM you will have to use getenv_r() until then to read environment variables. -The environment is now protected by a CRC32 checksum. Before the -monitor is relocated into RAM, as a result of a bad CRC you will be -working with the compiled-in default environment - *silently*!!! -[This is necessary, because the first environment variable we need is -the "baudrate" setting for the console - if we have a bad CRC, we -don't have any device yet where we could complain.] +The environment is protected by a CRC32 checksum. Before the monitor +is relocated into RAM, as a result of a bad CRC you will be working +with the compiled-in default environment - *silently*!!! [This is +necessary, because the first environment variable we need is the +"baudrate" setting for the console - if we have a bad CRC, we don't +have any device yet where we could complain.] Note: once the monitor has been relocated, then it will complain if the default environment is used; a new CRC is computed as soon as you -use the "setenv" command to modify / delete / add any environment -variable [even when you try to delete a non-existing variable!]. +use the "saveenv" command to store a valid environment. + +- CFG_FAULT_ECHO_LINK_DOWN: + Echo the inverted Ethernet link state to the fault LED. + + Note: If this option is active, then CFG_FAULT_MII_ADDR + also needs to be defined. -Note2: you must edit your u-boot.lds file to reflect this -configuration. +- CFG_FAULT_MII_ADDR: + MII address of the PHY to check for the Ethernet link state. +- CFG_64BIT_VSPRINTF: + Makes vsprintf (and all *printf functions) support printing + of 64bit values by using the L quantifier + +- CFG_64BIT_STRTOUL: + Adds simple_strtoull that returns a 64bit value Low Level (hardware related) configuration options: +--------------------------------------------------- - CFG_CACHELINE_SIZE: Cache Line Size of the CPU. - CFG_DEFAULT_IMMR: Default address of the IMMR after system reset. - Needed on some 8260 systems (MPC8260ADS and RPXsuper) - to be able to adjust the position of the IMMR - register after a reset. + + Needed on some 8260 systems (MPC8260ADS, PQ2FADS-ZU, + and RPXsuper) to be able to adjust the position of + the IMMR register after a reset. - Floppy Disk Support: CFG_FDC_DRIVE_NUMBER @@ -1576,7 +1856,7 @@ Low Level (hardware related) configuration options: - CFG_INIT_RAM_ADDR: - Start address of memory area tha can be used for + Start address of memory area that can be used for initial data and stack; please note that this must be writable memory that is working WITHOUT special initialization, i. e. you CANNOT use normal RAM which @@ -1589,16 +1869,16 @@ Low Level (hardware related) configuration options: - MPC824X: data cache - PPC4xx: data cache -- CFG_INIT_DATA_OFFSET: +- CFG_GBL_DATA_OFFSET: Offset of the initial data structure in the memory area defined by CFG_INIT_RAM_ADDR. Usually - CFG_INIT_DATA_OFFSET is chosen such that the initial + CFG_GBL_DATA_OFFSET is chosen such that the initial data is located at the end of the available space (sometimes written as (CFG_INIT_RAM_END - CFG_INIT_DATA_SIZE), and the initial stack is just below that area (growing from (CFG_INIT_RAM_ADDR + - CFG_INIT_DATA_OFFSET) downward. + CFG_GBL_DATA_OFFSET) downward. Note: On the MPC824X (or other systems that use the data @@ -1662,6 +1942,36 @@ Low Level (hardware related) configuration options: #define'd default value in commproc.h resp. cpm_8260.h. +- CFG_PCI_SLV_MEM_LOCAL, CFG_PCI_SLV_MEM_BUS, CFG_PICMR0_MASK_ATTRIB, + CFG_PCI_MSTR0_LOCAL, CFG_PCIMSK0_MASK, CFG_PCI_MSTR1_LOCAL, + CFG_PCIMSK1_MASK, CFG_PCI_MSTR_MEM_LOCAL, CFG_PCI_MSTR_MEM_BUS, + CFG_CPU_PCI_MEM_START, CFG_PCI_MSTR_MEM_SIZE, CFG_POCMR0_MASK_ATTRIB, + CFG_PCI_MSTR_MEMIO_LOCAL, CFG_PCI_MSTR_MEMIO_BUS, CPU_PCI_MEMIO_START, + CFG_PCI_MSTR_MEMIO_SIZE, CFG_POCMR1_MASK_ATTRIB, CFG_PCI_MSTR_IO_LOCAL, + CFG_PCI_MSTR_IO_BUS, CFG_CPU_PCI_IO_START, CFG_PCI_MSTR_IO_SIZE, + 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. + Building the Software: ====================== @@ -1680,7 +1990,7 @@ change it to: CROSS_COMPILE = ppc_4xx- -U-Boot is intended to be simple to build. After installing the +U-Boot is intended to be simple to build. After installing the sources you must configure U-Boot for one specific board type. This is done by typing: @@ -1689,1145 +1999,1275 @@ is done by typing: where "NAME_config" is the name of one of the existing configurations; the following names are supported: - ADCIOP_config GTH_config TQM850L_config - ADS860_config IP860_config TQM855L_config - AR405_config IVML24_config TQM860L_config - CANBT_config IVMS8_config WALNUT405_config - CPCI405_config LANTEC_config cogent_common_config - CPCIISER4_config MBX_config cogent_mpc8260_config - CU824_config MBX860T_config cogent_mpc8xx_config - ESTEEM192E_config RPXlite_config hermes_config - ETX094_config RPXsuper_config hymod_config - FADS823_config SM850_config lwmon_config - FADS850SAR_config SPD823TS_config pcu_e_config - FADS860T_config SXNI855T_config rsdproto_config - FPS850L_config Sandpoint8240_config sbc8260_config - GENIETV_config TQM823L_config PIP405_config - GEN860T_config EBONY_config FPS860L_config + 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 + stxgp3_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 + + 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. -Note: for some board special configuration names may exist; check if - additional information is available from the board vendor; for - instance, the TQM8xxL systems run normally at 50 MHz and use a - SCC for 10baseT ethernet; there are also systems with 80 MHz - CPU clock, and an optional Fast Ethernet module is available - for CPU's with FEC. You can select such additional "features" - when chosing the configuration, i. e. - - make TQM860L_config - - will configure for a plain TQM860L, i. e. 50MHz, no FEC - - make TQM860L_FEC_config - - will configure for a TQM860L at 50MHz with FEC for ethernet - - make TQM860L_80MHz_config - - will configure for a TQM860L at 80 MHz, with normal 10baseT - interface - - make TQM860L_FEC_80MHz_config - - will configure for a TQM860L at 80 MHz with FEC for ethernet - - make TQM823L_LCD_config - - will configure for a TQM823L with U-Boot console on LCD - - make TQM823L_LCD_80MHz_config - - will configure for a TQM823L at 80 MHz with U-Boot console on LCD - - etc. - - - -Finally, type "make all", and you should get some working U-Boot -images ready for downlod to / installation on your system: - -- "u-boot.bin" is a raw binary image -- "u-boot" is an image in ELF binary format -- "u-boot.srec" is in Motorola S-Record format - - -Please be aware that the Makefiles assume you are using GNU make, so -for instance on NetBSD you might need to use "gmake" instead of -native "make". - - -If the system board that you have is not listed, then you will need -to port U-Boot to your hardware platform. To do this, follow these -steps: - -1. Add a new configuration option for your board to the toplevel - "Makefile", using the existing entries as examples. -2. Create a new directory to hold your board specific code. Add any - files you need. -3. If you're porting U-Boot to a new CPU, then also create a new - directory to hold your CPU specific code. Add any files you need. -4. Run "make config_name" with your new name. -5. Type "make", and you should get a working "u-boot.srec" file - to be installed on your target system. - [Of course, this last step is much harder than it sounds.] - - -Testing of U-Boot Modifications, Ports to New Hardware, etc.: -============================================================== - -If you have modified U-Boot sources (for instance added a new board -or support for new devices, a new CPU, etc.) you are expected to -provide feedback to the other developers. The feedback normally takes -the form of a "patch", i. e. a context diff against a certain (latest -official or latest in CVS) version of U-Boot sources. - -But before you submit such a patch, please verify that your modifi- -cation did not break existing code. At least make sure that *ALL* of -the supported boards compile WITHOUT ANY compiler warnings. To do so, -just run the "MAKEALL" script, which will configure and build U-Boot -for ALL supported system. Be warned, this will take a while. You can -select which (cross) compiler to use py passing a `CROSS_COMPILE' -environment variable to the script, i. e. to use the cross tools from -MontaVista's Hard Hat Linux you can type - - CROSS_COMPILE=ppc_8xx- MAKEALL - -or to build on a native PowerPC system you can type - - CROSS_COMPILE=' ' MAKEALL - -See also "U-Boot Porting Guide" below. - - - -Monitor Commands - Overview: -============================ - -go - start application at address 'addr' -run - run commands in an environment variable -bootm - boot application image from memory -bootp - boot image via network using BootP/TFTP protocol -tftpboot- boot image via network using TFTP protocol - and env variables "ipaddr" and "serverip" - (and eventually "gatewayip") -rarpboot- boot image via network using RARP/TFTP protocol -diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd' -loads - load S-Record file over serial line -loadb - load binary file over serial line (kermit mode) -md - memory display -mm - memory modify (auto-incrementing) -nm - memory modify (constant address) -mw - memory write (fill) -cp - memory copy -cmp - memory compare -crc32 - checksum calculation -imd - i2c memory display -imm - i2c memory modify (auto-incrementing) -inm - i2c memory modify (constant address) -imw - i2c memory write (fill) -icrc32 - i2c checksum calculation -iprobe - probe to discover valid I2C chip addresses -iloop - infinite loop on address range -isdram - print SDRAM configuration information -sspi - SPI utility commands -base - print or set address offset -printenv- print environment variables -setenv - set environment variables -saveenv - save environment variables to persistent storage -protect - enable or disable FLASH write protection -erase - erase FLASH memory -flinfo - print FLASH memory information -bdinfo - print Board Info structure -iminfo - print header information for application image -coninfo - print console devices and informations -ide - IDE sub-system -loop - infinite loop on address range -mtest - simple RAM test -icache - enable or disable instruction cache -dcache - enable or disable data cache -reset - Perform RESET of the CPU -echo - echo args to console -version - print monitor version -help - print online help -? - alias for 'help' - - -Monitor Commands - Detailed Description: -======================================== - -TODO. - -For now: just type "help ". - - -Environment Variables: -====================== + ipaddr - IP address; needed for tftpboot command -U-Boot supports user configuration using Environment Variables which -can be made persistent by saving to Flash memory. + loadaddr - Default load address for commands like "bootp", + "rarpboot", "tftpboot", "loadb" or "diskboot" -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. + loads_echo - see CONFIG_LOADS_ECHO -Some configuration options can be set using Environment Variables: + serverip - TFTP server IP address; needed for tftpboot command - baudrate - see CONFIG_BAUDRATE + bootretry - see CONFIG_BOOT_RETRY_TIME - bootdelay - see CONFIG_BOOTDELAY + bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR - bootcmd - see CONFIG_BOOTCOMMAND + bootstopkey - see CONFIG_AUTOBOOT_STOP_STR - bootargs - Boot arguments when booting an RTOS image + ethprime - When CONFIG_NET_MULTI is enabled controls which + interface is used first. - bootfile - Name of the image to load with TFTP + ethact - When CONFIG_NET_MULTI is enabled controls which + interface is currently active. For example you + can do the following - 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 + => 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 - autostart - if set to "yes", an image loaded using the "bootp", - "rarpboot", "tftpboot" or "diskboot" commands will - be automatically started (by internally calling - "bootm") + netretry - When set to "no" each network operation will + either succeed or fail without retrying. + When set to "once" the network operation will + fail when all the available network interfaces + are tried once without success. + Useful on scripts which control the retry operation + themselves. - initrd_high - restrict positioning of initrd images: - If this variable is not set, initrd images will be - copied to the highest possible address in RAM; this - is usually what you want since it allows for - maximum initrd size. If for some reason you want to - make sure that the initrd image is loaded below the - CFG_BOOTMAPSZ limit, you can set this environment - variable to a value of "no" or "off" or "0". - Alternatively, you can set it to a maximum upper - address to use (U-Boot will still check that it - does not overwrite the U-Boot stack and data). + vlan - When set to a value < 4095 the traffic over + ethernet is encapsulated/received over 802.1q + VLAN tagged frames. - For instance, when you have a system with 16 MB - RAM, and want to reseve 4 MB from use by Linux, - you can do this by adding "mem=12M" to the value of - the "bootargs" variable. However, now you must make - sure, that the initrd image is placed in the first - 12 MB as well - this can be done with + The following environment variables may be used and automatically + updated by the network boot commands ("bootp" and "rarpboot"), + depending the information provided by your boot server: - setenv initrd_high 00c00000 + bootfile - see above + dnsip - IP address of your Domain Name Server + dnsip2 - IP address of your secondary Domain Name Server + gatewayip - IP address of the Gateway (Router) to use + hostname - Target hostname + ipaddr - see above + netmask - Subnet Mask + rootpath - Pathname of the root filesystem on the NFS server + serverip - see above - ipaddr - IP address; needed for tftpboot command - loadaddr - Default load address for commands like "bootp", - "rarpboot", "tftpboot" or "diskboot" + There are two special Environment Variables: - loads_echo - see CONFIG_LOADS_ECHO + serial# - contains hardware identification information such + as type string and/or serial number + ethaddr - Ethernet address - serverip - TFTP server IP address; needed for tftpboot command + 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. - bootretry - see CONFIG_BOOT_RETRY_TIME - bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR + Further special Environment Variables: - bootstopkey - see CONFIG_AUTOBOOT_STOP_STR + ver - Contains the U-Boot version string as printed + with the "version" command. This variable is + readonly (see CONFIG_VERSION_VARIABLE). -The following environment variables may be used and automatically -updated by the network boot commands ("bootp" and "rarpboot"), -depending the information provided by your boot server: + Please note that changes to some configuration parameters may take + only effect after the next boot (yes, that's just like Windoze :-). + - bootfile - see above - dnsip - IP address of your Domain Name Server - gatewayip - IP address of the Gateway (Router) to use - hostname - Target hostname - ipaddr - see above - netmask - Subnet Mask - rootpath - Pathname of the root filesystem on the NFS server - serverip - see above + Command Line Parsing: + ===================== + There are two different command line parsers available with U-Boot: + the old "simple" one, and the much more powerful "hush" shell: -There are two special Environment Variables: + Old, simple command line parser: + -------------------------------- - serial# - contains hardware identification information such - as type string and/or serial number - ethaddr - Ethernet address + - 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' -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. + Hush shell: + ----------- + - 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 -Please note that changes to some configuration parameters may take -only effect after the next boot (yes, that's just like Windoze :-). + General rules: + -------------- + (1) If a command line (or an environment variable executed by a "run" + command) contains several commands separated by semicolon, and + one of these commands fails, then the remaining commands will be + executed anyway. -Note for Redundant Ethernet Interfaces: -======================================= + (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. -Some boards come with redundand ethernet interfaces; U-Boot supports -such configurations and is capable of automatic selection of a -"working" interface when needed. MAC assignemnt works as follows: + Note for Redundant Ethernet Interfaces: + ======================================= -Network interfaces are numbered eth0, eth1, eth2, ... Corresponding -MAC addresses can be stored in the environment as "ethaddr" (=>eth0), -"eth1addr" (=>eth1), "eth2addr", ... + 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: -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: + Network interfaces are numbered eth0, eth1, eth2, ... Corresponding + MAC addresses can be stored in the environment as "ethaddr" (=>eth0), + "eth1addr" (=>eth1), "eth2addr", ... -o If the SROM has a valid MAC address, and there is no address in the - environment, the SROM's address is used. + 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 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 the SROM has a valid MAC address, and there is no address in the + environment, the SROM's address is used. -o If both the SROM and the environment contain a MAC address, and - both addresses are the same, this MAC address is used. + o If 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 the - addresses differ, the value from the environment is used and a - warning is printed. + o If both the SROM and the environment contain a MAC address, and + both addresses are the same, this MAC address is used. -o If neither SROM nor the environment contain a MAC address, an error - is raised. + o If both the SROM and the environment contain a MAC address, and the + addresses differ, the value from the environment is used and a + warning is printed. + o If neither SROM nor the environment contain a MAC address, an error + is raised. -Image Formats: -============== + Image Formats: + ============== -The "boot" commands of this monitor operate on "image" files which -can be basicly anything, preceeded by a special header; see the -definitions in include/image.h for details; basicly, the header -defines the following image properties: + The "boot" commands of this monitor operate on "image" files which + can be basicly anything, preceeded by a special header; see the + definitions in include/image.h for details; basicly, the header + defines the following image properties: -* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, - 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, - LynxOS, pSOS, QNX; - Currently supported: Linux, NetBSD, VxWorks, QNX). -* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, - IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; - Currently supported: PowerPC). -* Compression Type (Provisions for uncompressed, gzip, bzip2; - Currently supported: uncompressed, gzip). -* Load Address -* Entry Point -* Image Name -* Image Timestamp + * 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 -The header is marked by a special Magic Number, and both the header -and the data portions of the image are secured against corruption by -CRC32 checksums. + The header is marked by a special Magic Number, and both the header + and the data portions of the image are secured against corruption by + CRC32 checksums. -Linux Support: -============== + Linux Support: + ============== -Although U-Boot should support any OS or standalone application -easily, Linux has always been in the focus during the design of -U-Boot. + 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. -U-Boot includes many features that so far have been part of some -special "boot loader" code within the Linux kernel. Also, any -"initrd" images to be used are no longer part of one big Linux image; -instead, kernel and "initrd" are separate images. This implementation -serves serveral purposes: + U-Boot includes many features that so far have been part of some + special "boot loader" code within the Linux kernel. Also, any + "initrd" images to be used are no longer part of one big Linux image; + instead, kernel and "initrd" are separate images. This implementation + serves several purposes: -- the same features can be used for other OS or standalone - applications (for instance: using compressed images to reduce the - Flash memory footprint) + - the same features can be used for other OS or standalone + applications (for instance: using compressed images to reduce the + Flash memory footprint) -- it becomes much easier to port new Linux kernel versions because - lots of low-level, hardware dependend stuff are done by U-Boot + - it becomes much easier to port new Linux kernel versions because + lots of low-level, hardware dependent stuff are done by U-Boot -- 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. + - the same Linux kernel image can now be used with different "initrd" + images; of course this also means that different kernel images can + be run with the same "initrd". This makes testing easier (you don't + have to build a new "zImage.initrd" Linux image when you just + change a file in your "initrd"). Also, a field-upgrade of the + software is easier now. -Linux HOWTO: -============ + Linux HOWTO: + ============ -Porting Linux to U-Boot based systems: ---------------------------------------- + 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 :-). + 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). + But now you can ignore ALL boot loader code (in arch/ppc/mbxboot). -Just make sure your machine specific header file (for instance -include/asm-ppc/tqm8xx.h) includes the same definition of the Board -Information structure as we define in include/u-boot.h, and make -sure that your definition of IMAP_ADDR uses the same value as your -U-Boot configuration in CFG_IMMR. + 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. -Configuring the Linux kernel: ------------------------------ + Configuring the Linux kernel: + ----------------------------- -No specific requirements for U-Boot. Make sure you have some root -device (initial ramdisk, NFS) for your target system. + No specific requirements for U-Boot. Make sure you have some root + device (initial ramdisk, NFS) for your target system. -Building a Linux Image: ------------------------ + 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 + 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: -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: + make TQM850L_config + make oldconfig + make dep + make uImage - tools/mkimage -l image - -l ==> list image header information + 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 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' + * 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 -Right now, all Linux kernels use the same load address (0x00000000), -but the entry point address depends on the kernel version: - -- 2.2.x kernels have the entry point at 0x0000000C, -- 2.3.x and later kernels have the entry point at 0x00000000. - -So a typical call to build a U-Boot image would read: - - -> tools/mkimage -n '2.4.4 kernel for TQM850L' \ - > -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \ - > -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/ppc/coffboot/vmlinux.gz \ - > examples/uImage.TQM850L - Image Name: 2.4.4 kernel for TQM850L - Created: Wed Jul 19 02:34:59 2000 - Image Type: PowerPC Linux Kernel Image (gzip compressed) - Data Size: 335725 Bytes = 327.86 kB = 0.32 MB - Load Address: 0x00000000 - Entry Point: 0x00000000 + * package compressed binary image for U-Boot: -To verify the contents of the image (or check for corruption): + mkimage -A ppc -O linux -T kernel -C gzip \ + -a 0 -e 0 -n "Linux Kernel Image" \ + -d linux.bin.gz uImage - -> tools/mkimage -l examples/uImage.TQM850L - Image Name: 2.4.4 kernel for TQM850L - Created: Wed Jul 19 02:34:59 2000 - Image Type: PowerPC Linux Kernel Image (gzip compressed) - Data Size: 335725 Bytes = 327.86 kB = 0.32 MB - Load Address: 0x00000000 - Entry Point: 0x00000000 -NOTE: for embedded systems where boot time is critical you can trade -speed for memory and install an UNCOMPRESSED image instead: this -needs more space in Flash, but boots much faster since it does not -need to be uncompressed: + 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. - -> 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: + "mkimage" can be called in two ways: to verify existing images and + print the header information, or to build new images. - -> 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 addreses 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 - - -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 summy of these issues to the - u-boot-users mailing list: - - Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)? - From: "Chris Hallinan" - 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 relocationg 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 chosing 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 first form (with "-l" option) mkimage lists the information + contained in the header of an existing U-Boot image; this includes + checksum verification: -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 it's 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 larger 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 -l image + -l ==> list image header information -[Based on messages by Jerry Van Baren in the U-Boot-Users mailing -list, October 2002] + 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' -int main (int argc, char *argv[]) -{ - sighandler_t no_more_time; + Right now, all Linux kernels use the same load address (0x00000000), + but the entry point address depends on the kernel version: - signal (SIGALRM, no_more_time); - alarm (PROJECT_DEADLINE - toSec (3 * WEEK)); + - 2.2.x kernels have the entry point at 0x0000000C, + - 2.3.x and later kernels have the entry point at 0x00000000. - if (available_money > available_manpower) { - pay consultant to port U-Boot; - return 0; - } + So a typical call to build a U-Boot image would read: - Download latest U-Boot source; + -> 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 - Subscribe to u-boot-users mailing list; + To verify the contents of the image (or check for corruption): - if (clueless) { - email ("Hi, I am new to U-Boot, how do I get started?"); - } + -> 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 - while (learning) { - Read the README file in the top level directory; - Read http://www.denx.de/re/DPLG.html - Read the source, Luke; - } + 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; - if (available_money > toLocalCurrency ($2500)) { - Buy a BDI2000; - } else { - Add a lot of aggravation and time; + return 0; } - Create your own board support subdirectory; + void no_more_time (int sig) + { + hire_a_guru(); + } - 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; + Coding Standards: + ----------------- - return 0; -} + All contributions to U-Boot should conform to the Linux kernel + coding style; see the file "Documentation/CodingStyle" in your Linux + kernel source directory. -void no_more_time (int sig) -{ - hire_a_guru(); -} + 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 + Submissions which do not conform to the standards may be returned + with a request to reformat the changes. -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. + Submitting Patches: + ------------------- -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. + 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. -Submissions which do not conform to the standards may be returned -with a request to reformat the changes. + When you send a patch, please include the following information with + it: -Submitting Patches: -------------------- + * 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. -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. + * For new features: a description of the feature and your + implementation. + * A CHANGELOG entry as plaintext (separate from the patch) -When you send a patch, please include the following information with -it: + * For major contributions, your entry to the CREDITS file -* 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. + * When you add support for a new board, don't forget to add this + board to the MAKEALL script, too. -* For new features: a description of the feature and your - implementation. + * If your patch adds new configuration options, don't forget to + document these in the README file. -* A CHANGELOG entry as plaintext (separate from the patch) + * 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. -* For major contributions, your entry to the CREDITS file + 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). -* When you add support for a new board, don't forget to add this - board to the MAKEALL script, too. + We accept patches as plain text, MIME attachments or as uuencoded + gzipped text. -* If your patch adds new configuration options, don't forget to - document these in the README file. + * If one logical set of modifications affects or creates several + files, all these changes shall be submitted in a SINGLE patch 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. + * Changesets that contain different, unrelated modifications shall be + submitted as SEPARATE patches, one patch per changeset. - We accept patches as plain text, MIME attachments or as uuencoded - gzipped text. -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.