Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 1 | menu "Boot options" |
| 2 | |
| 3 | menu "Boot images" |
| 4 | |
| 5 | config ANDROID_BOOT_IMAGE |
| 6 | bool "Enable support for Android Boot Images" |
| 7 | default y if FASTBOOT |
| 8 | help |
| 9 | This enables support for booting images which use the Android |
| 10 | image format header. |
| 11 | |
| 12 | config FIT |
| 13 | bool "Support Flattened Image Tree" |
| 14 | select MD5 |
| 15 | select SHA1 |
| 16 | help |
| 17 | This option allows you to boot the new uImage structure, |
| 18 | Flattened Image Tree. FIT is formally a FDT, which can include |
| 19 | images of various types (kernel, FDT blob, ramdisk, etc.) |
| 20 | in a single blob. To boot this new uImage structure, |
| 21 | pass the address of the blob to the "bootm" command. |
| 22 | FIT is very flexible, supporting compression, multiple images, |
| 23 | multiple configurations, verification through hashing and also |
| 24 | verified boot (secure boot using RSA). |
| 25 | |
| 26 | if FIT |
| 27 | |
| 28 | config FIT_EXTERNAL_OFFSET |
| 29 | hex "FIT external data offset" |
| 30 | default 0x0 |
| 31 | help |
| 32 | This specifies a data offset in fit image. |
| 33 | The offset is from data payload offset to the beginning of |
| 34 | fit image header. When specifies a offset, specific data |
| 35 | could be put in the hole between data payload and fit image |
| 36 | header, such as CSF data on i.MX platform. |
| 37 | |
| 38 | config FIT_ENABLE_SHA256_SUPPORT |
| 39 | bool "Support SHA256 checksum of FIT image contents" |
| 40 | default y |
| 41 | select SHA256 |
| 42 | help |
| 43 | Enable this to support SHA256 checksum of FIT image contents. A |
| 44 | SHA256 checksum is a 256-bit (32-byte) hash value used to check that |
| 45 | the image contents have not been corrupted. |
| 46 | |
| 47 | config FIT_ENABLE_SHA384_SUPPORT |
| 48 | bool "Support SHA384 checksum of FIT image contents" |
| 49 | default n |
| 50 | select SHA384 |
| 51 | help |
| 52 | Enable this to support SHA384 checksum of FIT image contents. A |
| 53 | SHA384 checksum is a 384-bit (48-byte) hash value used to check that |
| 54 | the image contents have not been corrupted. Use this for the highest |
| 55 | security. |
| 56 | |
| 57 | config FIT_ENABLE_SHA512_SUPPORT |
| 58 | bool "Support SHA512 checksum of FIT image contents" |
| 59 | default n |
| 60 | select SHA512 |
| 61 | help |
| 62 | Enable this to support SHA512 checksum of FIT image contents. A |
| 63 | SHA512 checksum is a 512-bit (64-byte) hash value used to check that |
| 64 | the image contents have not been corrupted. |
| 65 | |
Simon Glass | 6f3c2d8 | 2021-02-15 17:08:10 -0700 | [diff] [blame] | 66 | config FIT_FULL_CHECK |
| 67 | bool "Do a full check of the FIT before using it" |
| 68 | default y |
| 69 | help |
| 70 | Enable this do a full check of the FIT to make sure it is valid. This |
| 71 | helps to protect against carefully crafted FITs which take advantage |
| 72 | of bugs or omissions in the code. This includes a bad structure, |
| 73 | multiple root nodes and the like. |
| 74 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 75 | config FIT_SIGNATURE |
| 76 | bool "Enable signature verification of FIT uImages" |
| 77 | depends on DM |
| 78 | select HASH |
| 79 | select RSA |
| 80 | select RSA_VERIFY |
| 81 | select IMAGE_SIGN_INFO |
Simon Glass | 6f3c2d8 | 2021-02-15 17:08:10 -0700 | [diff] [blame] | 82 | select FIT_FULL_CHECK |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 83 | help |
| 84 | This option enables signature verification of FIT uImages, |
| 85 | using a hash signed and verified using RSA. If |
| 86 | CONFIG_SHA_PROG_HW_ACCEL is defined, i.e support for progressive |
| 87 | hashing is available using hardware, then the RSA library will use |
| 88 | it. See doc/uImage.FIT/signature.txt for more details. |
| 89 | |
| 90 | WARNING: When relying on signed FIT images with a required signature |
| 91 | check the legacy image format is disabled by default, so that |
| 92 | unsigned images cannot be loaded. If a board needs the legacy image |
| 93 | format support in this case, enable it using |
| 94 | CONFIG_LEGACY_IMAGE_FORMAT. |
| 95 | |
| 96 | config FIT_SIGNATURE_MAX_SIZE |
| 97 | hex "Max size of signed FIT structures" |
| 98 | depends on FIT_SIGNATURE |
| 99 | default 0x10000000 |
| 100 | help |
| 101 | This option sets a max size in bytes for verified FIT uImages. |
| 102 | A sane value of 256MB protects corrupted DTB structures from overlapping |
| 103 | device memory. Assure this size does not extend past expected storage |
| 104 | space. |
| 105 | |
| 106 | config FIT_ENABLE_RSASSA_PSS_SUPPORT |
| 107 | bool "Support rsassa-pss signature scheme of FIT image contents" |
| 108 | depends on FIT_SIGNATURE |
| 109 | default n |
| 110 | help |
| 111 | Enable this to support the pss padding algorithm as described |
| 112 | in the rfc8017 (https://tools.ietf.org/html/rfc8017). |
| 113 | |
| 114 | config FIT_CIPHER |
| 115 | bool "Enable ciphering data in a FIT uImages" |
| 116 | depends on DM |
| 117 | select AES |
| 118 | help |
| 119 | Enable the feature of data ciphering/unciphering in the tool mkimage |
| 120 | and in the u-boot support of the FIT image. |
| 121 | |
| 122 | config FIT_VERBOSE |
| 123 | bool "Show verbose messages when FIT images fail" |
| 124 | help |
| 125 | Generally a system will have valid FIT images so debug messages |
| 126 | are a waste of code space. If you are debugging your images then |
| 127 | you can enable this option to get more verbose information about |
| 128 | failures. |
| 129 | |
| 130 | config FIT_BEST_MATCH |
| 131 | bool "Select the best match for the kernel device tree" |
| 132 | help |
| 133 | When no configuration is explicitly selected, default to the |
| 134 | one whose fdt's compatibility field best matches that of |
| 135 | U-Boot itself. A match is considered "best" if it matches the |
| 136 | most specific compatibility entry of U-Boot's fdt's root node. |
| 137 | The order of entries in the configuration's fdt is ignored. |
| 138 | |
| 139 | config FIT_IMAGE_POST_PROCESS |
| 140 | bool "Enable post-processing of FIT artifacts after loading by U-Boot" |
| 141 | depends on TI_SECURE_DEVICE |
| 142 | help |
| 143 | Allows doing any sort of manipulation to blobs after they got extracted |
| 144 | from FIT images like stripping off headers or modifying the size of the |
| 145 | blob, verification, authentication, decryption etc. in a platform or |
| 146 | board specific way. In order to use this feature a platform or board- |
| 147 | specific implementation of board_fit_image_post_process() must be |
| 148 | provided. Also, anything done during this post-processing step would |
| 149 | need to be comprehended in how the images were prepared before being |
| 150 | injected into the FIT creation (i.e. the blobs would have been pre- |
| 151 | processed before being added to the FIT image). |
| 152 | |
Ravik Hasija | 7a01882 | 2021-01-27 14:01:48 -0800 | [diff] [blame] | 153 | config FIT_PRINT |
| 154 | bool "Support FIT printing" |
| 155 | default y |
| 156 | help |
| 157 | Support printing the content of the fitImage in a verbose manner. |
| 158 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 159 | if SPL |
| 160 | |
| 161 | config SPL_FIT |
| 162 | bool "Support Flattened Image Tree within SPL" |
| 163 | depends on SPL |
| 164 | select SPL_OF_LIBFDT |
| 165 | |
| 166 | config SPL_FIT_PRINT |
| 167 | bool "Support FIT printing within SPL" |
| 168 | depends on SPL_FIT |
| 169 | help |
| 170 | Support printing the content of the fitImage in a verbose manner in SPL. |
| 171 | |
Simon Glass | 6f3c2d8 | 2021-02-15 17:08:10 -0700 | [diff] [blame] | 172 | config SPL_FIT_FULL_CHECK |
| 173 | bool "Do a full check of the FIT before using it" |
| 174 | help |
| 175 | Enable this do a full check of the FIT to make sure it is valid. This |
| 176 | helps to protect against carefully crafted FITs which take advantage |
| 177 | of bugs or omissions in the code. This includes a bad structure, |
| 178 | multiple root nodes and the like. |
| 179 | |
| 180 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 181 | config SPL_FIT_SIGNATURE |
| 182 | bool "Enable signature verification of FIT firmware within SPL" |
| 183 | depends on SPL_DM |
Klaus Heinrich Kiwi | bdb7f26 | 2021-02-09 15:41:54 -0300 | [diff] [blame] | 184 | depends on SPL_LOAD_FIT || SPL_LOAD_FIT_FULL |
Klaus Heinrich Kiwi | 6ce2813 | 2021-02-09 15:41:53 -0300 | [diff] [blame] | 185 | select FIT_SIGNATURE |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 186 | select SPL_FIT |
| 187 | select SPL_CRYPTO_SUPPORT |
| 188 | select SPL_HASH_SUPPORT |
| 189 | select SPL_RSA |
| 190 | select SPL_RSA_VERIFY |
| 191 | select SPL_IMAGE_SIGN_INFO |
Simon Glass | 6f3c2d8 | 2021-02-15 17:08:10 -0700 | [diff] [blame] | 192 | select SPL_FIT_FULL_CHECK |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 193 | |
| 194 | config SPL_LOAD_FIT |
| 195 | bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)" |
| 196 | select SPL_FIT |
| 197 | help |
| 198 | Normally with the SPL framework a legacy image is generated as part |
| 199 | of the build. This contains U-Boot along with information as to |
| 200 | where it should be loaded. This option instead enables generation |
| 201 | of a FIT (Flat Image Tree) which provides more flexibility. In |
| 202 | particular it can handle selecting from multiple device tree |
| 203 | and passing the correct one to U-Boot. |
| 204 | |
| 205 | config SPL_LOAD_FIT_ADDRESS |
| 206 | hex "load address of fit image" |
| 207 | depends on SPL_LOAD_FIT |
| 208 | default 0x0 |
| 209 | help |
| 210 | Specify the load address of the fit image that will be loaded |
| 211 | by SPL. |
| 212 | |
| 213 | config SPL_LOAD_FIT_APPLY_OVERLAY |
| 214 | bool "Enable SPL applying DT overlays from FIT" |
| 215 | depends on SPL_LOAD_FIT |
| 216 | select OF_LIBFDT_OVERLAY |
| 217 | help |
| 218 | The device tree is loaded from the FIT image. Allow the SPL is to |
| 219 | also load device-tree overlays from the FIT image an apply them |
| 220 | over the device tree. |
| 221 | |
| 222 | config SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ |
| 223 | depends on SPL_LOAD_FIT_APPLY_OVERLAY |
| 224 | default 0x10000 |
| 225 | hex "size of temporary buffer used to load the overlays" |
| 226 | help |
| 227 | The size of the area where the overlays will be loaded and |
| 228 | uncompress. Must be at least as large as biggest overlay |
| 229 | (uncompressed) |
| 230 | |
| 231 | config SPL_LOAD_FIT_FULL |
| 232 | bool "Enable SPL loading U-Boot as a FIT (full fitImage features)" |
| 233 | select SPL_FIT |
| 234 | help |
| 235 | Normally with the SPL framework a legacy image is generated as part |
| 236 | of the build. This contains U-Boot along with information as to |
| 237 | where it should be loaded. This option instead enables generation |
| 238 | of a FIT (Flat Image Tree) which provides more flexibility. In |
| 239 | particular it can handle selecting from multiple device tree |
| 240 | and passing the correct one to U-Boot. |
| 241 | |
| 242 | config SPL_FIT_IMAGE_POST_PROCESS |
| 243 | bool "Enable post-processing of FIT artifacts after loading by the SPL" |
| 244 | depends on SPL_LOAD_FIT |
| 245 | help |
| 246 | Allows doing any sort of manipulation to blobs after they got extracted |
| 247 | from the U-Boot FIT image like stripping off headers or modifying the |
| 248 | size of the blob, verification, authentication, decryption etc. in a |
| 249 | platform or board specific way. In order to use this feature a platform |
| 250 | or board-specific implementation of board_fit_image_post_process() must |
| 251 | be provided. Also, anything done during this post-processing step would |
| 252 | need to be comprehended in how the images were prepared before being |
| 253 | injected into the FIT creation (i.e. the blobs would have been pre- |
| 254 | processed before being added to the FIT image). |
| 255 | |
| 256 | config SPL_FIT_SOURCE |
| 257 | string ".its source file for U-Boot FIT image" |
| 258 | depends on SPL_FIT |
| 259 | help |
| 260 | Specifies a (platform specific) FIT source file to generate the |
| 261 | U-Boot FIT image. This could specify further image to load and/or |
| 262 | execute. |
| 263 | |
| 264 | config USE_SPL_FIT_GENERATOR |
| 265 | bool "Use a script to generate the .its script" |
| 266 | default y if SPL_FIT && !ARCH_SUNXI |
| 267 | |
| 268 | config SPL_FIT_GENERATOR |
| 269 | string ".its file generator script for U-Boot FIT image" |
| 270 | depends on USE_SPL_FIT_GENERATOR |
| 271 | default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP |
| 272 | default "arch/arm/mach-zynqmp/mkimage_fit_atf.sh" if SPL_LOAD_FIT && ARCH_ZYNQMP |
| 273 | default "arch/riscv/lib/mkimage_fit_opensbi.sh" if SPL_LOAD_FIT && RISCV |
| 274 | help |
| 275 | Specifies a (platform specific) script file to generate the FIT |
| 276 | source file used to build the U-Boot FIT image file. This gets |
| 277 | passed a list of supported device tree file stub names to |
| 278 | include in the generated image. |
| 279 | |
| 280 | endif # SPL |
| 281 | |
| 282 | endif # FIT |
| 283 | |
| 284 | config LEGACY_IMAGE_FORMAT |
| 285 | bool "Enable support for the legacy image format" |
| 286 | default y if !FIT_SIGNATURE |
| 287 | help |
| 288 | This option enables the legacy image format. It is enabled by |
| 289 | default for backward compatibility, unless FIT_SIGNATURE is |
| 290 | set where it is disabled so that unsigned images cannot be |
| 291 | loaded. If a board needs the legacy image format support in this |
| 292 | case, enable it here. |
| 293 | |
Simon Glass | aefa34f | 2020-09-10 20:21:19 -0600 | [diff] [blame] | 294 | config SUPPORT_RAW_INITRD |
| 295 | bool "Enable raw initrd images" |
| 296 | help |
| 297 | Note, defining the SUPPORT_RAW_INITRD allows user to supply |
| 298 | kernel with raw initrd images. The syntax is slightly different, the |
| 299 | address of the initrd must be augmented by it's size, in the following |
| 300 | format: "<initrd address>:<initrd size>". |
| 301 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 302 | config OF_BOARD_SETUP |
| 303 | bool "Set up board-specific details in device tree before boot" |
| 304 | depends on OF_LIBFDT |
| 305 | help |
| 306 | This causes U-Boot to call ft_board_setup() before booting into |
| 307 | the Operating System. This function can set up various |
| 308 | board-specific information in the device tree for use by the OS. |
| 309 | The device tree is then passed to the OS. |
| 310 | |
| 311 | config OF_SYSTEM_SETUP |
| 312 | bool "Set up system-specific details in device tree before boot" |
| 313 | depends on OF_LIBFDT |
| 314 | help |
| 315 | This causes U-Boot to call ft_system_setup() before booting into |
| 316 | the Operating System. This function can set up various |
| 317 | system-specific information in the device tree for use by the OS. |
| 318 | The device tree is then passed to the OS. |
| 319 | |
| 320 | config OF_STDOUT_VIA_ALIAS |
| 321 | bool "Update the device-tree stdout alias from U-Boot" |
| 322 | depends on OF_LIBFDT |
| 323 | help |
| 324 | This uses U-Boot's serial alias from the aliases node to update |
| 325 | the device tree passed to the OS. The "linux,stdout-path" property |
| 326 | in the chosen node is set to point to the correct serial node. |
| 327 | This option currently references CONFIG_CONS_INDEX, which is |
| 328 | incorrect when used with device tree as this option does not |
| 329 | exist / should not be used. |
| 330 | |
| 331 | config SYS_EXTRA_OPTIONS |
| 332 | string "Extra Options (DEPRECATED)" |
| 333 | help |
| 334 | The old configuration infrastructure (= mkconfig + boards.cfg) |
| 335 | provided the extra options field. If you have something like |
| 336 | "HAS_BAR,BAZ=64", the optional options |
| 337 | #define CONFIG_HAS |
| 338 | #define CONFIG_BAZ 64 |
| 339 | will be defined in include/config.h. |
| 340 | This option was prepared for the smooth migration from the old |
| 341 | configuration to Kconfig. Since this option will be removed sometime, |
| 342 | new boards should not use this option. |
| 343 | |
| 344 | config HAVE_SYS_TEXT_BASE |
| 345 | bool |
| 346 | depends on !NIOS2 && !XTENSA |
| 347 | depends on !EFI_APP |
| 348 | default y |
| 349 | |
| 350 | config SYS_TEXT_BASE |
| 351 | depends on HAVE_SYS_TEXT_BASE |
| 352 | default 0x80800000 if ARCH_OMAP2PLUS || ARCH_K3 |
| 353 | default 0x4a000000 if ARCH_SUNXI && !MACH_SUN9I && !MACH_SUN8I_V3S |
| 354 | default 0x2a000000 if ARCH_SUNXI && MACH_SUN9I |
| 355 | default 0x42e00000 if ARCH_SUNXI && MACH_SUN8I_V3S |
| 356 | hex "Text Base" |
| 357 | help |
| 358 | The address in memory that U-Boot will be running from, initially. |
| 359 | |
| 360 | config SYS_CLK_FREQ |
| 361 | depends on ARC || ARCH_SUNXI || MPC83xx |
| 362 | int "CPU clock frequency" |
| 363 | help |
| 364 | TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture |
| 365 | |
| 366 | config ARCH_FIXUP_FDT_MEMORY |
| 367 | bool "Enable arch_fixup_memory_banks() call" |
| 368 | default y |
| 369 | help |
| 370 | Enable FDT memory map syncup before OS boot. This feature can be |
| 371 | used for booting OS with different memory setup where the part of |
| 372 | the memory location should be used for different purpose. |
| 373 | |
Simon Glass | 96d0aa9 | 2020-11-04 09:57:35 -0700 | [diff] [blame] | 374 | config CHROMEOS |
| 375 | bool "Support booting Chrome OS" |
| 376 | help |
| 377 | Chrome OS requires U-Boot to set up a table indicating the boot mode |
| 378 | (e.g. Developer mode) and a few other things. Enable this if you are |
| 379 | booting on a Chromebook to avoid getting an error about an invalid |
| 380 | firmware ID. |
| 381 | |
| 382 | config CHROMEOS_VBOOT |
| 383 | bool "Support Chrome OS verified boot" |
| 384 | help |
| 385 | This is intended to enable the full Chrome OS verified boot support |
| 386 | in U-Boot. It is not actually implemented in the U-Boot source code |
| 387 | at present, so this option is always set to 'n'. It allows |
| 388 | distinguishing between booting Chrome OS in a basic way (developer |
| 389 | mode) and a full boot. |
| 390 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 391 | endmenu # Boot images |
| 392 | |
Simon Glass | 75e65cc | 2020-09-10 20:21:14 -0600 | [diff] [blame] | 393 | menu "Boot timing" |
| 394 | |
| 395 | config BOOTSTAGE |
| 396 | bool "Boot timing and reporting" |
| 397 | help |
| 398 | Enable recording of boot time while booting. To use it, insert |
| 399 | calls to bootstage_mark() with a suitable BOOTSTAGE_ID from |
| 400 | bootstage.h. Only a single entry is recorded for each ID. You can |
| 401 | give the entry a name with bootstage_mark_name(). You can also |
| 402 | record elapsed time in a particular stage using bootstage_start() |
| 403 | before starting and bootstage_accum() when finished. Bootstage will |
| 404 | add up all the accumulated time and report it. |
| 405 | |
| 406 | Normally, IDs are defined in bootstage.h but a small number of |
| 407 | additional 'user' IDs can be used by passing BOOTSTAGE_ID_ALLOC |
| 408 | as the ID. |
| 409 | |
| 410 | Calls to show_boot_progress() will also result in log entries but |
| 411 | these will not have names. |
| 412 | |
| 413 | config SPL_BOOTSTAGE |
| 414 | bool "Boot timing and reported in SPL" |
| 415 | depends on BOOTSTAGE |
| 416 | help |
| 417 | Enable recording of boot time in SPL. To make this visible to U-Boot |
| 418 | proper, enable BOOTSTAGE_STASH as well. This will stash the timing |
| 419 | information when SPL finishes and load it when U-Boot proper starts |
| 420 | up. |
| 421 | |
| 422 | config TPL_BOOTSTAGE |
| 423 | bool "Boot timing and reported in TPL" |
| 424 | depends on BOOTSTAGE |
| 425 | help |
| 426 | Enable recording of boot time in SPL. To make this visible to U-Boot |
| 427 | proper, enable BOOTSTAGE_STASH as well. This will stash the timing |
| 428 | information when TPL finishes and load it when U-Boot proper starts |
| 429 | up. |
| 430 | |
| 431 | config BOOTSTAGE_REPORT |
| 432 | bool "Display a detailed boot timing report before booting the OS" |
| 433 | depends on BOOTSTAGE |
| 434 | help |
| 435 | Enable output of a boot time report just before the OS is booted. |
| 436 | This shows how long it took U-Boot to go through each stage of the |
| 437 | boot process. The report looks something like this: |
| 438 | |
| 439 | Timer summary in microseconds: |
| 440 | Mark Elapsed Stage |
| 441 | 0 0 reset |
| 442 | 3,575,678 3,575,678 board_init_f start |
| 443 | 3,575,695 17 arch_cpu_init A9 |
| 444 | 3,575,777 82 arch_cpu_init done |
| 445 | 3,659,598 83,821 board_init_r start |
| 446 | 3,910,375 250,777 main_loop |
| 447 | 29,916,167 26,005,792 bootm_start |
| 448 | 30,361,327 445,160 start_kernel |
| 449 | |
| 450 | config BOOTSTAGE_RECORD_COUNT |
| 451 | int "Number of boot stage records to store" |
Simon Glass | 939b04e | 2021-02-03 06:00:49 -0700 | [diff] [blame^] | 452 | depends on BOOTSTAGE |
Simon Glass | 75e65cc | 2020-09-10 20:21:14 -0600 | [diff] [blame] | 453 | default 30 |
| 454 | help |
| 455 | This is the size of the bootstage record list and is the maximum |
| 456 | number of bootstage records that can be recorded. |
| 457 | |
| 458 | config SPL_BOOTSTAGE_RECORD_COUNT |
| 459 | int "Number of boot stage records to store for SPL" |
Simon Glass | 939b04e | 2021-02-03 06:00:49 -0700 | [diff] [blame^] | 460 | depends on SPL_BOOTSTAGE |
Simon Glass | 75e65cc | 2020-09-10 20:21:14 -0600 | [diff] [blame] | 461 | default 5 |
| 462 | help |
| 463 | This is the size of the bootstage record list and is the maximum |
| 464 | number of bootstage records that can be recorded. |
| 465 | |
| 466 | config TPL_BOOTSTAGE_RECORD_COUNT |
| 467 | int "Number of boot stage records to store for TPL" |
Simon Glass | 939b04e | 2021-02-03 06:00:49 -0700 | [diff] [blame^] | 468 | depends on TPL_BOOTSTAGE |
Simon Glass | 75e65cc | 2020-09-10 20:21:14 -0600 | [diff] [blame] | 469 | default 5 |
| 470 | help |
| 471 | This is the size of the bootstage record list and is the maximum |
| 472 | number of bootstage records that can be recorded. |
| 473 | |
| 474 | config BOOTSTAGE_FDT |
| 475 | bool "Store boot timing information in the OS device tree" |
| 476 | depends on BOOTSTAGE |
| 477 | help |
| 478 | Stash the bootstage information in the FDT. A root 'bootstage' |
| 479 | node is created with each bootstage id as a child. Each child |
| 480 | has a 'name' property and either 'mark' containing the |
| 481 | mark time in microseconds, or 'accum' containing the |
| 482 | accumulated time for that bootstage id in microseconds. |
| 483 | For example: |
| 484 | |
| 485 | bootstage { |
| 486 | 154 { |
| 487 | name = "board_init_f"; |
| 488 | mark = <3575678>; |
| 489 | }; |
| 490 | 170 { |
| 491 | name = "lcd"; |
| 492 | accum = <33482>; |
| 493 | }; |
| 494 | }; |
| 495 | |
| 496 | Code in the Linux kernel can find this in /proc/devicetree. |
| 497 | |
| 498 | config BOOTSTAGE_STASH |
| 499 | bool "Stash the boot timing information in memory before booting OS" |
| 500 | depends on BOOTSTAGE |
| 501 | help |
| 502 | Some OSes do not support device tree. Bootstage can instead write |
| 503 | the boot timing information in a binary format at a given address. |
| 504 | This happens through a call to bootstage_stash(), typically in |
| 505 | the CPU's cleanup_before_linux() function. You can use the |
| 506 | 'bootstage stash' and 'bootstage unstash' commands to do this on |
| 507 | the command line. |
| 508 | |
| 509 | config BOOTSTAGE_STASH_ADDR |
| 510 | hex "Address to stash boot timing information" |
| 511 | default 0 |
| 512 | help |
| 513 | Provide an address which will not be overwritten by the OS when it |
| 514 | starts, so that it can read this information when ready. |
| 515 | |
| 516 | config BOOTSTAGE_STASH_SIZE |
| 517 | hex "Size of boot timing stash region" |
| 518 | default 0x1000 |
| 519 | help |
| 520 | This should be large enough to hold the bootstage stash. A value of |
| 521 | 4096 (4KiB) is normally plenty. |
| 522 | |
| 523 | config SHOW_BOOT_PROGRESS |
| 524 | bool "Show boot progress in a board-specific manner" |
| 525 | help |
| 526 | Defining this option allows to add some board-specific code (calling |
| 527 | a user-provided function show_boot_progress(int) that enables you to |
| 528 | show the system's boot progress on some display (for example, some |
| 529 | LEDs) on your board. At the moment, the following checkpoints are |
| 530 | implemented: |
| 531 | |
| 532 | Legacy uImage format: |
| 533 | |
| 534 | Arg Where When |
| 535 | 1 common/cmd_bootm.c before attempting to boot an image |
| 536 | -1 common/cmd_bootm.c Image header has bad magic number |
| 537 | 2 common/cmd_bootm.c Image header has correct magic number |
| 538 | -2 common/cmd_bootm.c Image header has bad checksum |
| 539 | 3 common/cmd_bootm.c Image header has correct checksum |
| 540 | -3 common/cmd_bootm.c Image data has bad checksum |
| 541 | 4 common/cmd_bootm.c Image data has correct checksum |
| 542 | -4 common/cmd_bootm.c Image is for unsupported architecture |
| 543 | 5 common/cmd_bootm.c Architecture check OK |
| 544 | -5 common/cmd_bootm.c Wrong Image Type (not kernel, multi) |
| 545 | 6 common/cmd_bootm.c Image Type check OK |
| 546 | -6 common/cmd_bootm.c gunzip uncompression error |
| 547 | -7 common/cmd_bootm.c Unimplemented compression type |
| 548 | 7 common/cmd_bootm.c Uncompression OK |
| 549 | 8 common/cmd_bootm.c No uncompress/copy overwrite error |
| 550 | -9 common/cmd_bootm.c Unsupported OS (not Linux, BSD, VxWorks, QNX) |
| 551 | |
| 552 | 9 common/image.c Start initial ramdisk verification |
| 553 | -10 common/image.c Ramdisk header has bad magic number |
| 554 | -11 common/image.c Ramdisk header has bad checksum |
| 555 | 10 common/image.c Ramdisk header is OK |
| 556 | -12 common/image.c Ramdisk data has bad checksum |
| 557 | 11 common/image.c Ramdisk data has correct checksum |
| 558 | 12 common/image.c Ramdisk verification complete, start loading |
| 559 | -13 common/image.c Wrong Image Type (not PPC Linux ramdisk) |
| 560 | 13 common/image.c Start multifile image verification |
| 561 | 14 common/image.c No initial ramdisk, no multifile, continue. |
| 562 | |
| 563 | 15 arch/<arch>/lib/bootm.c All preparation done, transferring control to OS |
| 564 | |
| 565 | -30 arch/powerpc/lib/board.c Fatal error, hang the system |
| 566 | -31 post/post.c POST test failed, detected by post_output_backlog() |
| 567 | -32 post/post.c POST test failed, detected by post_run_single() |
| 568 | |
| 569 | 34 common/cmd_doc.c before loading a Image from a DOC device |
| 570 | -35 common/cmd_doc.c Bad usage of "doc" command |
| 571 | 35 common/cmd_doc.c correct usage of "doc" command |
| 572 | -36 common/cmd_doc.c No boot device |
| 573 | 36 common/cmd_doc.c correct boot device |
| 574 | -37 common/cmd_doc.c Unknown Chip ID on boot device |
| 575 | 37 common/cmd_doc.c correct chip ID found, device available |
| 576 | -38 common/cmd_doc.c Read Error on boot device |
| 577 | 38 common/cmd_doc.c reading Image header from DOC device OK |
| 578 | -39 common/cmd_doc.c Image header has bad magic number |
| 579 | 39 common/cmd_doc.c Image header has correct magic number |
| 580 | -40 common/cmd_doc.c Error reading Image from DOC device |
| 581 | 40 common/cmd_doc.c Image header has correct magic number |
| 582 | 41 common/cmd_ide.c before loading a Image from a IDE device |
| 583 | -42 common/cmd_ide.c Bad usage of "ide" command |
| 584 | 42 common/cmd_ide.c correct usage of "ide" command |
| 585 | -43 common/cmd_ide.c No boot device |
| 586 | 43 common/cmd_ide.c boot device found |
| 587 | -44 common/cmd_ide.c Device not available |
| 588 | 44 common/cmd_ide.c Device available |
| 589 | -45 common/cmd_ide.c wrong partition selected |
| 590 | 45 common/cmd_ide.c partition selected |
| 591 | -46 common/cmd_ide.c Unknown partition table |
| 592 | 46 common/cmd_ide.c valid partition table found |
| 593 | -47 common/cmd_ide.c Invalid partition type |
| 594 | 47 common/cmd_ide.c correct partition type |
| 595 | -48 common/cmd_ide.c Error reading Image Header on boot device |
| 596 | 48 common/cmd_ide.c reading Image Header from IDE device OK |
| 597 | -49 common/cmd_ide.c Image header has bad magic number |
| 598 | 49 common/cmd_ide.c Image header has correct magic number |
| 599 | -50 common/cmd_ide.c Image header has bad checksum |
| 600 | 50 common/cmd_ide.c Image header has correct checksum |
| 601 | -51 common/cmd_ide.c Error reading Image from IDE device |
| 602 | 51 common/cmd_ide.c reading Image from IDE device OK |
| 603 | 52 common/cmd_nand.c before loading a Image from a NAND device |
| 604 | -53 common/cmd_nand.c Bad usage of "nand" command |
| 605 | 53 common/cmd_nand.c correct usage of "nand" command |
| 606 | -54 common/cmd_nand.c No boot device |
| 607 | 54 common/cmd_nand.c boot device found |
| 608 | -55 common/cmd_nand.c Unknown Chip ID on boot device |
| 609 | 55 common/cmd_nand.c correct chip ID found, device available |
| 610 | -56 common/cmd_nand.c Error reading Image Header on boot device |
| 611 | 56 common/cmd_nand.c reading Image Header from NAND device OK |
| 612 | -57 common/cmd_nand.c Image header has bad magic number |
| 613 | 57 common/cmd_nand.c Image header has correct magic number |
| 614 | -58 common/cmd_nand.c Error reading Image from NAND device |
| 615 | 58 common/cmd_nand.c reading Image from NAND device OK |
| 616 | |
| 617 | -60 common/env_common.c Environment has a bad CRC, using default |
| 618 | |
| 619 | 64 net/eth.c starting with Ethernet configuration. |
| 620 | -64 net/eth.c no Ethernet found. |
| 621 | 65 net/eth.c Ethernet found. |
| 622 | |
| 623 | -80 common/cmd_net.c usage wrong |
| 624 | 80 common/cmd_net.c before calling net_loop() |
| 625 | -81 common/cmd_net.c some error in net_loop() occurred |
| 626 | 81 common/cmd_net.c net_loop() back without error |
| 627 | -82 common/cmd_net.c size == 0 (File with size 0 loaded) |
| 628 | 82 common/cmd_net.c trying automatic boot |
| 629 | 83 common/cmd_net.c running "source" command |
| 630 | -83 common/cmd_net.c some error in automatic boot or "source" command |
| 631 | 84 common/cmd_net.c end without errors |
| 632 | |
| 633 | FIT uImage format: |
| 634 | |
| 635 | Arg Where When |
| 636 | 100 common/cmd_bootm.c Kernel FIT Image has correct format |
| 637 | -100 common/cmd_bootm.c Kernel FIT Image has incorrect format |
| 638 | 101 common/cmd_bootm.c No Kernel subimage unit name, using configuration |
| 639 | -101 common/cmd_bootm.c Can't get configuration for kernel subimage |
| 640 | 102 common/cmd_bootm.c Kernel unit name specified |
| 641 | -103 common/cmd_bootm.c Can't get kernel subimage node offset |
| 642 | 103 common/cmd_bootm.c Found configuration node |
| 643 | 104 common/cmd_bootm.c Got kernel subimage node offset |
| 644 | -104 common/cmd_bootm.c Kernel subimage hash verification failed |
| 645 | 105 common/cmd_bootm.c Kernel subimage hash verification OK |
| 646 | -105 common/cmd_bootm.c Kernel subimage is for unsupported architecture |
| 647 | 106 common/cmd_bootm.c Architecture check OK |
| 648 | -106 common/cmd_bootm.c Kernel subimage has wrong type |
| 649 | 107 common/cmd_bootm.c Kernel subimage type OK |
| 650 | -107 common/cmd_bootm.c Can't get kernel subimage data/size |
| 651 | 108 common/cmd_bootm.c Got kernel subimage data/size |
| 652 | -108 common/cmd_bootm.c Wrong image type (not legacy, FIT) |
| 653 | -109 common/cmd_bootm.c Can't get kernel subimage type |
| 654 | -110 common/cmd_bootm.c Can't get kernel subimage comp |
| 655 | -111 common/cmd_bootm.c Can't get kernel subimage os |
| 656 | -112 common/cmd_bootm.c Can't get kernel subimage load address |
| 657 | -113 common/cmd_bootm.c Image uncompress/copy overwrite error |
| 658 | |
| 659 | 120 common/image.c Start initial ramdisk verification |
| 660 | -120 common/image.c Ramdisk FIT image has incorrect format |
| 661 | 121 common/image.c Ramdisk FIT image has correct format |
| 662 | 122 common/image.c No ramdisk subimage unit name, using configuration |
| 663 | -122 common/image.c Can't get configuration for ramdisk subimage |
| 664 | 123 common/image.c Ramdisk unit name specified |
| 665 | -124 common/image.c Can't get ramdisk subimage node offset |
| 666 | 125 common/image.c Got ramdisk subimage node offset |
| 667 | -125 common/image.c Ramdisk subimage hash verification failed |
| 668 | 126 common/image.c Ramdisk subimage hash verification OK |
| 669 | -126 common/image.c Ramdisk subimage for unsupported architecture |
| 670 | 127 common/image.c Architecture check OK |
| 671 | -127 common/image.c Can't get ramdisk subimage data/size |
| 672 | 128 common/image.c Got ramdisk subimage data/size |
| 673 | 129 common/image.c Can't get ramdisk load address |
| 674 | -129 common/image.c Got ramdisk load address |
| 675 | |
| 676 | -130 common/cmd_doc.c Incorrect FIT image format |
| 677 | 131 common/cmd_doc.c FIT image format OK |
| 678 | |
| 679 | -140 common/cmd_ide.c Incorrect FIT image format |
| 680 | 141 common/cmd_ide.c FIT image format OK |
| 681 | |
| 682 | -150 common/cmd_nand.c Incorrect FIT image format |
| 683 | 151 common/cmd_nand.c FIT image format OK |
| 684 | |
| 685 | endmenu |
| 686 | |
Simon Glass | 7b6baa3 | 2020-09-10 20:21:15 -0600 | [diff] [blame] | 687 | menu "Boot media" |
| 688 | |
| 689 | config NOR_BOOT |
| 690 | bool "Support for booting from NOR flash" |
| 691 | depends on NOR |
| 692 | help |
| 693 | Enabling this will make a U-Boot binary that is capable of being |
| 694 | booted via NOR. In this case we will enable certain pinmux early |
| 695 | as the ROM only partially sets up pinmux. We also default to using |
| 696 | NOR for environment. |
| 697 | |
| 698 | config NAND_BOOT |
| 699 | bool "Support for booting from NAND flash" |
| 700 | default n |
| 701 | imply MTD_RAW_NAND |
| 702 | help |
| 703 | Enabling this will make a U-Boot binary that is capable of being |
| 704 | booted via NAND flash. This is not a must, some SoCs need this, |
| 705 | some not. |
| 706 | |
| 707 | config ONENAND_BOOT |
| 708 | bool "Support for booting from ONENAND" |
| 709 | default n |
| 710 | imply MTD_RAW_NAND |
| 711 | help |
| 712 | Enabling this will make a U-Boot binary that is capable of being |
| 713 | booted via ONENAND. This is not a must, some SoCs need this, |
| 714 | some not. |
| 715 | |
| 716 | config QSPI_BOOT |
| 717 | bool "Support for booting from QSPI flash" |
| 718 | default n |
| 719 | help |
| 720 | Enabling this will make a U-Boot binary that is capable of being |
| 721 | booted via QSPI flash. This is not a must, some SoCs need this, |
| 722 | some not. |
| 723 | |
| 724 | config SATA_BOOT |
| 725 | bool "Support for booting from SATA" |
| 726 | default n |
| 727 | help |
| 728 | Enabling this will make a U-Boot binary that is capable of being |
| 729 | booted via SATA. This is not a must, some SoCs need this, |
| 730 | some not. |
| 731 | |
| 732 | config SD_BOOT |
| 733 | bool "Support for booting from SD/EMMC" |
| 734 | default n |
| 735 | help |
| 736 | Enabling this will make a U-Boot binary that is capable of being |
| 737 | booted via SD/EMMC. This is not a must, some SoCs need this, |
| 738 | some not. |
| 739 | |
| 740 | config SPI_BOOT |
| 741 | bool "Support for booting from SPI flash" |
| 742 | default n |
| 743 | help |
| 744 | Enabling this will make a U-Boot binary that is capable of being |
| 745 | booted via SPI flash. This is not a must, some SoCs need this, |
| 746 | some not. |
| 747 | |
| 748 | endmenu |
| 749 | |
Simon Glass | 98eed0d | 2020-09-10 20:21:16 -0600 | [diff] [blame] | 750 | menu "Autoboot options" |
| 751 | |
| 752 | config AUTOBOOT |
| 753 | bool "Autoboot" |
| 754 | default y |
| 755 | help |
| 756 | This enables the autoboot. See doc/README.autoboot for detail. |
| 757 | |
Simon Glass | 95fd4f3 | 2020-09-10 20:21:17 -0600 | [diff] [blame] | 758 | config BOOTDELAY |
| 759 | int "delay in seconds before automatically booting" |
| 760 | default 2 |
| 761 | depends on AUTOBOOT |
| 762 | help |
| 763 | Delay before automatically running bootcmd; |
| 764 | set to 0 to autoboot with no delay, but you can stop it by key input. |
| 765 | set to -1 to disable autoboot. |
| 766 | set to -2 to autoboot with no delay and not check for abort |
| 767 | |
| 768 | If this value is >= 0 then it is also used for the default delay |
| 769 | before starting the default entry in bootmenu. If it is < 0 then |
| 770 | a default value of 10s is used. |
| 771 | |
| 772 | See doc/README.autoboot for details. |
| 773 | |
Simon Glass | 98eed0d | 2020-09-10 20:21:16 -0600 | [diff] [blame] | 774 | config AUTOBOOT_KEYED |
| 775 | bool "Stop autobooting via specific input key / string" |
| 776 | default n |
| 777 | help |
| 778 | This option enables stopping (aborting) of the automatic |
| 779 | boot feature only by issuing a specific input key or |
| 780 | string. If not enabled, any input key will abort the |
| 781 | U-Boot automatic booting process and bring the device |
| 782 | to the U-Boot prompt for user input. |
| 783 | |
| 784 | config AUTOBOOT_PROMPT |
| 785 | string "Autoboot stop prompt" |
| 786 | depends on AUTOBOOT_KEYED |
| 787 | default "Autoboot in %d seconds\\n" |
| 788 | help |
| 789 | This string is displayed before the boot delay selected by |
| 790 | CONFIG_BOOTDELAY starts. If it is not defined there is no |
| 791 | output indicating that autoboot is in progress. |
| 792 | |
| 793 | Note that this define is used as the (only) argument to a |
| 794 | printf() call, so it may contain '%' format specifications, |
| 795 | provided that it also includes, sepearated by commas exactly |
| 796 | like in a printf statement, the required arguments. It is |
| 797 | the responsibility of the user to select only such arguments |
| 798 | that are valid in the given context. |
| 799 | |
| 800 | config AUTOBOOT_ENCRYPTION |
| 801 | bool "Enable encryption in autoboot stopping" |
| 802 | depends on AUTOBOOT_KEYED |
| 803 | help |
| 804 | This option allows a string to be entered into U-Boot to stop the |
| 805 | autoboot. The string itself is hashed and compared against the hash |
| 806 | in the environment variable 'bootstopkeysha256'. If it matches then |
| 807 | boot stops and a command-line prompt is presented. |
| 808 | |
| 809 | This provides a way to ship a secure production device which can also |
| 810 | be accessed at the U-Boot command line. |
| 811 | |
| 812 | config AUTOBOOT_DELAY_STR |
| 813 | string "Delay autobooting via specific input key / string" |
| 814 | depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION |
| 815 | help |
| 816 | This option delays the automatic boot feature by issuing |
| 817 | a specific input key or string. If CONFIG_AUTOBOOT_DELAY_STR |
| 818 | or the environment variable "bootdelaykey" is specified |
| 819 | and this string is received from console input before |
| 820 | autoboot starts booting, U-Boot gives a command prompt. The |
| 821 | U-Boot prompt will time out if CONFIG_BOOT_RETRY_TIME is |
| 822 | used, otherwise it never times out. |
| 823 | |
| 824 | config AUTOBOOT_STOP_STR |
| 825 | string "Stop autobooting via specific input key / string" |
| 826 | depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION |
| 827 | help |
| 828 | This option enables stopping (aborting) of the automatic |
| 829 | boot feature only by issuing a specific input key or |
| 830 | string. If CONFIG_AUTOBOOT_STOP_STR or the environment |
| 831 | variable "bootstopkey" is specified and this string is |
| 832 | received from console input before autoboot starts booting, |
| 833 | U-Boot gives a command prompt. The U-Boot prompt never |
| 834 | times out, even if CONFIG_BOOT_RETRY_TIME is used. |
| 835 | |
| 836 | config AUTOBOOT_KEYED_CTRLC |
| 837 | bool "Enable Ctrl-C autoboot interruption" |
| 838 | depends on AUTOBOOT_KEYED && !AUTOBOOT_ENCRYPTION |
| 839 | default n |
| 840 | help |
| 841 | This option allows for the boot sequence to be interrupted |
| 842 | by ctrl-c, in addition to the "bootdelaykey" and "bootstopkey". |
| 843 | Setting this variable provides an escape sequence from the |
| 844 | limited "password" strings. |
| 845 | |
| 846 | config AUTOBOOT_STOP_STR_SHA256 |
| 847 | string "Stop autobooting via SHA256 encrypted password" |
| 848 | depends on AUTOBOOT_KEYED && AUTOBOOT_ENCRYPTION |
| 849 | help |
| 850 | This option adds the feature to only stop the autobooting, |
| 851 | and therefore boot into the U-Boot prompt, when the input |
| 852 | string / password matches a values that is encypted via |
Joel Peshkin | 652b504 | 2020-11-21 17:18:59 -0800 | [diff] [blame] | 853 | a SHA256 hash and saved in the environment variable |
| 854 | "bootstopkeysha256". If the value in that variable |
| 855 | includes a ":", the portion prior to the ":" will be treated |
| 856 | as a salt value. |
Simon Glass | 98eed0d | 2020-09-10 20:21:16 -0600 | [diff] [blame] | 857 | |
| 858 | config AUTOBOOT_USE_MENUKEY |
| 859 | bool "Allow a specify key to run a menu from the environment" |
| 860 | depends on !AUTOBOOT_KEYED |
| 861 | help |
| 862 | If a specific key is pressed to stop autoboot, then the commands in |
| 863 | the environment variable 'menucmd' are executed before boot starts. |
| 864 | |
| 865 | config AUTOBOOT_MENUKEY |
| 866 | int "ASCII value of boot key to show a menu" |
| 867 | default 0 |
| 868 | depends on AUTOBOOT_USE_MENUKEY |
| 869 | help |
| 870 | If this key is pressed to stop autoboot, then the commands in the |
| 871 | environment variable 'menucmd' will be executed before boot starts. |
| 872 | For example, 33 means "!" in ASCII, so pressing ! at boot would take |
| 873 | this action. |
| 874 | |
| 875 | config AUTOBOOT_MENU_SHOW |
| 876 | bool "Show a menu on boot" |
| 877 | depends on CMD_BOOTMENU |
| 878 | help |
| 879 | This enables the boot menu, controlled by environment variables |
| 880 | defined by the board. The menu starts after running the 'preboot' |
| 881 | environmnent variable (if enabled) and before handling the boot delay. |
| 882 | See README.bootmenu for more details. |
| 883 | |
| 884 | endmenu |
| 885 | |
Simon Glass | fe5db25 | 2020-09-10 20:21:18 -0600 | [diff] [blame] | 886 | config USE_BOOTARGS |
| 887 | bool "Enable boot arguments" |
| 888 | help |
| 889 | Provide boot arguments to bootm command. Boot arguments are specified |
| 890 | in CONFIG_BOOTARGS option. Enable this option to be able to specify |
| 891 | CONFIG_BOOTARGS string. If this option is disabled, CONFIG_BOOTARGS |
| 892 | will be undefined and won't take any space in U-Boot image. |
| 893 | |
| 894 | config BOOTARGS |
| 895 | string "Boot arguments" |
| 896 | depends on USE_BOOTARGS && !USE_DEFAULT_ENV_FILE |
| 897 | help |
| 898 | This can be used to pass arguments to the bootm command. The value of |
| 899 | CONFIG_BOOTARGS goes into the environment value "bootargs". Note that |
| 900 | this value will also override the "chosen" node in FDT blob. |
| 901 | |
Simon Glass | 51bb338 | 2020-11-05 10:33:48 -0700 | [diff] [blame] | 902 | config BOOTARGS_SUBST |
| 903 | bool "Support substituting strings in boot arguments" |
| 904 | help |
| 905 | This allows substituting string values in the boot arguments. These |
| 906 | are applied after the commandline has been built. |
| 907 | |
| 908 | One use for this is to insert the root-disk UUID into the command |
| 909 | line where bootargs contains "root=${uuid}" |
| 910 | |
| 911 | setenv bootargs "console= root=${uuid}" |
| 912 | # Set the 'uuid' environment variable |
| 913 | part uuid mmc 2:2 uuid |
| 914 | |
| 915 | # Command-line substitution will put the real uuid into the |
| 916 | # kernel command line |
| 917 | bootm |
| 918 | |
Simon Glass | fe5db25 | 2020-09-10 20:21:18 -0600 | [diff] [blame] | 919 | config USE_BOOTCOMMAND |
| 920 | bool "Enable a default value for bootcmd" |
| 921 | help |
| 922 | Provide a default value for the bootcmd entry in the environment. If |
| 923 | autoboot is enabled this is what will be run automatically. Enable |
| 924 | this option to be able to specify CONFIG_BOOTCOMMAND as a string. If |
| 925 | this option is disabled, CONFIG_BOOTCOMMAND will be undefined and |
| 926 | won't take any space in U-Boot image. |
| 927 | |
| 928 | config BOOTCOMMAND |
| 929 | string "bootcmd value" |
| 930 | depends on USE_BOOTCOMMAND && !USE_DEFAULT_ENV_FILE |
| 931 | default "run distro_bootcmd" if DISTRO_DEFAULTS |
| 932 | help |
| 933 | This is the string of commands that will be used as bootcmd and if |
| 934 | AUTOBOOT is set, automatically run. |
| 935 | |
| 936 | config USE_PREBOOT |
| 937 | bool "Enable preboot" |
| 938 | help |
| 939 | When this option is enabled, the existence of the environment |
| 940 | variable "preboot" will be checked immediately before starting the |
| 941 | CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp. |
| 942 | entering interactive mode. |
| 943 | |
| 944 | This feature is especially useful when "preboot" is automatically |
| 945 | generated or modified. For example, the boot code can modify the |
| 946 | "preboot" when a user holds down a certain combination of keys. |
| 947 | |
| 948 | config PREBOOT |
| 949 | string "preboot default value" |
| 950 | depends on USE_PREBOOT && !USE_DEFAULT_ENV_FILE |
Patrick Delaunay | 87459da | 2020-10-12 09:47:50 +0200 | [diff] [blame] | 951 | default "usb start" if USB_KEYBOARD |
Simon Glass | fe5db25 | 2020-09-10 20:21:18 -0600 | [diff] [blame] | 952 | default "" |
| 953 | help |
| 954 | This is the default of "preboot" environment variable. |
| 955 | |
Simon Glass | 832876a | 2020-09-10 20:21:20 -0600 | [diff] [blame] | 956 | config DEFAULT_FDT_FILE |
| 957 | string "Default fdt file" |
| 958 | help |
| 959 | This option is used to set the default fdt file to boot OS. |
| 960 | |
Simon Glass | cf29816 | 2020-09-10 20:21:13 -0600 | [diff] [blame] | 961 | endmenu # Booting |