* [PATCH 01/16] Kconfig: Add a 'Boot options' menu
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 02/16] Kconfig: Move boot menu into common/ Simon Glass
` (16 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
There are quite a few boot-related menu options at the top level. Create a
new menu to hold these and move 'Boot images' into it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Kconfig b/Kconfig
index 883e3f71d01..3866b2b6e75 100644
--- a/Kconfig
+++ b/Kconfig
@@ -424,6 +424,8 @@ config SYS_SRAM_SIZE
endmenu # General setup
+menu "Boot options"
+
menu "Boot images"
config ANDROID_BOOT_IMAGE
@@ -762,6 +764,8 @@ config ARCH_FIXUP_FDT_MEMORY
endmenu # Boot images
+endmenu # Booting
+
source "api/Kconfig"
source "common/Kconfig"
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 02/16] Kconfig: Move boot menu into common/
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
2020-09-11 2:21 ` [PATCH 01/16] Kconfig: Add a 'Boot options' menu Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 03/16] Kconfig: Move boot timing under boot options Simon Glass
` (15 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
Most of the boot options are in common/Kconfig but that file is already
extremely large. Create a new Kconfig.boot to hold the boot options.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Kconfig | 342 --------------------------------------------
common/Kconfig | 2 +
common/Kconfig.boot | 341 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 343 insertions(+), 342 deletions(-)
create mode 100644 common/Kconfig.boot
diff --git a/Kconfig b/Kconfig
index 3866b2b6e75..aa979a7dcf9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -424,348 +424,6 @@ config SYS_SRAM_SIZE
endmenu # General setup
-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 MD5
- select SHA1
- 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_ENABLE_SHA256_SUPPORT
- bool "Support SHA256 checksum of FIT image contents"
- default y
- select SHA256
- help
- Enable this to support SHA256 checksum of FIT image contents. A
- SHA256 checksum is a 256-bit (32-byte) hash value used to check that
- the image contents have not been corrupted.
-
-config FIT_ENABLE_SHA384_SUPPORT
- bool "Support SHA384 checksum of FIT image contents"
- default n
- select SHA384
- help
- Enable this to support SHA384 checksum of FIT image contents. A
- SHA384 checksum is a 384-bit (48-byte) hash value used to check that
- the image contents have not been corrupted. Use this for the highest
- security.
-
-config FIT_ENABLE_SHA512_SUPPORT
- bool "Support SHA512 checksum of FIT image contents"
- default n
- select SHA512
- help
- Enable this to support SHA512 checksum of FIT image contents. A
- SHA512 checksum is a 512-bit (64-byte) hash value used to check that
- the image contents have not been corrupted.
-
-config FIT_SIGNATURE
- bool "Enable signature verification of FIT uImages"
- depends on DM
- select HASH
- select RSA
- select RSA_VERIFY
- select IMAGE_SIGN_INFO
- 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_ENABLE_RSASSA_PSS_SUPPORT
- bool "Support rsassa-pss signature scheme of FIT image contents"
- depends on FIT_SIGNATURE
- default n
- 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
- 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).
-
-if SPL
-
-config SPL_FIT
- bool "Support Flattened Image Tree within SPL"
- depends on SPL
- 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_SIGNATURE
- bool "Enable signature verification of FIT firmware within SPL"
- depends on SPL_DM
- select SPL_FIT
- select SPL_CRYPTO_SUPPORT
- select SPL_HASH_SUPPORT
- select SPL_RSA
- select SPL_RSA_VERIFY
- select SPL_IMAGE_SIGN_INFO
-
-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.
-
-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
-
-config SPL_FIT_GENERATOR
- string ".its file generator script for U-Boot FIT image"
- depends on USE_SPL_FIT_GENERATOR
- default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
- 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
- default "arch/riscv/lib/mkimage_fit_opensbi.sh" if SPL_LOAD_FIT && RISCV
- 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 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 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.
-
-endmenu # Boot images
-
-endmenu # Booting
-
source "api/Kconfig"
source "common/Kconfig"
diff --git a/common/Kconfig b/common/Kconfig
index c58f08ba91b..42be92ec7a7 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1,3 +1,5 @@
+source "common/Kconfig.boot"
+
menu "Boot timing"
config BOOTSTAGE
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
new file mode 100644
index 00000000000..d65b66d53ce
--- /dev/null
+++ b/common/Kconfig.boot
@@ -0,0 +1,341 @@
+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 MD5
+ select SHA1
+ 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_ENABLE_SHA256_SUPPORT
+ bool "Support SHA256 checksum of FIT image contents"
+ default y
+ select SHA256
+ help
+ Enable this to support SHA256 checksum of FIT image contents. A
+ SHA256 checksum is a 256-bit (32-byte) hash value used to check that
+ the image contents have not been corrupted.
+
+config FIT_ENABLE_SHA384_SUPPORT
+ bool "Support SHA384 checksum of FIT image contents"
+ default n
+ select SHA384
+ help
+ Enable this to support SHA384 checksum of FIT image contents. A
+ SHA384 checksum is a 384-bit (48-byte) hash value used to check that
+ the image contents have not been corrupted. Use this for the highest
+ security.
+
+config FIT_ENABLE_SHA512_SUPPORT
+ bool "Support SHA512 checksum of FIT image contents"
+ default n
+ select SHA512
+ help
+ Enable this to support SHA512 checksum of FIT image contents. A
+ SHA512 checksum is a 512-bit (64-byte) hash value used to check that
+ the image contents have not been corrupted.
+
+config FIT_SIGNATURE
+ bool "Enable signature verification of FIT uImages"
+ depends on DM
+ select HASH
+ select RSA
+ select RSA_VERIFY
+ select IMAGE_SIGN_INFO
+ 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_ENABLE_RSASSA_PSS_SUPPORT
+ bool "Support rsassa-pss signature scheme of FIT image contents"
+ depends on FIT_SIGNATURE
+ default n
+ 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
+ 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).
+
+if SPL
+
+config SPL_FIT
+ bool "Support Flattened Image Tree within SPL"
+ depends on SPL
+ 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_SIGNATURE
+ bool "Enable signature verification of FIT firmware within SPL"
+ depends on SPL_DM
+ select SPL_FIT
+ select SPL_CRYPTO_SUPPORT
+ select SPL_HASH_SUPPORT
+ select SPL_RSA
+ select SPL_RSA_VERIFY
+ select SPL_IMAGE_SIGN_INFO
+
+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.
+
+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
+
+config SPL_FIT_GENERATOR
+ string ".its file generator script for U-Boot FIT image"
+ depends on USE_SPL_FIT_GENERATOR
+ default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
+ 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
+ default "arch/riscv/lib/mkimage_fit_opensbi.sh" if SPL_LOAD_FIT && RISCV
+ 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 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 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.
+
+endmenu # Boot images
+
+endmenu # Booting
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 03/16] Kconfig: Move boot timing under boot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
2020-09-11 2:21 ` [PATCH 01/16] Kconfig: Add a 'Boot options' menu Simon Glass
2020-09-11 2:21 ` [PATCH 02/16] Kconfig: Move boot menu into common/ Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 04/16] Kconfig: Move boot media " Simon Glass
` (14 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This relates to booting, so move it under the boot menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 291 --------------------------------------------
common/Kconfig.boot | 291 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 291 insertions(+), 291 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 42be92ec7a7..58363b901a2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1,296 +1,5 @@
source "common/Kconfig.boot"
-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 TPL_BOOTSTAGE_RECORD_COUNT
- int "Number of boot stage records to store for TPL"
- 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
-
-endmenu
-
menu "Boot media"
config NOR_BOOT
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index d65b66d53ce..eb85045255a 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -338,4 +338,295 @@ config ARCH_FIXUP_FDT_MEMORY
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"
+ 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 TPL_BOOTSTAGE_RECORD_COUNT
+ int "Number of boot stage records to store for TPL"
+ 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
+
+endmenu
+
endmenu # Booting
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 04/16] Kconfig: Move boot media under boot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (2 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 03/16] Kconfig: Move boot timing under boot options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 05/16] Kconfig: Move autoboot options " Simon Glass
` (13 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This relates to booting, so move it under the boot menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 63 ---------------------------------------------
common/Kconfig.boot | 63 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 58363b901a2..a350b66c4d0 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1,68 +1,5 @@
source "common/Kconfig.boot"
-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 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"
- default n
- 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"
- 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
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index eb85045255a..f356f7f39d9 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -629,4 +629,67 @@ config 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"
+ default n
+ 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"
+ default n
+ 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"
+ 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
+
endmenu # Booting
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 05/16] Kconfig: Move autoboot options under boot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (3 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 04/16] Kconfig: Move boot media " Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 06/16] Kconfig: Move CONFIG_BOOTDELAY under autoboot options Simon Glass
` (12 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
At present the autoboot options are in cmd/Kconfig but they don't really
relate to commands. They relate to booting, so move this menu under the
boot menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
cmd/Kconfig | 117 --------------------------------------------
common/Kconfig.boot | 117 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 117 insertions(+), 117 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0761dbb7460..f9a30019540 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -66,123 +66,6 @@ config SYS_XTRACE
To enable the tracer a variable "xtrace" needs to be defined in
the environment.
-menu "Autoboot options"
-
-config AUTOBOOT
- bool "Autoboot"
- default y
- help
- This enables the autoboot. See doc/README.autoboot for detail.
-
-config AUTOBOOT_KEYED
- bool "Stop autobooting via specific input key / string"
- default n
- 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_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 string itself is hashed and compared against the hash
- in the environment variable 'bootstopkeysha256'. If it matches 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_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
- default n
- 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_STOP_STR_SHA256
- string "Stop autobooting via SHA256 encrypted password"
- depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
- 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.
-
-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 BUILD_BIN2C
bool
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index f356f7f39d9..4c67510e6c8 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -692,4 +692,121 @@ config SPI_BOOT
endmenu
+menu "Autoboot options"
+
+config AUTOBOOT
+ bool "Autoboot"
+ default y
+ help
+ This enables the autoboot. See doc/README.autoboot for detail.
+
+config AUTOBOOT_KEYED
+ bool "Stop autobooting via specific input key / string"
+ default n
+ 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_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 string itself is hashed and compared against the hash
+ in the environment variable 'bootstopkeysha256'. If it matches 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_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
+ default n
+ 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_STOP_STR_SHA256
+ string "Stop autobooting via SHA256 encrypted password"
+ depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION
+ 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.
+
+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
+
endmenu # Booting
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 06/16] Kconfig: Move CONFIG_BOOTDELAY under autoboot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (4 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 05/16] Kconfig: Move autoboot options " Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 07/16] Kconfig: Move misc boot options under 'boot options' Simon Glass
` (11 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This option relates to autoboot, so move it there.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 16 ----------------
common/Kconfig.boot | 16 ++++++++++++++++
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index a350b66c4d0..cf492af3ff5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1,21 +1,5 @@
source "common/Kconfig.boot"
-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
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 4c67510e6c8..e93475f1e42 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -700,6 +700,22 @@ config AUTOBOOT
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"
default n
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 07/16] Kconfig: Move misc boot options under 'boot options'
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (5 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 06/16] Kconfig: Move CONFIG_BOOTDELAY under autoboot options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 08/16] Kconfig: Move SUPPORT_RAW_INITRD under boot options Simon Glass
` (10 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
There are a number of miscellaneous boot images at the top level of the
kconfig menu. Move these into the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 53 ---------------------------------------------
common/Kconfig.boot | 53 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index cf492af3ff5..703505b0818 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1,58 +1,5 @@
source "common/Kconfig.boot"
-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.
-
-config USE_PREBOOT
- bool "Enable preboot"
- default "usb start" if USB_KEYBOARD
- 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
- default ""
- help
- This is the default of "preboot" environment variable.
-
menu "Console"
config MENU
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index e93475f1e42..297595bf8f4 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -825,4 +825,57 @@ config AUTOBOOT_MENU_SHOW
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
+ 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.
+
+config USE_PREBOOT
+ bool "Enable preboot"
+ default "usb start" if USB_KEYBOARD
+ 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
+ default ""
+ help
+ This is the default of "preboot" environment variable.
+
endmenu # Booting
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 08/16] Kconfig: Move SUPPORT_RAW_INITRD under boot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (6 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 07/16] Kconfig: Move misc boot options under 'boot options' Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 09/16] Kconfig: Move DEFAULT_FDT_FILE " Simon Glass
` (9 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This relates to booting, so move it under the 'boot images' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 8 --------
common/Kconfig.boot | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 703505b0818..bd9b574a8dc 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -433,14 +433,6 @@ endif
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
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 297595bf8f4..e4c2d5a603b 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -264,6 +264,14 @@ config LEGACY_IMAGE_FORMAT
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
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 09/16] Kconfig: Move DEFAULT_FDT_FILE under boot options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (7 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 08/16] Kconfig: Move SUPPORT_RAW_INITRD under boot options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 10/16] Kconfig: Create a new 'init options' menu Simon Glass
` (8 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This relates to booting since it is the default devicetree provided to
Linux. Move it under the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 5 -----
common/Kconfig.boot | 5 +++++
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index bd9b574a8dc..6423ab37973 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -433,11 +433,6 @@ endif
endmenu
-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
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index e4c2d5a603b..3be7316a1be 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -886,4 +886,9 @@ config PREBOOT
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
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 10/16] Kconfig: Create a new 'init options' menu
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (8 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 09/16] Kconfig: Move DEFAULT_FDT_FILE " Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 11/16] Kconfig: Move startup hooks under init options Simon Glass
` (7 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
There are quite a few options at the top level relating to U-Boot init.
Move them into their own menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/common/Kconfig b/common/Kconfig
index 6423ab37973..3aa8cf358a0 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -433,6 +433,8 @@ endif
endmenu
+menu "Init options"
+
config MISC_INIT_R
bool "Execute Misc Init"
default y if ARCH_KEYSTONE || ARCH_SUNXI || MPC85xx
@@ -483,6 +485,8 @@ config DISPLAY_BOARDINFO_LATE
the relocation phase. The board function checkboard() is called to do
this.
+endmenu # Init options
+
config BOUNCE_BUFFER
bool "Include bounce buffer API"
help
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 11/16] Kconfig: Move startup hooks under init options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (9 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 10/16] Kconfig: Create a new 'init options' menu Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 12/16] Kconfig: MISC_INIT_R and BOARD_LATE_INIT -> start-up hooks Simon Glass
` (6 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
These hooks relate to U-Boot init so move them under that menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 62 +++++++++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 3aa8cf358a0..1955dd6ee91 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -442,16 +442,6 @@ config MISC_INIT_R
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
@@ -485,27 +475,6 @@ config DISPLAY_BOARDINFO_LATE
the relocation phase. The board function checkboard() is called to do
this.
-endmenu # Init options
-
-config BOUNCE_BUFFER
- bool "Include bounce buffer API"
- help
- Some peripherals support DMA from a subset of physically
- addressable memory only. To support such peripherals, the
- bounce buffer API uses a temporary buffer: it copies data
- to/from DMA regions while managing cache operations.
-
- A second possible use of bounce buffers is their ability to
- provide aligned buffers for DMA operations.
-
-config BOARD_TYPES
- bool "Call get_board_type() to get and display the board type"
- help
- If this option is enabled, checkboard() will call get_board_type()
- to get a string containing the board type and this will be
- displayed immediately after the model is shown on the console
- early in boot.
-
menu "Start-up hooks"
config ARCH_EARLY_INIT_R
@@ -561,6 +530,37 @@ config PCI_INIT_R
endmenu
+endmenu # Init options
+
+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 BOUNCE_BUFFER
+ bool "Include bounce buffer API"
+ help
+ Some peripherals support DMA from a subset of physically
+ addressable memory only. To support such peripherals, the
+ bounce buffer API uses a temporary buffer: it copies data
+ to/from DMA regions while managing cache operations.
+
+ A second possible use of bounce buffers is their ability to
+ provide aligned buffers for DMA operations.
+
+config BOARD_TYPES
+ bool "Call get_board_type() to get and display the board type"
+ help
+ If this option is enabled, checkboard() will call get_board_type()
+ to get a string containing the board type and this will be
+ displayed immediately after the model is shown on the console
+ early in boot.
+
menu "Security support"
config HASH
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 12/16] Kconfig: MISC_INIT_R and BOARD_LATE_INIT -> start-up hooks
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (10 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 11/16] Kconfig: Move startup hooks under init options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 13/16] Kconfig: Move VERSION_VARIABLE under environment Simon Glass
` (5 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
These are start-up hooks so put them under that menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 1955dd6ee91..bcb3519c775 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -435,23 +435,6 @@ endmenu
menu "Init options"
-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 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
@@ -509,6 +492,16 @@ config BOARD_EARLY_INIT_R
relocation. With this option, U-Boot calls board_early_init_r()
in the post-relocation init sequence.
+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 LAST_STAGE_INIT
bool "Call board-specific as last setup step"
help
@@ -518,6 +511,13 @@ config LAST_STAGE_INIT
U-Boot calls last_stage_init() before the command-line interpreter is
started.
+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 PCI_INIT_R
bool "Enumerate PCI buses during init"
depends on PCI
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 13/16] Kconfig: Move VERSION_VARIABLE under environment
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (11 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 12/16] Kconfig: MISC_INIT_R and BOARD_LATE_INIT -> start-up hooks Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 14/16] Kconfig: Move BOUNCE_BUFFER under driver options Simon Glass
` (4 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This relates to the environment so should not be at the top level. Move
it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 10 ----------
env/Kconfig | 9 +++++++++
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index bcb3519c775..132d1051607 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -532,16 +532,6 @@ endmenu
endmenu # Init options
-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 BOUNCE_BUFFER
bool "Include bounce buffer API"
help
diff --git a/env/Kconfig b/env/Kconfig
index b59ba310ec3..02dcd98e111 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -773,4 +773,13 @@ config TPL_ENV_IS_IN_FLASH
endif
+config VERSION_VARIABLE
+ bool "Add a 'ver' environment variable with the U-Boot version"
+ 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.
+
endmenu
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 14/16] Kconfig: Move BOUNCE_BUFFER under driver options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (12 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 13/16] Kconfig: Move VERSION_VARIABLE under environment Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 15/16] Kconfig: Move BOARD_TYPES under init options Simon Glass
` (3 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This option does not belong at the top level. Move it under generic
driver options.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 11 -----------
drivers/core/Kconfig | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 132d1051607..a1a898babd8 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -532,17 +532,6 @@ endmenu
endmenu # Init options
-config BOUNCE_BUFFER
- bool "Include bounce buffer API"
- help
- Some peripherals support DMA from a subset of physically
- addressable memory only. To support such peripherals, the
- bounce buffer API uses a temporary buffer: it copies data
- to/from DMA regions while managing cache operations.
-
- A second possible use of bounce buffers is their ability to
- provide aligned buffers for DMA operations.
-
config BOARD_TYPES
bool "Call get_board_type() to get and display the board type"
help
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 00d1d80dc38..818bf85b64a 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -277,4 +277,15 @@ config ACPIGEN
things like generating device-specific tables and returning the ACPI
name of a device.
+config BOUNCE_BUFFER
+ bool "Include bounce buffer API"
+ help
+ Some peripherals support DMA from a subset of physically
+ addressable memory only. To support such peripherals, the
+ bounce buffer API uses a temporary buffer: it copies data
+ to/from DMA regions while managing cache operations.
+
+ A second possible use of bounce buffers is their ability to
+ provide aligned buffers for DMA operations.
+
endmenu
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 15/16] Kconfig: Move BOARD_TYPES under init options
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (13 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 14/16] Kconfig: Move BOUNCE_BUFFER under driver options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 2:21 ` [PATCH 16/16] Kconfig: Create a new tools menu Simon Glass
` (2 subsequent siblings)
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
This actually relates to something displayed on start-up, so move it into
that menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
common/Kconfig | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index a1a898babd8..318d372a481 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -435,6 +435,14 @@ endmenu
menu "Init options"
+config BOARD_TYPES
+ bool "Call get_board_type() to get and display the board type"
+ help
+ If this option is enabled, checkboard() will call get_board_type()
+ to get a string containing the board type and this will be
+ displayed immediately after the model is shown on the console
+ early in boot.
+
config DISPLAY_CPUINFO
bool "Display information about the CPU during start up"
default y if ARC|| ARM || NIOS2 || X86 || XTENSA || M68K
@@ -532,14 +540,6 @@ endmenu
endmenu # Init options
-config BOARD_TYPES
- bool "Call get_board_type() to get and display the board type"
- help
- If this option is enabled, checkboard() will call get_board_type()
- to get a string containing the board type and this will be
- displayed immediately after the model is shown on the console
- early in boot.
-
menu "Security support"
config HASH
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 16/16] Kconfig: Create a new tools menu
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (14 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 15/16] Kconfig: Move BOARD_TYPES under init options Simon Glass
@ 2020-09-11 2:21 ` Simon Glass
2020-09-11 16:11 ` [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Tom Rini
2020-10-09 22:11 ` Tom Rini
17 siblings, 0 replies; 21+ messages in thread
From: Simon Glass @ 2020-09-11 2:21 UTC (permalink / raw)
To: u-boot
At present MKIMAGE_DTC_PATH is in the devicetree menu but not within
'devicetree control' since it does not relate to that. As a result it
shows up in the top menu.
It actually relates to the mkimage tool, so create a new tools menu for it
and move it there.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Kconfig | 2 ++
dts/Kconfig | 9 ---------
tools/Kconfig | 12 ++++++++++++
3 files changed, 14 insertions(+), 9 deletions(-)
create mode 100644 tools/Kconfig
diff --git a/Kconfig b/Kconfig
index aa979a7dcf9..6731bed2bc0 100644
--- a/Kconfig
+++ b/Kconfig
@@ -445,3 +445,5 @@ source "fs/Kconfig"
source "lib/Kconfig"
source "test/Kconfig"
+
+source "tools/Kconfig"
diff --git a/dts/Kconfig b/dts/Kconfig
index 046a54a1736..86ea8ce8875 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -377,12 +377,3 @@ config TPL_OF_PLATDATA
declarations for each node. See of-plat.txt for more information.
endmenu
-
-config MKIMAGE_DTC_PATH
- string "Path to dtc binary for use within mkimage"
- default "dtc"
- help
- The mkimage host tool will, in order to generate FIT images make
- calls to the dtc application in order to create the output. In
- some cases the system dtc may not support all required features
- and the path to a different version should be given here.
diff --git a/tools/Kconfig b/tools/Kconfig
new file mode 100644
index 00000000000..b2f5012240c
--- /dev/null
+++ b/tools/Kconfig
@@ -0,0 +1,12 @@
+menu "Tools options"
+
+config MKIMAGE_DTC_PATH
+ string "Path to dtc binary for use within mkimage"
+ default "dtc"
+ help
+ The mkimage host tool will, in order to generate FIT images make
+ calls to the dtc application in order to create the output. In
+ some cases the system dtc may not support all required features
+ and the path to a different version should be given here.
+
+endmenu
--
2.28.0.618.gf4bc123cb7-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (15 preceding siblings ...)
2020-09-11 2:21 ` [PATCH 16/16] Kconfig: Create a new tools menu Simon Glass
@ 2020-09-11 16:11 ` Tom Rini
2020-09-11 20:15 ` Simon Glass
2020-10-09 22:11 ` Tom Rini
17 siblings, 1 reply; 21+ messages in thread
From: Tom Rini @ 2020-09-11 16:11 UTC (permalink / raw)
To: u-boot
On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote:
>
> At present this menu is pretty messy, with quite a few minor options shown
> at the top level. This series creates a few new menus and moves things
> around so that the top-level menu is cleaner.
>
> There is more to do, but this is a start.
[snip]
> Kconfig | 340 +---------------
> cmd/Kconfig | 117 ------
> common/Kconfig | 505 ++----------------------
> common/Kconfig.boot | 894 +++++++++++++++++++++++++++++++++++++++++++
> drivers/core/Kconfig | 11 +
> dts/Kconfig | 9 -
> env/Kconfig | 9 +
> tools/Kconfig | 12 +
> 8 files changed, 955 insertions(+), 942 deletions(-)
> create mode 100644 common/Kconfig.boot
> create mode 100644 tools/Kconfig
And after a resync of the defconfigs:
555 files changed, 941 insertions(+), 941 deletions(-)
and a partial wc -l:
449 Kconfig
697 common/Kconfig
894 common/Kconfig.boot
2190 cmd/Kconfig
So in the end, yes, this is I think making things easier to maintain but
will cause a few merge hiccups.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200911/7e80ee44/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
2020-09-11 16:11 ` [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Tom Rini
@ 2020-09-11 20:15 ` Simon Glass
2020-09-11 20:20 ` Tom Rini
0 siblings, 1 reply; 21+ messages in thread
From: Simon Glass @ 2020-09-11 20:15 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Fri, 11 Sep 2020 at 10:11, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote:
>
> >
> > At present this menu is pretty messy, with quite a few minor options shown
> > at the top level. This series creates a few new menus and moves things
> > around so that the top-level menu is cleaner.
> >
> > There is more to do, but this is a start.
> [snip]
> > Kconfig | 340 +---------------
> > cmd/Kconfig | 117 ------
> > common/Kconfig | 505 ++----------------------
> > common/Kconfig.boot | 894 +++++++++++++++++++++++++++++++++++++++++++
> > drivers/core/Kconfig | 11 +
> > dts/Kconfig | 9 -
> > env/Kconfig | 9 +
> > tools/Kconfig | 12 +
> > 8 files changed, 955 insertions(+), 942 deletions(-)
> > create mode 100644 common/Kconfig.boot
> > create mode 100644 tools/Kconfig
>
> And after a resync of the defconfigs:
> 555 files changed, 941 insertions(+), 941 deletions(-)
> and a partial wc -l:
> 449 Kconfig
> 697 common/Kconfig
> 894 common/Kconfig.boot
> 2190 cmd/Kconfig
>
> So in the end, yes, this is I think making things easier to maintain but
> will cause a few merge hiccups.
Oh dear, I completely forgot about that aspect. Should I add a resync
patch at the end, or is it better to do it when reviewed/applied?
Regards,
Simon
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
2020-09-11 20:15 ` Simon Glass
@ 2020-09-11 20:20 ` Tom Rini
0 siblings, 0 replies; 21+ messages in thread
From: Tom Rini @ 2020-09-11 20:20 UTC (permalink / raw)
To: u-boot
On Fri, Sep 11, 2020 at 02:15:50PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 11 Sep 2020 at 10:11, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote:
> >
> > >
> > > At present this menu is pretty messy, with quite a few minor options shown
> > > at the top level. This series creates a few new menus and moves things
> > > around so that the top-level menu is cleaner.
> > >
> > > There is more to do, but this is a start.
> > [snip]
> > > Kconfig | 340 +---------------
> > > cmd/Kconfig | 117 ------
> > > common/Kconfig | 505 ++----------------------
> > > common/Kconfig.boot | 894 +++++++++++++++++++++++++++++++++++++++++++
> > > drivers/core/Kconfig | 11 +
> > > dts/Kconfig | 9 -
> > > env/Kconfig | 9 +
> > > tools/Kconfig | 12 +
> > > 8 files changed, 955 insertions(+), 942 deletions(-)
> > > create mode 100644 common/Kconfig.boot
> > > create mode 100644 tools/Kconfig
> >
> > And after a resync of the defconfigs:
> > 555 files changed, 941 insertions(+), 941 deletions(-)
> > and a partial wc -l:
> > 449 Kconfig
> > 697 common/Kconfig
> > 894 common/Kconfig.boot
> > 2190 cmd/Kconfig
> >
> > So in the end, yes, this is I think making things easier to maintain but
> > will cause a few merge hiccups.
>
> Oh dear, I completely forgot about that aspect. Should I add a resync
> patch at the end, or is it better to do it when reviewed/applied?
Don't worry about re-sync patches, those are trivially generated and
fail to apply easily. Really I'm fine with most cases not touching
defconfigs EXCEPT when we're changing requires / depends stuff. That
requires a defconfig change at the same time to not break things.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200911/d8cb897e/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu
2020-09-11 2:21 [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Simon Glass
` (16 preceding siblings ...)
2020-09-11 16:11 ` [PATCH 00/16] Kconfig: Tidy up the top-level kconfig menu Tom Rini
@ 2020-10-09 22:11 ` Tom Rini
17 siblings, 0 replies; 21+ messages in thread
From: Tom Rini @ 2020-10-09 22:11 UTC (permalink / raw)
To: u-boot
On Thu, Sep 10, 2020 at 08:21:11PM -0600, Simon Glass wrote:
> At present this menu is pretty messy, with quite a few minor options shown
> at the top level. This series creates a few new menus and moves things
> around so that the top-level menu is cleaner.
>
> There is more to do, but this is a start.
>
>
> Simon Glass (16):
> Kconfig: Add a 'Boot options' menu
> Kconfig: Move boot menu into common/
> Kconfig: Move boot timing under boot options
> Kconfig: Move boot media under boot options
> Kconfig: Move autoboot options under boot options
> Kconfig: Move CONFIG_BOOTDELAY under autoboot options
> Kconfig: Move misc boot options under 'boot options'
> Kconfig: Move SUPPORT_RAW_INITRD under boot options
> Kconfig: Move DEFAULT_FDT_FILE under boot options
> Kconfig: Create a new 'init options' menu
> Kconfig: Move startup hooks under init options
> Kconfig: MISC_INIT_R and BOARD_LATE_INIT -> start-up hooks
> Kconfig: Move VERSION_VARIABLE under environment
> Kconfig: Move BOUNCE_BUFFER under driver options
> Kconfig: Move BOARD_TYPES under init options
> Kconfig: Create a new tools menu
>
> Kconfig | 340 +---------------
> cmd/Kconfig | 117 ------
> common/Kconfig | 505 ++----------------------
> common/Kconfig.boot | 894 +++++++++++++++++++++++++++++++++++++++++++
> drivers/core/Kconfig | 11 +
> dts/Kconfig | 9 -
> env/Kconfig | 9 +
> tools/Kconfig | 12 +
> 8 files changed, 955 insertions(+), 942 deletions(-)
> create mode 100644 common/Kconfig.boot
> create mode 100644 tools/Kconfig
For the series, applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201009/38b1f1b7/attachment.sig>
^ permalink raw reply [flat|nested] 21+ messages in thread