|
|
|
|
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 accumated time and report it.
|
|
|
|
|
|
|
|
|
|
Normally, IDs are defined in bootstage.h but a small number of
|
|
|
|
|
additional 'user' IDs can be used but passing BOOTSTAGE_ID_ALLOC
|
|
|
|
|
as the ID.
|
|
|
|
|
|
|
|
|
|
Calls to show_boot_progress() wil also result in log entries but
|
|
|
|
|
these will not have names.
|
|
|
|
|
|
|
|
|
|
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_USER_COUNT
|
|
|
|
|
hex "Number of boot ID numbers available for user use"
|
|
|
|
|
default 20
|
|
|
|
|
help
|
|
|
|
|
This is the number of available user bootstage records.
|
|
|
|
|
Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...)
|
|
|
|
|
a new ID will be allocated from this stash. If you exceed
|
|
|
|
|
the limit, recording will stop.
|
|
|
|
|
|
|
|
|
|
config BOOTSTAGE_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 microsecond, 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 4096
|
|
|
|
|
help
|
|
|
|
|
This should be large enough to hold the bootstage stash. A value of
|
|
|
|
|
4096 (4KiB) is normally plenty.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
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,
|
|
|
|
|
somes not.
|
|
|
|
|
|
|
|
|
|
config ONENAND_BOOT
|
|
|
|
|
bool "Support for booting from ONENAND"
|
|
|
|
|
default n
|
|
|
|
|
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,
|
|
|
|
|
somes 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,
|
|
|
|
|
somes 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,
|
|
|
|
|
somes 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,
|
|
|
|
|
somes 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,
|
|
|
|
|
somes not.
|
|
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
config BOOTDELAY
|
|
|
|
|
int "delay in seconds before automatically booting"
|
|
|
|
|
default 2
|
|
|
|
|
depends on AUTOBOOT
|
|
|
|
|
help
|
|
|
|
|
Delay before automatically running bootcmd;
|
autoboot: remove CONFIG_ZERO_BOOTDELAY_CHECK
As the help message of CONFIG_BOOTDELAY says, CONFIG_BOOTDELAY=-2
means the autoboot with no delay, with no abort check even if
CONFIG_ZERO_BOOTDELAY_CHECK is defined.
To sum up, the autoboot behaves as follows:
[1] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=y
autoboot with no delay, but you can abort it by key input
[2] CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
autoboot with no delay, with no check for abort
[3] CONFIG_BOOTDELAY=-1
disable autoboot
[4] CONFIG_BOOTDELAY=-2
autoboot with no delay, with no check for abort
As you notice, [2] and [4] come to the same result, which means we
do not need CONFIG_ZERO_BOOTDELAY_CHECK. We can control all the
cases only by CONFIG_BOOTDELAY, like this:
[1] CONFIG_BOOTDELAY=0
autoboot with no delay, but you can abort it by key input
[2] CONFIG_BOOTDELAY=-1
disable autoboot
[3] CONFIG_BOOTDELAY=-2
autoboot with no delay, with no check for abort
This commit converts the logic as follow:
CONFIG_BOOTDELAY=0 && CONFIG_ZERO_BOOTDELAY_CHECK=n
--> CONFIG_BOOTDELAY=-2
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Christian Riesch <christian.riesch@omicronenergy.com>
Acked-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
8 years ago
|
|
|
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
|
|
|
|
|
|
|
|
|
|
See doc/README.autoboot for details.
|
|
|
|
|
|
|
|
|
|
config CONSOLE_RECORD
|
|
|
|
|
bool "Console recording"
|
|
|
|
|
help
|
|
|
|
|
This provides a way to record console output (and provide console
|
|
|
|
|
input) through cirular 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 SYS_NO_FLASH
|
|
|
|
|
bool "Disable support for parallel NOR flash"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option is used to disable support for parallel NOR flash.
|
