mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-12-12 14:23:00 +00:00
7b6c34cb15
LOG_DEFAULT_LEVEL has been chosen as 6. Adjust the default of LOG_MAX_LEVEL to this value. Use ranges to clamp log levels to reasonable values. Group output options by main U-Boot, SPL, TPL, followed by other logging options. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
1094 lines
37 KiB
Text
1094 lines
37 KiB
Text
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.
|
|
|
|
menu "Console"
|
|
|
|
config MENU
|
|
bool
|
|
help
|
|
This is the library functionality to provide a text-based menu of
|
|
choices for the user to make choices with.
|
|
|
|
config CONSOLE_RECORD
|
|
bool "Console recording"
|
|
help
|
|
This provides a way to record console output (and provide console
|
|
input) through circular buffers. This is mostly useful for testing.
|
|
Console output is recorded even when the console is silent.
|
|
To enable console recording, call console_record_reset_enable()
|
|
from your code.
|
|
|
|
config CONSOLE_RECORD_OUT_SIZE
|
|
hex "Output buffer size"
|
|
depends on CONSOLE_RECORD
|
|
default 0x400 if CONSOLE_RECORD
|
|
help
|
|
Set the size of the console output buffer. When this fills up, no
|
|
more data will be recorded until some is removed. The buffer is
|
|
allocated immediately after the malloc() region is ready.
|
|
|
|
config CONSOLE_RECORD_IN_SIZE
|
|
hex "Input buffer size"
|
|
depends on CONSOLE_RECORD
|
|
default 0x100 if CONSOLE_RECORD
|
|
help
|
|
Set the size of the console input buffer. When this contains data,
|
|
tstc() and getc() will use this in preference to real device input.
|
|
The buffer is allocated immediately after the malloc() region is
|
|
ready.
|
|
|
|
config DISABLE_CONSOLE
|
|
bool "Add functionality to disable console completely"
|
|
help
|
|
Disable console (in & out).
|
|
|
|
config IDENT_STRING
|
|
string "Board specific string to be added to uboot version string"
|
|
help
|
|
This options adds the board specific name to u-boot version.
|
|
|
|
config LOGLEVEL
|
|
int "loglevel"
|
|
default 4
|
|
range 0 10
|
|
help
|
|
All Messages with a loglevel smaller than the console loglevel will
|
|
be compiled in. The loglevels are defined as follows:
|
|
|
|
0 - emergency
|
|
1 - alert
|
|
2 - critical
|
|
3 - error
|
|
4 - warning
|
|
5 - note
|
|
6 - info
|
|
7 - debug
|
|
8 - debug content
|
|
9 - debug hardware I/O
|
|
|
|
config SPL_LOGLEVEL
|
|
int
|
|
default LOGLEVEL
|
|
|
|
config TPL_LOGLEVEL
|
|
int
|
|
default LOGLEVEL
|
|
|
|
config SILENT_CONSOLE
|
|
bool "Support a silent console"
|
|
help
|
|
This option allows the console to be silenced, meaning that no
|
|
output will appear on the console devices. This is controlled by
|
|
setting the environment variable 'silent' to a non-empty value.
|
|
Note this also silences the console when booting Linux.
|
|
|
|
When the console is set up, the variable is checked, and the
|
|
GD_FLG_SILENT flag is set. Changing the environment variable later
|
|
will update the flag.
|
|
|
|
config SILENT_U_BOOT_ONLY
|
|
bool "Only silence the U-Boot console"
|
|
depends on SILENT_CONSOLE
|
|
help
|
|
Normally when the U-Boot console is silenced, Linux's console is
|
|
also silenced (assuming the board boots into Linux). This option
|
|
allows the linux console to operate normally, even if U-Boot's
|
|
is silenced.
|
|
|
|
config SILENT_CONSOLE_UPDATE_ON_SET
|
|
bool "Changes to the 'silent' environment variable update immediately"
|
|
depends on SILENT_CONSOLE
|
|
default y if SILENT_CONSOLE
|
|
help
|
|
When the 'silent' environment variable is changed, update the
|
|
console silence flag immediately. This allows 'setenv' to be used
|
|
to silence or un-silence the console.
|
|
|
|
The effect is that any change to the variable will affect the
|
|
GD_FLG_SILENT flag.
|
|
|
|
config SILENT_CONSOLE_UPDATE_ON_RELOC
|
|
bool "Allow flags to take effect on relocation"
|
|
depends on SILENT_CONSOLE
|
|
help
|
|
In some cases the environment is not available until relocation
|
|
(e.g. NAND). This option makes the value of the 'silent'
|
|
environment variable take effect at relocation.
|
|
|
|
config PRE_CONSOLE_BUFFER
|
|
bool "Buffer characters before the console is available"
|
|
help
|
|
Prior to the console being initialised (i.e. serial UART
|
|
initialised etc) all console output is silently discarded.
|
|
Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
|
|
buffer any console messages prior to the console being
|
|
initialised to a buffer. The buffer is a circular buffer, so
|
|
if it overflows, earlier output is discarded.
|
|
|
|
Note that this is not currently supported in SPL. It would be
|
|
useful to be able to share the pre-console buffer with SPL.
|
|
|
|
config PRE_CON_BUF_SZ
|
|
int "Sets the size of the pre-console buffer"
|
|
depends on PRE_CONSOLE_BUFFER
|
|
default 4096
|
|
help
|
|
The size of the pre-console buffer affects how much console output
|
|
can be held before it overflows and starts discarding earlier
|
|
output. Normally there is very little output at this early stage,
|
|
unless debugging is enabled, so allow enough for ~10 lines of
|
|
text.
|
|
|
|
This is a useful feature if you are using a video console and
|
|
want to see the full boot output on the console. Without this
|
|
option only the post-relocation output will be displayed.
|
|
|
|
config PRE_CON_BUF_ADDR
|
|
hex "Address of the pre-console buffer"
|
|
depends on PRE_CONSOLE_BUFFER
|
|
default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
|
|
default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
|
|
default 0x0f000000 if ROCKCHIP_RK3288
|
|
default 0x0f200000 if ROCKCHIP_RK3399
|
|
help
|
|
This sets the start address of the pre-console buffer. This must
|
|
be in available memory and is accessed before relocation and
|
|
possibly before DRAM is set up. Therefore choose an address
|
|
carefully.
|
|
|
|
We should consider removing this option and allocating the memory
|
|
in board_init_f_init_reserve() instead.
|
|
|
|
config CONSOLE_MUX
|
|
bool "Enable console multiplexing"
|
|
default y if DM_VIDEO || VIDEO || LCD
|
|
help
|
|
This allows multiple devices to be used for each console 'file'.
|
|
For example, stdout can be set to go to serial and video.
|
|
Similarly, stdin can be set to come from serial and keyboard.
|
|
Input can be provided from either source. Console multiplexing
|
|
adds a small amount of size to U-Boot. Changes to the environment
|
|
variables stdout, stdin and stderr will take effect immediately.
|
|
|
|
config SYS_CONSOLE_IS_IN_ENV
|
|
bool "Select console devices from the environment"
|
|
default y if CONSOLE_MUX
|
|
help
|
|
This allows multiple input/output devices to be set at boot time.
|
|
For example, if stdout is set to "serial,video" then output will
|
|
be sent to both the serial and video devices on boot. The
|
|
environment variables can be updated after boot to change the
|
|
input/output devices.
|
|
|
|
config SYS_CONSOLE_OVERWRITE_ROUTINE
|
|
bool "Allow board control over console overwriting"
|
|
help
|
|
If this is enabled, and the board-specific function
|
|
overwrite_console() returns 1, the stdin, stderr and stdout are
|
|
switched to the serial port, else the settings in the environment
|
|
are used. If this is not enabled, the console will not be switched
|
|
to serial.
|
|
|
|
config SYS_CONSOLE_ENV_OVERWRITE
|
|
bool "Update environment variables during console init"
|
|
help
|
|
The console environment variables (stdout, stdin, stderr) can be
|
|
used to determine the correct console devices on start-up. This
|
|
option writes the console devices to these variables on console
|
|
start-up (after relocation). This causes the environment to be
|
|
updated to match the console devices actually chosen.
|
|
|
|
config SYS_CONSOLE_INFO_QUIET
|
|
bool "Don't display the console devices on boot"
|
|
help
|
|
Normally U-Boot displays the current settings for stdout, stdin
|
|
and stderr on boot when the post-relocation console is set up.
|
|
Enable this option to suppress this output. It can be obtained by
|
|
calling stdio_print_current_devices() from board code.
|
|
|
|
config SYS_STDIO_DEREGISTER
|
|
bool "Allow deregistering stdio devices"
|
|
default y if USB_KEYBOARD
|
|
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.
|
|
|
|
endmenu
|
|
|
|
menu "Logging"
|
|
|
|
config LOG
|
|
bool "Enable logging support"
|
|
depends on DM
|
|
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"
|
|
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
|
|
this level will be discarded at build time. Levels:
|
|
|
|
0 - emergency
|
|
1 - alert
|
|
2 - critical
|
|
3 - error
|
|
4 - warning
|
|
5 - note
|
|
6 - info
|
|
7 - debug
|
|
8 - debug content
|
|
9 - debug hardware I/O
|
|
|
|
config LOG_DEFAULT_LEVEL
|
|
int "Default logging level to display"
|
|
default LOG_MAX_LEVEL
|
|
range 0 LOG_MAX_LEVEL
|
|
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.
|
|
|
|
0 - emergency
|
|
1 - alert
|
|
2 - critical
|
|
3 - error
|
|
4 - warning
|
|
5 - note
|
|
6 - info
|
|
7 - debug
|
|
8 - debug content
|
|
9 - debug hardware I/O
|
|
|
|
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 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
|
|
this level will be discarded at build time. Levels:
|
|
|
|
0 - emergency
|
|
1 - alert
|
|
2 - critical
|
|
3 - error
|
|
4 - warning
|
|
5 - note
|
|
6 - info
|
|
7 - debug
|
|
8 - debug content
|
|
9 - debug hardware I/O
|
|
|
|
config SPL_LOG_CONSOLE
|
|
bool "Allow log output to the console in 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.
|
|
|
|
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
|
|
2 - critical
|
|
3 - error
|
|
4 - warning
|
|
5 - note
|
|
6 - info
|
|
7 - debug
|
|
8 - debug content
|
|
9 - debug hardware I/O
|
|
|
|
config TPL_LOG_CONSOLE
|
|
bool "Allow log output to the console in TPL"
|
|
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.
|
|
|
|
endif
|
|
|
|
config LOG_ERROR_RETURN
|
|
bool "Log all functions which return an error"
|
|
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
|
|
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.
|
|
|
|
config LOG_TEST
|
|
bool "Provide a test for logging"
|
|
depends on UNIT_TEST
|
|
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
|
|
|
|
endmenu
|
|
|
|
config SUPPORT_RAW_INITRD
|
|
bool "Enable raw initrd images"
|
|
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>".
|
|
|
|
config DEFAULT_FDT_FILE
|
|
string "Default fdt file"
|
|
help
|
|
This option is used to set the default fdt file to boot OS.
|
|
|
|
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 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.
|
|
|
|
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 DISPLAY_CPUINFO
|
|
bool "Display information about the CPU during start up"
|
|
default y if ARC|| 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
|
|
to do this.
|
|
|
|
config DISPLAY_BOARDINFO
|
|
bool "Display information about the board during early start up"
|
|
default y if ARC || 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.
|
|
|
|
config DISPLAY_BOARDINFO_LATE
|
|
bool "Display information about the board during late start up"
|
|
help
|
|
Display information about the board that U-Boot is running on after
|
|
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
|
|
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 relocation.
|
|
|
|
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.
|
|
|
|
config BOARD_EARLY_INIT_R
|
|
bool "Call board-specific init after relocation"
|
|
help
|
|
Some boards need to perform initialisation as directly after
|
|
relocation. With this option, U-Boot calls board_early_init_r()
|
|
in the post-relocation init sequence.
|
|
|
|
config LAST_STAGE_INIT
|
|
bool "Call board-specific as last setup step"
|
|
help
|
|
Some boards need to perform initialisation immediately before control
|
|
is passed to the command-line interpreter (e.g. for initializations
|
|
that depend on later phases in the init sequence). With this option,
|
|
U-Boot calls last_stage_init() before the command-line interpreter is
|
|
started.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
config AVB_VERIFY
|
|
bool "Build Android Verified Boot operations"
|
|
depends on LIBAVB && FASTBOOT
|
|
depends on PARTITION_UUIDS
|
|
help
|
|
This option enables compilation of bootloader-dependent operations,
|
|
used by Android Verified Boot 2.0 library (libavb). Includes:
|
|
* Helpers to process strings in order to build OS bootargs.
|
|
* Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c.
|
|
* Helpers to alloc/init/free avb ops.
|
|
|
|
config SPL_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.
|
|
|
|
config TPL_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
|
|
|
|
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
|
|
|
|
config ANDROID_AB
|
|
bool "Android A/B updates"
|
|
default n
|
|
help
|
|
If enabled, adds support for the new Android A/B update model. This
|
|
allows the bootloader to select which slot to boot from based on the
|
|
information provided by userspace via the Android boot_ctrl HAL. This
|
|
allows a bootloader to try a new version of the system but roll back
|
|
to previous version if the new one didn't boot all the way.
|
|
|
|
endmenu
|
|
|
|
menu "Blob list"
|
|
|
|
config BLOBLIST
|
|
bool "Support for a bloblist"
|
|
help
|
|
This enables support for a bloblist in U-Boot, which can be passed
|
|
from TPL to SPL to U-Boot proper (and potentially to Linux). The
|
|
blob list supports multiple binary blobs of data, each with a tag,
|
|
so that different U-Boot components can store data which can survive
|
|
through to the next stage of the boot.
|
|
|
|
config SPL_BLOBLIST
|
|
bool "Support for a bloblist in SPL"
|
|
depends on BLOBLIST
|
|
default y if SPL
|
|
help
|
|
This enables a bloblist in SPL. If this is the first part of U-Boot
|
|
to run, then the bloblist is set up in SPL and passed to U-Boot
|
|
proper. If TPL also has a bloblist, then SPL uses the one from there.
|
|
|
|
config TPL_BLOBLIST
|
|
bool "Support for a bloblist in TPL"
|
|
depends on BLOBLIST
|
|
default y if TPL
|
|
help
|
|
This enables a bloblist in TPL. The bloblist is set up in TPL and
|
|
passed to SPL and U-Boot proper.
|
|
|
|
config BLOBLIST_SIZE
|
|
hex "Size of bloblist"
|
|
depends on BLOBLIST
|
|
default 0x400
|
|
help
|
|
Sets the size of the bloblist in bytes. This must include all
|
|
overhead (alignment, bloblist header, record header). The bloblist
|
|
is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
|
|
proper), and this sane bloblist is used for subsequent stages.
|
|
|
|
config BLOBLIST_ADDR
|
|
hex "Address of bloblist"
|
|
depends on BLOBLIST
|
|
default 0xe000 if SANDBOX
|
|
help
|
|
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.
|
|
|
|
endmenu
|
|
|
|
source "common/spl/Kconfig"
|
|
|
|
config IMAGE_SIGN_INFO
|
|
bool
|
|
select SHA1
|
|
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
|