Calls to show_boot_progress() will also result in log entries but
these will not have names.
+config SPL_BOOTSTAGE
+ bool "Boot timing and reported in SPL"
+ depends on BOOTSTAGE
+ help
+ Enable recording of boot time in SPL. To make this visible to U-Boot
+ proper, enable BOOTSTAGE_STASH as well. This will stash the timing
+ information when SPL finishes and load it when U-Boot proper starts
+ up.
+
config BOOTSTAGE_REPORT
bool "Display a detailed boot timing report before booting the OS"
depends on BOOTSTAGE
30,361,327 445,160 start_kernel
config BOOTSTAGE_USER_COUNT
- hex "Number of boot ID numbers available for user use"
+ int "Number of boot ID numbers available for user use"
default 20
help
This is the number of available user bootstage records.
a new ID will be allocated from this stash. If you exceed
the limit, recording will stop.
+config BOOTSTAGE_RECORD_COUNT
+ int "Number of boot stage records to store"
+ default 30
+ help
+ This is the size of the bootstage record list and is the maximum
+ number of bootstage records that can be recorded.
+
config BOOTSTAGE_FDT
bool "Store boot timing information in the OS device tree"
depends on BOOTSTAGE
config BOOTSTAGE_STASH_SIZE
hex "Size of boot timing stash region"
- default 4096
+ default 0x1000
help
This should be large enough to hold the bootstage stash. A value of
4096 (4KiB) is normally plenty.
endmenu
+menu "Environment"
+
+config ENV_IS_IN_DATAFLASH
+ bool "Environment in dataflash"
+ depends on !CHAIN_OF_TRUST
+ help
+ 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_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_FAT
+ bool "Environment is in a FAT filesystem"
+ depends on !CHAIN_OF_TRUST
+ select FAT_WRITE
+ help
+ Define this if you want to use the FAT file system for the environment.
+
+
+ - CONFIG_FAT_WRITE:
+ This must be enabled. Otherwise it cannot save the environment file.
+
+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_ONENAND
+ bool "Environment is in OneNAND"
+ depends on !CHAIN_OF_TRUST
+ help
+ Define this if you want to put your local device's environment in
+ OneNAND.
+
+ - CONFIG_ENV_ADDR:
+ - CONFIG_ENV_SIZE:
+
+ These two #defines are used to determine the device range 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_REMOTE
+ bool "Environment is in remove memory space"
+ depends on !CHAIN_OF_TRUST
+ help
+ Define this if you have a remote memory space which you
+ want to use for the local device's environment.
+
+ - CONFIG_ENV_ADDR:
+ - CONFIG_ENV_SIZE:
+
+ These two #defines specify the address and size of the
+ environment area within the remote memory space. The
+ local device can get the environment from remote memory
+ space by SRIO or PCIE links.
+
+config ENV_IS_IN_SPI_FLASH
+ bool "Environment is in SPI flash"
+ depends on !CHAIN_OF_TRUST
+ help
+ Define this if you have a SPI Flash memory 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 SPI Flash. CONFIG_ENV_OFFSET must be
+ aligned to an erase sector boundary.
+
+ - CONFIG_ENV_SECT_SIZE:
+
+ Define the SPI flash's sector size.
+
+ - 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 sector boundary.
+
+ - CONFIG_ENV_SPI_BUS (optional):
+ - CONFIG_ENV_SPI_CS (optional):
+
+ Define the SPI bus and chip select. If not defined they will be 0.
+
+ - CONFIG_ENV_SPI_MAX_HZ (optional):
+
+ Define the SPI max work clock. If not defined then use 1MHz.
+
+ - CONFIG_ENV_SPI_MODE (optional):
+
+ Define the SPI work mode. If not defined then use SPI_MODE_3.
+
+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
+
+config ENV_FAT_INTERFACE
+ string "Name of the block device for the environment"
+ depends on ENV_IS_IN_FAT
+ default "mmc" if TI_COMMON_CMD_OPTIONS || ARCH_ZYNQMP || ARCH_AT91
+ help
+ Define this to a string that is the name of the block device.
+
+config ENV_FAT_DEVICE_AND_PART
+ string "Device and partition for where to store the environemt in FAT"
+ depends on ENV_IS_IN_FAT
+ default "0:1" if TI_COMMON_CMD_OPTIONS
+ default "0:auto" if ARCH_ZYNQMP
+ default "0" if ARCH_AT91
+ help
+ Define this to a string to specify the partition of the device. It can
+ be as following:
+
+ "D:P", "D:0", "D", "D:" or "D:auto" (D, P are integers. And P >= 1)
+ - "D:P": device D partition P. Error occurs if device D has no
+ partition table.
+ - "D:0": device D.
+ - "D" or "D:": device D partition 1 if device D has partition
+ table, or the whole device D if has no partition
+ table.
+ - "D:auto": first partition in device D with bootable flag set.
+ If none, first valid partition in device D. If no
+ partition table then means device D.
+
+config ENV_FAT_FILE
+ string "Name of the FAT file to use for the environemnt"
+ depends on ENV_IS_IN_FAT
+ default "uboot.env"
+ help
+ It's a string of the FAT file name. This file use to store the
+ environment.
+
+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
endmenu
+config DTB_RESELECT
+ bool "Support swapping dtbs at a later point in boot"
+ depends on FIT_EMBED
+ help
+ It is possible during initial boot you may need to use a generic
+ dtb until you can fully determine the board your running on. This
+ config allows boards to implement a function at a later point
+ during boot to switch to the "correct" dtb.
+
+config FIT_EMBED
+ bool "Support a FIT image embedded in the U-boot image"
+ help
+ This option provides hooks to allow U-boot to parse an
+ appended FIT image and enable board specific code to then select
+ the correct DTB to be used.
+
config DEFAULT_FDT_FILE
string "Default fdt file"
help
This option is used to set the default fdt file to boot OS.
-config SYS_NO_FLASH
- bool "Disable support for parallel NOR flash"
- default n
- help
- This option is used to disable support for parallel NOR flash.
-
config VERSION_VARIABLE
bool "add U-Boot environment variable vers"
default n
config DISPLAY_CPUINFO
bool "Display information about the CPU during start up"
- default y if ARM || BLACKFIN || NIOS2 || X86 || XTENSA
+ default y if ARM || NIOS2 || X86 || XTENSA
help
Display information about the CPU that U-Boot is running on
when U-Boot starts up. The function print_cpuinfo() is called
config DISPLAY_BOARDINFO
bool "Display information about the board during start up"
- default y if ARM || M68K || MIPS || PPC || SPARC || XTENSA
+ default y if ARM || M68K || MIPS || PPC || SANDBOX || XTENSA
help
Display information about the board that U-Boot is running on
when U-Boot starts up. The board function checkboard() is called
to do this.
+menu "Start-up hooks"
+
+config ARCH_EARLY_INIT_R
+ bool "Call arch-specific init soon after relocation"
+ 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
+ is on. Note that board_early_init_r() is called first, if
+ enabled. This can be used to set up architecture-specific devices.
+
+config ARCH_MISC_INIT
+ bool "Call arch-specific init after relocation, when console is ready"
+ help
+ With this option U-Boot will call arch_misc_init() after
+ relocation to allow miscellaneous arch-dependent initialisation
+ to be performed. This function should be defined by the board
+ and will be called after the console is set up, after relocaiton.
+
+config BOARD_EARLY_INIT_F
+ bool "Call board-specific init before relocation"
+ help
+ Some boards need to perform initialisation as soon as possible
+ after boot. With this option, U-Boot calls board_early_init_f()
+ after driver model is ready in the pre-relocation init sequence.
+ Note that the normal serial console is not yet set up, but the
+ debug UART will be available if enabled.
+
+endmenu
+
+menu "Security support"
+
+config HASH
+ bool # "Support hashing API (SHA1, SHA256, etc.)"
+ help
+ This provides a way to hash data in memory using various supported
+ algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
+ and the algorithms it supports are defined in common/hash.c. See
+ also CMD_HASH for command-line access.
+
+endmenu
+
source "common/spl/Kconfig"
projects / people / ms / u-boot.git / blobdiff