Newer
Older
copy from RAM to flash.
The two-step approach is usually more reliable, since
you can check if the download worked before you erase
the flash, but in some situations (when sytem RAM is
too limited to allow for a tempory copy of the
downloaded image) this option may be very useful.
- CFG_FLASH_CFI:
Define if the flash driver uses extra elements in the
common flash structure for storing flash geometry.
- CFG_FLASH_CFI_DRIVER
This option also enables the building of the cfi_flash driver
in the drivers directory
- CFG_FLASH_QUIET_TEST
If this option is defined, the common CFI flash doesn't
print it's warning upon not recognized FLASH banks. This
is useful, if some of the configured banks are only
optionally available.
- CFG_RX_ETH_BUFFER:
Defines the number of ethernet receive buffers. On some
ethernet controllers it is recommended to set this value
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.
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:
- CFG_ENV_IS_IN_FLASH:
Define this if the environment is in flash memory.
a) The environment occupies one whole flash sector, which is
"embedded" in the text segment with the U-Boot code. This
happens usually with "bottom boot sector" or "top boot
sector" type flash chips, which have several smaller
sectors at the start or the end. For instance, such a
layout can have sector sizes of 8, 2x4, 16, Nx32 kB. In
such a case you would place the environment in one of the
4 kB sectors - with U-Boot code before and after it. With
"top boot sector" type flash chips, you would put the
environment in one of the last sectors, leaving a gap
between U-Boot and the environment.
- CFG_ENV_OFFSET:
Offset of environment data (variable area) to the
beginning of flash memory; for instance, with bottom boot
type flash chips the second sector can be used: the offset
for this sector is given here.
CFG_ENV_OFFSET is used relative to CFG_FLASH_BASE.
- CFG_ENV_ADDR:
This is just another way to specify the start address of
the flash sector containing the environment (instead of
CFG_ENV_OFFSET).
- CFG_ENV_SECT_SIZE:
Size of the sector containing the environment.
b) Sometimes flash chips have few, equal sized, BIG sectors.
In such a case you don't want to spend a whole sector for
the environment.
- CFG_ENV_SIZE:
If you use this in combination with CFG_ENV_IS_IN_FLASH
and CFG_ENV_SECT_SIZE, you can specify to use only a part
of this flash sector for the environment. This saves
memory for the RAM copy of the environment.
It may also save flash memory if you decide to use this
when your environment is "embedded" within U-Boot code,
since then the remainder of the flash sector could be used
for U-Boot code. It should be pointed out that this is
STRONGLY DISCOURAGED from a robustness point of view:
updating the environment in flash makes it always
necessary to erase the WHOLE sector. If something goes
wrong before the contents has been restored from a copy in
RAM, your target system will be dead.
- CFG_ENV_ADDR_REDUND
CFG_ENV_SIZE_REDUND
These settings describe a second storage area used to hold
a redundand copy of the environment data, so that there is
a valid backup copy in case there is a power failure during
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
BE CAREFUL! Any changes to the flash layout, and some changes to the
source code will make it necessary to adapt <board>/u-boot.lds*
accordingly!
- CFG_ENV_IS_IN_NVRAM:
Define this if you have some non-volatile memory device
(NVRAM, battery buffered SRAM) which you want to use for the
environment.
- CFG_ENV_ADDR:
- CFG_ENV_SIZE:
These two #defines are used to determin the memory area you
want to use for environment. It is assumed that this memory
can just be read and written to, without any special
provision.
BE CAREFUL! The first access to the environment happens quite early
in U-Boot initalization (when we try to get the setting of for the
console baudrate). You *MUST* have mappend your NVRAM area then, or
U-Boot will hang.
Please note that even with NVRAM we still use a copy of the
environment in RAM: we could work on NVRAM directly, but we want to
keep settings there always unmodified except somebody uses "saveenv"
to save the current settings.
- CFG_ENV_IS_IN_EEPROM:
Use this if you have an EEPROM or similar serial access
device and a driver for it.
- CFG_ENV_OFFSET:
- CFG_ENV_SIZE:
These two #defines specify the offset and size of the
environment area within the total memory of your EEPROM.
- CFG_I2C_EEPROM_ADDR:
If defined, specified the chip address of the EEPROM device.
The default address is zero.
- CFG_EEPROM_PAGE_WRITE_BITS:
If defined, the number of bits used to address bytes in a
single page in the EEPROM device. A 64 byte page, for example
would require six bits.
- CFG_EEPROM_PAGE_WRITE_DELAY_MS:
If defined, the number of milliseconds to delay between
page writes. The default is zero milliseconds.
- CFG_I2C_EEPROM_ADDR_LEN:
The length in bytes of the EEPROM memory array address. Note
that this is NOT the chip address length!
- CFG_I2C_EEPROM_ADDR_OVERFLOW:
EEPROM chips that implement "address overflow" are ones
like Catalyst 24WC04/08/16 which has 9/10/11 bits of
address and the extra bits end up in the "chip address" bit
slots. This makes a 24WC08 (1Kbyte) chip look like four 256
byte chips.
Note that we consider the length of the address field to
still be one byte because the extra address bits are hidden
in the chip address.
- CFG_EEPROM_SIZE:
The size in bytes of the EEPROM device.
- 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_ENV_IS_IN_NAND:
Define this if you have a NAND device which you want to use
for the environment.
- CFG_ENV_OFFSET:
- CFG_ENV_SIZE:
These two #defines specify the offset and size of the environment
area within the first NAND device.
- CFG_ENV_OFFSET_REDUND
This setting describes a second storage area of CFG_ENV_SIZE
size used to hold a redundant copy of the environment data,
so that there is a valid backup copy in case there is a
power failure during a "saveenv" operation.
Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned
to a block boundary, and CFG_ENV_SIZE must be a multiple of
the NAND devices block size.
- CFG_SPI_INIT_OFFSET
Defines offset to the initial SPI buffer area in DPRAM. The
area is used at an early stage (ROM part) if the environment
is configured to reside in the SPI EEPROM: We need a 520 byte
scratch DPRAM area. It is used between the two initialization
calls (spi_init_f() and spi_init_r()). A value of 0xB00 seems
to be a good choice since it makes it far enough from the
start of the data area as well as from the stack pointer.
Please note that the environment is read-only as long as the monitor
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 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 "saveenv" command to store a valid environment.
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.
- 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
---------------------------------------------------
- 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, 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
the default drive number (default value 0)
CFG_ISA_IO_STRIDE
defines the spacing between fdc chipset registers
(default value 1)
CFG_ISA_IO_OFFSET
defines the offset of register from address. It
depends on which part of the data bus is connected to
the fdc chipset. (default value 0)
If CFG_ISA_IO_STRIDE CFG_ISA_IO_OFFSET and
CFG_FDC_DRIVE_NUMBER are undefined, they take their
default value.
if CFG_FDC_HW_INIT is defined, then the function
fdc_hw_init() is called at the beginning of the FDC
setup. fdc_hw_init() must be provided by the board
source code. It is used to make hardware dependant
initializations.
- CFG_IMMR: Physical address of the Internal Memory.
doing! (11-4) [MPC8xx/82xx systems only]
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
will become available only after programming the
memory controller and running certain initialization
sequences.
U-Boot uses the following memory types:
- MPC8xx and MPC8260: IMMR (internal memory of the CPU)
- MPC824X: data cache
- PPC4xx: data cache
Offset of the initial data structure in the memory
area defined by CFG_INIT_RAM_ADDR. Usually
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 +
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
Note:
On the MPC824X (or other systems that use the data
cache for initial memory) the address chosen for
CFG_INIT_RAM_ADDR is basically arbitrary - it must
point to an otherwise UNUSED address space between
the top of RAM and the start of the PCI space.
- CFG_SIUMCR: SIU Module Configuration (11-6)
- CFG_SYPCR: System Protection Control (11-9)
- CFG_TBSCR: Time Base Status and Control (11-26)
- CFG_PISCR: Periodic Interrupt Status and Control (11-31)
- CFG_PLPRCR: PLL, Low-Power, and Reset Control Register (15-30)
- CFG_SCCR: System Clock and reset Control Register (15-27)
- CFG_OR_TIMING_SDRAM:
SDRAM timing
- CFG_MAMR_PTA:
periodic timer for refresh
- CFG_DER: Debug Event Register (37-47)
- FLASH_BASE0_PRELIM, FLASH_BASE1_PRELIM, CFG_REMAP_OR_AM,
CFG_PRELIM_OR_AM, CFG_OR_TIMING_FLASH, CFG_OR0_REMAP,
CFG_OR0_PRELIM, CFG_BR0_PRELIM, CFG_OR1_REMAP, CFG_OR1_PRELIM,
CFG_BR1_PRELIM:
Memory Controller Definitions: BR0/1 and OR0/1 (FLASH)
- SDRAM_BASE2_PRELIM, SDRAM_BASE3_PRELIM, SDRAM_MAX_SIZE,
CFG_OR_TIMING_SDRAM, CFG_OR2_PRELIM, CFG_BR2_PRELIM,
CFG_OR3_PRELIM, CFG_BR3_PRELIM:
Memory Controller Definitions: BR2/3 and OR2/3 (SDRAM)
- CFG_MAMR_PTA, CFG_MPTPR_2BK_4K, CFG_MPTPR_1BK_4K, CFG_MPTPR_2BK_8K,
CFG_MPTPR_1BK_8K, CFG_MAMR_8COL, CFG_MAMR_9COL:
Machine Mode Register and Memory Periodic Timer
Prescaler definitions (SDRAM timing)
- CFG_I2C_UCODE_PATCH, CFG_I2C_DPMEM_OFFSET [0x1FC0]:
enable I2C microcode relocation patch (MPC8xx);
define relocation offset in DPRAM [DSP2]
- CFG_SPI_UCODE_PATCH, CFG_SPI_DPMEM_OFFSET [0x1FC0]:
enable SPI microcode relocation patch (MPC8xx);
define relocation offset in DPRAM [SCC4]
- CFG_USE_OSCCLK:
Use OSCM clock mode on MBX8xx board. Be careful,
wrong setting might damage your board. Read
doc/README.MBX before setting this variable!
- CFG_CPM_POST_WORD_ADDR: (MPC8xx, MPC8260 only)
Offset of the bootmode word in DPRAM used by post
(Power On Self Tests). This definition overrides
#define'd default value in commproc.h resp.
cpm_8260.h.
- 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_SPD_EEPROM
Get DDR timing information from an I2C EEPROM. Common with pluggable
memory modules such as SODIMMs
SPD_EEPROM_ADDRESS
I2C address of the SPD EEPROM
- CFG_SPD_BUS_NUM
If SPD EEPROM is on an I2C bus other than the first one, specify here.
Note that the value must resolve to something your driver can deal with.
- CFG_83XX_DDR_USES_CS0
Only for 83xx systems. If specified, then DDR should be configured
using CS0 and CS1 instead of CS2 and CS3.
- CFG_83XX_DDR_USES_CS0
Only for 83xx systems. If specified, then DDR should be configured
using CS0 and CS1 instead of CS2 and CS3.
- CONFIG_ETHER_ON_FEC[12]
Define to enable FEC[12] on a 8xx series processor.
- CONFIG_FEC[12]_PHY
Define to the hardcoded PHY address which corresponds
to the given FEC; i. e.
#define CONFIG_FEC1_PHY 4
means that the PHY with address 4 is connected to FEC1
When set to -1, means to probe for first available.
- CONFIG_FEC[12]_PHY_NORXERR
The PHY does not have a RXERR line (RMII only).
(so program the FEC to ignore it).
- CONFIG_RMII
Enable RMII mode for all FECs.
Note that this is a global option, we can't
have one FEC in standard MII mode and another in RMII mode.
- CONFIG_CRC32_VERIFY
Add a verify option to the crc32 command.
The syntax is:
=> crc32 -v <address> <count> <crc32>
Where address/count indicate a memory area
and crc32 is the correct crc32 which the
area should have.
- CONFIG_LOOPW
Add the "loopw" memory command. This only takes effect if
the memory commands are activated globally (CONFIG_CMD_MEM).
- CONFIG_MX_CYCLIC
Add the "mdc" and "mwc" memory commands. These are cyclic
"md/mw" commands.
Examples:
This command will print 4 bytes (10,11,12,13) each 500 ms.
This command will write 12345678 to address 100 all 10 ms.
This only takes effect if the memory commands are activated
globally (CONFIG_CMD_MEM).
- CONFIG_SKIP_LOWLEVEL_INIT
- CONFIG_SKIP_RELOCATE_UBOOT
[ARM only] If these variables are defined, then
certain low level initializations (like setting up
the memory controller) are omitted and/or U-Boot does
not relocate itself into RAM.
Normally these variables MUST NOT be defined. The
only exception is when U-Boot is loaded (to RAM) by
some other boot loader or by a debugger which
performs these intializations itself.
Building the Software:
======================
Building U-Boot has been tested in native PPC environments (on a
PowerBook G3 running LinuxPPC 2000) and in cross environments
(running RedHat 6.x and 7.x Linux on x86, Solaris 2.6 on a SPARC, and
NetBSD 1.5 on x86).
If you are not using a native PPC environment, it is assumed that you
have the GNU cross compiling tools available in your path and named
with a prefix of "powerpc-linux-". If this is not the case, (e.g. if
you are using Monta Vista's Hard Hat Linux CDK 1.2) you must change
the definition of CROSS_COMPILE in Makefile. For HHL on a 4xx CPU,
change it to:
CROSS_COMPILE = ppc_4xx-
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:
make NAME_config
where "NAME_config" is the name of one of the existing
configurations; the following names are supported:
ADCIOP_config FPS860L_config omap730p2_config
ADS860_config GEN860T_config pcu_e_config
AR405_config GENIETV_config PIP405_config
at91rm9200dk_config GTH_config QS823_config
CANBT_config hermes_config QS850_config
cmi_mpc5xx_config hymod_config QS860T_config
cogent_common_config IP860_config RPXlite_config
cogent_mpc8260_config IVML24_config RPXlite_DW_config
cogent_mpc8xx_config IVMS8_config RPXsuper_config
CPCI405_config JSE_config rsdproto_config
CPCIISER4_config LANTEC_config Sandpoint8240_config
csb272_config lwmon_config sbc8260_config
CU824_config MBX860T_config sbc8560_33_config
DUET_ADS_config MBX_config sbc8560_66_config
EBONY_config mpc7448hpc2_config SM850_config
ELPT860_config MPC8260ADS_config SPD823TS_config
ESTEEM192E_config MPC8540ADS_config stxgp3_config
ETX094_config MPC8540EVAL_config SXNI855T_config
FADS823_config NMPC8560ADS_config TQM823L_config
FADS850SAR_config NETVIA_config TQM850L_config
FADS860T_config omap1510inn_config TQM855L_config
FPS850L_config omap1610h2_config TQM860L_config
omap1610inn_config walnut_config
omap5912osk_config Yukon8220_config
omap2420h4_config ZPC1900_config
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
Note: for some board special configuration names may exist; check if
additional information is available from the board vendor; for
instance, the TQM823L systems are available without (standard)
or with LCD support. You can select such additional "features"
when chosing the configuration, i. e.
make TQM823L_config
- will configure for a plain TQM823L, i. e. no LCD support
make TQM823L_LCD_config
- will configure for a TQM823L with U-Boot console on LCD
etc.
Finally, type "make all", and you should get some working U-Boot
images ready for download to / installation on your system:
- "u-boot.bin" is a raw binary image
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format
By default the build is performed locally and the objects are saved
in the source directory. One of the two methods can be used to change
this behavior and build U-Boot to some external directory:
1. Add O= to the make command line invocations:
make O=/tmp/build distclean
make O=/tmp/build NAME_config
make O=/tmp/build all
2. Set environment variable BUILD_DIR to point to the desired location:
export BUILD_DIR=/tmp/build
make distclean
make NAME_config
make all
Note that the command line "O=" setting overrides the BUILD_DIR environment
variable.
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
Please be aware that the Makefiles assume you are using GNU make, so
for instance on NetBSD you might need to use "gmake" instead of
native "make".
If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:
1. Add a new configuration option for your board to the toplevel
"Makefile" and to the "MAKEALL" script, using the existing
entries as examples. Note that here and at many other places
boards and other names are listed in alphabetical sort order. Please
keep this order.
2. Create a new directory to hold your board specific code. Add any
files you need. In your board directory, you will need at least
the "Makefile", a "<board>.c", "flash.c" and "u-boot.lds".
3. Create a new configuration file "include/configs/<board>.h" for
your board
3. If you're porting U-Boot to a new CPU, then also create a new
directory to hold your CPU specific code. Add any files you need.
4. Run "make <board>_config" with your new name.
5. Type "make", and you should get a working "u-boot.srec" file
to be installed on your target system.
6. Debug and solve any problems that might arise.
[Of course, this last step is much harder than it sounds.]
Testing of U-Boot Modifications, Ports to New Hardware, etc.:
==============================================================
If you have modified U-Boot sources (for instance added a new board
or support for new devices, a new CPU, etc.) you are expected to
provide feedback to the other developers. The feedback normally takes
the form of a "patch", i. e. a context diff against a certain (latest
official or latest in CVS) version of U-Boot sources.
But before you submit such a patch, please verify that your modifi-
cation did not break existing code. At least make sure that *ALL* of
the supported boards compile WITHOUT ANY compiler warnings. To do so,
just run the "MAKEALL" script, which will configure and build U-Boot
for ALL supported system. Be warned, this will take a while. You can
select which (cross) compiler to use by passing a `CROSS_COMPILE'
environment variable to the script, i. e. to use the cross tools from
MontaVista's Hard Hat Linux you can type
CROSS_COMPILE=ppc_8xx- MAKEALL
or to build on a native PowerPC system you can type
CROSS_COMPILE=' ' MAKEALL
When using the MAKEALL script, the default behaviour is to build U-Boot
in the source directory. This location can be changed by setting the
BUILD_DIR environment variable. Also, for each target built, the MAKEALL
script saves two log files (<target>.ERR and <target>.MAKEALL) in the
<source dir>/LOG directory. This default location can be changed by
setting the MAKEALL_LOGDIR environment variable. For example:
export BUILD_DIR=/tmp/build
export MAKEALL_LOGDIR=/tmp/log
CROSS_COMPILE=ppc_8xx- MAKEALL
With the above settings build objects are saved in the /tmp/build, log
files are saved in the /tmp/log and the source tree remains clean during
the whole build process.
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
See also "U-Boot Porting Guide" below.
Monitor Commands - Overview:
============================
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
and env variables "ipaddr" and "serverip"
(and eventually "gatewayip")
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd'
loads - load S-Record file over serial line
loadb - load binary file over serial line (kermit mode)
md - memory display
mm - memory modify (auto-incrementing)
nm - memory modify (constant address)
mw - memory write (fill)
cp - memory copy
cmp - memory compare
crc32 - checksum calculation
imd - i2c memory display
imm - i2c memory modify (auto-incrementing)
inm - i2c memory modify (constant address)
imw - i2c memory write (fill)
icrc32 - i2c checksum calculation
iprobe - probe to discover valid I2C chip addresses
iloop - infinite loop on address range
isdram - print SDRAM configuration information
sspi - SPI utility commands
base - print or set address offset
printenv- print environment variables
setenv - set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase - erase FLASH memory
flinfo - print FLASH memory information
bdinfo - print Board Info structure
iminfo - print header information for application image
coninfo - print console devices and informations
ide - IDE sub-system
loop - infinite loop on address range
loopw - infinite write loop on address range
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
mtest - simple RAM test
icache - enable or disable instruction cache
dcache - enable or disable data cache
reset - Perform RESET of the CPU
echo - echo args to console
version - print monitor version
help - print online help
? - alias for 'help'
Monitor Commands - Detailed Description:
========================================
TODO.
For now: just type "help <command>".
Environment Variables:
======================
U-Boot supports user configuration using Environment Variables which
can be made persistent by saving to Flash memory.
Environment Variables are set using "setenv", printed using
"printenv", and saved to Flash using "saveenv". Using "setenv"
without a value can be used to delete a variable from the
environment. As long as you don't save the environment you are
working with an in-memory copy. In case the Flash area containing the
environment is erased by accident, a default environment is provided.
Some configuration options can be set using Environment Variables:
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.
i2cfast - (PPC405GP|PPC405EP only)
if set to 'y' configures Linux I2C driver for fast
mode (400kHZ). This environment variable is used in
initialization code. So, for changes to be effective
it must be saved and board must be reset.
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
If you set initrd_high to 0xFFFFFFFF, this is an
indication to U-Boot that all addresses are legal
for the Linux kernel, including addresses in flash
memory. In this case U-Boot will NOT COPY the
ramdisk at all. This may be useful to reduce the
boot time on your system, but requires that this
feature is supported by your Linux kernel.
ipaddr - IP address; needed for tftpboot command
loadaddr - Default load address for commands like "bootp",
"rarpboot", "tftpboot", "loadb" or "diskboot"
loads_echo - see CONFIG_LOADS_ECHO
serverip - TFTP server IP address; needed for tftpboot command
bootretry - see CONFIG_BOOT_RETRY_TIME
bootdelaykey - see CONFIG_AUTOBOOT_DELAY_STR
bootstopkey - see CONFIG_AUTOBOOT_STOP_STR
ethprime - When CONFIG_NET_MULTI is enabled controls which
interface is used first.
ethact - When CONFIG_NET_MULTI is enabled controls which
interface is currently active. For example you
can do the following
=> setenv ethact FEC ETHERNET
=> ping 192.168.0.1 # traffic sent on FEC ETHERNET
=> setenv ethact SCC ETHERNET
=> ping 10.0.0.1 # traffic sent on SCC ETHERNET
netretry - When set to "no" each network operation will
either succeed or fail without retrying.
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.
tftpsrcport - If this is set, the value is used for TFTP's
tftpdstport - If this is set, the value is used for TFTP's UDP
destination port instead of the Well Know Port 69.
vlan - When set to a value < 4095 the traffic over
ethernet is encapsulated/received over 802.1q
VLAN tagged frames.
The following environment variables may be used and automatically
updated by the network boot commands ("bootp" and "rarpboot"),
depending the information provided by your boot server:
bootfile - see above
dnsip - IP address of your Domain Name Server
dnsip2 - IP address of your secondary Domain Name Server
gatewayip - IP address of the Gateway (Router) to use
hostname - Target hostname
ipaddr - see above
netmask - Subnet Mask
rootpath - Pathname of the root filesystem on the NFS server
serverip - see above
There are two special Environment Variables:
serial# - contains hardware identification information such
as type string and/or serial number
ethaddr - Ethernet address
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.
Further special Environment Variables:
ver - Contains the U-Boot version string as printed
with the "version" command. This variable is
readonly (see CONFIG_VERSION_VARIABLE).
Please note that changes to some configuration parameters may take
only effect after the next boot (yes, that's just like Windoze :-).
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:
Old, simple command line parser:
--------------------------------
- supports environment variables (through setenv / saveenv commands)
- several commands on one line, separated by ';'
- variable substitution using "... ${name} ..." syntax
- special characters ('$', ';') can be escaped by prefixing with '\',
for example:
setenv bootcmd bootm \${address}
- You can also escape text by enclosing in single apostrophes, for example:
setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off'
- similar to Bourne shell, with control structures like
if...then...else...fi, for...do...done; while...do...done,
until...do...done, ...
- supports environment ("global") variables (through setenv / saveenv
commands) and local shell variables (through standard shell syntax
"name=value"); only environment variables can be used with "run"
command
General rules:
--------------
(1) If a command line (or an environment variable executed by a "run"
command) contains several commands separated by semicolon, and
one of these commands fails, then the remaining commands will be
executed anyway.
(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.
Note for Redundant Ethernet Interfaces:
=======================================
Some boards come with redundant ethernet interfaces; U-Boot supports
such configurations and is capable of automatic selection of a
"working" interface when needed. MAC assignment works as follows:
Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
"eth1addr" (=>eth1), "eth2addr", ...
If the network interface stores some valid MAC address (for instance
in SROM), this is used as default address if there is NO correspon-
ding setting in the environment; if the corresponding environment
variable is set, this overrides the settings in the card; that means:
o If the SROM has a valid MAC address, and there is no address in the
environment, the SROM's address is used.
o If there is no valid address in the SROM, and a definition in the
environment exists, then the value from the environment variable is
used.
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 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:
==============
The "boot" commands of this monitor operate on "image" files which
can be basicly anything, preceeded by a special header; see the
definitions in include/image.h for details; basicly, the header
defines the following image properties:
* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
LynxOS, pSOS, QNX, RTEMS, ARTOS;
Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS).
* Target CPU Architecture (Provisions for Alpha, ARM, AVR32, Intel x86,
IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
Currently supported: ARM, AVR32, Intel x86, MIPS, NIOS, PowerPC).
* Compression Type (uncompressed, gzip, bzip2)
* Load Address
* Entry Point
* Image Name
* Image Timestamp
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:
==============
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 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)
- 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.
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 :-).
But now you can ignore ALL boot loader code (in arch/ppc/mbxboot).
Just make sure your machine specific header file (for instance