| 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 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 | 
 | 	imply 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 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. | 
 |  | 
 | 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 8 | 
 | 	help | 
 | 	  All Messages with a loglevel smaller than the console loglevel will | 
 | 	  be compiled in. The loglevels are defined as follows: | 
 |  | 
 | 	  0 (KERN_EMERG)          system is unusable | 
 | 	  1 (KERN_ALERT)          action must be taken immediately | 
 | 	  2 (KERN_CRIT)           critical conditions | 
 | 	  3 (KERN_ERR)            error conditions | 
 | 	  4 (KERN_WARNING)        warning conditions | 
 | 	  5 (KERN_NOTICE)         normal but significant condition | 
 | 	  6 (KERN_INFO)           informational | 
 | 	  7 (KERN_DEBUG)          debug-level messages | 
 |  | 
 | 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 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 | 
 |  | 
 | 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. | 
 |  | 
 | config SPL_LOG | 
 | 	bool "Enable logging support in SPL" | 
 | 	depends on LOG | 
 | 	help | 
 | 	  This enables support for logging of status and debug messages. These | 
 | 	  can be displayed on the console, recorded in a memory buffer, or | 
 | 	  discarded if not needed. Logging supports various categories and | 
 | 	  levels of severity. | 
 |  | 
 | config TPL_LOG | 
 | 	bool "Enable logging support in TPL" | 
 | 	depends on LOG | 
 | 	help | 
 | 	  This enables support for logging of status and debug messages. These | 
 | 	  can be displayed on the console, recorded in a memory buffer, or | 
 | 	  discarded if not needed. Logging supports various categories and | 
 | 	  levels of severity. | 
 |  | 
 | config LOG_MAX_LEVEL | 
 | 	int "Maximum log level to record" | 
 | 	depends on LOG | 
 | 	default 5 | 
 | 	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 - panic | 
 | 	    1 - critical | 
 | 	    2 - error | 
 | 	    3 - warning | 
 | 	    4 - note | 
 | 	    5 - info | 
 | 	    6 - detail | 
 | 	    7 - debug | 
 |  | 
 | config SPL_LOG_MAX_LEVEL | 
 | 	int "Maximum log level to record in SPL" | 
 | 	depends on SPL_LOG | 
 | 	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 - panic | 
 | 	    1 - critical | 
 | 	    2 - error | 
 | 	    3 - warning | 
 | 	    4 - note | 
 | 	    5 - info | 
 | 	    6 - detail | 
 | 	    7 - debug | 
 |  | 
 | config TPL_LOG_MAX_LEVEL | 
 | 	int "Maximum log level to record in TPL" | 
 | 	depends on TPL_LOG | 
 | 	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 - panic | 
 | 	    1 - critical | 
 | 	    2 - error | 
 | 	    3 - warning | 
 | 	    4 - note | 
 | 	    5 - info | 
 | 	    6 - detail | 
 | 	    7 - debug | 
 |  | 
 | config LOG_CONSOLE | 
 | 	bool "Allow log output to the console" | 
 | 	depends on LOG | 
 | 	default y | 
 | 	help | 
 | 	  Enables a log driver which writes log records to the console. | 
 | 	  Generally the console is the serial port or LCD display. Only the | 
 | 	  log message is shown - other details like level, category, file and | 
 | 	  line number are omitted. | 
 |  | 
 | config SPL_LOG_CONSOLE | 
 | 	bool "Allow log output to the console in SPL" | 
 | 	depends on SPL_LOG | 
 | 	default y | 
 | 	help | 
 | 	  Enables a log driver which writes log records to the console. | 
 | 	  Generally the console is the serial port or LCD display. Only the | 
 | 	  log message is shown - other details like level, category, file and | 
 | 	  line number are omitted. | 
 |  | 
 | config TPL_LOG_CONSOLE | 
 | 	bool "Allow log output to the console in SPL" | 
 | 	depends on TPL_LOG | 
 | 	default y | 
 | 	help | 
 | 	  Enables a log driver which writes log records to the console. | 
 | 	  Generally the console is the serial port or LCD display. Only the | 
 | 	  log message is shown - other details like level, category, file and | 
 | 	  line number are omitted. | 
 |  | 
 | config LOG_TEST | 
 | 	bool "Provide a test for logging" | 
 | 	depends on LOG | 
 | 	default y if SANDBOX | 
 | 	help | 
 | 	  This enables a 'log test' command to test logging. It is normally | 
 | 	  executed from a pytest and simply outputs logging information | 
 | 	  in various different ways to test that the logging system works | 
 | 	  correctly with varoius settings. | 
 |  | 
 | config LOG_ERROR_RETURN | 
 | 	bool "Log all functions which return an error" | 
 | 	depends on LOG | 
 | 	help | 
 | 	  When an error is returned in U-Boot it is sometimes difficult to | 
 | 	  figure out the root cause. For eaxmple, 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. | 
 |  | 
 | 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. | 
 |  | 
 | 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 relocaiton. | 
 |  | 
 | 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. | 
 |  | 
 | 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. | 
 |  | 
 | config TA_VX | 
 | 	bool "Support Verified Execution Trusted App" | 
 | 	default n | 
 |  | 
 | config TA_VX_TESTS | 
 | 	bool "Enable `fastboot oem vx-test` and `vx test` commands." | 
 | 	help | 
 | 	  Enable `fastboot oem vx-test [name]` and `vx test [name]` in U-Boot | 
 | 	  shell that trigger internal tests defined in the VX TA. The VX TA | 
 | 	  also needs to be built with CFG_TA_VX_TESTS (bl32/ta/vx/Makefile). | 
 | 	depends on TA_VX | 
 | 	default n | 
 | 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 | 
 |  | 
 | 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" | 
 |  |