| 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 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 |
| int "Number of boot ID numbers available for user use" |
| default 20 |
| help |
| This is the number of available user bootstage records. |
| Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...) |
| a new ID will be allocated from this stash. If you exceed |
| the limit, recording will stop. |
| |
| config BOOTSTAGE_RECORD_COUNT |
| int "Number of boot stage records to store" |
| default 30 |
| 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. |
| |
| 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, |
| some 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, |
| 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 |
| |
| menu "Environment" |
| |
| config ENV_IS_IN_MMC |
| bool "Environment in an MMC device" |
| depends on !CHAIN_OF_TRUST |
| default y if ARCH_SUNXI |
| help |
| Define this if you have an MMC device which you want to use for the |
| environment. |
| |
| config ENV_IS_IN_NAND |
| bool "Environment in a NAND device" |
| depends on !CHAIN_OF_TRUST |
| help |
| Define this if you have a NAND device which you want to use for the |
| environment. |
| |
| config ENV_IS_IN_UBI |
| bool "Environment in a UBI volume" |
| depends on !CHAIN_OF_TRUST |
| help |
| Define this if you have a UBI volume which you want to use for the |
| environment. |
| |
| config ENV_IS_NOWHERE |
| bool "Environment is not stored" |
| help |
| Define this if you don't want to or can't have an environment stored |
| on a storage medium |
| |
| if ARCH_SUNXI |
| |
| config ENV_OFFSET |
| hex "Environment Offset" |
| depends on !ENV_IS_IN_UBI |
| depends on !ENV_IS_NOWHERE |
| default 0x88000 if ARCH_SUNXI |
| help |
| Offset from the start of the device (or partition) |
| |
| config ENV_SIZE |
| hex "Environment Size" |
| depends on !ENV_IS_NOWHERE |
| default 0x20000 if ARCH_SUNXI |
| help |
| Size of the environment storage area |
| |
| config ENV_UBI_PART |
| string "UBI partition name" |
| depends on ENV_IS_IN_UBI |
| help |
| MTD partition containing the UBI device |
| |
| config ENV_UBI_VOLUME |
| string "UBI volume name" |
| depends on ENV_IS_IN_UBI |
| help |
| Name of the volume that you want to store the environment in. |
| |
| endif |
| |
| endmenu |
| |
| config BOOTDELAY |
| int "delay in seconds before automatically booting" |
| default 2 |
| 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 |
| |
| See doc/README.autoboot for details. |
| |
| 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 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 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 vaariable '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 |
| 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 supress 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 |
| |
| config DTB_RESELECT |
| bool "Support swapping dtbs at a later point in boot" |
| depends on FIT_EMBED |
| help |
| It is possible during initial boot you may need to use a generic |
| dtb until you can fully determine the board your running on. This |
| config allows boards to implement a function at a later point |
| during boot to switch to the "correct" dtb. |
| |
| config FIT_EMBED |
| bool "Support a FIT image embedded in the U-boot image" |
| help |
| This option provides hooks to allow U-boot to parse an |
| appended FIT image and enable board specific code to then select |
| the correct DTB to be used. |
| |
| config DEFAULT_FDT_FILE |
| string "Default fdt file" |
| help |
| This option is used to set the default fdt file to boot OS. |
| |
| 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 |
| 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 ARM || NIOS2 || X86 || XTENSA |
| 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 start up" |
| default y if 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. |
| |
| menu "Start-up hooks" |
| |
| config ARCH_EARLY_INIT_R |
| bool "Call arch-specific init soon after relocation" |
| default y if X86 |
| help |
| With this option U-Boot will call arch_early_init_r() soon after |
| relocation. Driver model is running by this point, and the cache |
| 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 relocaiton. |
| |
| config BOARD_EARLY_INIT_F |
| bool "Call board-specific init before relocation" |
| default y if X86 |
| help |
| Some boards need to perform initialisation as soon as possible |
| after boot. With this option, U-Boot calls board_early_init_f() |
| 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. |
| |
| 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. |
| |
| endmenu |
| |
| source "common/spl/Kconfig" |