Newer
Older
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
39 common/cmd_doc.c Image header has correct magic number
-40 common/cmd_doc.c Error reading Image from DOC device
40 common/cmd_doc.c Image header has correct magic number
41 common/cmd_ide.c before loading a Image from a IDE device
-42 common/cmd_ide.c Bad usage of "ide" command
42 common/cmd_ide.c correct usage of "ide" command
-43 common/cmd_ide.c No boot device
43 common/cmd_ide.c boot device found
-44 common/cmd_ide.c Device not available
44 common/cmd_ide.c Device available
-45 common/cmd_ide.c wrong partition selected
45 common/cmd_ide.c partition selected
-46 common/cmd_ide.c Unknown partition table
46 common/cmd_ide.c valid partition table found
-47 common/cmd_ide.c Invalid partition type
47 common/cmd_ide.c correct partition type
-48 common/cmd_ide.c Error reading Image Header on boot device
48 common/cmd_ide.c reading Image Header from IDE device OK
-49 common/cmd_ide.c Image header has bad magic number
49 common/cmd_ide.c Image header has correct magic number
-50 common/cmd_ide.c Image header has bad checksum
50 common/cmd_ide.c Image header has correct checksum
-51 common/cmd_ide.c Error reading Image from IDE device
51 common/cmd_ide.c reading Image from IDE device OK
52 common/cmd_nand.c before loading a Image from a NAND device
-53 common/cmd_nand.c Bad usage of "nand" command
53 common/cmd_nand.c correct usage of "nand" command
-54 common/cmd_nand.c No boot device
54 common/cmd_nand.c boot device found
-55 common/cmd_nand.c Unknown Chip ID on boot device
55 common/cmd_nand.c correct chip ID found, device available
-56 common/cmd_nand.c Error reading Image Header on boot device
56 common/cmd_nand.c reading Image Header from NAND device OK
-57 common/cmd_nand.c Image header has bad magic number
57 common/cmd_nand.c Image header has correct magic number
-58 common/cmd_nand.c Error reading Image from NAND device
58 common/cmd_nand.c reading Image from NAND device OK
-60 common/env_common.c Environment has a bad CRC, using default
64 net/eth.c starting with Ethernet configuration.
-64 net/eth.c no Ethernet found.
65 net/eth.c Ethernet found.
-80 common/cmd_net.c usage wrong
80 common/cmd_net.c before calling NetLoop()
-81 common/cmd_net.c some error in NetLoop() occurred
81 common/cmd_net.c NetLoop() back without error
-82 common/cmd_net.c size == 0 (File with size 0 loaded)
82 common/cmd_net.c trying automatic boot
83 common/cmd_net.c running "source" command
-83 common/cmd_net.c some error in automatic boot or "source" command
84 common/cmd_net.c end without errors
FIT uImage format:
Arg Where When
100 common/cmd_bootm.c Kernel FIT Image has correct format
-100 common/cmd_bootm.c Kernel FIT Image has incorrect format
101 common/cmd_bootm.c No Kernel subimage unit name, using configuration
-101 common/cmd_bootm.c Can't get configuration for kernel subimage
102 common/cmd_bootm.c Kernel unit name specified
-103 common/cmd_bootm.c Can't get kernel subimage node offset
Marian Balakowicz
committed
103 common/cmd_bootm.c Found configuration node
104 common/cmd_bootm.c Got kernel subimage node offset
-104 common/cmd_bootm.c Kernel subimage hash verification failed
105 common/cmd_bootm.c Kernel subimage hash verification OK
-105 common/cmd_bootm.c Kernel subimage is for unsupported architecture
106 common/cmd_bootm.c Architecture check OK
-106 common/cmd_bootm.c Kernel subimage has wrong type
107 common/cmd_bootm.c Kernel subimage type OK
-107 common/cmd_bootm.c Can't get kernel subimage data/size
108 common/cmd_bootm.c Got kernel subimage data/size
-108 common/cmd_bootm.c Wrong image type (not legacy, FIT)
-109 common/cmd_bootm.c Can't get kernel subimage type
-110 common/cmd_bootm.c Can't get kernel subimage comp
-111 common/cmd_bootm.c Can't get kernel subimage os
-112 common/cmd_bootm.c Can't get kernel subimage load address
-113 common/cmd_bootm.c Image uncompress/copy overwrite error
120 common/image.c Start initial ramdisk verification
-120 common/image.c Ramdisk FIT image has incorrect format
121 common/image.c Ramdisk FIT image has correct format
122 common/image.c No ramdisk subimage unit name, using configuration
-122 common/image.c Can't get configuration for ramdisk subimage
123 common/image.c Ramdisk unit name specified
-124 common/image.c Can't get ramdisk subimage node offset
125 common/image.c Got ramdisk subimage node offset
-125 common/image.c Ramdisk subimage hash verification failed
126 common/image.c Ramdisk subimage hash verification OK
-126 common/image.c Ramdisk subimage for unsupported architecture
127 common/image.c Architecture check OK
-127 common/image.c Can't get ramdisk subimage data/size
128 common/image.c Got ramdisk subimage data/size
129 common/image.c Can't get ramdisk load address
-129 common/image.c Got ramdisk load address
-130 common/cmd_doc.c Incorrect FIT image format
131 common/cmd_doc.c FIT image format OK
-140 common/cmd_ide.c Incorrect FIT image format
141 common/cmd_ide.c FIT image format OK
-150 common/cmd_nand.c Incorrect FIT image format
151 common/cmd_nand.c FIT image format OK
- Automatic software updates via TFTP server
CONFIG_UPDATE_TFTP
CONFIG_UPDATE_TFTP_CNT_MAX
CONFIG_UPDATE_TFTP_MSEC_MAX
These options enable and control the auto-update feature;
for a more detailed description refer to doc/README.update.
- MTD Support (mtdparts command, UBI support)
CONFIG_MTD_DEVICE
Adds the MTD device infrastructure from the Linux kernel.
Needed for mtdparts command support.
CONFIG_MTD_PARTITIONS
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
[so far only for SMDK2400 and TRAB boards]
CONFIG_MODEM_SUPPORT
- RTS/CTS Flow control enable:
CONFIG_HWFLOW
- Modem debug support:
CONFIG_MODEM_SUPPORT_DEBUG
Enables debugging stuff (char screen[1024], dbg())
for modem support. Useful only with BDI2000.
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().
In the target system modem support is enabled when a
specific key (key combination) is pressed during
power-on. Otherwise U-Boot will boot normally
(autoboot). The key_pressed() function is called from
board_init(). Currently key_pressed() is a dummy
function, returning 1 and thus enabling modem
initialization.
If there are no modem init strings in the
environment, U-Boot proceed to autoboot; the
previous output (banner, info printfs) will be
See also: doc/README.Modem
Configuration Settings:
-----------------------
- CONFIG_SYS_LONGHELP: Defined when you want long help messages included;
- CONFIG_SYS_HELP_CMD_WIDTH: Defined when you want to override the default
width of the commands listed in the 'help' command output.
- CONFIG_SYS_PROMPT: This is what U-Boot prints on the console to
- CONFIG_SYS_CBSIZE: Buffer size for input from the Console
- CONFIG_SYS_PBSIZE: Buffer size for Console output
- CONFIG_SYS_MAXARGS: max. Number of arguments accepted for monitor commands
- CONFIG_SYS_BARGSIZE: Buffer size for Boot Arguments which are passed to
the application (usually a Linux kernel) when it is
booted
- CONFIG_SYS_BAUDRATE_TABLE:
- CONFIG_SYS_CONSOLE_INFO_QUIET
- CONFIG_SYS_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
serial port, else the settings in the environment are used.
- CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
- CONFIG_SYS_CONSOLE_ENV_OVERWRITE
Enable overwrite of previous console environment settings.
- CONFIG_SYS_MEMTEST_START, CONFIG_SYS_MEMTEST_END:
Begin and End addresses of the area used by the
simple memory test.
- CONFIG_SYS_ALT_MEMTEST:
- CONFIG_SYS_MEMTEST_SCRATCH:
Scratch address used by the alternate memory test
You only need to set this if address zero isn't writeable
- CONFIG_SYS_MEM_TOP_HIDE (PPC only):
If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config header,
Stefan Roese
committed
this specified memory area will get subtracted from the top
(end) of RAM and won't get "touched" at all by U-Boot. By
Stefan Roese
committed
fixing up gd->ram_size the Linux kernel should gets passed
the now "corrected" memory size and won't touch it either.
This should work for arch/ppc and arch/powerpc. Only Linux
board ports in arch/powerpc with bootwrapper support that
Stefan Roese
committed
recalculate the memory size from the SDRAM controller setup
will have to get fixed in Linux additionally.
Stefan Roese
committed
This option can be used as a workaround for the 440EPx/GRx
CHIP 11 errata where the last 256 bytes in SDRAM shouldn't
be touched.
WARNING: Please make sure that this value is a multiple of
the Linux page size (normally 4k). If this is not the case,
then the end address of the Linux memory will be located at a
non page size aligned address and this could cause major
problems.
- CONFIG_SYS_TFTP_LOADADDR:
- CONFIG_SYS_LOADS_BAUD_CHANGE:
Enable temporary baudrate change while serial download
- CONFIG_SYS_SDRAM_BASE:
Physical start address of SDRAM. _Must_ be 0 here.
- CONFIG_SYS_MBIO_BASE:
Physical start address of Motherboard I/O (if using a
Cogent motherboard)
- CONFIG_SYS_FLASH_BASE:
- CONFIG_SYS_MONITOR_BASE:
Physical start address of boot monitor code (set by
make config files to be same as the text base address
(TEXT_BASE) used when linking) - same as
CONFIG_SYS_FLASH_BASE when booting from flash.
- CONFIG_SYS_MONITOR_LEN:
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.
- CONFIG_SYS_MALLOC_LEN:
- CONFIG_SYS_BOOTM_LEN:
Normally compressed uImages are limited to an
uncompressed size of 8 MBytes. If this is not enough,
you can define CONFIG_SYS_BOOTM_LEN in your board config file
to adjust this setting to your needs.
- CONFIG_SYS_BOOTMAPSZ:
Maximum size of memory mapped by the startup code of
the Linux kernel; all data that must be processed by
the Linux kernel (bd_info, boot arguments, FDT blob if
used) must be put below this limit, unless "bootm_low"
enviroment variable is defined and non-zero. In such case
all data for the Linux kernel must be between "bootm_low"
and "bootm_low" + CONFIG_SYS_BOOTMAPSZ.
- CONFIG_SYS_MAX_FLASH_BANKS:
- CONFIG_SYS_MAX_FLASH_SECT:
- CONFIG_SYS_FLASH_ERASE_TOUT:
- CONFIG_SYS_FLASH_WRITE_TOUT:
- CONFIG_SYS_FLASH_LOCK_TOUT
Timeout for Flash set sector lock bit operation (in ms)
- CONFIG_SYS_FLASH_UNLOCK_TOUT
Timeout for Flash clear lock bits operation (in ms)
- CONFIG_SYS_FLASH_PROTECTION
If defined, hardware flash sectors protection is used
instead of U-Boot software protection.
- CONFIG_SYS_DIRECT_FLASH_TFTP:
Enable TFTP transfers directly to flash memory;
without this option such a download has to be
performed in two steps: (1) download to RAM, and (2)
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 system RAM is
too limited to allow for a temporary copy of the
downloaded image) this option may be very useful.
- CONFIG_SYS_FLASH_CFI:
Define if the flash driver uses extra elements in the
common flash structure for storing flash geometry.
- CONFIG_FLASH_CFI_DRIVER
This option also enables the building of the cfi_flash driver
in the drivers directory
- CONFIG_FLASH_CFI_MTD
This option enables the building of the cfi_mtd driver
in the drivers directory. The driver exports CFI flash
to the MTD layer.
- CONFIG_SYS_FLASH_USE_BUFFER_WRITE
Guennadi Liakhovetski
committed
Use buffered writes to flash.
- CONFIG_FLASH_SPANSION_S29WS_N
s29ws-n MirrorBit flash has non-standard addresses for buffered
write commands.
- CONFIG_SYS_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.
- CONFIG_FLASH_SHOW_PROGRESS
If defined (must be an integer), print out countdown
digits and dots. Recommended value: 45 (9..1) for 80
column displays, 15 (3..1) for 40 column displays.
- CONFIG_SYS_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
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:
- CONFIG_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.
- CONFIG_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.
CONFIG_ENV_OFFSET is used relative to CONFIG_SYS_FLASH_BASE.
- CONFIG_ENV_ADDR:
This is just another way to specify the start address of
the flash sector containing the environment (instead of
CONFIG_ENV_OFFSET).
- CONFIG_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.
- CONFIG_ENV_SIZE:
If you use this in combination with CONFIG_ENV_IS_IN_FLASH
and CONFIG_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.
- CONFIG_ENV_ADDR_REDUND
CONFIG_ENV_SIZE_REDUND
These settings describe a second storage area 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
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!
- CONFIG_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.
- CONFIG_ENV_ADDR:
- CONFIG_ENV_SIZE:
These two #defines are used to determine 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 mapped 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.
- CONFIG_ENV_IS_IN_EEPROM:
Use this if you have an EEPROM or similar serial access
device and a driver for it.
- CONFIG_ENV_OFFSET:
- CONFIG_ENV_SIZE:
These two #defines specify the offset and size of the
environment area within the total memory of your EEPROM.
- CONFIG_SYS_I2C_EEPROM_ADDR:
If defined, specified the chip address of the EEPROM device.
The default address is zero.
- CONFIG_SYS_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.
- CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS:
If defined, the number of milliseconds to delay between
page writes. The default is zero milliseconds.
- CONFIG_SYS_I2C_EEPROM_ADDR_LEN:
The length in bytes of the EEPROM memory array address. Note
that this is NOT the chip address length!
- CONFIG_SYS_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.
- CONFIG_SYS_EEPROM_SIZE:
- CONFIG_ENV_EEPROM_IS_ON_I2C
define this, if you have I2C and SPI activated, and your
EEPROM, which holds the environment, is on the I2C bus.
- CONFIG_I2C_ENV_EEPROM_BUS
if you have an Environment on an EEPROM reached over
I2C muxes, you can define here, how to reach this
EEPROM. For example:
EEPROM which holds the environment, is reached over
a pca9547 i2c mux with address 0x70, channel 3.
Jean-Christophe PLAGNIOL-VILLARD
committed
- CONFIG_ENV_IS_IN_DATAFLASH:
Define this if you have a DataFlash memory device which you
want to use for the environment.
- CONFIG_ENV_OFFSET:
- CONFIG_ENV_ADDR:
- CONFIG_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.
- CONFIG_ENV_IS_IN_NAND:
Define this if you have a NAND device which you want to use
for the environment.
- CONFIG_ENV_OFFSET:
- CONFIG_ENV_SIZE:
These two #defines specify the offset and size of the environment
area within the first NAND device.
- CONFIG_ENV_OFFSET_REDUND
This setting describes a second storage area of CONFIG_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: CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND must be aligned
to a block boundary, and CONFIG_ENV_SIZE must be a multiple of
the NAND devices block size.
Guennadi Liakhovetski
committed
- CONFIG_NAND_ENV_DST
Defines address in RAM to which the nand_spl code should copy the
environment. If redundant environment is used, it will be copied to
CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.
- CONFIG_SYS_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 until 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_f()
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.
- CONFIG_SYS_FAULT_ECHO_LINK_DOWN:
Echo the inverted Ethernet link state to the fault LED.
Note: If this option is active, then CONFIG_SYS_FAULT_MII_ADDR
- CONFIG_SYS_FAULT_MII_ADDR:
MII address of the PHY to check for the Ethernet link state.
- CONFIG_NS16550_MIN_FUNCTIONS:
Define this if you desire to only have use of the NS16550_init
and NS16550_putc functions for the serial driver located at
drivers/serial/ns16550.c. This option is useful for saving
space for already greatly restricted images, including but not
limited to NAND_SPL configurations.
---------------------------------------------------
- CONFIG_SYS_CACHELINE_SIZE:
- CONFIG_SYS_DEFAULT_IMMR:
Needed on some 8260 systems (MPC8260ADS, PQ2FADS-ZU,
and RPXsuper) to be able to adjust the position of
the IMMR register after a reset.
CONFIG_SYS_FDC_DRIVE_NUMBER
the default drive number (default value 0)
CONFIG_SYS_ISA_IO_STRIDE
defines the spacing between FDC chipset registers
CONFIG_SYS_ISA_IO_OFFSET
defines the offset of register from address. It
depends on which part of the data bus is connected to
If CONFIG_SYS_ISA_IO_STRIDE CONFIG_SYS_ISA_IO_OFFSET and
CONFIG_SYS_FDC_DRIVE_NUMBER are undefined, they take their
if CONFIG_SYS_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.
- CONFIG_SYS_IMMR: Physical address of the Internal Memory.
doing! (11-4) [MPC8xx/82xx systems only]
- CONFIG_SYS_INIT_RAM_ADDR:
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
- CONFIG_SYS_GBL_DATA_OFFSET:
Offset of the initial data structure in the memory
area defined by CONFIG_SYS_INIT_RAM_ADDR. Usually
CONFIG_SYS_GBL_DATA_OFFSET is chosen such that the initial
(sometimes written as (CONFIG_SYS_INIT_RAM_END -
CONFIG_SYS_INIT_DATA_SIZE), and the initial stack is just
below that area (growing from (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_GBL_DATA_OFFSET) downward.
Note:
On the MPC824X (or other systems that use the data
cache for initial memory) the address chosen for
CONFIG_SYS_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.
- CONFIG_SYS_SIUMCR: SIU Module Configuration (11-6)
- CONFIG_SYS_SYPCR: System Protection Control (11-9)
- CONFIG_SYS_TBSCR: Time Base Status and Control (11-26)
- CONFIG_SYS_PISCR: Periodic Interrupt Status and Control (11-31)
- CONFIG_SYS_PLPRCR: PLL, Low-Power, and Reset Control Register (15-30)
- CONFIG_SYS_SCCR: System Clock and reset Control Register (15-27)
- CONFIG_SYS_OR_TIMING_SDRAM:
- CONFIG_SYS_MAMR_PTA:
- CONFIG_SYS_DER: Debug Event Register (37-47)
- FLASH_BASE0_PRELIM, FLASH_BASE1_PRELIM, CONFIG_SYS_REMAP_OR_AM,
CONFIG_SYS_PRELIM_OR_AM, CONFIG_SYS_OR_TIMING_FLASH, CONFIG_SYS_OR0_REMAP,
CONFIG_SYS_OR0_PRELIM, CONFIG_SYS_BR0_PRELIM, CONFIG_SYS_OR1_REMAP, CONFIG_SYS_OR1_PRELIM,
CONFIG_SYS_BR1_PRELIM:
Memory Controller Definitions: BR0/1 and OR0/1 (FLASH)
- SDRAM_BASE2_PRELIM, SDRAM_BASE3_PRELIM, SDRAM_MAX_SIZE,
CONFIG_SYS_OR_TIMING_SDRAM, CONFIG_SYS_OR2_PRELIM, CONFIG_SYS_BR2_PRELIM,
CONFIG_SYS_OR3_PRELIM, CONFIG_SYS_BR3_PRELIM:
Memory Controller Definitions: BR2/3 and OR2/3 (SDRAM)
- CONFIG_SYS_MAMR_PTA, CONFIG_SYS_MPTPR_2BK_4K, CONFIG_SYS_MPTPR_1BK_4K, CONFIG_SYS_MPTPR_2BK_8K,
CONFIG_SYS_MPTPR_1BK_8K, CONFIG_SYS_MAMR_8COL, CONFIG_SYS_MAMR_9COL:
Machine Mode Register and Memory Periodic Timer
Prescaler definitions (SDRAM timing)
- CONFIG_SYS_I2C_UCODE_PATCH, CONFIG_SYS_I2C_DPMEM_OFFSET [0x1FC0]:
enable I2C microcode relocation patch (MPC8xx);
define relocation offset in DPRAM [DSP2]
- CONFIG_SYS_SMC_UCODE_PATCH, CONFIG_SYS_SMC_DPMEM_OFFSET [0x1FC0]:
enable SMC microcode relocation patch (MPC8xx);
define relocation offset in DPRAM [SMC1]
- CONFIG_SYS_SPI_UCODE_PATCH, CONFIG_SYS_SPI_DPMEM_OFFSET [0x1FC0]:
enable SPI microcode relocation patch (MPC8xx);
define relocation offset in DPRAM [SCC4]
- CONFIG_SYS_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!
- CONFIG_SYS_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.
- CONFIG_SYS_PCI_SLV_MEM_LOCAL, CONFIG_SYS_PCI_SLV_MEM_BUS, CONFIG_SYS_PICMR0_MASK_ATTRIB,
CONFIG_SYS_PCI_MSTR0_LOCAL, CONFIG_SYS_PCIMSK0_MASK, CONFIG_SYS_PCI_MSTR1_LOCAL,
CONFIG_SYS_PCIMSK1_MASK, CONFIG_SYS_PCI_MSTR_MEM_LOCAL, CONFIG_SYS_PCI_MSTR_MEM_BUS,
CONFIG_SYS_CPU_PCI_MEM_START, CONFIG_SYS_PCI_MSTR_MEM_SIZE, CONFIG_SYS_POCMR0_MASK_ATTRIB,
CONFIG_SYS_PCI_MSTR_MEMIO_LOCAL, CONFIG_SYS_PCI_MSTR_MEMIO_BUS, CPU_PCI_MEMIO_START,
CONFIG_SYS_PCI_MSTR_MEMIO_SIZE, CONFIG_SYS_POCMR1_MASK_ATTRIB, CONFIG_SYS_PCI_MSTR_IO_LOCAL,
CONFIG_SYS_PCI_MSTR_IO_BUS, CONFIG_SYS_CPU_PCI_IO_START, CONFIG_SYS_PCI_MSTR_IO_SIZE,
CONFIG_SYS_POCMR2_MASK_ATTRIB: (MPC826x only)
Overrides the default PCI memory map in arch/powerpc/cpu/mpc8260/pci.c if set.
- CONFIG_PCI_DISABLE_PCIE:
Disable PCI-Express on systems where it is supported but not
required.
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
- CONFIG_SYS_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.
- CONFIG_SYS_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 initializations itself.
- CONFIG_PRELOADER
Modifies the behaviour of start.S when compiling a loader
that is executed before the actual U-Boot. E.g. when
compiling a NAND SPL.
Building the Software:
======================
Building U-Boot has been tested in several native build environments
and in many different cross environments. Of course we cannot support
all possibly existing versions of cross development tools in all
(potentially obsolete) versions. In case of tool chain problems we
recommend to use the ELDK (see http://www.denx.de/wiki/DULG/ELDK)
which is extensively used to build and test U-Boot.
If you are not using a native environment, it is assumed that you
have GNU cross compiling tools available in your path. In this case,
you must set the environment variable CROSS_COMPILE in your shell.
Note that no changes to the Makefile or any other source files are
necessary. For example using the ELDK on a 4xx CPU, please enter:
$ CROSS_COMPILE=ppc_4xx-
$ export CROSS_COMPILE
Note: If you wish to generate Windows versions of the utilities in
the tools directory you can use the MinGW toolchain
(http://www.mingw.org). Set your HOST tools to the MinGW
toolchain and execute 'make tools'. For example:
$ make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools
Binaries such as tools/mkimage.exe will be created which can
be executed on computers running Windows.
U-Boot is intended to be simple to build. After installing the
sources you must configure U-Boot for one specific board type. This
where "NAME_config" is the name of one of the existing configu-
rations; see the main Makefile for supported names.
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 choosing 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.
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
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 the git repository) 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 ELDK cross tools
you can type
CROSS_COMPILE=ppc_8xx- MAKEALL
or to build on a native PowerPC system you can type
CROSS_COMPILE=' ' MAKEALL
When using the MAKEALL script, the default behaviour is to build
U-Boot in the source directory. This location can be changed by
setting the BUILD_DIR environment variable. Also, for each target
built, the MAKEALL script saves two log files (<target>.ERR and
<target>.MAKEALL) in the <source dir>/LOG directory. This default
location can be changed by setting the MAKEALL_LOGDIR environment
variable. For example:
export BUILD_DIR=/tmp/build
export MAKEALL_LOGDIR=/tmp/log
CROSS_COMPILE=ppc_8xx- MAKEALL
With the above settings build objects are saved in the /tmp/build,
log files are saved in the /tmp/log and the source tree remains clean
during the whole build process.
See also "U-Boot Porting Guide" below.
Monitor Commands - Overview:
============================
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
and env variables "ipaddr" and "serverip"
(and eventually "gatewayip")
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd'