endmenu
-menu "Environment"
-
-config ENV_IS_IN_EEPROM
- bool "Environment in EEPROM"
- depends on !CHAIN_OF_TRUST
- help
- 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_I2C_EEPROM_BUS:
- If defined, specified the i2c bus of the EEPROM device.
-
- - 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:
- The size in bytes of the EEPROM device.
-
- - 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:
-
- #define CONFIG_I2C_ENV_EEPROM_BUS 1
-
- EEPROM which holds the environment, is reached over
- a pca9547 i2c mux with address 0x70, channel 3.
-
-config ENV_IS_IN_FLASH
- bool "Environment in flash memory"
- depends on !CHAIN_OF_TRUST
- help
- Define this if you have a flash device which you want to use for the
- environment.
-
- 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
- a "saveenv" operation.
-
- 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_MMC
- bool "Environment in an MMC device"
- depends on !CHAIN_OF_TRUST
- default y if ARCH_SUNXI
- help
- Define this if you have an MMC device which you want to use for the
- environment.
-
- CONFIG_SYS_MMC_ENV_DEV:
-
- Specifies which MMC device the environment is stored in.
-
- CONFIG_SYS_MMC_ENV_PART (optional):
-
- Specifies which MMC partition the environment is stored in. If not
- set, defaults to partition 0, the user area. Common values might be
- 1 (first MMC boot partition), 2 (second MMC boot partition).
-
- CONFIG_ENV_OFFSET:
- CONFIG_ENV_SIZE:
-
- These two #defines specify the offset and size of the environment
- area within the specified MMC device.
-
- If offset is positive (the usual case), it is treated as relative to
- the start of the MMC partition. If offset is negative, it is treated
- as relative to the end of the MMC partition. This can be useful if
- your board may be fitted with different MMC devices, which have
- different sizes for the MMC partitions, and you always want the
- environment placed at the very end of the partition, to leave the
- maximum possible space before it, to store other data.
-
- These two values are in units of bytes, but must be aligned to an
- MMC sector boundary.
-
- CONFIG_ENV_OFFSET_REDUND (optional):
-
- Specifies a second storage area, of CONFIG_ENV_SIZE size, used to
- hold a redundant copy of the environment data. This provides a
- valid backup copy in case the other copy is corrupted, e.g. due
- to a power failure during a "saveenv" operation.
-
- This value may also be positive or negative; this is handled in the
- same way as CONFIG_ENV_OFFSET.
-
- This value is also in units of bytes, but must also be aligned to
- an MMC sector boundary.
-
- CONFIG_ENV_SIZE_REDUND (optional):
-
- This value need not be set, even when CONFIG_ENV_OFFSET_REDUND is
- set. If this value is set, it must be set to the same value as
- CONFIG_ENV_SIZE.
-
-config ENV_IS_IN_NAND
- bool "Environment in a NAND device"
- depends on !CHAIN_OF_TRUST
- help
- 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 must be
- aligned to an erase block boundary.
-
- - CONFIG_ENV_OFFSET_REDUND (optional):
-
- 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. CONFIG_ENV_OFFSET_REDUND must be
- aligned to an erase block boundary.
-
- - CONFIG_ENV_RANGE (optional):
-
- Specifies the length of the region in which the environment
- can be written. This should be a multiple of the NAND device's
- block size. Specifying a range with more erase blocks than
- are needed to hold CONFIG_ENV_SIZE allows bad blocks within
- the range to be avoided.
-
- - CONFIG_ENV_OFFSET_OOB (optional):
-
- Enables support for dynamically retrieving the offset of the
- environment from block zero's out-of-band data. The
- "nand env.oob" command can be used to record this offset.
- Currently, CONFIG_ENV_OFFSET_REDUND is not supported when
- using CONFIG_ENV_OFFSET_OOB.
-
-config ENV_IS_IN_NVRAM
- bool "Environment in a non-volatile RAM"
- depends on !CHAIN_OF_TRUST
- help
- 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.
-
-config ENV_IS_IN_UBI
- bool "Environment in a UBI volume"
- depends on !CHAIN_OF_TRUST
- help
- Define this if you have an UBI volume that you want to use for the
- environment. This has the benefit of wear-leveling the environment
- accesses, which is important on NAND.
-
- - CONFIG_ENV_UBI_PART:
-
- Define this to a string that is the mtd partition containing the UBI.
-
- - CONFIG_ENV_UBI_VOLUME:
-
- Define this to the name of the volume that you want to store the
- environment in.
-
- - CONFIG_ENV_UBI_VOLUME_REDUND:
-
- Define this to the name of another volume to store a second copy of
- the environment in. This will enable redundant environments in UBI.
- It is assumed that both volumes are in the same MTD partition.
-
- - CONFIG_UBI_SILENCE_MSG
- - CONFIG_UBIFS_SILENCE_MSG
-
- You will probably want to define these to avoid a really noisy system
- when storing the env in UBI.
-
-config ENV_IS_NOWHERE
- bool "Environment is not stored"
- help
- Define this if you don't want to or can't have an environment stored
- on a storage medium
-
-if ARCH_SUNXI
-
-config ENV_OFFSET
- hex "Environment Offset"
- depends on !ENV_IS_IN_UBI
- depends on !ENV_IS_NOWHERE
- default 0x88000 if ARCH_SUNXI
- help
- Offset from the start of the device (or partition)
-
-config ENV_SIZE
- hex "Environment Size"
- depends on !ENV_IS_NOWHERE
- default 0x20000 if ARCH_SUNXI
- help
- Size of the environment storage area
-
-config ENV_UBI_PART
- string "UBI partition name"
- depends on ENV_IS_IN_UBI
- help
- MTD partition containing the UBI device
-
-config ENV_UBI_VOLUME
- string "UBI volume name"
- depends on ENV_IS_IN_UBI
- help
- Name of the volume that you want to store the environment in.
-
-endif
-
-endmenu
-
config BOOTDELAY
int "delay in seconds before automatically booting"
default 2
See doc/README.autoboot for details.
+config USE_BOOTARGS
+ bool "Enable boot arguments"
+ help
+ Provide boot arguments to bootm command. Boot arguments are specified
+ in CONFIG_BOOTARGS option. Enable this option to be able to specify
+ CONFIG_BOOTARGS string. If this option is disabled, CONFIG_BOOTARGS
+ will be undefined and won't take any space in U-Boot image.
+
+config BOOTARGS
+ string "Boot arguments"
+ depends on USE_BOOTARGS
+ help
+ This can be used to pass arguments to the bootm command. The value of
+ CONFIG_BOOTARGS goes into the environment value "bootargs". Note that
+ this value will also override the "chosen" node in FDT blob.
+
menu "Console"
config MENU
config ARCH_EARLY_INIT_R
bool "Call arch-specific init soon after relocation"
- default y if X86
help
With this option U-Boot will call arch_early_init_r() soon after
relocation. Driver model is running by this point, and the cache
config BOARD_EARLY_INIT_F
bool "Call board-specific init before relocation"
- default y if X86
help
Some boards need to perform initialisation as soon as possible
after boot. With this option, U-Boot calls board_early_init_f()