1menu "Boot timing" 2 3config BOOTSTAGE 4 bool "Boot timing and reporting" 5 help 6 Enable recording of boot time while booting. To use it, insert 7 calls to bootstage_mark() with a suitable BOOTSTAGE_ID from 8 bootstage.h. Only a single entry is recorded for each ID. You can 9 give the entry a name with bootstage_mark_name(). You can also 10 record elapsed time in a particular stage using bootstage_start() 11 before starting and bootstage_accum() when finished. Bootstage will 12 add up all the accumulated time and report it. 13 14 Normally, IDs are defined in bootstage.h but a small number of 15 additional 'user' IDs can be used by passing BOOTSTAGE_ID_ALLOC 16 as the ID. 17 18 Calls to show_boot_progress() will also result in log entries but 19 these will not have names. 20 21config SPL_BOOTSTAGE 22 bool "Boot timing and reported in SPL" 23 depends on BOOTSTAGE 24 help 25 Enable recording of boot time in SPL. To make this visible to U-Boot 26 proper, enable BOOTSTAGE_STASH as well. This will stash the timing 27 information when SPL finishes and load it when U-Boot proper starts 28 up. 29 30config BOOTSTAGE_REPORT 31 bool "Display a detailed boot timing report before booting the OS" 32 depends on BOOTSTAGE 33 help 34 Enable output of a boot time report just before the OS is booted. 35 This shows how long it took U-Boot to go through each stage of the 36 boot process. The report looks something like this: 37 38 Timer summary in microseconds: 39 Mark Elapsed Stage 40 0 0 reset 41 3,575,678 3,575,678 board_init_f start 42 3,575,695 17 arch_cpu_init A9 43 3,575,777 82 arch_cpu_init done 44 3,659,598 83,821 board_init_r start 45 3,910,375 250,777 main_loop 46 29,916,167 26,005,792 bootm_start 47 30,361,327 445,160 start_kernel 48 49config BOOTSTAGE_USER_COUNT 50 int "Number of boot ID numbers available for user use" 51 default 20 52 help 53 This is the number of available user bootstage records. 54 Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...) 55 a new ID will be allocated from this stash. If you exceed 56 the limit, recording will stop. 57 58config BOOTSTAGE_RECORD_COUNT 59 int "Number of boot stage records to store" 60 default 30 61 help 62 This is the size of the bootstage record list and is the maximum 63 number of bootstage records that can be recorded. 64 65config BOOTSTAGE_FDT 66 bool "Store boot timing information in the OS device tree" 67 depends on BOOTSTAGE 68 help 69 Stash the bootstage information in the FDT. A root 'bootstage' 70 node is created with each bootstage id as a child. Each child 71 has a 'name' property and either 'mark' containing the 72 mark time in microseconds, or 'accum' containing the 73 accumulated time for that bootstage id in microseconds. 74 For example: 75 76 bootstage { 77 154 { 78 name = "board_init_f"; 79 mark = <3575678>; 80 }; 81 170 { 82 name = "lcd"; 83 accum = <33482>; 84 }; 85 }; 86 87 Code in the Linux kernel can find this in /proc/devicetree. 88 89config BOOTSTAGE_STASH 90 bool "Stash the boot timing information in memory before booting OS" 91 depends on BOOTSTAGE 92 help 93 Some OSes do not support device tree. Bootstage can instead write 94 the boot timing information in a binary format at a given address. 95 This happens through a call to bootstage_stash(), typically in 96 the CPU's cleanup_before_linux() function. You can use the 97 'bootstage stash' and 'bootstage unstash' commands to do this on 98 the command line. 99 100config BOOTSTAGE_STASH_ADDR 101 hex "Address to stash boot timing information" 102 default 0 103 help 104 Provide an address which will not be overwritten by the OS when it 105 starts, so that it can read this information when ready. 106 107config BOOTSTAGE_STASH_SIZE 108 hex "Size of boot timing stash region" 109 default 0x1000 110 help 111 This should be large enough to hold the bootstage stash. A value of 112 4096 (4KiB) is normally plenty. 113 114endmenu 115 116menu "Boot media" 117 118config NOR_BOOT 119 bool "Support for booting from NOR flash" 120 depends on NOR 121 help 122 Enabling this will make a U-Boot binary that is capable of being 123 booted via NOR. In this case we will enable certain pinmux early 124 as the ROM only partially sets up pinmux. We also default to using 125 NOR for environment. 126 127config NAND_BOOT 128 bool "Support for booting from NAND flash" 129 default n 130 help 131 Enabling this will make a U-Boot binary that is capable of being 132 booted via NAND flash. This is not a must, some SoCs need this, 133 some not. 134 135config ONENAND_BOOT 136 bool "Support for booting from ONENAND" 137 default n 138 help 139 Enabling this will make a U-Boot binary that is capable of being 140 booted via ONENAND. This is not a must, some SoCs need this, 141 some not. 142 143config QSPI_BOOT 144 bool "Support for booting from QSPI flash" 145 default n 146 help 147 Enabling this will make a U-Boot binary that is capable of being 148 booted via QSPI flash. This is not a must, some SoCs need this, 149 some not. 150 151config SATA_BOOT 152 bool "Support for booting from SATA" 153 default n 154 help 155 Enabling this will make a U-Boot binary that is capable of being 156 booted via SATA. This is not a must, some SoCs need this, 157 some not. 158 159config SD_BOOT 160 bool "Support for booting from SD/EMMC" 161 default n 162 help 163 Enabling this will make a U-Boot binary that is capable of being 164 booted via SD/EMMC. This is not a must, some SoCs need this, 165 some not. 166 167config SPI_BOOT 168 bool "Support for booting from SPI flash" 169 default n 170 help 171 Enabling this will make a U-Boot binary that is capable of being 172 booted via SPI flash. This is not a must, some SoCs need this, 173 some not. 174 175endmenu 176 177menu "Environment" 178 179config ENV_IS_IN_FLASH 180 bool "Environment in flash memory" 181 depends on !CHAIN_OF_TRUST 182 help 183 Define this if you have a flash device which you want to use for the 184 environment. 185 186 a) The environment occupies one whole flash sector, which is 187 "embedded" in the text segment with the U-Boot code. This 188 happens usually with "bottom boot sector" or "top boot 189 sector" type flash chips, which have several smaller 190 sectors at the start or the end. For instance, such a 191 layout can have sector sizes of 8, 2x4, 16, Nx32 kB. In 192 such a case you would place the environment in one of the 193 4 kB sectors - with U-Boot code before and after it. With 194 "top boot sector" type flash chips, you would put the 195 environment in one of the last sectors, leaving a gap 196 between U-Boot and the environment. 197 198 CONFIG_ENV_OFFSET: 199 200 Offset of environment data (variable area) to the 201 beginning of flash memory; for instance, with bottom boot 202 type flash chips the second sector can be used: the offset 203 for this sector is given here. 204 205 CONFIG_ENV_OFFSET is used relative to CONFIG_SYS_FLASH_BASE. 206 207 CONFIG_ENV_ADDR: 208 209 This is just another way to specify the start address of 210 the flash sector containing the environment (instead of 211 CONFIG_ENV_OFFSET). 212 213 CONFIG_ENV_SECT_SIZE: 214 215 Size of the sector containing the environment. 216 217 218 b) Sometimes flash chips have few, equal sized, BIG sectors. 219 In such a case you don't want to spend a whole sector for 220 the environment. 221 222 CONFIG_ENV_SIZE: 223 224 If you use this in combination with CONFIG_ENV_IS_IN_FLASH 225 and CONFIG_ENV_SECT_SIZE, you can specify to use only a part 226 of this flash sector for the environment. This saves 227 memory for the RAM copy of the environment. 228 229 It may also save flash memory if you decide to use this 230 when your environment is "embedded" within U-Boot code, 231 since then the remainder of the flash sector could be used 232 for U-Boot code. It should be pointed out that this is 233 STRONGLY DISCOURAGED from a robustness point of view: 234 updating the environment in flash makes it always 235 necessary to erase the WHOLE sector. If something goes 236 wrong before the contents has been restored from a copy in 237 RAM, your target system will be dead. 238 239 CONFIG_ENV_ADDR_REDUND 240 CONFIG_ENV_SIZE_REDUND 241 242 These settings describe a second storage area used to hold 243 a redundant copy of the environment data, so that there is 244 a valid backup copy in case there is a power failure during 245 a "saveenv" operation. 246 247 BE CAREFUL! Any changes to the flash layout, and some changes to the 248 source code will make it necessary to adapt <board>/u-boot.lds* 249 accordingly! 250 251config ENV_IS_IN_MMC 252 bool "Environment in an MMC device" 253 depends on !CHAIN_OF_TRUST 254 default y if ARCH_SUNXI 255 help 256 Define this if you have an MMC device which you want to use for the 257 environment. 258 259 CONFIG_SYS_MMC_ENV_DEV: 260 261 Specifies which MMC device the environment is stored in. 262 263 CONFIG_SYS_MMC_ENV_PART (optional): 264 265 Specifies which MMC partition the environment is stored in. If not 266 set, defaults to partition 0, the user area. Common values might be 267 1 (first MMC boot partition), 2 (second MMC boot partition). 268 269 CONFIG_ENV_OFFSET: 270 CONFIG_ENV_SIZE: 271 272 These two #defines specify the offset and size of the environment 273 area within the specified MMC device. 274 275 If offset is positive (the usual case), it is treated as relative to 276 the start of the MMC partition. If offset is negative, it is treated 277 as relative to the end of the MMC partition. This can be useful if 278 your board may be fitted with different MMC devices, which have 279 different sizes for the MMC partitions, and you always want the 280 environment placed at the very end of the partition, to leave the 281 maximum possible space before it, to store other data. 282 283 These two values are in units of bytes, but must be aligned to an 284 MMC sector boundary. 285 286 CONFIG_ENV_OFFSET_REDUND (optional): 287 288 Specifies a second storage area, of CONFIG_ENV_SIZE size, used to 289 hold a redundant copy of the environment data. This provides a 290 valid backup copy in case the other copy is corrupted, e.g. due 291 to a power failure during a "saveenv" operation. 292 293 This value may also be positive or negative; this is handled in the 294 same way as CONFIG_ENV_OFFSET. 295 296 This value is also in units of bytes, but must also be aligned to 297 an MMC sector boundary. 298 299 CONFIG_ENV_SIZE_REDUND (optional): 300 301 This value need not be set, even when CONFIG_ENV_OFFSET_REDUND is 302 set. If this value is set, it must be set to the same value as 303 CONFIG_ENV_SIZE. 304 305config ENV_IS_IN_NAND 306 bool "Environment in a NAND device" 307 depends on !CHAIN_OF_TRUST 308 help 309 Define this if you have a NAND device which you want to use for the 310 environment. 311 312 - CONFIG_ENV_OFFSET: 313 - CONFIG_ENV_SIZE: 314 315 These two #defines specify the offset and size of the environment 316 area within the first NAND device. CONFIG_ENV_OFFSET must be 317 aligned to an erase block boundary. 318 319 - CONFIG_ENV_OFFSET_REDUND (optional): 320 321 This setting describes a second storage area of CONFIG_ENV_SIZE 322 size used to hold a redundant copy of the environment data, so 323 that there is a valid backup copy in case there is a power failure 324 during a "saveenv" operation. CONFIG_ENV_OFFSET_REDUND must be 325 aligned to an erase block boundary. 326 327 - CONFIG_ENV_RANGE (optional): 328 329 Specifies the length of the region in which the environment 330 can be written. This should be a multiple of the NAND device's 331 block size. Specifying a range with more erase blocks than 332 are needed to hold CONFIG_ENV_SIZE allows bad blocks within 333 the range to be avoided. 334 335 - CONFIG_ENV_OFFSET_OOB (optional): 336 337 Enables support for dynamically retrieving the offset of the 338 environment from block zero's out-of-band data. The 339 "nand env.oob" command can be used to record this offset. 340 Currently, CONFIG_ENV_OFFSET_REDUND is not supported when 341 using CONFIG_ENV_OFFSET_OOB. 342 343config ENV_IS_IN_NVRAM 344 bool "Environment in a non-volatile RAM" 345 depends on !CHAIN_OF_TRUST 346 help 347 Define this if you have some non-volatile memory device 348 (NVRAM, battery buffered SRAM) which you want to use for the 349 environment. 350 351 - CONFIG_ENV_ADDR: 352 - CONFIG_ENV_SIZE: 353 354 These two #defines are used to determine the memory area you 355 want to use for environment. It is assumed that this memory 356 can just be read and written to, without any special 357 provision. 358 359config ENV_IS_IN_UBI 360 bool "Environment in a UBI volume" 361 depends on !CHAIN_OF_TRUST 362 help 363 Define this if you have an UBI volume that you want to use for the 364 environment. This has the benefit of wear-leveling the environment 365 accesses, which is important on NAND. 366 367 - CONFIG_ENV_UBI_PART: 368 369 Define this to a string that is the mtd partition containing the UBI. 370 371 - CONFIG_ENV_UBI_VOLUME: 372 373 Define this to the name of the volume that you want to store the 374 environment in. 375 376 - CONFIG_ENV_UBI_VOLUME_REDUND: 377 378 Define this to the name of another volume to store a second copy of 379 the environment in. This will enable redundant environments in UBI. 380 It is assumed that both volumes are in the same MTD partition. 381 382 - CONFIG_UBI_SILENCE_MSG 383 - CONFIG_UBIFS_SILENCE_MSG 384 385 You will probably want to define these to avoid a really noisy system 386 when storing the env in UBI. 387 388config ENV_IS_NOWHERE 389 bool "Environment is not stored" 390 help 391 Define this if you don't want to or can't have an environment stored 392 on a storage medium 393 394if ARCH_SUNXI 395 396config ENV_OFFSET 397 hex "Environment Offset" 398 depends on !ENV_IS_IN_UBI 399 depends on !ENV_IS_NOWHERE 400 default 0x88000 if ARCH_SUNXI 401 help 402 Offset from the start of the device (or partition) 403 404config ENV_SIZE 405 hex "Environment Size" 406 depends on !ENV_IS_NOWHERE 407 default 0x20000 if ARCH_SUNXI 408 help 409 Size of the environment storage area 410 411config ENV_UBI_PART 412 string "UBI partition name" 413 depends on ENV_IS_IN_UBI 414 help 415 MTD partition containing the UBI device 416 417config ENV_UBI_VOLUME 418 string "UBI volume name" 419 depends on ENV_IS_IN_UBI 420 help 421 Name of the volume that you want to store the environment in. 422 423endif 424 425endmenu 426 427config BOOTDELAY 428 int "delay in seconds before automatically booting" 429 default 2 430 depends on AUTOBOOT 431 help 432 Delay before automatically running bootcmd; 433 set to 0 to autoboot with no delay, but you can stop it by key input. 434 set to -1 to disable autoboot. 435 set to -2 to autoboot with no delay and not check for abort 436 437 See doc/README.autoboot for details. 438 439menu "Console" 440 441config MENU 442 bool 443 help 444 This is the library functionality to provide a text-based menu of 445 choices for the user to make choices with. 446 447config CONSOLE_RECORD 448 bool "Console recording" 449 help 450 This provides a way to record console output (and provide console 451 input) through circular buffers. This is mostly useful for testing. 452 Console output is recorded even when the console is silent. 453 To enable console recording, call console_record_reset_enable() 454 from your code. 455 456config CONSOLE_RECORD_OUT_SIZE 457 hex "Output buffer size" 458 depends on CONSOLE_RECORD 459 default 0x400 if CONSOLE_RECORD 460 help 461 Set the size of the console output buffer. When this fills up, no 462 more data will be recorded until some is removed. The buffer is 463 allocated immediately after the malloc() region is ready. 464 465config CONSOLE_RECORD_IN_SIZE 466 hex "Input buffer size" 467 depends on CONSOLE_RECORD 468 default 0x100 if CONSOLE_RECORD 469 help 470 Set the size of the console input buffer. When this contains data, 471 tstc() and getc() will use this in preference to real device input. 472 The buffer is allocated immediately after the malloc() region is 473 ready. 474 475config IDENT_STRING 476 string "Board specific string to be added to uboot version string" 477 help 478 This options adds the board specific name to u-boot version. 479 480config SILENT_CONSOLE 481 bool "Support a silent console" 482 help 483 This option allows the console to be silenced, meaning that no 484 output will appear on the console devices. This is controlled by 485 setting the environment vaariable 'silent' to a non-empty value. 486 Note this also silences the console when booting Linux. 487 488 When the console is set up, the variable is checked, and the 489 GD_FLG_SILENT flag is set. Changing the environment variable later 490 will update the flag. 491 492config SILENT_U_BOOT_ONLY 493 bool "Only silence the U-Boot console" 494 depends on SILENT_CONSOLE 495 help 496 Normally when the U-Boot console is silenced, Linux's console is 497 also silenced (assuming the board boots into Linux). This option 498 allows the linux console to operate normally, even if U-Boot's 499 is silenced. 500 501config SILENT_CONSOLE_UPDATE_ON_SET 502 bool "Changes to the 'silent' environment variable update immediately" 503 depends on SILENT_CONSOLE 504 default y if SILENT_CONSOLE 505 help 506 When the 'silent' environment variable is changed, update the 507 console silence flag immediately. This allows 'setenv' to be used 508 to silence or un-silence the console. 509 510 The effect is that any change to the variable will affect the 511 GD_FLG_SILENT flag. 512 513config SILENT_CONSOLE_UPDATE_ON_RELOC 514 bool "Allow flags to take effect on relocation" 515 depends on SILENT_CONSOLE 516 help 517 In some cases the environment is not available until relocation 518 (e.g. NAND). This option makes the value of the 'silent' 519 environment variable take effect at relocation. 520 521config PRE_CONSOLE_BUFFER 522 bool "Buffer characters before the console is available" 523 help 524 Prior to the console being initialised (i.e. serial UART 525 initialised etc) all console output is silently discarded. 526 Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to 527 buffer any console messages prior to the console being 528 initialised to a buffer. The buffer is a circular buffer, so 529 if it overflows, earlier output is discarded. 530 531 Note that this is not currently supported in SPL. It would be 532 useful to be able to share the pre-console buffer with SPL. 533 534config PRE_CON_BUF_SZ 535 int "Sets the size of the pre-console buffer" 536 depends on PRE_CONSOLE_BUFFER 537 default 4096 538 help 539 The size of the pre-console buffer affects how much console output 540 can be held before it overflows and starts discarding earlier 541 output. Normally there is very little output at this early stage, 542 unless debugging is enabled, so allow enough for ~10 lines of 543 text. 544 545 This is a useful feature if you are using a video console and 546 want to see the full boot output on the console. Without this 547 option only the post-relocation output will be displayed. 548 549config PRE_CON_BUF_ADDR 550 hex "Address of the pre-console buffer" 551 depends on PRE_CONSOLE_BUFFER 552 default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I 553 default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I 554 help 555 This sets the start address of the pre-console buffer. This must 556 be in available memory and is accessed before relocation and 557 possibly before DRAM is set up. Therefore choose an address 558 carefully. 559 560 We should consider removing this option and allocating the memory 561 in board_init_f_init_reserve() instead. 562 563config CONSOLE_MUX 564 bool "Enable console multiplexing" 565 default y if DM_VIDEO || VIDEO || LCD 566 help 567 This allows multiple devices to be used for each console 'file'. 568 For example, stdout can be set to go to serial and video. 569 Similarly, stdin can be set to come from serial and keyboard. 570 Input can be provided from either source. Console multiplexing 571 adds a small amount of size to U-Boot. Changes to the environment 572 variables stdout, stdin and stderr will take effect immediately. 573 574config SYS_CONSOLE_IS_IN_ENV 575 bool "Select console devices from the environment" 576 default y if CONSOLE_MUX 577 help 578 This allows multiple input/output devices to be set at boot time. 579 For example, if stdout is set to "serial,video" then output will 580 be sent to both the serial and video devices on boot. The 581 environment variables can be updated after boot to change the 582 input/output devices. 583 584config SYS_CONSOLE_OVERWRITE_ROUTINE 585 bool "Allow board control over console overwriting" 586 help 587 If this is enabled, and the board-specific function 588 overwrite_console() returns 1, the stdin, stderr and stdout are 589 switched to the serial port, else the settings in the environment 590 are used. If this is not enabled, the console will not be switched 591 to serial. 592 593config SYS_CONSOLE_ENV_OVERWRITE 594 bool "Update environment variables during console init" 595 help 596 The console environment variables (stdout, stdin, stderr) can be 597 used to determine the correct console devices on start-up. This 598 option writes the console devices to these variables on console 599 start-up (after relocation). This causes the environment to be 600 updated to match the console devices actually chosen. 601 602config SYS_CONSOLE_INFO_QUIET 603 bool "Don't display the console devices on boot" 604 help 605 Normally U-Boot displays the current settings for stdout, stdin 606 and stderr on boot when the post-relocation console is set up. 607 Enable this option to supress this output. It can be obtained by 608 calling stdio_print_current_devices() from board code. 609 610config SYS_STDIO_DEREGISTER 611 bool "Allow deregistering stdio devices" 612 default y if USB_KEYBOARD 613 help 614 Generally there is no need to deregister stdio devices since they 615 are never deactivated. But if a stdio device is used which can be 616 removed (for example a USB keyboard) then this option can be 617 enabled to ensure this is handled correctly. 618 619endmenu 620 621config DTB_RESELECT 622 bool "Support swapping dtbs at a later point in boot" 623 depends on FIT_EMBED 624 help 625 It is possible during initial boot you may need to use a generic 626 dtb until you can fully determine the board your running on. This 627 config allows boards to implement a function at a later point 628 during boot to switch to the "correct" dtb. 629 630config FIT_EMBED 631 bool "Support a FIT image embedded in the U-boot image" 632 help 633 This option provides hooks to allow U-boot to parse an 634 appended FIT image and enable board specific code to then select 635 the correct DTB to be used. 636 637config DEFAULT_FDT_FILE 638 string "Default fdt file" 639 help 640 This option is used to set the default fdt file to boot OS. 641 642config VERSION_VARIABLE 643 bool "add U-Boot environment variable vers" 644 default n 645 help 646 If this variable is defined, an environment variable 647 named "ver" is created by U-Boot showing the U-Boot 648 version as printed by the "version" command. 649 Any change to this variable will be reverted at the 650 next reset. 651 652config BOARD_LATE_INIT 653 bool 654 help 655 Sometimes board require some initialization code that might 656 require once the actual init done, example saving board specific env, 657 boot-modes etc. which eventually done at late. 658 659 So this config enable the late init code with the help of board_late_init 660 function which should defined on respective boards. 661 662config DISPLAY_CPUINFO 663 bool "Display information about the CPU during start up" 664 default y if ARM || NIOS2 || X86 || XTENSA 665 help 666 Display information about the CPU that U-Boot is running on 667 when U-Boot starts up. The function print_cpuinfo() is called 668 to do this. 669 670config DISPLAY_BOARDINFO 671 bool "Display information about the board during start up" 672 default y if ARM || M68K || MIPS || PPC || SANDBOX || XTENSA 673 help 674 Display information about the board that U-Boot is running on 675 when U-Boot starts up. The board function checkboard() is called 676 to do this. 677 678menu "Start-up hooks" 679 680config ARCH_EARLY_INIT_R 681 bool "Call arch-specific init soon after relocation" 682 default y if X86 683 help 684 With this option U-Boot will call arch_early_init_r() soon after 685 relocation. Driver model is running by this point, and the cache 686 is on. Note that board_early_init_r() is called first, if 687 enabled. This can be used to set up architecture-specific devices. 688 689config ARCH_MISC_INIT 690 bool "Call arch-specific init after relocation, when console is ready" 691 help 692 With this option U-Boot will call arch_misc_init() after 693 relocation to allow miscellaneous arch-dependent initialisation 694 to be performed. This function should be defined by the board 695 and will be called after the console is set up, after relocaiton. 696 697config BOARD_EARLY_INIT_F 698 bool "Call board-specific init before relocation" 699 default y if X86 700 help 701 Some boards need to perform initialisation as soon as possible 702 after boot. With this option, U-Boot calls board_early_init_f() 703 after driver model is ready in the pre-relocation init sequence. 704 Note that the normal serial console is not yet set up, but the 705 debug UART will be available if enabled. 706 707endmenu 708 709menu "Security support" 710 711config HASH 712 bool # "Support hashing API (SHA1, SHA256, etc.)" 713 help 714 This provides a way to hash data in memory using various supported 715 algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h 716 and the algorithms it supports are defined in common/hash.c. See 717 also CMD_HASH for command-line access. 718 719endmenu 720 721source "common/spl/Kconfig" 722