2016-10-18 02:12:35 +00:00
|
|
|
menu "Console"
|
|
|
|
|
2016-11-29 14:14:56 +00:00
|
|
|
config MENU
|
|
|
|
bool
|
|
|
|
help
|
|
|
|
This is the library functionality to provide a text-based menu of
|
|
|
|
choices for the user to make choices with.
|
|
|
|
|
2015-11-09 06:47:48 +00:00
|
|
|
config CONSOLE_RECORD
|
|
|
|
bool "Console recording"
|
|
|
|
help
|
|
|
|
This provides a way to record console output (and provide console
|
2016-08-31 16:49:13 +00:00
|
|
|
input) through circular buffers. This is mostly useful for testing.
|
2015-11-09 06:47:48 +00:00
|
|
|
Console output is recorded even when the console is silent.
|
|
|
|
To enable console recording, call console_record_reset_enable()
|
|
|
|
from your code.
|
|
|
|
|
2020-11-28 08:43:03 +00:00
|
|
|
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.
|
|
|
|
|
2015-11-09 06:47:48 +00:00
|
|
|
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.
|
|
|
|
|
2021-10-23 23:26:03 +00:00
|
|
|
config CONSOLE_RECORD_OUT_SIZE_F
|
|
|
|
hex "Output buffer size before relocation"
|
|
|
|
depends on CONSOLE_RECORD
|
|
|
|
default 0x400 if CONSOLE_RECORD
|
|
|
|
help
|
|
|
|
Set the size of the console output buffer before relocation. When
|
|
|
|
this fills up, no more data will be recorded until some is removed.
|
|
|
|
The buffer is allocated immediately after the early malloc() region is
|
|
|
|
ready.
|
|
|
|
|
2015-11-09 06:47:48 +00:00
|
|
|
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.
|
2016-07-19 05:12:22 +00:00
|
|
|
|
2018-09-10 10:43:16 +00:00
|
|
|
config DISABLE_CONSOLE
|
|
|
|
bool "Add functionality to disable console completely"
|
|
|
|
help
|
|
|
|
Disable console (in & out).
|
|
|
|
|
2016-07-29 10:01:47 +00:00
|
|
|
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.
|
|
|
|
|
printk: collect printk stuff into <linux/printk.h> with loglevel support
When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support them in a clean
way. So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.
We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround. Hence this
patch, to find the best home for all printk variants. If you want to
use printk() and friends, please include <linux/printk.h>. This header
is self-contained, and pulls in only a few headers.
When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards. This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.
To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel". (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.
The difference is the loglevel is build-time determined. To save the
image size, lower priority pr_*() are compiled out. I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.
I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-09-16 05:10:40 +00:00
|
|
|
config LOGLEVEL
|
|
|
|
int "loglevel"
|
2017-10-04 20:44:30 +00:00
|
|
|
default 4
|
2020-02-03 10:43:32 +00:00
|
|
|
range 0 10
|
printk: collect printk stuff into <linux/printk.h> with loglevel support
When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support them in a clean
way. So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.
We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround. Hence this
patch, to find the best home for all printk variants. If you want to
use printk() and friends, please include <linux/printk.h>. This header
is self-contained, and pulls in only a few headers.
When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards. This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.
To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel". (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.
The difference is the loglevel is build-time determined. To save the
image size, lower priority pr_*() are compiled out. I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.
I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-09-16 05:10:40 +00:00
|
|
|
help
|
|
|
|
All Messages with a loglevel smaller than the console loglevel will
|
|
|
|
be compiled in. The loglevels are defined as follows:
|
|
|
|
|
2019-02-17 03:24:34 +00:00
|
|
|
0 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
|
|
|
7 - debug
|
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
printk: collect printk stuff into <linux/printk.h> with loglevel support
When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support them in a clean
way. So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.
We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround. Hence this
patch, to find the best home for all printk variants. If you want to
use printk() and friends, please include <linux/printk.h>. This header
is self-contained, and pulls in only a few headers.
When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards. This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.
To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel". (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.
The difference is the loglevel is build-time determined. To save the
image size, lower priority pr_*() are compiled out. I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.
I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-09-16 05:10:40 +00:00
|
|
|
|
|
|
|
config SPL_LOGLEVEL
|
|
|
|
int
|
|
|
|
default LOGLEVEL
|
|
|
|
|
2018-11-16 01:43:49 +00:00
|
|
|
config TPL_LOGLEVEL
|
|
|
|
int
|
|
|
|
default LOGLEVEL
|
|
|
|
|
2022-04-30 06:56:53 +00:00
|
|
|
config VPL_LOGLEVEL
|
|
|
|
int "loglevel for VPL"
|
|
|
|
default LOGLEVEL
|
|
|
|
help
|
|
|
|
All Messages with a loglevel smaller than the console loglevel will
|
|
|
|
be compiled in to VPL. See LOGLEVEL for a list of available log
|
|
|
|
levels. Setting this to a value above 4 may increase the code size
|
|
|
|
significantly.
|
|
|
|
|
2016-10-18 02:12:35 +00:00
|
|
|
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
|
2019-01-11 02:30:50 +00:00
|
|
|
setting the environment variable 'silent' to a non-empty value.
|
2016-10-18 02:12:35 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-18 02:12:36 +00:00
|
|
|
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
|
2020-01-23 14:12:19 +00:00
|
|
|
default 0x0f000000 if ROCKCHIP_RK3288
|
2020-04-02 11:41:23 +00:00
|
|
|
default 0x0f200000 if ROCKCHIP_RK3399
|
2016-10-18 02:12:36 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-18 02:12:37 +00:00
|
|
|
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.
|
2021-10-04 14:04:32 +00:00
|
|
|
For example, if stdout is set to "serial,vidconsole" then output
|
|
|
|
will be sent to both the serial and video devices on boot. The
|
2016-10-18 02:12:37 +00:00
|
|
|
environment variables can be updated after boot to change the
|
|
|
|
input/output devices.
|
|
|
|
|
2016-10-18 02:12:59 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-18 02:12:58 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-18 02:13:00 +00:00
|
|
|
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.
|
2019-01-11 02:30:50 +00:00
|
|
|
Enable this option to suppress this output. It can be obtained by
|
2016-10-18 02:13:00 +00:00
|
|
|
calling stdio_print_current_devices() from board code.
|
|
|
|
|
2016-10-18 02:13:02 +00:00
|
|
|
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.
|
|
|
|
|
2020-08-11 17:23:36 +00:00
|
|
|
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"
|
2020-08-11 17:23:37 +00:00
|
|
|
default y if SPLASH_SCREEN || SYS_STDIO_DEREGISTER
|
2020-08-11 17:23:36 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-18 02:12:35 +00:00
|
|
|
endmenu
|
|
|
|
|
2017-12-04 20:48:24 +00:00
|
|
|
menu "Logging"
|
|
|
|
|
|
|
|
config LOG
|
|
|
|
bool "Enable logging support"
|
2018-07-23 13:55:11 +00:00
|
|
|
depends on DM
|
2017-12-04 20:48:24 +00:00
|
|
|
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.
|
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
if LOG
|
2017-12-04 20:48:24 +00:00
|
|
|
|
2022-04-30 06:56:53 +00:00
|
|
|
config VPL_LOG
|
|
|
|
bool "Enable logging support in VPL"
|
|
|
|
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.
|
|
|
|
|
2017-12-04 20:48:24 +00:00
|
|
|
config LOG_MAX_LEVEL
|
|
|
|
int "Maximum log level to record"
|
2020-05-31 13:34:22 +00:00
|
|
|
default 6
|
|
|
|
range 0 9
|
2017-12-04 20:48:24 +00:00
|
|
|
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:
|
|
|
|
|
2019-02-17 03:24:34 +00:00
|
|
|
0 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
2017-12-04 20:48:24 +00:00
|
|
|
7 - debug
|
2019-02-17 03:24:34 +00:00
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
2017-12-04 20:48:24 +00:00
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
config LOG_DEFAULT_LEVEL
|
|
|
|
int "Default logging level to display"
|
|
|
|
default LOG_MAX_LEVEL
|
|
|
|
range 0 LOG_MAX_LEVEL
|
2017-12-04 20:48:24 +00:00
|
|
|
help
|
2020-05-31 13:34:22 +00:00
|
|
|
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.
|
2017-12-04 20:48:24 +00:00
|
|
|
|
2019-02-17 03:24:34 +00:00
|
|
|
0 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
2017-12-04 20:48:24 +00:00
|
|
|
7 - debug
|
2019-02-17 03:24:34 +00:00
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
2017-12-04 20:48:24 +00:00
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
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.
|
|
|
|
|
2020-06-17 19:52:44 +00:00
|
|
|
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.
|
|
|
|
|
2021-07-05 22:33:00 +00:00
|
|
|
config LOGF_FUNC_PAD
|
|
|
|
int "Number of characters to use for function"
|
|
|
|
default 20
|
|
|
|
help
|
|
|
|
Sets the field width to use when showing the function. Set this to
|
|
|
|
a larger value if you have lots of long function names, and want
|
|
|
|
things to line up.
|
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
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
|
2018-11-16 01:43:49 +00:00
|
|
|
default 3
|
2020-05-31 13:34:22 +00:00
|
|
|
range 0 9
|
2018-11-16 01:43:49 +00:00
|
|
|
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:
|
|
|
|
|
2019-02-17 03:24:34 +00:00
|
|
|
0 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
2018-11-16 01:43:49 +00:00
|
|
|
7 - debug
|
2019-02-17 03:24:34 +00:00
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
2018-11-16 01:43:49 +00:00
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
config SPL_LOG_CONSOLE
|
|
|
|
bool "Allow log output to the console in SPL"
|
|
|
|
default y
|
2019-02-17 03:24:35 +00:00
|
|
|
help
|
2020-05-31 13:34:22 +00:00
|
|
|
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:
|
2019-02-17 03:24:35 +00:00
|
|
|
|
|
|
|
0 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
|
|
|
7 - debug
|
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
|
|
|
|
2018-11-16 01:43:49 +00:00
|
|
|
config TPL_LOG_CONSOLE
|
2019-10-02 14:55:06 +00:00
|
|
|
bool "Allow log output to the console in TPL"
|
2017-12-04 20:48:25 +00:00
|
|
|
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.
|
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
endif
|
2017-12-04 20:48:27 +00:00
|
|
|
|
2022-04-30 06:56:53 +00:00
|
|
|
config VPL_LOG
|
|
|
|
bool "Enable logging support in VPL"
|
|
|
|
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 VPL_LOG
|
|
|
|
|
|
|
|
config VPL_LOG_MAX_LEVEL
|
|
|
|
int "Maximum log level to record in VPL"
|
|
|
|
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 - emergency
|
|
|
|
1 - alert
|
|
|
|
2 - critical
|
|
|
|
3 - error
|
|
|
|
4 - warning
|
|
|
|
5 - note
|
|
|
|
6 - info
|
|
|
|
7 - debug
|
|
|
|
8 - debug content
|
|
|
|
9 - debug hardware I/O
|
|
|
|
|
|
|
|
config VPL_LOG_CONSOLE
|
|
|
|
bool "Allow log output to the console in VPL"
|
|
|
|
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
|
|
|
|
|
2017-12-28 20:14:23 +00:00
|
|
|
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
|
2019-01-11 02:30:50 +00:00
|
|
|
figure out the root cause. For example, reading from SPI flash may
|
2017-12-28 20:14:23 +00:00
|
|
|
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.
|
|
|
|
|
2020-05-31 13:34:22 +00:00
|
|
|
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
|
|
|
|
|
2017-12-04 20:48:24 +00:00
|
|
|
endmenu
|
|
|
|
|
2020-09-11 02:21:21 +00:00
|
|
|
menu "Init options"
|
|
|
|
|
2020-09-11 02:21:26 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-08 18:41:44 +00:00
|
|
|
config DISPLAY_CPUINFO
|
|
|
|
bool "Display information about the CPU during start up"
|
2018-10-02 08:43:28 +00:00
|
|
|
default y if ARC|| ARM || NIOS2 || X86 || XTENSA || M68K
|
2016-10-08 18:41:44 +00:00
|
|
|
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.
|
|
|
|
|
2016-10-12 01:33:46 +00:00
|
|
|
config DISPLAY_BOARDINFO
|
2018-03-28 12:38:17 +00:00
|
|
|
bool "Display information about the board during early start up"
|
2018-10-02 08:43:28 +00:00
|
|
|
default y if ARC || ARM || M68K || MIPS || PPC || SANDBOX || XTENSA
|
2016-10-12 01:33:46 +00:00
|
|
|
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.
|
|
|
|
|
2018-03-28 12:38:17 +00:00
|
|
|
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.
|
|
|
|
|
2017-01-23 20:31:19 +00:00
|
|
|
menu "Start-up hooks"
|
|
|
|
|
2022-03-04 15:43:00 +00:00
|
|
|
config EVENT
|
|
|
|
bool "General-purpose event-handling mechanism"
|
|
|
|
default y if SANDBOX
|
|
|
|
help
|
|
|
|
This enables sending and processing of events, to allow interested
|
|
|
|
parties to be alerted when something happens. This is an attempt to
|
|
|
|
step the flow of weak functions, hooks, functions in board_f.c
|
|
|
|
and board_r.c and the Kconfig options below.
|
|
|
|
|
|
|
|
See doc/develop/event.rst for more information.
|
|
|
|
|
|
|
|
if EVENT
|
|
|
|
|
|
|
|
config EVENT_DYNAMIC
|
|
|
|
bool "Support event registration at runtime"
|
|
|
|
default y if SANDBOX
|
|
|
|
help
|
|
|
|
Enable this to support adding an event spy at runtime, without adding
|
|
|
|
it to the EVENT_SPy() linker list. This increases code size slightly
|
|
|
|
but provides more flexibility for boards and subsystems that need it.
|
|
|
|
|
|
|
|
config EVENT_DEBUG
|
|
|
|
bool "Enable event debugging assistance"
|
|
|
|
default y if SANDBOX
|
|
|
|
help
|
|
|
|
Enable this get usefui features for seeing what is happening with
|
|
|
|
events, such as event-type names. This adds to the code size of
|
|
|
|
U-Boot so can be turned off for production builds.
|
|
|
|
|
|
|
|
endif # EVENT
|
|
|
|
|
2017-01-23 20:31:19 +00:00
|
|
|
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.
|
|
|
|
|
2017-01-23 20:31:21 +00:00
|
|
|
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
|
2019-01-11 02:30:50 +00:00
|
|
|
and will be called after the console is set up, after relocation.
|
2017-01-23 20:31:21 +00:00
|
|
|
|
2017-01-23 20:31:20 +00:00
|
|
|
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.
|
|
|
|
|
2018-03-28 12:38:15 +00:00
|
|
|
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.
|
|
|
|
|
2022-02-25 16:19:47 +00:00
|
|
|
config BOARD_POSTCLK_INIT
|
|
|
|
bool "Call board_postclk_init"
|
|
|
|
help
|
|
|
|
Some boards need this to initialize select items, after clocks /
|
|
|
|
timebase and before env / serial.
|
|
|
|
|
2020-09-11 02:21:23 +00:00
|
|
|
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.
|
|
|
|
|
2022-03-23 21:20:08 +00:00
|
|
|
config CLOCKS
|
|
|
|
bool "Call set_cpu_clk_info"
|
|
|
|
depends on ARM
|
|
|
|
|
2021-12-13 03:12:34 +00:00
|
|
|
config SYS_FSL_CLK
|
|
|
|
bool
|
|
|
|
depends on ARCH_LS1021A || FSL_LSCH2 || FSL_LSCH3 || \
|
|
|
|
(FSL_ESDHC_IMX && (ARCH_MX5 || ARCH_MX6 || ARCH_MX7))
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable to call get_clocks() in board_init_f() for platforms other
|
|
|
|
than PowerPC or M68k. This is a legacy option. If not TARGET_BRPPT2
|
|
|
|
|
2018-03-28 12:38:16 +00:00
|
|
|
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.
|
|
|
|
|
2020-09-11 02:21:23 +00:00
|
|
|
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
|
|
|
|
|
2021-08-17 21:59:41 +00:00
|
|
|
config ID_EEPROM
|
|
|
|
bool "Enable I2C connected system identifier EEPROM"
|
|
|
|
help
|
|
|
|
A number of different systems and vendors enable a vendor-specified
|
|
|
|
EEPROM that contains various identifying features.
|
|
|
|
|
2020-05-06 17:38:44 +00:00
|
|
|
config PCI_INIT_R
|
|
|
|
bool "Enumerate PCI buses during init"
|
|
|
|
depends on 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.
|
|
|
|
|
2022-03-18 12:38:20 +00:00
|
|
|
config RESET_PHY_R
|
|
|
|
bool "Reset ethernet PHY during init"
|
|
|
|
help
|
|
|
|
Implement reset_phy() in board code if required to reset the ethernet
|
|
|
|
PHY.
|
|
|
|
|
2017-01-23 20:31:19 +00:00
|
|
|
endmenu
|
|
|
|
|
2020-09-11 02:21:22 +00:00
|
|
|
endmenu # Init options
|
|
|
|
|
2017-05-17 15:05:34 +00:00
|
|
|
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.
|
|
|
|
|
2018-07-17 11:33:25 +00:00
|
|
|
config AVB_VERIFY
|
|
|
|
bool "Build Android Verified Boot operations"
|
2020-08-11 14:46:03 +00:00
|
|
|
depends on LIBAVB
|
2021-01-25 11:17:57 +00:00
|
|
|
depends on MMC
|
2018-08-14 00:43:05 +00:00
|
|
|
depends on PARTITION_UUIDS
|
2018-07-17 11:33:25 +00:00
|
|
|
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.
|
|
|
|
|
2020-08-11 14:46:03 +00:00
|
|
|
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
|
|
|
|
|
2021-02-14 15:27:23 +00:00
|
|
|
config SCP03
|
|
|
|
bool "Build SCP03 - Secure Channel Protocol O3 - controls"
|
|
|
|
depends on OPTEE || SANDBOX
|
|
|
|
depends on TEE
|
|
|
|
help
|
|
|
|
This option allows U-Boot to enable and or provision SCP03 on an OPTEE
|
|
|
|
controlled Secured Element.
|
|
|
|
|
2018-11-06 22:21:28 +00:00
|
|
|
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.
|
|
|
|
|
2021-04-11 09:21:58 +00:00
|
|
|
config STACKPROTECTOR
|
|
|
|
bool "Stack Protector buffer overflow detection"
|
|
|
|
help
|
|
|
|
Enable stack smash detection through compiler's stack-protector
|
|
|
|
canary logic
|
|
|
|
|
|
|
|
config SPL_STACKPROTECTOR
|
|
|
|
bool "Stack Protector buffer overflow detection for SPL"
|
|
|
|
depends on STACKPROTECTOR && SPL
|
|
|
|
|
|
|
|
config TPL_STACKPROTECTOR
|
|
|
|
bool "Stack Protector buffer overflow detection for TPL"
|
|
|
|
depends on STACKPROTECTOR && TPL
|
|
|
|
|
2017-05-17 15:05:34 +00:00
|
|
|
endmenu
|
|
|
|
|
2018-02-10 15:22:06 +00:00
|
|
|
menu "Update support"
|
|
|
|
|
2020-10-29 04:47:43 +00:00
|
|
|
config UPDATE_COMMON
|
|
|
|
bool
|
|
|
|
select DFU_WRITE_ALT
|
|
|
|
|
2018-02-10 15:22:06 +00:00
|
|
|
config UPDATE_TFTP
|
|
|
|
bool "Auto-update using fitImage via TFTP"
|
|
|
|
depends on FIT
|
2020-10-29 04:47:43 +00:00
|
|
|
select UPDATE_COMMON
|
2018-02-10 15:22:06 +00:00
|
|
|
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
|
|
|
|
|
2020-10-29 04:47:43 +00:00
|
|
|
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.
|
|
|
|
|
2019-07-05 12:37:32 +00:00
|
|
|
config ANDROID_AB
|
|
|
|
bool "Android A/B updates"
|
|
|
|
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.
|
|
|
|
|
2018-02-10 15:22:06 +00:00
|
|
|
endmenu
|
|
|
|
|
2018-11-16 01:43:50 +00:00
|
|
|
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
|
2022-01-13 02:26:21 +00:00
|
|
|
through to the next phase of the boot.
|
2018-11-16 01:43:50 +00:00
|
|
|
|
|
|
|
config SPL_BLOBLIST
|
|
|
|
bool "Support for a bloblist in SPL"
|
2022-04-30 06:56:48 +00:00
|
|
|
depends on BLOBLIST && SPL_LIBGENERIC_SUPPORT && SPL_LIBCOMMON_SUPPORT
|
2018-11-16 01:43:50 +00:00
|
|
|
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"
|
2022-04-30 06:56:48 +00:00
|
|
|
depends on BLOBLIST && TPL_LIBGENERIC_SUPPORT && TPL_LIBCOMMON_SUPPORT
|
2018-11-16 01:43:50 +00:00
|
|
|
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.
|
2022-04-30 06:56:53 +00:00
|
|
|
|
|
|
|
config VPL_BLOBLIST
|
|
|
|
bool "Support for a bloblist in VPL"
|
|
|
|
depends on BLOBLIST && VPL_LIBGENERIC_SUPPORT && VPL_LIBCOMMON_SUPPORT
|
|
|
|
default y if VPL
|
|
|
|
help
|
|
|
|
This enables a bloblist in VPL. The bloblist is set up in VPL and
|
|
|
|
passed to SPL and U-Boot proper.
|
2018-11-16 01:43:50 +00:00
|
|
|
|
2021-11-04 03:09:20 +00:00
|
|
|
if BLOBLIST
|
|
|
|
|
2022-01-13 02:26:22 +00:00
|
|
|
choice
|
|
|
|
prompt "Bloblist location"
|
2018-11-16 01:43:50 +00:00
|
|
|
help
|
2022-01-13 02:26:22 +00:00
|
|
|
Select the location of the bloblist, via various means.
|
|
|
|
|
|
|
|
config BLOBLIST_FIXED
|
|
|
|
bool "Place bloblist at a fixed address in memory"
|
|
|
|
help
|
|
|
|
Select this to used a fixed memory address for the bloblist. If the
|
|
|
|
bloblist exists at this address from a previous phase, it used as is.
|
|
|
|
If not it is created at this address in U-Boot.
|
2018-11-16 01:43:50 +00:00
|
|
|
|
2021-11-04 03:09:20 +00:00
|
|
|
config BLOBLIST_ALLOC
|
|
|
|
bool "Allocate bloblist"
|
|
|
|
help
|
|
|
|
Allocate the bloblist using malloc(). This avoids the need to
|
|
|
|
specify a fixed address on systems where this is unknown or can
|
|
|
|
change at runtime.
|
|
|
|
|
2022-01-13 02:26:22 +00:00
|
|
|
endchoice
|
|
|
|
|
2018-11-16 01:43:50 +00:00
|
|
|
config BLOBLIST_ADDR
|
|
|
|
hex "Address of bloblist"
|
2021-07-05 22:32:48 +00:00
|
|
|
default 0xc000 if SANDBOX
|
2022-01-13 02:26:22 +00:00
|
|
|
depends on BLOBLIST_FIXED
|
2018-11-16 01:43:50 +00:00
|
|
|
help
|
|
|
|
Sets the address of the bloblist, set up by the first part of U-Boot
|
2022-01-13 02:26:21 +00:00
|
|
|
which runs. Subsequent U-Boot phases typically use the same address.
|
2018-11-16 01:43:50 +00:00
|
|
|
|
2021-11-04 03:09:20 +00:00
|
|
|
This is not used if BLOBLIST_ALLOC is selected.
|
|
|
|
|
2022-01-13 02:26:22 +00:00
|
|
|
config BLOBLIST_SIZE
|
|
|
|
hex "Size of 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 phases.
|
|
|
|
|
2021-01-14 03:29:43 +00:00
|
|
|
config BLOBLIST_SIZE_RELOC
|
|
|
|
hex "Size of bloblist after relocation"
|
2022-01-13 02:26:22 +00:00
|
|
|
default BLOBLIST_SIZE if BLOBLIST_FIXED || BLOBLIST_ALLOC
|
|
|
|
default 0 if BLOBLIST_PASSAGE
|
2021-01-14 03:29:43 +00:00
|
|
|
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.
|
|
|
|
|
2021-11-04 03:09:20 +00:00
|
|
|
endif # BLOBLIST
|
|
|
|
|
2022-01-13 02:26:22 +00:00
|
|
|
if SPL_BLOBLIST
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "Bloblist location in SPL"
|
|
|
|
help
|
|
|
|
Select the location of the bloblist, via various means. Typically
|
|
|
|
you should use the same value for SPL as for U-Boot, since they need
|
|
|
|
to look in the same place. But if BLOBLIST_ALLOC is used, then a
|
|
|
|
fresh bloblist will be created each time, since there is no shared
|
|
|
|
address (between phases) for the bloblist.
|
|
|
|
|
|
|
|
config SPL_BLOBLIST_FIXED
|
|
|
|
bool "Place bloblist at a fixed address in memory"
|
|
|
|
help
|
|
|
|
Select this to used a fixed memory address for the bloblist. If the
|
|
|
|
bloblist exists at this address from a previous phase, it used as is.
|
|
|
|
If not it is created at this address in SPL.
|
|
|
|
|
|
|
|
config SPL_BLOBLIST_ALLOC
|
|
|
|
bool "Allocate bloblist"
|
|
|
|
help
|
|
|
|
Allocate the bloblist using malloc(). This avoids the need to
|
|
|
|
specify a fixed address on systems where this is unknown or can
|
|
|
|
change at runtime.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
endif # SPL_BLOBLIST
|
|
|
|
|
|
|
|
if TPL_BLOBLIST
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "Bloblist location in TPL"
|
|
|
|
help
|
|
|
|
Select the location of the bloblist, via various means. Typically
|
|
|
|
you should use the same value for SPL as for U-Boot, since they need
|
|
|
|
to look in the same place. But if BLOBLIST_ALLOC is used, then a
|
|
|
|
fresh bloblist will be created each time, since there is no shared
|
|
|
|
address (between phases) for the bloblist.
|
|
|
|
|
|
|
|
config TPL_BLOBLIST_FIXED
|
|
|
|
bool "Place bloblist at a fixed address in memory"
|
|
|
|
help
|
|
|
|
Select this to used a fixed memory address for the bloblist. If the
|
|
|
|
bloblist exists at this address from a previous phase, it used as is.
|
|
|
|
If not it is created at this address in TPL.
|
|
|
|
|
|
|
|
config TPL_BLOBLIST_ALLOC
|
|
|
|
bool "Allocate bloblist"
|
|
|
|
help
|
|
|
|
Allocate the bloblist using malloc(). This avoids the need to
|
|
|
|
specify a fixed address on systems where this is unknown or can
|
|
|
|
change at runtime.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
endif # TPL_BLOBLIST
|
|
|
|
|
2018-11-16 01:43:50 +00:00
|
|
|
endmenu
|
|
|
|
|
2016-09-13 05:18:22 +00:00
|
|
|
source "common/spl/Kconfig"
|
2020-02-21 06:12:55 +00:00
|
|
|
|
|
|
|
config IMAGE_SIGN_INFO
|
|
|
|
bool
|
|
|
|
select SHA1
|
|
|
|
select SHA256
|
|
|
|
help
|
|
|
|
Enable image_sign_info helper functions.
|
2020-04-15 16:46:21 +00:00
|
|
|
|
|
|
|
if IMAGE_SIGN_INFO
|
|
|
|
|
|
|
|
config SPL_IMAGE_SIGN_INFO
|
|
|
|
bool
|
|
|
|
select SHA1
|
|
|
|
select SHA256
|
|
|
|
help
|
|
|
|
Enable image_sign_info helper functions in SPL.
|
|
|
|
|
|
|
|
endif
|
2021-11-15 15:32:17 +00:00
|
|
|
|
|
|
|
config FDT_SIMPLEFB
|
|
|
|
bool "FDT tools for simplefb support"
|
|
|
|
depends on OF_LIBFDT
|
|
|
|
help
|
|
|
|
Enable the fdt tools to manage the simple fb nodes in device tree.
|
|
|
|
These functions can be used by board to indicate to the OS
|
|
|
|
the presence of the simple frame buffer with associated reserved
|
|
|
|
memory
|