common/Kconfig

   1 menu "Boot timing"
   2
   3 config 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
  21 config 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
  30 config 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
  49 config 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
  58 config 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
  65 config 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
  89 config 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
 100 config 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
 107 config 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
 114 endmenu
 115
 116 menu "Boot media"
 117
 118 config 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
 127 config 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
 135 config 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
 143 config 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
 151 config 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
 159 config 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
 167 config 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
 175 endmenu
 176
 177 menu "Environment"
 178
 179 config 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
 251 config 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
 305 config 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
 343 config ENV_IS_IN_UBI
 344         bool "Environment in a UBI volume"
 345         depends on !CHAIN_OF_TRUST
 346         help
 347           Define this if you have an UBI volume that you want to use for the
 348           environment.  This has the benefit of wear-leveling the environment
 349           accesses, which is important on NAND.
 350
 351           - CONFIG_ENV_UBI_PART:
 352
 353           Define this to a string that is the mtd partition containing the UBI.
 354
 355           - CONFIG_ENV_UBI_VOLUME:
 356
 357           Define this to the name of the volume that you want to store the
 358           environment in.
 359
 360           - CONFIG_ENV_UBI_VOLUME_REDUND:
 361
 362           Define this to the name of another volume to store a second copy of
 363           the environment in.  This will enable redundant environments in UBI.
 364           It is assumed that both volumes are in the same MTD partition.
 365
 366           - CONFIG_UBI_SILENCE_MSG
 367           - CONFIG_UBIFS_SILENCE_MSG
 368
 369           You will probably want to define these to avoid a really noisy system
 370           when storing the env in UBI.
 371
 372 config ENV_IS_NOWHERE
 373         bool "Environment is not stored"
 374         help
 375           Define this if you don't want to or can't have an environment stored
 376           on a storage medium
 377
 378 if ARCH_SUNXI
 379
 380 config ENV_OFFSET
 381         hex "Environment Offset"
 382         depends on !ENV_IS_IN_UBI
 383         depends on !ENV_IS_NOWHERE
 384         default 0x88000 if ARCH_SUNXI
 385         help
 386           Offset from the start of the device (or partition)
 387
 388 config ENV_SIZE
 389         hex "Environment Size"
 390         depends on !ENV_IS_NOWHERE
 391         default 0x20000 if ARCH_SUNXI
 392         help
 393           Size of the environment storage area
 394
 395 config ENV_UBI_PART
 396         string "UBI partition name"
 397         depends on ENV_IS_IN_UBI
 398         help
 399           MTD partition containing the UBI device
 400
 401 config ENV_UBI_VOLUME
 402         string "UBI volume name"
 403         depends on ENV_IS_IN_UBI
 404         help
 405           Name of the volume that you want to store the environment in.
 406
 407 endif
 408
 409 endmenu
 410
 411 config BOOTDELAY
 412         int "delay in seconds before automatically booting"
 413         default 2
 414         depends on AUTOBOOT
 415         help
 416           Delay before automatically running bootcmd;
 417           set to 0 to autoboot with no delay, but you can stop it by key input.
 418           set to -1 to disable autoboot.
 419           set to -2 to autoboot with no delay and not check for abort
 420
 421           See doc/README.autoboot for details.
 422
 423 menu "Console"
 424
 425 config MENU
 426         bool
 427         help
 428           This is the library functionality to provide a text-based menu of
 429           choices for the user to make choices with.
 430
 431 config CONSOLE_RECORD
 432         bool "Console recording"
 433         help
 434           This provides a way to record console output (and provide console
 435           input) through circular buffers. This is mostly useful for testing.
 436           Console output is recorded even when the console is silent.
 437           To enable console recording, call console_record_reset_enable()
 438           from your code.
 439
 440 config CONSOLE_RECORD_OUT_SIZE
 441         hex "Output buffer size"
 442         depends on CONSOLE_RECORD
 443         default 0x400 if CONSOLE_RECORD
 444         help
 445           Set the size of the console output buffer. When this fills up, no
 446           more data will be recorded until some is removed. The buffer is
 447           allocated immediately after the malloc() region is ready.
 448
 449 config CONSOLE_RECORD_IN_SIZE
 450         hex "Input buffer size"
 451         depends on CONSOLE_RECORD
 452         default 0x100 if CONSOLE_RECORD
 453         help
 454           Set the size of the console input buffer. When this contains data,
 455           tstc() and getc() will use this in preference to real device input.
 456           The buffer is allocated immediately after the malloc() region is
 457           ready.
 458
 459 config IDENT_STRING
 460         string "Board specific string to be added to uboot version string"
 461         help
 462           This options adds the board specific name to u-boot version.
 463
 464 config SILENT_CONSOLE
 465         bool "Support a silent console"
 466         help
 467           This option allows the console to be silenced, meaning that no
 468           output will appear on the console devices. This is controlled by
 469           setting the environment vaariable 'silent' to a non-empty value.
 470           Note this also silences the console when booting Linux.
 471
 472           When the console is set up, the variable is checked, and the
 473           GD_FLG_SILENT flag is set. Changing the environment variable later
 474           will update the flag.
 475
 476 config SILENT_U_BOOT_ONLY
 477         bool "Only silence the U-Boot console"
 478         depends on SILENT_CONSOLE
 479         help
 480           Normally when the U-Boot console is silenced, Linux's console is
 481           also silenced (assuming the board boots into Linux). This option
 482           allows the linux console to operate normally, even if U-Boot's
 483           is silenced.
 484
 485 config SILENT_CONSOLE_UPDATE_ON_SET
 486         bool "Changes to the 'silent' environment variable update immediately"
 487         depends on SILENT_CONSOLE
 488         default y if SILENT_CONSOLE
 489         help
 490           When the 'silent' environment variable is changed, update the
 491           console silence flag immediately. This allows 'setenv' to be used
 492           to silence or un-silence the console.
 493
 494           The effect is that any change to the variable will affect the
 495           GD_FLG_SILENT flag.
 496
 497 config SILENT_CONSOLE_UPDATE_ON_RELOC
 498         bool "Allow flags to take effect on relocation"
 499         depends on SILENT_CONSOLE
 500         help
 501           In some cases the environment is not available until relocation
 502           (e.g. NAND). This option makes the value of the 'silent'
 503           environment variable take effect at relocation.
 504
 505 config PRE_CONSOLE_BUFFER
 506         bool "Buffer characters before the console is available"
 507         help
 508           Prior to the console being initialised (i.e. serial UART
 509           initialised etc) all console output is silently discarded.
 510           Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
 511           buffer any console messages prior to the console being
 512           initialised to a buffer. The buffer is a circular buffer, so
 513           if it overflows, earlier output is discarded.
 514
 515           Note that this is not currently supported in SPL. It would be
 516           useful to be able to share the pre-console buffer with SPL.
 517
 518 config PRE_CON_BUF_SZ
 519         int "Sets the size of the pre-console buffer"
 520         depends on PRE_CONSOLE_BUFFER
 521         default 4096
 522         help
 523           The size of the pre-console buffer affects how much console output
 524           can be held before it overflows and starts discarding earlier
 525           output. Normally there is very little output at this early stage,
 526           unless debugging is enabled, so allow enough for ~10 lines of
 527           text.
 528
 529           This is a useful feature if you are using a video console and
 530           want to see the full boot output on the console. Without this
 531           option only the post-relocation output will be displayed.
 532
 533 config PRE_CON_BUF_ADDR
 534         hex "Address of the pre-console buffer"
 535         depends on PRE_CONSOLE_BUFFER
 536         default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
 537         default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
 538         help
 539           This sets the start address of the pre-console buffer. This must
 540           be in available memory and is accessed before relocation and
 541           possibly before DRAM is set up. Therefore choose an address
 542           carefully.
 543
 544           We should consider removing this option and allocating the memory
 545           in board_init_f_init_reserve() instead.
 546
 547 config CONSOLE_MUX
 548         bool "Enable console multiplexing"
 549         default y if DM_VIDEO || VIDEO || LCD
 550         help
 551           This allows multiple devices to be used for each console 'file'.
 552           For example, stdout can be set to go to serial and video.
 553           Similarly, stdin can be set to come from serial and keyboard.
 554           Input can be provided from either source. Console multiplexing
 555           adds a small amount of size to U-Boot.  Changes to the environment
 556           variables stdout, stdin and stderr will take effect immediately.
 557
 558 config SYS_CONSOLE_IS_IN_ENV
 559         bool "Select console devices from the environment"
 560         default y if CONSOLE_MUX
 561         help
 562           This allows multiple input/output devices to be set at boot time.
 563           For example, if stdout is set to "serial,video" then output will
 564           be sent to both the serial and video devices on boot. The
 565           environment variables can be updated after boot to change the
 566           input/output devices.
 567
 568 config SYS_CONSOLE_OVERWRITE_ROUTINE
 569         bool "Allow board control over console overwriting"
 570         help
 571           If this is enabled, and the board-specific function
 572           overwrite_console() returns 1, the stdin, stderr and stdout are
 573           switched to the serial port, else the settings in the environment
 574           are used. If this is not enabled, the console will not be switched
 575           to serial.
 576
 577 config SYS_CONSOLE_ENV_OVERWRITE
 578         bool "Update environment variables during console init"
 579         help
 580           The console environment variables (stdout, stdin, stderr) can be
 581           used to determine the correct console devices on start-up. This
 582           option writes the console devices to these variables on console
 583           start-up (after relocation). This causes the environment to be
 584           updated to match the console devices actually chosen.
 585
 586 config SYS_CONSOLE_INFO_QUIET
 587         bool "Don't display the console devices on boot"
 588         help
 589           Normally U-Boot displays the current settings for stdout, stdin
 590           and stderr on boot when the post-relocation console is set up.
 591           Enable this option to supress this output. It can be obtained by
 592           calling stdio_print_current_devices() from board code.
 593
 594 config SYS_STDIO_DEREGISTER
 595         bool "Allow deregistering stdio devices"
 596         default y if USB_KEYBOARD
 597         help
 598           Generally there is no need to deregister stdio devices since they
 599           are never deactivated. But if a stdio device is used which can be
 600           removed (for example a USB keyboard) then this option can be
 601           enabled to ensure this is handled correctly.
 602
 603 endmenu
 604
 605 config DTB_RESELECT
 606         bool "Support swapping dtbs at a later point in boot"
 607         depends on FIT_EMBED
 608         help
 609           It is possible during initial boot you may need to use a generic
 610           dtb until you can fully determine the board your running on. This
 611           config allows boards to implement a function at a later point
 612           during boot to switch to the "correct" dtb.
 613
 614 config FIT_EMBED
 615         bool "Support a FIT image embedded in the U-boot image"
 616         help
 617           This option provides hooks to allow U-boot to parse an
 618           appended FIT image and enable board specific code to then select
 619           the correct DTB to be used.
 620
 621 config DEFAULT_FDT_FILE
 622         string "Default fdt file"
 623         help
 624           This option is used to set the default fdt file to boot OS.
 625
 626 config VERSION_VARIABLE
 627         bool "add U-Boot environment variable vers"
 628         default n
 629         help
 630           If this variable is defined, an environment variable
 631           named "ver" is created by U-Boot showing the U-Boot
 632           version as printed by the "version" command.
 633           Any change to this variable will be reverted at the
 634           next reset.
 635
 636 config BOARD_LATE_INIT
 637         bool
 638         help
 639           Sometimes board require some initialization code that might
 640           require once the actual init done, example saving board specific env,
 641           boot-modes etc. which eventually done at late.
 642
 643           So this config enable the late init code with the help of board_late_init
 644           function which should defined on respective boards.
 645
 646 config DISPLAY_CPUINFO
 647         bool "Display information about the CPU during start up"
 648         default y if ARM || NIOS2 || X86 || XTENSA
 649         help
 650           Display information about the CPU that U-Boot is running on
 651           when U-Boot starts up. The function print_cpuinfo() is called
 652           to do this.
 653
 654 config DISPLAY_BOARDINFO
 655         bool "Display information about the board during start up"
 656         default y if ARM || M68K || MIPS || PPC || SANDBOX || XTENSA
 657         help
 658           Display information about the board that U-Boot is running on
 659           when U-Boot starts up. The board function checkboard() is called
 660           to do this.
 661
 662 menu "Start-up hooks"
 663
 664 config ARCH_EARLY_INIT_R
 665         bool "Call arch-specific init soon after relocation"
 666         default y if X86
 667         help
 668           With this option U-Boot will call arch_early_init_r() soon after
 669           relocation. Driver model is running by this point, and the cache
 670           is on. Note that board_early_init_r() is called first, if
 671           enabled. This can be used to set up architecture-specific devices.
 672
 673 config ARCH_MISC_INIT
 674         bool "Call arch-specific init after relocation, when console is ready"
 675         help
 676           With this option U-Boot will call arch_misc_init() after
 677           relocation to allow miscellaneous arch-dependent initialisation
 678           to be performed. This function should be defined by the board
 679           and will be called after the console is set up, after relocaiton.
 680
 681 config BOARD_EARLY_INIT_F
 682         bool "Call board-specific init before relocation"
 683         default y if X86
 684         help
 685           Some boards need to perform initialisation as soon as possible
 686           after boot. With this option, U-Boot calls board_early_init_f()
 687           after driver model is ready in the pre-relocation init sequence.
 688           Note that the normal serial console is not yet set up, but the
 689           debug UART will be available if enabled.
 690
 691 endmenu
 692
 693 menu "Security support"
 694
 695 config HASH
 696         bool # "Support hashing API (SHA1, SHA256, etc.)"
 697         help
 698           This provides a way to hash data in memory using various supported
 699           algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
 700           and the algorithms it supports are defined in common/hash.c. See
 701           also CMD_HASH for command-line access.
 702
 703 endmenu
 704
 705 source "common/spl/Kconfig"