-menu "Boot timing"
-
-config BOOTSTAGE
- bool "Boot timing and reporting"
- help
- Enable recording of boot time while booting. To use it, insert
- calls to bootstage_mark() with a suitable BOOTSTAGE_ID from
- bootstage.h. Only a single entry is recorded for each ID. You can
- give the entry a name with bootstage_mark_name(). You can also
- record elapsed time in a particular stage using bootstage_start()
- before starting and bootstage_accum() when finished. Bootstage will
- add up all the accumulated time and report it.
-
- Normally, IDs are defined in bootstage.h but a small number of
- additional 'user' IDs can be used by passing BOOTSTAGE_ID_ALLOC
- as the ID.
-
- 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 TPL_BOOTSTAGE
- bool "Boot timing and reported in TPL"
- 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 TPL 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
- help
- Enable output of a boot time report just before the OS is booted.
- This shows how long it took U-Boot to go through each stage of the
- boot process. The report looks something like this:
-
- Timer summary in microseconds:
- Mark Elapsed Stage
- 0 0 reset
- 3,575,678 3,575,678 board_init_f start
- 3,575,695 17 arch_cpu_init A9
- 3,575,777 82 arch_cpu_init done
- 3,659,598 83,821 board_init_r start
- 3,910,375 250,777 main_loop
- 29,916,167 26,005,792 bootm_start
- 30,361,327 445,160 start_kernel
-
-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 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 TPL_BOOTSTAGE_RECORD_COUNT
- int "Number of boot stage records to store for TPL"
- 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
- help
- Stash the bootstage information in the FDT. A root 'bootstage'
- node is created with each bootstage id as a child. Each child
- has a 'name' property and either 'mark' containing the
- mark time in microseconds, or 'accum' containing the
- accumulated time for that bootstage id in microseconds.
- For example:
-
- bootstage {
- 154 {
- name = "board_init_f";
- mark = <3575678>;
- };
- 170 {
- name = "lcd";
- accum = <33482>;
- };
- };
-
- Code in the Linux kernel can find this in /proc/devicetree.
-
-config BOOTSTAGE_STASH
- bool "Stash the boot timing information in memory before booting OS"
- depends on BOOTSTAGE
- help
- Some OSes do not support device tree. Bootstage can instead write
- the boot timing information in a binary format at a given address.
- This happens through a call to bootstage_stash(), typically in
- the CPU's cleanup_before_linux() function. You can use the
- 'bootstage stash' and 'bootstage unstash' commands to do this on
- the command line.
-
-config BOOTSTAGE_STASH_ADDR
- hex "Address to stash boot timing information"
- default 0
- help
- Provide an address which will not be overwritten by the OS when it
- starts, so that it can read this information when ready.
-
-config BOOTSTAGE_STASH_SIZE
- hex "Size of boot timing stash region"
- default 0x1000
- help
- This should be large enough to hold the bootstage stash. A value of
- 4096 (4KiB) is normally plenty.
-
-config SHOW_BOOT_PROGRESS
- bool "Show boot progress in a board-specific manner"
- help
- 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
- LEDs) 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()
-
- 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
- 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
-
-endmenu
-
-menu "Boot media"
-
-config NOR_BOOT
- bool "Support for booting from NOR flash"
- depends on NOR
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via NOR. In this case we will enable certain pinmux early
- as the ROM only partially sets up pinmux. We also default to using
- NOR for environment.
-
-config NAND_BOOT
- bool "Support for booting from NAND flash"
- default n
- imply MTD_RAW_NAND
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via NAND flash. This is not a must, some SoCs need this,
- some not.
-
-config ONENAND_BOOT
- bool "Support for booting from ONENAND"
- default n
- imply MTD_RAW_NAND
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via ONENAND. This is not a must, some SoCs need this,
- some not.
-
-config QSPI_BOOT
- bool "Support for booting from QSPI flash"
- default n
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via QSPI flash. This is not a must, some SoCs need this,
- some not.
-
-config SATA_BOOT
- bool "Support for booting from SATA"
- default n
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via SATA. This is not a must, some SoCs need this,
- some not.
-
-config SD_BOOT
- bool "Support for booting from SD/EMMC"
- default n
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via SD/EMMC. This is not a must, some SoCs need this,
- some not.
-
-config SPI_BOOT
- bool "Support for booting from SPI flash"
- default n
- help
- Enabling this will make a U-Boot binary that is capable of being
- booted via SPI flash. This is not a must, some SoCs need this,
- some not.
-
-endmenu
-
-config BOOTDELAY
- int "delay in seconds before automatically booting"
- default 2
- depends on AUTOBOOT
- help
- Delay before automatically running bootcmd;
- set to 0 to autoboot with no delay, but you can stop it by key input.
- set to -1 to disable autoboot.
- set to -2 to autoboot with no delay and not check for abort
-
- If this value is >= 0 then it is also used for the default delay
- before starting the default entry in bootmenu. If it is < 0 then
- a default value of 10s is used.
-
- 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.
-
-config USE_PREBOOT
- bool "Enable preboot"
- help
- When this option is enabled, the existence of the environment
- variable "preboot" will be checked immediately before starting the
- CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp.
- entering interactive mode.
-
- This feature is especially useful when "preboot" is automatically
- generated or modified. For example, the boot code can modify the
- "preboot" when a user holds down a certain combination of keys.
-
-config PREBOOT
- string "preboot default value"
- depends on USE_PREBOOT
- default ""
- help
- This is the default of "preboot" environment variable.
+source "common/Kconfig.boot"
menu "Console"
To enable console recording, call console_record_reset_enable()
from your code.
+config CONSOLE_RECORD_INIT_F
+ bool "Enable console recording during pre-relocation init"
+ depends on CONSOLE_RECORD && SYS_MALLOC_F
+ default y
+ help
+ This option enables console recording during pre-relocation init.
+ CONFIG_SYS_MALLOC_F must be enabled to use this feature.
+
config CONSOLE_RECORD_OUT_SIZE
hex "Output buffer size"
depends on CONSOLE_RECORD
removed (for example a USB keyboard) then this option can be
enabled to ensure this is handled correctly.
+config SPL_SYS_STDIO_DEREGISTER
+ bool "Allow deregistering stdio devices in SPL"
+ help
+ Generally there is no need to deregister stdio devices since they
+ are never deactivated. But if a stdio device is used which can be
+ removed (for example a USB keyboard) then this option can be
+ enabled to ensure this is handled correctly. This is very rarely
+ needed in SPL.
+
+config SYS_DEVICE_NULLDEV
+ bool "Enable a null device for stdio"
+ default y if SPLASH_SCREEN || SYS_STDIO_DEREGISTER
+ help
+ Enable creation of a "nulldev" stdio device. This allows silent
+ operation of the console by setting stdout to "nulldev". Enable
+ this to use a serial console under board control.
+
endmenu
menu "Logging"
discarded if not needed. Logging supports various categories and
levels of severity.
-config SPL_LOG
- bool "Enable logging support in SPL"
- depends on LOG
- 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 TPL_LOG
- bool "Enable logging support in TPL"
- depends on LOG
- 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.
+if LOG
config LOG_MAX_LEVEL
int "Maximum log level to record"
- depends on LOG
- default 5
+ default 6
+ range 0 9
help
This selects the maximum log level that will be recorded. Any value
higher than this will be ignored. If possible log statements below
8 - debug content
9 - debug hardware I/O
-config SPL_LOG_MAX_LEVEL
- int "Maximum log level to record in SPL"
- depends on SPL_LOG
- default 3
+config LOG_DEFAULT_LEVEL
+ int "Default logging level to display"
+ default LOG_MAX_LEVEL
+ range 0 LOG_MAX_LEVEL
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:
+ This is the default logging level set when U-Boot starts. It can
+ be adjusted later using the 'log level' command. Note that setting
+ this to a value above LOG_MAX_LEVEL will be ineffective, since the
+ higher levels are not compiled in to U-Boot.
0 - emergency
1 - alert
8 - debug content
9 - debug hardware I/O
-config TPL_LOG_MAX_LEVEL
- int "Maximum log level to record in TPL"
- depends on TPL_LOG
+config LOG_CONSOLE
+ bool "Allow log output to the console"
+ 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 LOGF_FILE
+ bool "Show source file name in log messages by default"
+ help
+ Show the source file name in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_LINE
+ bool "Show source line number in log messages by default"
+ help
+ Show the source line number in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_FUNC
+ bool "Show function name in log messages by default"
+ help
+ Show the function name in log messages by default. This value can
+ be overridden using the 'log format' command.
+
+config LOG_SYSLOG
+ bool "Log output to syslog server"
+ depends on NET
+ help
+ Enables a log driver which broadcasts log records via UDP port 514
+ to syslog servers.
+
+config SPL_LOG
+ bool "Enable logging support in SPL"
+ depends on LOG
+ 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.
+
+if SPL_LOG
+
+config SPL_LOG_MAX_LEVEL
+ int "Maximum log level to record in SPL"
+ depends on SPL_LOG
default 3
+ range 0 9
help
This selects the maximum log level that will be recorded. Any value
higher than this will be ignored. If possible log statements below
8 - debug content
9 - debug hardware I/O
-config LOG_DEFAULT_LEVEL
- int "Default logging level to display"
- default 6
+config SPL_LOG_CONSOLE
+ bool "Allow log output to the console in SPL"
+ default y
help
- This is the default logging level set when U-Boot starts. It can
- be adjusted later using the 'log level' command. Note that setting
- this to a value above LOG_MAX_LEVEL will be ineffective, since the
- higher levels are not compiled in to U-Boot.
+ 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.
+
+endif
+
+config TPL_LOG
+ bool "Enable logging support in TPL"
+ depends on LOG
+ 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.
+
+if TPL_LOG
+
+config TPL_LOG_MAX_LEVEL
+ int "Maximum log level to record in TPL"
+ depends on TPL_LOG
+ default 3
+ range 0 9
+ 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 - emergency
1 - alert
8 - debug content
9 - debug hardware I/O
-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 SPL_LOG_CONSOLE
- bool "Allow log output to the console in SPL"
- depends on SPL_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 TPL_LOG_CONSOLE
bool "Allow log output to the console in TPL"
- depends on TPL_LOG
default y
help
Enables a log driver which writes log records to the console.
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 various settings.
+endif
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 example, reading from SPI flash may
You can add log_ret() to all functions which return an error code.
-endmenu
-
-config SUPPORT_RAW_INITRD
- bool "Enable raw initrd images"
+config LOG_TEST
+ bool "Provide a test for logging"
+ depends on UNIT_TEST
+ default y if SANDBOX
help
- 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>".
+ 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 various settings.
-config DEFAULT_FDT_FILE
- string "Default fdt file"
- help
- This option is used to set the default fdt file to boot OS.
+endif
-config MISC_INIT_R
- bool "Execute Misc Init"
- default y if ARCH_KEYSTONE || ARCH_SUNXI || MPC85xx
- default y if ARCH_OMAP2PLUS && !AM33XX
- help
- Enabling this option calls 'misc_init_r' function
+endmenu
-config VERSION_VARIABLE
- bool "add U-Boot environment variable vers"
- default n
- help
- If this variable is defined, an environment variable
- named "ver" is created by U-Boot showing the U-Boot
- version as printed by the "version" command.
- Any change to this variable will be reverted at the
- next reset.
+menu "Init options"
-config BOARD_LATE_INIT
- bool "Execute Board late init"
+config BOARD_TYPES
+ bool "Call get_board_type() to get and display the board type"
help
- Sometimes board require some initialization code that might
- require once the actual init done, example saving board specific env,
- boot-modes etc. which eventually done at late.
-
- So this config enable the late init code with the help of board_late_init
- function which should defined on respective boards.
+ If this option is enabled, checkboard() will call get_board_type()
+ to get a string containing the board type and this will be
+ displayed immediately after the model is shown on the console
+ early in boot.
config DISPLAY_CPUINFO
bool "Display information about the CPU during start up"
the relocation phase. The board function checkboard() is called to do
this.
-config BOUNCE_BUFFER
- bool "Include bounce buffer API"
- help
- Some peripherals support DMA from a subset of physically
- addressable memory only. To support such peripherals, the
- bounce buffer API uses a temporary buffer: it copies data
- to/from DMA regions while managing cache operations.
-
- A second possible use of bounce buffers is their ability to
- provide aligned buffers for DMA operations.
-
-config BOARD_TYPES
- bool "Call get_board_type() to get and display the board type"
- help
- If this option is enabled, checkboard() will call get_board_type()
- to get a string containing the board type and this will be
- displayed immediately after the model is shown on the console
- early in boot.
-
menu "Start-up hooks"
config ARCH_EARLY_INIT_R
relocation. With this option, U-Boot calls board_early_init_r()
in the post-relocation init sequence.
+config BOARD_LATE_INIT
+ bool "Execute Board late init"
+ help
+ Sometimes board require some initialization code that might
+ require once the actual init done, example saving board specific env,
+ boot-modes etc. which eventually done at late.
+
+ So this config enable the late init code with the help of board_late_init
+ function which should defined on respective boards.
+
config LAST_STAGE_INIT
bool "Call board-specific as last setup step"
help
U-Boot calls last_stage_init() before the command-line interpreter is
started.
+config MISC_INIT_R
+ bool "Execute Misc Init"
+ default y if ARCH_KEYSTONE || ARCH_SUNXI || MPC85xx
+ default y if ARCH_OMAP2PLUS && !AM33XX
+ help
+ Enabling this option calls 'misc_init_r' function
+
+config PCI_INIT_R
+ bool "Enumerate PCI buses during init"
+ depends on PCI
+ default y if !DM_PCI
+ help
+ With this option U-Boot will call pci_init() soon after relocation,
+ which will enumerate PCI buses. This is needed, for instance, in the
+ case of DM PCI-based Ethernet devices, which will not be detected
+ without having the enumeration performed earlier.
+
endmenu
+endmenu # Init options
+
menu "Security support"
config HASH
config AVB_VERIFY
bool "Build Android Verified Boot operations"
- depends on LIBAVB && FASTBOOT
+ depends on LIBAVB
+ depends on MMC
depends on PARTITION_UUIDS
help
This option enables compilation of bootloader-dependent operations,
* Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c.
* Helpers to alloc/init/free avb ops.
+if AVB_VERIFY
+
+config AVB_BUF_ADDR
+ hex "Define AVB buffer address"
+ default FASTBOOT_BUF_ADDR
+ help
+ AVB requires a buffer for memory transactions. This variable defines the
+ buffer address.
+
+config AVB_BUF_SIZE
+ hex "Define AVB buffer SIZE"
+ default FASTBOOT_BUF_SIZE
+ help
+ AVB requires a buffer for memory transactions. This variable defines the
+ buffer size.
+
+endif # AVB_VERIFY
+
config SPL_HASH
bool # "Support hashing API (SHA1, SHA256, etc.)"
help
menu "Update support"
+config UPDATE_COMMON
+ bool
+ default n
+ select DFU_WRITE_ALT
+
config UPDATE_TFTP
bool "Auto-update using fitImage via TFTP"
depends on FIT
+ select UPDATE_COMMON
help
This option allows performing update of NOR with data in fitImage
sent via TFTP boot.
default 100
depends on UPDATE_TFTP
+config UPDATE_FIT
+ bool "Firmware update using fitImage"
+ depends on FIT
+ depends on DFU
+ select UPDATE_COMMON
+ help
+ This option allows performing update of DFU-capable storage with
+ data in fitImage.
+
config ANDROID_AB
bool "Android A/B updates"
default n
Sets the address of the bloblist, set up by the first part of U-Boot
which runs. Subsequent U-Boot stages typically use the same address.
+config BLOBLIST_SIZE_RELOC
+ hex "Size of bloblist after relocation"
+ depends on BLOBLIST
+ default BLOBLIST_SIZE
+ help
+ Sets the size of the bloblist in bytes after relocation. Since U-Boot
+ has a lot more memory available then, it is possible to use a larger
+ size than the one set up by SPL. This bloblist is set up during the
+ relocation process.
+
endmenu
source "common/spl/Kconfig"
select SHA256
help
Enable image_sign_info helper functions.
+
+if IMAGE_SIGN_INFO
+
+config SPL_IMAGE_SIGN_INFO
+ bool
+ select SHA1
+ select SHA256
+ help
+ Enable image_sign_info helper functions in SPL.
+
+endif
projects / platform / kernel / u-boot.git / blobdiff