Create a new boot/ directory

Quite a lot of the code in common/relates to booting and images. Before
adding more it seems like a good time to move the code into its own
directory.

Most files with 'boot' or 'image' in them are moved, except:

- autoboot.c which relates to U-Boot automatically running a script
- bootstage.c which relates to U-Boot timing

Drop the removal of boot* files from the output directory, since this
interfers with the symlinks created by tools and there does not appear
to be any such file from my brief testing.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>

1 files changed, 1036 insertions, 0 deletions

diff --git a/boot/Kconfig b/boot/Kconfig
new file mode 100644
index 0000000000..a8d4be23a9
--- /dev/null
+++ b/boot/Kconfig
@@ -0,0 +1,1036 @@
+menu "Boot options"
+
+menu "Boot images"
+
+config ANDROID_BOOT_IMAGE
+	bool "Enable support for Android Boot Images"
+	default y if FASTBOOT
+	help
+	  This enables support for booting images which use the Android
+	  image format header.
+
+config FIT
+	bool "Support Flattened Image Tree"
+	select HASH
+	select MD5
+	select SHA1
+	imply SHA256
+	help
+	  This option allows you to boot the new uImage structure,
+	  Flattened Image Tree.  FIT is formally a FDT, which can include
+	  images of various types (kernel, FDT blob, ramdisk, etc.)
+	  in a single blob.  To boot this new uImage structure,
+	  pass the address of the blob to the "bootm" command.
+	  FIT is very flexible, supporting compression, multiple images,
+	  multiple configurations, verification through hashing and also
+	  verified boot (secure boot using RSA).
+
+if FIT
+
+config FIT_EXTERNAL_OFFSET
+	hex "FIT external data offset"
+	default 0x0
+	help
+	  This specifies a data offset in fit image.
+	  The offset is from data payload offset to the beginning of
+	  fit image header. When specifies a offset, specific data
+	  could be put in the hole between data payload and fit image
+	  header, such as CSF data on i.MX platform.
+
+config FIT_FULL_CHECK
+	bool "Do a full check of the FIT before using it"
+	default y
+	help
+	  Enable this do a full check of the FIT to make sure it is valid. This
+	  helps to protect against carefully crafted FITs which take advantage
+	  of bugs or omissions in the code. This includes a bad structure,
+	  multiple root nodes and the like.
+
+config FIT_SIGNATURE
+	bool "Enable signature verification of FIT uImages"
+	depends on DM
+	select HASH
+	imply RSA
+	imply RSA_VERIFY
+	select IMAGE_SIGN_INFO
+	select FIT_FULL_CHECK
+	help
+	  This option enables signature verification of FIT uImages,
+	  using a hash signed and verified using RSA. If
+	  CONFIG_SHA_PROG_HW_ACCEL is defined, i.e support for progressive
+	  hashing is available using hardware, then the RSA library will use
+	  it. See doc/uImage.FIT/signature.txt for more details.
+
+	  WARNING: When relying on signed FIT images with a required signature
+	  check the legacy image format is disabled by default, so that
+	  unsigned images cannot be loaded. If a board needs the legacy image
+	  format support in this case, enable it using
+	  CONFIG_LEGACY_IMAGE_FORMAT.
+
+config FIT_SIGNATURE_MAX_SIZE
+	hex "Max size of signed FIT structures"
+	depends on FIT_SIGNATURE
+	default 0x10000000
+	help
+	  This option sets a max size in bytes for verified FIT uImages.
+	  A sane value of 256MB protects corrupted DTB structures from overlapping
+	  device memory. Assure this size does not extend past expected storage
+	  space.
+
+config FIT_RSASSA_PSS
+	bool "Support rsassa-pss signature scheme of FIT image contents"
+	depends on FIT_SIGNATURE
+	help
+	  Enable this to support the pss padding algorithm as described
+	  in the rfc8017 (https://tools.ietf.org/html/rfc8017).
+
+config FIT_CIPHER
+	bool "Enable ciphering data in a FIT uImages"
+	depends on DM
+	select AES
+	help
+	  Enable the feature of data ciphering/unciphering in the tool mkimage
+	  and in the u-boot support of the FIT image.
+
+config FIT_VERBOSE
+	bool "Show verbose messages when FIT images fail"
+	help
+	  Generally a system will have valid FIT images so debug messages
+	  are a waste of code space. If you are debugging your images then
+	  you can enable this option to get more verbose information about
+	  failures.
+
+config FIT_BEST_MATCH
+	bool "Select the best match for the kernel device tree"
+	help
+	  When no configuration is explicitly selected, default to the
+	  one whose fdt's compatibility field best matches that of
+	  U-Boot itself. A match is considered "best" if it matches the
+	  most specific compatibility entry of U-Boot's fdt's root node.
+	  The order of entries in the configuration's fdt is ignored.
+
+config FIT_IMAGE_POST_PROCESS
+	bool "Enable post-processing of FIT artifacts after loading by U-Boot"
+	depends on TI_SECURE_DEVICE || SOCFPGA_SECURE_VAB_AUTH
+	help
+	  Allows doing any sort of manipulation to blobs after they got extracted
+	  from FIT images like stripping off headers or modifying the size of the
+	  blob, verification, authentication, decryption etc. in a platform or
+	  board specific way. In order to use this feature a platform or board-
+	  specific implementation of board_fit_image_post_process() must be
+	  provided. Also, anything done during this post-processing step would
+	  need to be comprehended in how the images were prepared before being
+	  injected into the FIT creation (i.e. the blobs would have been pre-
+	  processed before being added to the FIT image).
+
+config FIT_PRINT
+        bool "Support FIT printing"
+        default y
+        help
+          Support printing the content of the fitImage in a verbose manner.
+
+if SPL
+
+config SPL_FIT
+	bool "Support Flattened Image Tree within SPL"
+	depends on SPL
+	select SPL_HASH
+	select SPL_OF_LIBFDT
+
+config SPL_FIT_PRINT
+	bool "Support FIT printing within SPL"
+	depends on SPL_FIT
+	help
+	  Support printing the content of the fitImage in a verbose manner in SPL.
+
+config SPL_FIT_FULL_CHECK
+	bool "Do a full check of the FIT before using it"
+	help
+	  Enable this do a full check of the FIT to make sure it is valid. This
+	  helps to protect against carefully crafted FITs which take advantage
+	  of bugs or omissions in the code. This includes a bad structure,
+	  multiple root nodes and the like.
+
+
+config SPL_FIT_SIGNATURE
+	bool "Enable signature verification of FIT firmware within SPL"
+	depends on SPL_DM
+	depends on SPL_LOAD_FIT || SPL_LOAD_FIT_FULL
+	select FIT_SIGNATURE
+	select SPL_FIT
+	select SPL_CRYPTO
+	select SPL_HASH
+	imply SPL_RSA
+	imply SPL_RSA_VERIFY
+	select SPL_IMAGE_SIGN_INFO
+	select SPL_FIT_FULL_CHECK
+
+config SPL_FIT_SIGNATURE_MAX_SIZE
+	hex "Max size of signed FIT structures in SPL"
+	depends on SPL_FIT_SIGNATURE
+	default 0x10000000
+	help
+	  This option sets a max size in bytes for verified FIT uImages.
+	  A sane value of 256MB protects corrupted DTB structures from overlapping
+	  device memory. Assure this size does not extend past expected storage
+	  space.
+
+config SPL_FIT_RSASSA_PSS
+	bool "Support rsassa-pss signature scheme of FIT image contents in SPL"
+	depends on SPL_FIT_SIGNATURE
+	help
+	  Enable this to support the pss padding algorithm as described
+	  in the rfc8017 (https://tools.ietf.org/html/rfc8017) in SPL.
+
+config SPL_LOAD_FIT
+	bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
+	select SPL_FIT
+	help
+	  Normally with the SPL framework a legacy image is generated as part
+	  of the build. This contains U-Boot along with information as to
+	  where it should be loaded. This option instead enables generation
+	  of a FIT (Flat Image Tree) which provides more flexibility. In
+	  particular it can handle selecting from multiple device tree
+	  and passing the correct one to U-Boot.
+
+	  This path has the following limitations:
+
+	  1. "loadables" images, other than FDTs, which do not have a "load"
+	     property will not be loaded. This limitation also applies to FPGA
+	     images with the correct "compatible" string.
+	  2. For FPGA images, only the "compatible" = "u-boot,fpga-legacy"
+	     loading method is supported.
+	  3. FDTs are only loaded for images with an "os" property of "u-boot".
+	     "linux" images are also supported with Falcon boot mode.
+
+config SPL_LOAD_FIT_ADDRESS
+	hex "load address of fit image"
+	depends on SPL_LOAD_FIT
+	default 0x0
+	help
+	  Specify the load address of the fit image that will be loaded
+	  by SPL.
+
+config SPL_LOAD_FIT_APPLY_OVERLAY
+	bool "Enable SPL applying DT overlays from FIT"
+	depends on SPL_LOAD_FIT
+	select OF_LIBFDT_OVERLAY
+	help
+	  The device tree is loaded from the FIT image. Allow the SPL is to
+	  also load device-tree overlays from the FIT image an apply them
+	  over the device tree.
+
+config SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ
+	depends on SPL_LOAD_FIT_APPLY_OVERLAY
+	default 0x10000
+	hex "size of temporary buffer used to load the overlays"
+	help
+	  The size of the area where the overlays will be loaded and
+	  uncompress. Must be at least as large as biggest overlay
+	  (uncompressed)
+
+config SPL_LOAD_FIT_FULL
+	bool "Enable SPL loading U-Boot as a FIT (full fitImage features)"
+	select SPL_FIT
+	help
+	  Normally with the SPL framework a legacy image is generated as part
+	  of the build. This contains U-Boot along with information as to
+	  where it should be loaded. This option instead enables generation
+	  of a FIT (Flat Image Tree) which provides more flexibility. In
+	  particular it can handle selecting from multiple device tree
+	  and passing the correct one to U-Boot.
+
+config SPL_FIT_IMAGE_POST_PROCESS
+	bool "Enable post-processing of FIT artifacts after loading by the SPL"
+	depends on SPL_LOAD_FIT
+	help
+	  Allows doing any sort of manipulation to blobs after they got extracted
+	  from the U-Boot FIT image like stripping off headers or modifying the
+	  size of the blob, verification, authentication, decryption etc. in a
+	  platform or board specific way. In order to use this feature a platform
+	  or board-specific implementation of board_fit_image_post_process() must
+	  be provided. Also, anything done during this post-processing step would
+	  need to be comprehended in how the images were prepared before being
+	  injected into the FIT creation (i.e. the blobs would have been pre-
+	  processed before being added to the FIT image).
+
+config SPL_FIT_SOURCE
+	string ".its source file for U-Boot FIT image"
+	depends on SPL_FIT
+	help
+	  Specifies a (platform specific) FIT source file to generate the
+	  U-Boot FIT image. This could specify further image to load and/or
+	  execute.
+
+config USE_SPL_FIT_GENERATOR
+	bool "Use a script to generate the .its script"
+	default y if SPL_FIT && (!ARCH_SUNXI && !RISCV)
+
+config SPL_FIT_GENERATOR
+	string ".its file generator script for U-Boot FIT image"
+	depends on USE_SPL_FIT_GENERATOR
+	default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP
+	default "arch/arm/mach-zynqmp/mkimage_fit_atf.sh" if SPL_LOAD_FIT && ARCH_ZYNQMP
+	help
+	  Specifies a (platform specific) script file to generate the FIT
+	  source file used to build the U-Boot FIT image file. This gets
+	  passed a list of supported device tree file stub names to
+	  include in the generated image.
+
+endif # SPL
+
+endif # FIT
+
+config LEGACY_IMAGE_FORMAT
+	bool "Enable support for the legacy image format"
+	default y if !FIT_SIGNATURE
+	help
+	  This option enables the legacy image format. It is enabled by
+	  default for backward compatibility, unless FIT_SIGNATURE is
+	  set where it is disabled so that unsigned images cannot be
+	  loaded. If a board needs the legacy image format support in this
+	  case, enable it here.
+
+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 OF_BOARD_SETUP
+	bool "Set up board-specific details in device tree before boot"
+	depends on OF_LIBFDT
+	help
+	  This causes U-Boot to call ft_board_setup() before booting into
+	  the Operating System. This function can set up various
+	  board-specific information in the device tree for use by the OS.
+	  The device tree is then passed to the OS.
+
+config OF_SYSTEM_SETUP
+	bool "Set up system-specific details in device tree before boot"
+	depends on OF_LIBFDT
+	help
+	  This causes U-Boot to call ft_system_setup() before booting into
+	  the Operating System. This function can set up various
+	  system-specific information in the device tree for use by the OS.
+	  The device tree is then passed to the OS.
+
+config OF_STDOUT_VIA_ALIAS
+	bool "Update the device-tree stdout alias from U-Boot"
+	depends on OF_LIBFDT
+	help
+	  This uses U-Boot's serial alias from the aliases node to update
+	  the device tree passed to the OS. The "linux,stdout-path" property
+	  in the chosen node is set to point to the correct serial node.
+	  This option currently references CONFIG_CONS_INDEX, which is
+	  incorrect when used with device tree as this option does not
+	  exist / should not be used.
+
+config SYS_EXTRA_OPTIONS
+	string "Extra Options (DEPRECATED)"
+	help
+	  The old configuration infrastructure (= mkconfig + boards.cfg)
+	  provided the extra options field. If you have something like
+	  "HAS_BAR,BAZ=64", the optional options
+	    #define CONFIG_HAS
+	    #define CONFIG_BAZ	64
+	  will be defined in include/config.h.
+	  This option was prepared for the smooth migration from the old
+	  configuration to Kconfig. Since this option will be removed sometime,
+	  new boards should not use this option.
+
+config HAVE_SYS_TEXT_BASE
+	bool
+	depends on !NIOS2 && !XTENSA
+	depends on !EFI_APP
+	default y
+
+config SYS_TEXT_BASE
+	depends on HAVE_SYS_TEXT_BASE
+	default 0x0 if POSITION_INDEPENDENT
+	default 0x80800000 if ARCH_OMAP2PLUS || ARCH_K3
+	default 0x4a000000 if ARCH_SUNXI && !MACH_SUN9I && !MACH_SUN8I_V3S
+	default 0x2a000000 if ARCH_SUNXI && MACH_SUN9I
+	default 0x42e00000 if ARCH_SUNXI && MACH_SUN8I_V3S
+	hex "Text Base"
+	help
+	  The address in memory that U-Boot will be running from, initially.
+
+config SYS_CLK_FREQ
+	depends on ARC || ARCH_SUNXI || MPC83xx
+	int "CPU clock frequency"
+	help
+	  TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture
+
+config ARCH_FIXUP_FDT_MEMORY
+	bool "Enable arch_fixup_memory_banks() call"
+	default y
+	help
+	  Enable FDT memory map syncup before OS boot. This feature can be
+	  used for booting OS with different memory setup where the part of
+	  the memory location should be used for different purpose.
+
+config CHROMEOS
+	bool "Support booting Chrome OS"
+	help
+	  Chrome OS requires U-Boot to set up a table indicating the boot mode
+	  (e.g. Developer mode) and a few other things. Enable this if you are
+	  booting on a Chromebook to avoid getting an error about an invalid
+	  firmware ID.
+
+config CHROMEOS_VBOOT
+	bool "Support Chrome OS verified boot"
+	help
+	  This is intended to enable the full Chrome OS verified boot support
+	  in U-Boot. It is not actually implemented in the U-Boot source code
+	  at present, so this option is always set to 'n'. It allows
+	  distinguishing between booting Chrome OS in a basic way (developer
+	  mode) and a full boot.
+
+config RAMBOOT_PBL
+	bool "Freescale PBL(pre-boot loader) image format support"
+	help
+	  Some SoCs use PBL to load RCW and/or pre-initialization instructions.
+	  For more details refer to doc/README.pblimage
+
+config SYS_FSL_PBL_PBI
+	string "PBI(pre-boot instructions) commands for the PBL image"
+	depends on RAMBOOT_PBL
+	help
+	  PBI commands can be used to configure SoC before it starts the execution.
+	  Please refer doc/README.pblimage for more details.
+
+config SYS_FSL_PBL_RCW
+	string "Aadditional RCW (Power on reset configuration) for the PBL image"
+	depends on RAMBOOT_PBL
+	help
+	  Enables addition of RCW (Power on reset configuration) in built image.
+	  Please refer doc/README.pblimage for more details.
+
+endmenu		# Boot images
+
+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"
+	depends on BOOTSTAGE
+	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"
+	depends on SPL_BOOTSTAGE
+	default 5
+	help
+	  This is the size of the bootstage record list and is the maximum
+	  number of bootstage records that can be recorded.
+
+config TPL_BOOTSTAGE_RECORD_COUNT
+	int "Number of boot stage records to store for TPL"
+	depends on TPL_BOOTSTAGE
+	default 5
+	help
+	  This is the size of the bootstage record list and is the maximum
+	  number of bootstage records that can be recorded.
+
+config BOOTSTAGE_FDT
+	bool "Store boot timing information in the OS device tree"
+	depends on BOOTSTAGE
+	help
+	  Stash the bootstage information in the FDT. A root 'bootstage'
+	  node is created with each bootstage id as a child. Each child
+	  has a 'name' property and either 'mark' containing the
+	  mark time in microseconds, or 'accum' containing the
+	  accumulated time for that bootstage id in microseconds.
+	  For example:
+
+		bootstage {
+			154 {
+				name = "board_init_f";
+				mark = <3575678>;
+			};
+			170 {
+				name = "lcd";
+				accum = <33482>;
+			};
+		};
+
+	  Code in the Linux kernel can find this in /proc/devicetree.
+
+config BOOTSTAGE_STASH
+	bool "Stash the boot timing information in memory before booting OS"
+	depends on BOOTSTAGE
+	help
+	  Some OSes do not support device tree. Bootstage can instead write
+	  the boot timing information in a binary format at a given address.
+	  This happens through a call to bootstage_stash(), typically in
+	  the CPU's cleanup_before_linux() function. You can use the
+	  'bootstage stash' and 'bootstage unstash' commands to do this on
+	  the command line.
+
+config BOOTSTAGE_STASH_ADDR
+	hex "Address to stash boot timing information"
+	default 0
+	help
+	  Provide an address which will not be overwritten by the OS when it
+	  starts, so that it can read this information when ready.
+
+config BOOTSTAGE_STASH_SIZE
+	hex "Size of boot timing stash region"
+	default 0x1000
+	help
+	  This should be large enough to hold the bootstage stash. A value of
+	  4096 (4KiB) is normally plenty.
+
+config SHOW_BOOT_PROGRESS
+	bool "Show boot progress in a board-specific manner"
+	help
+	  Defining this option allows to add some board-specific code (calling
+	  a user-provided function show_boot_progress(int) that enables you to
+	  show the system's boot progress on some display (for example, some
+	  LEDs) on your board. At the moment, the following checkpoints are
+	  implemented:
+
+	  Legacy uImage format:
+
+	  Arg	Where			When
+	    1	common/cmd_bootm.c	before attempting to boot an image
+	   -1	common/cmd_bootm.c	Image header has bad	 magic number
+	    2	common/cmd_bootm.c	Image header has correct magic number
+	   -2	common/cmd_bootm.c	Image header has bad	 checksum
+	    3	common/cmd_bootm.c	Image header has correct checksum
+	   -3	common/cmd_bootm.c	Image data   has bad	 checksum
+	    4	common/cmd_bootm.c	Image data   has correct checksum
+	   -4	common/cmd_bootm.c	Image is for unsupported architecture
+	    5	common/cmd_bootm.c	Architecture check OK
+	   -5	common/cmd_bootm.c	Wrong Image Type (not kernel, multi)
+	    6	common/cmd_bootm.c	Image Type check OK
+	   -6	common/cmd_bootm.c	gunzip uncompression error
+	   -7	common/cmd_bootm.c	Unimplemented compression type
+	    7	common/cmd_bootm.c	Uncompression OK
+	    8	common/cmd_bootm.c	No uncompress/copy overwrite error
+	   -9	common/cmd_bootm.c	Unsupported OS (not Linux, BSD, VxWorks, QNX)
+
+	    9	common/image.c		Start initial ramdisk verification
+	  -10	common/image.c		Ramdisk header has bad	   magic number
+	  -11	common/image.c		Ramdisk header has bad	   checksum
+	   10	common/image.c		Ramdisk header is OK
+	  -12	common/image.c		Ramdisk data   has bad	   checksum
+	   11	common/image.c		Ramdisk data   has correct checksum
+	   12	common/image.c		Ramdisk verification complete, start loading
+	  -13	common/image.c		Wrong Image Type (not PPC Linux ramdisk)
+	   13	common/image.c		Start multifile image verification
+	   14	common/image.c		No initial ramdisk, no multifile, continue.
+
+	   15	arch/<arch>/lib/bootm.c All preparation done, transferring control to OS
+
+	  -30	arch/powerpc/lib/board.c	Fatal error, hang the system
+	  -31	post/post.c		POST test failed, detected by post_output_backlog()
+	  -32	post/post.c		POST test failed, detected by post_run_single()
+
+	   34	common/cmd_doc.c	before loading a Image from a DOC device
+	  -35	common/cmd_doc.c	Bad usage of "doc" command
+	   35	common/cmd_doc.c	correct usage of "doc" command
+	  -36	common/cmd_doc.c	No boot device
+	   36	common/cmd_doc.c	correct boot device
+	  -37	common/cmd_doc.c	Unknown Chip ID on boot device
+	   37	common/cmd_doc.c	correct chip ID found, device available
+	  -38	common/cmd_doc.c	Read Error on boot device
+	   38	common/cmd_doc.c	reading Image header from DOC device OK
+	  -39	common/cmd_doc.c	Image header has bad magic number
+	   39	common/cmd_doc.c	Image header has correct magic number
+	  -40	common/cmd_doc.c	Error reading Image from DOC device
+	   40	common/cmd_doc.c	Image header has correct magic number
+	   41	common/cmd_ide.c	before loading a Image from a IDE device
+	  -42	common/cmd_ide.c	Bad usage of "ide" command
+	   42	common/cmd_ide.c	correct usage of "ide" command
+	  -43	common/cmd_ide.c	No boot device
+	   43	common/cmd_ide.c	boot device found
+	  -44	common/cmd_ide.c	Device not available
+	   44	common/cmd_ide.c	Device available
+	  -45	common/cmd_ide.c	wrong partition selected
+	   45	common/cmd_ide.c	partition selected
+	  -46	common/cmd_ide.c	Unknown partition table
+	   46	common/cmd_ide.c	valid partition table found
+	  -47	common/cmd_ide.c	Invalid partition type
+	   47	common/cmd_ide.c	correct partition type
+	  -48	common/cmd_ide.c	Error reading Image Header on boot device
+	   48	common/cmd_ide.c	reading Image Header from IDE device OK
+	  -49	common/cmd_ide.c	Image header has bad magic number
+	   49	common/cmd_ide.c	Image header has correct magic number
+	  -50	common/cmd_ide.c	Image header has bad	 checksum
+	   50	common/cmd_ide.c	Image header has correct checksum
+	  -51	common/cmd_ide.c	Error reading Image from IDE device
+	   51	common/cmd_ide.c	reading Image from IDE device OK
+	   52	common/cmd_nand.c	before loading a Image from a NAND device
+	  -53	common/cmd_nand.c	Bad usage of "nand" command
+	   53	common/cmd_nand.c	correct usage of "nand" command
+	  -54	common/cmd_nand.c	No boot device
+	   54	common/cmd_nand.c	boot device found
+	  -55	common/cmd_nand.c	Unknown Chip ID on boot device
+	   55	common/cmd_nand.c	correct chip ID found, device available
+	  -56	common/cmd_nand.c	Error reading Image Header on boot device
+	   56	common/cmd_nand.c	reading Image Header from NAND device OK
+	  -57	common/cmd_nand.c	Image header has bad magic number
+	   57	common/cmd_nand.c	Image header has correct magic number
+	  -58	common/cmd_nand.c	Error reading Image from NAND device
+	   58	common/cmd_nand.c	reading Image from NAND device OK
+
+	  -60	common/env_common.c	Environment has a bad CRC, using default
+
+	   64	net/eth.c		starting with Ethernet configuration.
+	  -64	net/eth.c		no Ethernet found.
+	   65	net/eth.c		Ethernet found.
+
+	  -80	common/cmd_net.c	usage wrong
+	   80	common/cmd_net.c	before calling net_loop()
+	  -81	common/cmd_net.c	some error in net_loop() occurred
+	   81	common/cmd_net.c	net_loop() back without error
+	  -82	common/cmd_net.c	size == 0 (File with size 0 loaded)
+	   82	common/cmd_net.c	trying automatic boot
+	   83	common/cmd_net.c	running "source" command
+	  -83	common/cmd_net.c	some error in automatic boot or "source" command
+	   84	common/cmd_net.c	end without errors
+
+	  FIT uImage format:
+
+	  Arg	Where			When
+	  100	common/cmd_bootm.c	Kernel FIT Image has correct format
+	  -100	common/cmd_bootm.c	Kernel FIT Image has incorrect format
+	  101	common/cmd_bootm.c	No Kernel subimage unit name, using configuration
+	  -101	common/cmd_bootm.c	Can't get configuration for kernel subimage
+	  102	common/cmd_bootm.c	Kernel unit name specified
+	  -103	common/cmd_bootm.c	Can't get kernel subimage node offset
+	  103	common/cmd_bootm.c	Found configuration node
+	  104	common/cmd_bootm.c	Got kernel subimage node offset
+	  -104	common/cmd_bootm.c	Kernel subimage hash verification failed
+	  105	common/cmd_bootm.c	Kernel subimage hash verification OK
+	  -105	common/cmd_bootm.c	Kernel subimage is for unsupported architecture
+	  106	common/cmd_bootm.c	Architecture check OK
+	  -106	common/cmd_bootm.c	Kernel subimage has wrong type
+	  107	common/cmd_bootm.c	Kernel subimage type OK
+	  -107	common/cmd_bootm.c	Can't get kernel subimage data/size
+	  108	common/cmd_bootm.c	Got kernel subimage data/size
+	  -108	common/cmd_bootm.c	Wrong image type (not legacy, FIT)
+	  -109	common/cmd_bootm.c	Can't get kernel subimage type
+	  -110	common/cmd_bootm.c	Can't get kernel subimage comp
+	  -111	common/cmd_bootm.c	Can't get kernel subimage os
+	  -112	common/cmd_bootm.c	Can't get kernel subimage load address
+	  -113	common/cmd_bootm.c	Image uncompress/copy overwrite error
+
+	  120	common/image.c		Start initial ramdisk verification
+	  -120	common/image.c		Ramdisk FIT image has incorrect format
+	  121	common/image.c		Ramdisk FIT image has correct format
+	  122	common/image.c		No ramdisk subimage unit name, using configuration
+	  -122	common/image.c		Can't get configuration for ramdisk subimage
+	  123	common/image.c		Ramdisk unit name specified
+	  -124	common/image.c		Can't get ramdisk subimage node offset
+	  125	common/image.c		Got ramdisk subimage node offset
+	  -125	common/image.c		Ramdisk subimage hash verification failed
+	  126	common/image.c		Ramdisk subimage hash verification OK
+	  -126	common/image.c		Ramdisk subimage for unsupported architecture
+	  127	common/image.c		Architecture check OK
+	  -127	common/image.c		Can't get ramdisk subimage data/size
+	  128	common/image.c		Got ramdisk subimage data/size
+	  129	common/image.c		Can't get ramdisk load address
+	  -129	common/image.c		Got ramdisk load address
+
+	  -130	common/cmd_doc.c	Incorrect FIT image format
+	  131	common/cmd_doc.c	FIT image format OK
+
+	  -140	common/cmd_ide.c	Incorrect FIT image format
+	  141	common/cmd_ide.c	FIT image format OK
+
+	  -150	common/cmd_nand.c	Incorrect FIT image format
+	  151	common/cmd_nand.c	FIT image format OK
+
+config SPL_SHOW_BOOT_PROGRESS
+	bool "Show boot progress in a board-specific manner"
+	depends on SPL
+	help
+	  Defining this option allows to add some board-specific code (calling
+	  a user-provided function show_boot_progress(int) that enables you to
+	  show the system's boot progress on some display (for example, some
+	  LEDs) on your board. For details see SHOW_BOOT_PROGRESS.
+
+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"
+	imply MTD_RAW_NAND
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via NAND flash. This is not a must, some SoCs need this,
+	  some not.
+
+config ONENAND_BOOT
+	bool "Support for booting from ONENAND"
+	imply MTD_RAW_NAND
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via ONENAND. This is not a must, some SoCs need this,
+	  some not.
+
+config QSPI_BOOT
+	bool "Support for booting from QSPI flash"
+	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"
+	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"
+	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"
+	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 "Autoboot options"
+
+config AUTOBOOT
+	bool "Autoboot"
+	default y
+	help
+	  This enables the autoboot.  See doc/README.autoboot for detail.
+
+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 AUTOBOOT_KEYED
+	bool "Stop autobooting via specific input key / string"
+	help
+	  This option enables stopping (aborting) of the automatic
+	  boot feature only by issuing a specific input key or
+	  string. If not enabled, any input key will abort the
+	  U-Boot automatic booting process and bring the device
+	  to the U-Boot prompt for user input.
+
+config AUTOBOOT_FLUSH_STDIN
+	bool "Enable flushing stdin before starting to read the password"
+	depends on AUTOBOOT_KEYED && !SANDBOX
+	help
+	  When this option is enabled stdin buffer will be flushed before
+	  starting to read the password.
+	  This can't be enabled for the sandbox as flushing stdin would
+	  break the autoboot unit tests.
+
+config AUTOBOOT_PROMPT
+	string "Autoboot stop prompt"
+	depends on AUTOBOOT_KEYED
+	default "Autoboot in %d seconds\\n"
+	help
+	  This string is displayed before the boot delay selected by
+	  CONFIG_BOOTDELAY starts. If it is not defined	there is no
+	  output indicating that autoboot is in progress.
+
+	  Note that this define is used as the (only) argument to a
+	  printf() call, so it may contain '%' format specifications,
+	  provided that it also includes, sepearated by commas exactly
+	  like in a printf statement, the required arguments. It is
+	  the responsibility of the user to select only such arguments
+	  that are valid in the given context.
+
+config AUTOBOOT_ENCRYPTION
+	bool "Enable encryption in autoboot stopping"
+	depends on AUTOBOOT_KEYED
+	help
+	  This option allows a string to be entered into U-Boot to stop the
+	  autoboot.
+	  The behavior depends whether CONFIG_CRYPT_PW from lib is enabled
+	  or not.
+	  In case CONFIG_CRYPT_PW is enabled, the string will be forwarded
+	  to the crypt-based functionality and be compared against the
+	  string in the environment variable 'bootstopkeycrypt'.
+	  In case CONFIG_CRYPT_PW is disabled the string itself is hashed
+	  and compared against the hash in the environment variable
+	  'bootstopkeysha256'.
+	  If it matches in either case then boot stops and
+	  a command-line prompt is presented.
+	  This provides a way to ship a secure production device which can also
+	  be accessed at the U-Boot command line.
+
+config AUTOBOOT_SHA256_FALLBACK
+	bool "Allow fallback from crypt-hashed password to sha256"
+	depends on AUTOBOOT_ENCRYPTION && CRYPT_PW
+	help
+	  This option adds support to fall back from crypt-hashed
+	  passwords to checking a SHA256 hashed password in case the
+	  'bootstopusesha256' environment variable is set to 'true'.
+
+config AUTOBOOT_DELAY_STR
+	string "Delay autobooting via specific input key / string"
+	depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION
+	help
+	  This option delays the automatic boot feature by issuing
+	  a specific input key or string. If CONFIG_AUTOBOOT_DELAY_STR
+	  or the environment variable "bootdelaykey" is specified
+	  and this string is received from console input before
+	  autoboot starts booting, U-Boot gives a command prompt. The
+	  U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is
+	  used, otherwise it never times out.
+
+config AUTOBOOT_STOP_STR
+	string "Stop autobooting via specific input key / string"
+	depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION
+	help
+	  This option enables stopping (aborting) of the automatic
+	  boot feature only by issuing a specific input key or
+	  string. If CONFIG_AUTOBOOT_STOP_STR or the environment
+	  variable "bootstopkey" is specified and this string is
+	  received from console input before autoboot starts booting,
+	  U-Boot gives a command prompt. The U-Boot prompt never
+	  times out, even if CONFIG_BOOT_RETRY_TIME is used.
+
+config AUTOBOOT_KEYED_CTRLC
+	bool "Enable Ctrl-C autoboot interruption"
+	depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION
+	help
+	  This option allows for the boot sequence to be interrupted
+	  by ctrl-c, in addition to the "bootdelaykey" and "bootstopkey".
+	  Setting this variable	provides an escape sequence from the
+	  limited "password" strings.
+
+config AUTOBOOT_NEVER_TIMEOUT
+	bool "Make the password entry never time-out"
+	depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION && CRYPT_PW
+	help
+	  This option removes the timeout from the password entry
+	  when the user first presses the <Enter> key before entering
+	  any other character.
+
+config AUTOBOOT_STOP_STR_ENABLE
+	bool "Enable fixed string to stop autobooting"
+	depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
+	help
+	  This option enables the feature to add a fixed stop
+	  string that is defined at compile time.
+	  In every case it will be tried to load the stop
+	  string from the environment.
+	  In case this is enabled and there is no stop string
+	  in the environment, this will be used as default value.
+
+config AUTOBOOT_STOP_STR_CRYPT
+	string "Stop autobooting via crypt-hashed password"
+	depends on AUTOBOOT_STOP_STR_ENABLE && CRYPT_PW
+	help
+	  This option adds the feature to only stop the autobooting,
+	  and therefore boot into the U-Boot prompt, when the input
+	  string / password matches a values that is hashed via
+	  one of the supported crypt-style password hashing options
+	  and saved in the environment variable "bootstopkeycrypt".
+
+config AUTOBOOT_STOP_STR_SHA256
+	string "Stop autobooting via SHA256 hashed password"
+	depends on AUTOBOOT_STOP_STR_ENABLE
+	help
+	  This option adds the feature to only stop the autobooting,
+	  and therefore boot into the U-Boot prompt, when the input
+	  string / password matches a values that is encypted via
+	  a SHA256 hash and saved in the environment variable
+	  "bootstopkeysha256". If the value in that variable
+	  includes a ":", the portion prior to the ":" will be treated
+	  as a salt value.
+
+config AUTOBOOT_USE_MENUKEY
+	bool "Allow a specify key to run a menu from the environment"
+	depends on !AUTOBOOT_KEYED
+	help
+	  If a specific key is pressed to stop autoboot, then the commands in
+	  the environment variable 'menucmd' are executed before boot starts.
+
+config AUTOBOOT_MENUKEY
+	int "ASCII value of boot key to show a menu"
+	default 0
+	depends on AUTOBOOT_USE_MENUKEY
+	help
+	  If this key is pressed to stop autoboot, then the commands in the
+	  environment variable 'menucmd' will be executed before boot starts.
+	  For example, 33 means "!" in ASCII, so pressing ! at boot would take
+	  this action.
+
+config AUTOBOOT_MENU_SHOW
+	bool "Show a menu on boot"
+	depends on CMD_BOOTMENU
+	help
+	  This enables the boot menu, controlled by environment variables
+	  defined by the board. The menu starts after running the 'preboot'
+	  environmnent variable (if enabled) and before handling the boot delay.
+	  See README.bootmenu for more details.
+
+endmenu
+
+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 && !USE_DEFAULT_ENV_FILE
+	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 BOOTARGS_SUBST
+	bool "Support substituting strings in boot arguments"
+	help
+	  This allows substituting string values in the boot arguments. These
+	  are applied after the commandline has been built.
+
+	  One use for this is to insert the root-disk UUID into the command
+	  line where bootargs contains "root=${uuid}"
+
+		setenv bootargs "console= root=${uuid}"
+		# Set the 'uuid' environment variable
+		part uuid mmc 2:2 uuid
+
+		# Command-line substitution will put the real uuid into the
+		# kernel command line
+		bootm
+
+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 && !USE_DEFAULT_ENV_FILE
+	default "run distro_bootcmd" if DISTRO_DEFAULTS
+	help
+	  This is the string of commands that will be used as bootcmd and if
+	  AUTOBOOT is set, automatically run.
+
+config USE_PREBOOT
+	bool "Enable preboot"
+	help
+	  When this option is enabled, the existence of the environment
+	  variable "preboot" will be checked immediately before starting the
+	  CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp.
+	  entering interactive mode.
+
+	  This feature is especially useful when "preboot" is automatically
+	  generated or modified. For example, the boot code can modify the
+	  "preboot" when a user holds down a certain combination of keys.
+
+config PREBOOT
+	string "preboot default value"
+	depends on USE_PREBOOT && !USE_DEFAULT_ENV_FILE
+	default "usb start" if USB_KEYBOARD
+	default ""
+	help
+	  This is the default of "preboot" environment variable.
+
+config DEFAULT_FDT_FILE
+	string "Default fdt file"
+	help
+	  This option is used to set the default fdt file to boot OS.
+
+endmenu		# Booting