Newer
Older
- CONFIG_SYS_I2C_PPC4XX_CH0 activate hardware channel 0
- CONFIG_SYS_I2C_PPC4XX_CH1 activate hardware channel 1
- drivers/i2c/i2c_mxc.c
- activate this driver with CONFIG_SYS_I2C_MXC
- enable bus 1 with CONFIG_SYS_I2C_MXC_I2C1
- enable bus 2 with CONFIG_SYS_I2C_MXC_I2C2
- enable bus 3 with CONFIG_SYS_I2C_MXC_I2C3
- enable bus 4 with CONFIG_SYS_I2C_MXC_I2C4
- define speed for bus 1 with CONFIG_SYS_MXC_I2C1_SPEED
- define slave for bus 1 with CONFIG_SYS_MXC_I2C1_SLAVE
- define speed for bus 2 with CONFIG_SYS_MXC_I2C2_SPEED
- define slave for bus 2 with CONFIG_SYS_MXC_I2C2_SLAVE
- define speed for bus 3 with CONFIG_SYS_MXC_I2C3_SPEED
- define slave for bus 3 with CONFIG_SYS_MXC_I2C3_SLAVE
- define speed for bus 4 with CONFIG_SYS_MXC_I2C4_SPEED
- define slave for bus 4 with CONFIG_SYS_MXC_I2C4_SLAVE
If those defines are not set, default value is 100000
- drivers/i2c/rcar_i2c.c:
- activate this driver with CONFIG_SYS_I2C_RCAR
- This driver adds 4 i2c buses
- CONFIG_SYS_RCAR_I2C0_BASE for setting the register channel 0
- CONFIG_SYS_RCAR_I2C0_SPEED for for the speed channel 0
- CONFIG_SYS_RCAR_I2C1_BASE for setting the register channel 1
- CONFIG_SYS_RCAR_I2C1_SPEED for for the speed channel 1
- CONFIG_SYS_RCAR_I2C2_BASE for setting the register channel 2
- CONFIG_SYS_RCAR_I2C2_SPEED for for the speed channel 2
- CONFIG_SYS_RCAR_I2C3_BASE for setting the register channel 3
- CONFIG_SYS_RCAR_I2C3_SPEED for for the speed channel 3
- CONFIF_SYS_RCAR_I2C_NUM_CONTROLLERS for number of i2c buses
- drivers/i2c/sh_i2c.c:
- activate this driver with CONFIG_SYS_I2C_SH
- This driver adds from 2 to 5 i2c buses
- CONFIG_SYS_I2C_SH_BASE0 for setting the register channel 0
- CONFIG_SYS_I2C_SH_SPEED0 for for the speed channel 0
- CONFIG_SYS_I2C_SH_BASE1 for setting the register channel 1
- CONFIG_SYS_I2C_SH_SPEED1 for for the speed channel 1
- CONFIG_SYS_I2C_SH_BASE2 for setting the register channel 2
- CONFIG_SYS_I2C_SH_SPEED2 for for the speed channel 2
- CONFIG_SYS_I2C_SH_BASE3 for setting the register channel 3
- CONFIG_SYS_I2C_SH_SPEED3 for for the speed channel 3
- CONFIG_SYS_I2C_SH_BASE4 for setting the register channel 4
- CONFIG_SYS_I2C_SH_SPEED4 for for the speed channel 4
- CONFIG_SYS_I2C_SH_NUM_CONTROLLERS for number of i2c buses
- drivers/i2c/omap24xx_i2c.c
- activate this driver with CONFIG_SYS_I2C_OMAP24XX
- CONFIG_SYS_OMAP24_I2C_SPEED speed channel 0
- CONFIG_SYS_OMAP24_I2C_SLAVE slave addr channel 0
- CONFIG_SYS_OMAP24_I2C_SPEED1 speed channel 1
- CONFIG_SYS_OMAP24_I2C_SLAVE1 slave addr channel 1
- CONFIG_SYS_OMAP24_I2C_SPEED2 speed channel 2
- CONFIG_SYS_OMAP24_I2C_SLAVE2 slave addr channel 2
- CONFIG_SYS_OMAP24_I2C_SPEED3 speed channel 3
- CONFIG_SYS_OMAP24_I2C_SLAVE3 slave addr channel 3
- CONFIG_SYS_OMAP24_I2C_SPEED4 speed channel 4
- CONFIG_SYS_OMAP24_I2C_SLAVE4 slave addr channel 4
- drivers/i2c/zynq_i2c.c
- activate this driver with CONFIG_SYS_I2C_ZYNQ
- set CONFIG_SYS_I2C_ZYNQ_SPEED for speed setting
- set CONFIG_SYS_I2C_ZYNQ_SLAVE for slave addr
- drivers/i2c/s3c24x0_i2c.c:
- activate this driver with CONFIG_SYS_I2C_S3C24X0
- This driver adds i2c buses (11 for Exynos5250, Exynos5420
9 i2c buses for Exynos4 and 1 for S3C24X0 SoCs from Samsung)
with a fix speed from 100000 and the slave addr 0!
- drivers/i2c/ihs_i2c.c
- activate this driver with CONFIG_SYS_I2C_IHS
- CONFIG_SYS_I2C_IHS_CH0 activate hardware channel 0
- CONFIG_SYS_I2C_IHS_SPEED_0 speed channel 0
- CONFIG_SYS_I2C_IHS_SLAVE_0 slave addr channel 0
- CONFIG_SYS_I2C_IHS_CH1 activate hardware channel 1
- CONFIG_SYS_I2C_IHS_SPEED_1 speed channel 1
- CONFIG_SYS_I2C_IHS_SLAVE_1 slave addr channel 1
- CONFIG_SYS_I2C_IHS_CH2 activate hardware channel 2
- CONFIG_SYS_I2C_IHS_SPEED_2 speed channel 2
- CONFIG_SYS_I2C_IHS_SLAVE_2 slave addr channel 2
- CONFIG_SYS_I2C_IHS_CH3 activate hardware channel 3
- CONFIG_SYS_I2C_IHS_SPEED_3 speed channel 3
- CONFIG_SYS_I2C_IHS_SLAVE_3 slave addr channel 3
- activate dual channel with CONFIG_SYS_I2C_IHS_DUAL
- CONFIG_SYS_I2C_IHS_SPEED_0_1 speed channel 0_1
- CONFIG_SYS_I2C_IHS_SLAVE_0_1 slave addr channel 0_1
- CONFIG_SYS_I2C_IHS_SPEED_1_1 speed channel 1_1
- CONFIG_SYS_I2C_IHS_SLAVE_1_1 slave addr channel 1_1
- CONFIG_SYS_I2C_IHS_SPEED_2_1 speed channel 2_1
- CONFIG_SYS_I2C_IHS_SLAVE_2_1 slave addr channel 2_1
- CONFIG_SYS_I2C_IHS_SPEED_3_1 speed channel 3_1
- CONFIG_SYS_I2C_IHS_SLAVE_3_1 slave addr channel 3_1
additional defines:
CONFIG_SYS_NUM_I2C_BUSES
Hold the number of i2c buses you want to use.
CONFIG_SYS_I2C_DIRECT_BUS
define this, if you don't use i2c muxes on your hardware.
if CONFIG_SYS_I2C_MAX_HOPS is not defined or == 0 you can
omit this define.
CONFIG_SYS_I2C_MAX_HOPS
define how many muxes are maximal consecutively connected
on one i2c bus. If you not use i2c muxes, omit this
define.
CONFIG_SYS_I2C_BUSES
hold a list of buses you want to use, only used if
CONFIG_SYS_I2C_DIRECT_BUS is not defined, for example
a board with CONFIG_SYS_I2C_MAX_HOPS = 1 and
CONFIG_SYS_NUM_I2C_BUSES = 9:
CONFIG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 3}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 4}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 5}}}, \
{1, {I2C_NULL_HOP}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 1}}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 2}}}, \
}
which defines
bus 0 on adapter 0 without a mux
bus 1 on adapter 0 with a PCA9547 on address 0x70 port 1
bus 2 on adapter 0 with a PCA9547 on address 0x70 port 2
bus 3 on adapter 0 with a PCA9547 on address 0x70 port 3
bus 4 on adapter 0 with a PCA9547 on address 0x70 port 4
bus 5 on adapter 0 with a PCA9547 on address 0x70 port 5
bus 6 on adapter 1 without a mux
bus 7 on adapter 1 with a PCA9544 on address 0x72 port 1
bus 8 on adapter 1 with a PCA9544 on address 0x72 port 2
If you do not have i2c muxes on your board, omit this define.
If you use the software i2c interface (CONFIG_SYS_I2C_SOFT)
then the following macros need to be defined (examples are
from include/configs/lwmon.h):
(Optional). Any commands necessary to enable the I2C
controller or configure ports.
eg: #define I2C_INIT (immr->im_cpm.cp_pbdir |= PB_SCL)
(Only for MPC8260 CPU). The I/O port to use (the code
assumes both bits are on the same port). Valid values
are 0..3 for ports A..D.
I2C_ACTIVE
The code necessary to make the I2C data line active
(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)
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)
If <bit> is true, sets the I2C data line high. If it
is false, it clears it (low).
if(bit) immr->im_cpm.cp_pbdat |= PB_SDA; \
else immr->im_cpm.cp_pbdat &= ~PB_SDA
If <bit> is true, sets the I2C clock line high. If it
is false, it clears it (low).
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). Often defined to be something
like:
CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA
If your arch supports the generic GPIO framework (asm/gpio.h),
then you may alternatively define the two GPIOs that are to be
used as SCL / SDA. Any of the previous I2C_xxx macros will
have GPIO-based defaults assigned to them as appropriate.
You should define these to the GPIO value as given directly to
the generic GPIO functions.
CONFIG_SYS_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.
CONFIG_I2C_MULTI_BUS
This option allows the use of multiple I2C buses, each of which
must have a controller. At any point in time, only one bus is
active. To switch to a different bus, use the 'i2c dev' command.
Note that bus numbering is zero-based.
CONFIG_SYS_I2C_NOPROBES
This option specifies a list of I2C devices that will be skipped
when the 'i2c probe' command is issued. If CONFIG_I2C_MULTI_BUS
is set, specify a list of bus-device pairs. Otherwise, specify
a 1D array of device addresses
e.g.
#undef CONFIG_I2C_MULTI_BUS
#define CONFIG_SYS_I2C_NOPROBES {0x50,0x68}
will skip addresses 0x50 and 0x68 on a board with one I2C bus
#define CONFIG_SYS_I2C_NOPROBES {{0,0x50},{0,0x68},{1,0x54}}
will skip addresses 0x50 and 0x68 on bus 0 and address 0x54 on bus 1
CONFIG_SYS_SPD_BUS_NUM
If defined, then this indicates the I2C bus number for DDR SPD.
If not defined, then U-Boot assumes that SPD is on I2C bus 0.
CONFIG_SYS_RTC_BUS_NUM
If defined, then this indicates the I2C bus number for the RTC.
If not defined, then U-Boot assumes that RTC is on I2C bus 0.
CONFIG_SOFT_I2C_READ_REPEATED_START
defining this will force the i2c_read() function in
the soft_i2c driver to perform an I2C repeated start
between writing the address pointer and reading the
data. If this define is omitted the default behaviour
of doing a stop-start sequence will be used. Most I2C
devices can use either method, but some require one or
the other.
- SPI Support: CONFIG_SPI
Enables SPI driver (so far only tested with
SPI EEPROM, also an instance works with Crystal A/D and
D/As on the SACSng board)
CONFIG_SH_SPI
Enables the driver for SPI controller on SuperH. Currently
only SH7757 is supported.
Enables a software (bit-bang) SPI driver rather than
using hardware support. This is a general purpose
driver that only requires three general I/O port pins
(two outputs, one input) to function. If this is
defined, the board configuration must define several
SPI configuration items (port pins to use, etc). For
an example, see include/configs/sacsng.h.
CONFIG_HARD_SPI
Enables a hardware SPI driver for general-purpose reads
and writes. As with CONFIG_SOFT_SPI, the board configuration
must define a list of chip-select function pointers.
Currently supported on some MPC8xxx processors. For an
example, see include/configs/mpc8349emds.h.
CONFIG_MXC_SPI
Enables the driver for the SPI controllers on i.MX and MXC
SoCs. Currently i.MX31/35/51 are supported.
CONFIG_SYS_SPI_MXC_WAIT
Timeout for waiting until spi transfer completed.
default: (CONFIG_SYS_HZ/100) /* 10 ms */
Enables FPGA subsystem.
CONFIG_FPGA_<vendor>
Enables support for specific chip vendors.
(ALTERA, XILINX)
Enables support for FPGA family.
(SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)
CONFIG_FPGA_COUNT
Specify the number of FPGA devices to support.
CONFIG_SYS_FPGA_PROG_FEEDBACK
Enable printing of hash marks during FPGA configuration.
CONFIG_SYS_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.
CONFIG_SYS_FPGA_CHECK_CTRLC
CONFIG_SYS_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).
CONFIG_SYS_FPGA_WAIT_INIT
Maximum time to wait for the INIT_B line to de-assert
after PROB_B has been de-asserted during a Virtex II
FPGA configuration sequence. The default time is 500
CONFIG_SYS_FPGA_WAIT_BUSY
Maximum time to wait for BUSY to de-assert during
Virtex II FPGA configuration. The default is 5 ms.
CONFIG_SYS_FPGA_WAIT_CONFIG
Time to wait after FPGA configuration. The default is
CONFIG_BUILD_TARGET
Some SoCs need special image types (e.g. U-Boot binary
with a special header) as build targets. By defining
CONFIG_BUILD_TARGET in the SoC / board header, this
special image will be automatically built upon calling
If defined, this string will be added to the U-Boot
version information (U_BOOT_VERSION)
U-Boot considers the values of the environment
variables "serial#" (Board Serial Number) and
"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,
and write or delete attempts are rejected. You can
If CONFIG_ENV_OVERWRITE is #defined in your config
file, the write protection for vendor parameters is
completely disabled. Anybody can change or delete
Alternatively, if you define _both_ an ethaddr in the
default env _and_ CONFIG_OVERWRITE_ETHADDR_ONCE, a default
Ethernet address is installed in the environment,
which can be changed exactly ONCE by the user. [The
serial# is unaffected by this, i. e. it remains
read-only.]
The same can be accomplished in a more flexible way
for any variable by configuring the type of access
to allow for those variables in the ".flags" variable
or define CONFIG_ENV_FLAGS_LIST_STATIC.
- Protected RAM:
CONFIG_PRAM
Define this variable to enable the reservation of
"protected RAM", i. e. RAM which is not overwritten
by U-Boot. Define CONFIG_PRAM to hold the number of
kB you want to reserve for pRAM. You can overwrite
this default value by defining an environment
variable "pram" to the number of kB you want to
reserve. Note that the board info structure will
still show the full amount of RAM. If pRAM is
reserved, a new environment variable "mem" will
automatically be defined to hold the amount of
remaining RAM in a form that can be passed as boot
argument to Linux, for instance like that:
setenv bootargs ... mem=\${mem}
saveenv
This way you can tell Linux not to use this memory,
either, which results in a memory region that will
not be affected by reboots.
*WARNING* If your board configuration uses automatic
detection of the RAM size, you must make sure that
this memory test is non-destructive. So far, the
following board configurations are known to be
"pRAM-clean":
IVMS8, IVML24, SPD8xx, TQM8xxL,
HERMES, IP860, RPXlite, LWMON,
- Access to physical memory region (> 4GB)
Some basic support is provided for operations on memory not
normally accessible to U-Boot - e.g. some architectures
support access to more than 4GB of memory on 32-bit
machines using physical address extension or similar.
Define CONFIG_PHYSMEM to access this basic support, which
currently only supports clearing the memory.
- Error Recovery:
CONFIG_PANIC_HANG
Define this variable to stop the system in case of a
fatal error, so that you have to reset it manually.
This is probably NOT a good idea for an embedded
system where you want the system to reboot
automatically as fast as possible, but it may be
useful during development since you can try to debug
the conditions that lead to the situation.
CONFIG_NET_RETRY_COUNT
This variable defines the number of retries for
network operations like ARP, RARP, TFTP, or BOOTP
before giving up the operation. If not defined, a
default value of 5 is used.
CONFIG_ARP_TIMEOUT
Timeout waiting for an ARP reply in milliseconds.
CONFIG_NFS_TIMEOUT
Timeout in milliseconds used in NFS protocol.
If you encounter "ERROR: Cannot umount" in nfs command,
try longer timeout such as
#define CONFIG_NFS_TIMEOUT 10000UL
CONFIG_AUTO_COMPLETE
Enable auto completion of commands using TAB.
CONFIG_SYS_PROMPT_HUSH_PS2
This defines the secondary prompt string, which is
printed when the command interpreter needs more input
to complete a command. Usually "> ".
Note:
In the current implementation, the local variables
space and global environment variables space are
separated. Local variables are those you define by
simply typing `name=value'. To access a local
variable later on, you have write `$name' or
`${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
in such a variable, you need to use the run command,
and you must not use the '$' sign to access them.
To store commands and special characters in a
variable, please use double quotation marks
surrounding the whole text of the variable, instead
of the backslashes before semicolons and special
symbols.
- Command Line Editing and History:
Enable editing and History functions for interactive
- Command Line PS1/PS2 support:
CONFIG_CMDLINE_PS_SUPPORT
Enable support for changing the command prompt string
at run-time. Only static string is supported so far.
The string is obtained from environment variables PS1
and PS2.
Define this to contain any number of null terminated
strings (variable = value pairs) that will be part of
the default environment compiled into the boot image.
For example, place something like this in your
board's config file:
#define CONFIG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
Warning: This method is based on knowledge about the
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, there is no guarantee either.
Note: overly (ab)use of the default environment is
discouraged. Make sure to check other ways to preset
the environment like the "source" command or the
CONFIG_ENV_VARS_UBOOT_CONFIG
Define this in order to add variables describing the
U-Boot build configuration to the default environment.
These will be named arch, cpu, board, vendor, and soc.
Enabling this option will cause the following to be defined:
- CONFIG_SYS_ARCH
- CONFIG_SYS_CPU
- CONFIG_SYS_BOARD
- CONFIG_SYS_VENDOR
- CONFIG_SYS_SOC
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
Define this in order to add variables describing certain
run-time determined information about the hardware to the
environment. These will be named board_name, board_rev.
CONFIG_DELAY_ENVIRONMENT
Normally the environment is loaded when the board is
initialised so that it is available to U-Boot. This inhibits
that so that the environment is not available until
explicitly loaded later by U-Boot code. With CONFIG_OF_CONTROL
this is instead controlled by the value of
/config/load-environment.
CONFIG_HAS_DATAFLASH
Defining this option enables DataFlash features and
allows to read/write in Dataflash via the standard
commands cp, md...
- Serial Flash support
CONFIG_CMD_SF
Defining this option enables SPI flash commands
'sf probe/read/write/erase/update'.
Usage requires an initial 'probe' to define the serial
flash parameters, followed by read/write/erase/update
commands.
The following defaults may be provided by the platform
to handle the common case when only a single serial
flash is present on the system.
CONFIG_SF_DEFAULT_BUS Bus identifier
CONFIG_SF_DEFAULT_CS Chip-select
CONFIG_SF_DEFAULT_MODE (see include/spi.h)
CONFIG_SF_DEFAULT_SPEED in Hz
CONFIG_CMD_SF_TEST
Define this option to include a destructive SPI flash
test ('sf test').
CONFIG_SF_DUAL_FLASH Dual flash memories
Define this option to use dual flash support where two flash
memories can be connected with a given cs line.
Currently Xilinx Zynq qspi supports these type of connections.
- 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 also be defined in the
CONFIG_SYS_SYSTEMACE_BASE macro. For example:
#define CONFIG_SYS_SYSTEMACE_BASE 0xf0000000
When SystemACE support is added, the "ace" device type
becomes available to the fat commands, i.e. fatls.
- TFTP Fixed UDP Port:
CONFIG_TFTP_PORT
If this is defined, the environment variable tftpsrcp
is used to supply the TFTP UDP source port value.
If tftpsrcp isn't defined, the normal pseudo-random port
number generator is used.
Also, the environment variable tftpdstp is used to supply
the TFTP UDP destination port value. If tftpdstp isn't
defined, the normal port 69 is used.
The purpose for tftpsrcp is to allow a TFTP server to
blindly start the TFTP transfer using the pre-configured
target IP address and UDP port. This has the effect of
"punching through" the (Windows XP) firewall, allowing
the remainder of the TFTP transfer to proceed normally.
A better solution is to properly configure the firewall,
but sometimes that is not allowed.
- bootcount support:
CONFIG_BOOTCOUNT_LIMIT
This enables the bootcounter support, see:
http://www.denx.de/wiki/DULG/UBootBootCountLimit
CONFIG_AT91SAM9XE
enable special bootcounter support on at91sam9xe based boards.
CONFIG_SOC_DA8XX
enable special bootcounter support on da850 based boards.
CONFIG_BOOTCOUNT_RAM
enable support for the bootcounter in RAM
CONFIG_BOOTCOUNT_I2C
enable support for the bootcounter on an i2c (like RTC) device.
CONFIG_SYS_I2C_RTC_ADDR = i2c chip address
CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for
the bootcounter.
CONFIG_BOOTCOUNT_ALEN = address len
Defining this option allows to add some board-
specific code (calling a user-provided function
"show_boot_progress(int)") that enables you to show
the system's boot progress on some display (for
example, some LED's) on your board. At the moment,
the following checkpoints are implemented:
Legacy uImage format:
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
2 common/cmd_bootm.c Image header has correct magic number
-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
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
-5 common/cmd_bootm.c Wrong Image Type (not kernel, multi)
6 common/cmd_bootm.c Image Type check OK
-6 common/cmd_bootm.c gunzip uncompression error
-7 common/cmd_bootm.c Unimplemented compression type
7 common/cmd_bootm.c Uncompression OK
8 common/cmd_bootm.c No uncompress/copy overwrite error
-9 common/cmd_bootm.c Unsupported OS (not Linux, BSD, VxWorks, QNX)
9 common/image.c Start initial ramdisk verification
-10 common/image.c Ramdisk header has bad magic number
-11 common/image.c Ramdisk header has bad checksum
10 common/image.c Ramdisk header is OK
-12 common/image.c Ramdisk data has bad checksum
11 common/image.c Ramdisk data has correct checksum
12 common/image.c Ramdisk verification complete, start loading
-13 common/image.c Wrong Image Type (not PPC Linux ramdisk)
13 common/image.c Start multifile image verification
14 common/image.c No initial ramdisk, no multifile, continue.
15 arch/<arch>/lib/bootm.c All preparation done, transferring control to OS
-30 arch/powerpc/lib/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()
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
34 common/cmd_doc.c before loading a Image from a DOC device
-35 common/cmd_doc.c Bad usage of "doc" command
35 common/cmd_doc.c correct usage of "doc" command
-36 common/cmd_doc.c No boot device
36 common/cmd_doc.c correct boot device
-37 common/cmd_doc.c Unknown Chip ID on boot device
37 common/cmd_doc.c correct chip ID found, device available
-38 common/cmd_doc.c Read Error on boot device
38 common/cmd_doc.c reading Image header from DOC device OK
-39 common/cmd_doc.c Image header has bad magic number
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 net_loop()
-81 common/cmd_net.c some error in net_loop() occurred
81 common/cmd_net.c net_loop() 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
- legacy image format:
CONFIG_IMAGE_FORMAT_LEGACY
enables the legacy image format support in U-Boot.
Default:
enabled if CONFIG_FIT_SIGNATURE is not defined.
CONFIG_DISABLE_IMAGE_LEGACY
disable the legacy image format
This define is introduced, as the legacy image format is
enabled per default for backward compatibility.
- Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
This option defines a board specific value for the
address where standalone program gets loaded, thus
overwriting the architecture dependent default
settings.
- Frame Buffer Address:
CONFIG_FB_ADDR
Define CONFIG_FB_ADDR if you want to use specific
address for frame buffer. This is typically the case
when using a graphics controller has separate video
memory. U-Boot will then place the frame buffer at
the given address instead of dynamically reserving it
in system RAM by calling lcd_setmem(), which grabs
the memory for the frame buffer depending on the
configured panel size.
Please see board_init_f function.
- 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.
- UBI support
CONFIG_CMD_UBI
Adds commands for interacting with MTD partitions formatted
with the UBI flash translation layer
Requires also defining CONFIG_RBTREE
CONFIG_UBI_SILENCE_MSG
Make the verbose messages from UBI stop printing. This leaves
warnings and errors enabled.
CONFIG_MTD_UBI_WL_THRESHOLD
This parameter defines the maximum difference between the highest
erase counter value and the lowest erase counter value of eraseblocks
of UBI devices. When this threshold is exceeded, UBI starts performing
wear leveling by means of moving data from eraseblock with low erase
counter to eraseblocks with high erase counter.
The default value should be OK for SLC NAND flashes, NOR flashes and
other flashes which have eraseblock life-cycle 100000 or more.
However, in case of MLC NAND flashes which typically have eraseblock
life-cycle less than 10000, the threshold should be lessened (e.g.,
to 128 or 256, although it does not have to be power of 2).
default: 4096
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
CONFIG_MTD_UBI_BEB_LIMIT
This option specifies the maximum bad physical eraseblocks UBI
expects on the MTD device (per 1024 eraseblocks). If the
underlying flash does not admit of bad eraseblocks (e.g. NOR
flash), this value is ignored.
NAND datasheets often specify the minimum and maximum NVM
(Number of Valid Blocks) for the flashes' endurance lifetime.
The maximum expected bad eraseblocks per 1024 eraseblocks
then can be calculated as "1024 * (1 - MinNVB / MaxNVB)",
which gives 20 for most NANDs (MaxNVB is basically the total
count of eraseblocks on the chip).
To put it differently, if this value is 20, UBI will try to
reserve about 1.9% of physical eraseblocks for bad blocks
handling. And that will be 1.9% of eraseblocks on the entire
NAND chip, not just the MTD partition UBI attaches. This means
that if you have, say, a NAND flash chip admits maximum 40 bad
eraseblocks, and it is split on two MTD partitions of the same
size, UBI will reserve 40 eraseblocks when attaching a
partition.
default: 20
CONFIG_MTD_UBI_FASTMAP
Fastmap is a mechanism which allows attaching an UBI device
in nearly constant time. Instead of scanning the whole MTD device it
only has to locate a checkpoint (called fastmap) on the device.
The on-flash fastmap contains all information needed to attach
the device. Using fastmap makes only sense on large devices where
attaching by scanning takes long. UBI will not automatically install
a fastmap on old images, but you can set the UBI parameter
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT to 1 if you want so. Please note
that fastmap-enabled images are still usable with UBI implementations
without fastmap support. On typical flash devices the whole fastmap
fits into one PEB. UBI will reserve PEBs to hold two fastmaps.
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT
Set this parameter to enable fastmap automatically on images
without a fastmap.
default: 0
CONFIG_MTD_UBI_FM_DEBUG
Enable UBI fastmap debug
default: 0
- UBIFS support
CONFIG_CMD_UBIFS
Adds commands for interacting with UBI volumes formatted as
UBIFS. UBIFS is read-only in u-boot.
Requires UBI support as well as CONFIG_LZO
CONFIG_UBIFS_SILENCE_MSG
Make the verbose messages from UBIFS stop printing. This leaves
warnings and errors enabled.
- SPL framework
CONFIG_SPL
Enable building of SPL globally.
CONFIG_SPL_LDSCRIPT
LDSCRIPT for linking the SPL binary.
CONFIG_SPL_MAX_FOOTPRINT
Maximum size in memory allocated to the SPL, BSS included.
When defined, the linker checks that the actual memory
used by SPL from _start to __bss_end does not exceed it.
CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE
must not be both defined at the same time.