29,916,167 26,005,792 bootm_start
30,361,327 445,160 start_kernel
-config BOOTSTAGE_USER_COUNT
- int "Number of boot ID numbers available for user use"
- default 20
- help
- This is the number of available user bootstage records.
- Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...)
- 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
This is the size of the bootstage record list and is the maximum
number of bootstage records that can be recorded.
+config SPL_BOOTSTAGE_RECORD_COUNT
+ int "Number of boot stage records to store for SPL"
+ default 5
+ 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
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_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.
+
+config USE_BOOTCOMMAND
+ bool "Enable a default value for bootcmd"
+ help
+ Provide a default value for the bootcmd entry in the environment. If
+ autoboot is enabled this is what will be run automatically. Enable
+ this option to be able to specify CONFIG_BOOTCOMMAND as a string. If
+ this option is disabled, CONFIG_BOOTCOMMAND will be undefined and
+ won't take any space in U-Boot image.
+
+config BOOTCOMMAND
+ string "bootcmd value"
+ depends on USE_BOOTCOMMAND
+ default "run distro_bootcmd" if DISTRO_DEFAULTS
+ help
+ This is the string of commands that will be used as bootcmd and if
+ AUTOBOOT is set, automatically run.
+
menu "Console"
config MENU
help
This options adds the board specific name to u-boot version.
+config LOGLEVEL
+ int "loglevel"
+ default 4
+ range 0 8
+ help
+ All Messages with a loglevel smaller than the console loglevel will
+ be compiled in. The loglevels are defined as follows:
+
+ 0 (KERN_EMERG) system is unusable
+ 1 (KERN_ALERT) action must be taken immediately
+ 2 (KERN_CRIT) critical conditions
+ 3 (KERN_ERR) error conditions
+ 4 (KERN_WARNING) warning conditions
+ 5 (KERN_NOTICE) normal but significant condition
+ 6 (KERN_INFO) informational
+ 7 (KERN_DEBUG) debug-level messages
+
+config SPL_LOGLEVEL
+ int
+ default LOGLEVEL
+
config SILENT_CONSOLE
bool "Support a silent console"
help
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.
+menu "Logging"
+
+config LOG
+ bool "Enable logging support"
+ help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
+config SPL_LOG
+ bool "Enable logging support in SPL"
+ help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
+config LOG_MAX_LEVEL
+ int "Maximum log level to record"
+ depends on LOG
+ default 5
+ help
+ This selects the maximum log level that will be recorded. Any value
+ higher than this will be ignored. If possible log statements below
+ this level will be discarded at build time. Levels:
+
+ 0 - panic
+ 1 - critical
+ 2 - error
+ 3 - warning
+ 4 - note
+ 5 - info
+ 6 - detail
+ 7 - debug
+
+config SPL_LOG_MAX_LEVEL
+ int "Maximum log level to record in SPL"
+ depends on SPL_LOG
+ default 3
+ help
+ This selects the maximum log level that will be recorded. Any value
+ higher than this will be ignored. If possible log statements below
+ this level will be discarded at build time. Levels:
+
+ 0 - panic
+ 1 - critical
+ 2 - error
+ 3 - warning
+ 4 - note
+ 5 - info
+ 6 - detail
+ 7 - debug
+
+config LOG_CONSOLE
+ bool "Allow log output to the console"
+ depends on LOG
+ default y
+ help
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+config LOG_SPL_CONSOLE
+ bool "Allow log output to the console in SPL"
+ depends on LOG_SPL
+ default y
+ help
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+config LOG_TEST
+ bool "Provide a test for logging"
+ depends on LOG
+ default y if SANDBOX
+ help
+ This enables a 'log test' command to test logging. It is normally
+ executed from a pytest and simply outputs logging information
+ in various different ways to test that the logging system works
+ correctly with varoius settings.
+
+config LOG_ERROR_RETURN
+ bool "Log all functions which return an error"
+ depends on LOG
+ help
+ When an error is returned in U-Boot it is sometimes difficult to
+ figure out the root cause. For eaxmple, reading from SPI flash may
+ fail due to a problem in the SPI controller or due to the flash part
+ not returning the expected information. This option changes
+ log_ret() to log any errors it sees. With this option disabled,
+ log_ret() is a nop.
+
+ You can add log_ret() to all functions which return an error code.
+
+endmenu
-config FIT_EMBED
- bool "Support a FIT image embedded in the U-boot image"
+config SUPPORT_RAW_INITRD
+ bool "Enable raw initrd images"
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.
+ Note, defining the SUPPORT_RAW_INITRD allows user to supply
+ kernel with raw initrd images. The syntax is slightly different, the
+ address of the initrd must be augmented by it's size, in the following
+ format: "<initrd address>:<initrd size>".
config DEFAULT_FDT_FILE
string "Default fdt file"
config DISPLAY_CPUINFO
bool "Display information about the CPU during start up"
- default y if ARM || NIOS2 || X86 || XTENSA
+ default y if ARM || NIOS2 || X86 || XTENSA || M68K
help
Display information about the CPU that U-Boot is running on
when U-Boot starts up. The function print_cpuinfo() is called
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()
endmenu
+menu "Update support"
+
+config UPDATE_TFTP
+ bool "Auto-update using fitImage via TFTP"
+ depends on FIT
+ help
+ This option allows performing update of NOR with data in fitImage
+ sent via TFTP boot.
+
+config UPDATE_TFTP_CNT_MAX
+ int "The number of connection retries during auto-update"
+ default 0
+ depends on UPDATE_TFTP
+
+config UPDATE_TFTP_MSEC_MAX
+ int "Delay in mSec to wait for the TFTP server during auto-update"
+ default 100
+ depends on UPDATE_TFTP
+
+endmenu
+
source "common/spl/Kconfig"
projects / people / ms / u-boot.git / blobdiff