uboot/common/Kconfig
<<
>>
Prefs
   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 TPL_BOOTSTAGE
  31        bool "Boot timing and reported in TPL"
  32        depends on BOOTSTAGE
  33        help
  34          Enable recording of boot time in SPL. To make this visible to U-Boot
  35          proper, enable BOOTSTAGE_STASH as well. This will stash the timing
  36          information when TPL finishes and load it when U-Boot proper starts
  37          up.
  38
  39config BOOTSTAGE_REPORT
  40        bool "Display a detailed boot timing report before booting the OS"
  41        depends on BOOTSTAGE
  42        help
  43          Enable output of a boot time report just before the OS is booted.
  44          This shows how long it took U-Boot to go through each stage of the
  45          boot process. The report looks something like this:
  46
  47                Timer summary in microseconds:
  48                       Mark    Elapsed  Stage
  49                          0          0  reset
  50                  3,575,678  3,575,678  board_init_f start
  51                  3,575,695         17  arch_cpu_init A9
  52                  3,575,777         82  arch_cpu_init done
  53                  3,659,598     83,821  board_init_r start
  54                  3,910,375    250,777  main_loop
  55                 29,916,167 26,005,792  bootm_start
  56                 30,361,327    445,160  start_kernel
  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 SPL_BOOTSTAGE_RECORD_COUNT
  66        int "Number of boot stage records to store for SPL"
  67        default 5
  68        help
  69          This is the size of the bootstage record list and is the maximum
  70          number of bootstage records that can be recorded.
  71
  72config TPL_BOOTSTAGE_RECORD_COUNT
  73        int "Number of boot stage records to store for TPL"
  74        default 5
  75        help
  76          This is the size of the bootstage record list and is the maximum
  77          number of bootstage records that can be recorded.
  78
  79config BOOTSTAGE_FDT
  80        bool "Store boot timing information in the OS device tree"
  81        depends on BOOTSTAGE
  82        help
  83          Stash the bootstage information in the FDT. A root 'bootstage'
  84          node is created with each bootstage id as a child. Each child
  85          has a 'name' property and either 'mark' containing the
  86          mark time in microseconds, or 'accum' containing the
  87          accumulated time for that bootstage id in microseconds.
  88          For example:
  89
  90                bootstage {
  91                        154 {
  92                                name = "board_init_f";
  93                                mark = <3575678>;
  94                        };
  95                        170 {
  96                                name = "lcd";
  97                                accum = <33482>;
  98                        };
  99                };
 100
 101          Code in the Linux kernel can find this in /proc/devicetree.
 102
 103config BOOTSTAGE_STASH
 104        bool "Stash the boot timing information in memory before booting OS"
 105        depends on BOOTSTAGE
 106        help
 107          Some OSes do not support device tree. Bootstage can instead write
 108          the boot timing information in a binary format at a given address.
 109          This happens through a call to bootstage_stash(), typically in
 110          the CPU's cleanup_before_linux() function. You can use the
 111          'bootstage stash' and 'bootstage unstash' commands to do this on
 112          the command line.
 113
 114config BOOTSTAGE_STASH_ADDR
 115        hex "Address to stash boot timing information"
 116        default 0
 117        help
 118          Provide an address which will not be overwritten by the OS when it
 119          starts, so that it can read this information when ready.
 120
 121config BOOTSTAGE_STASH_SIZE
 122        hex "Size of boot timing stash region"
 123        default 0x1000
 124        help
 125          This should be large enough to hold the bootstage stash. A value of
 126          4096 (4KiB) is normally plenty.
 127
 128config SHOW_BOOT_PROGRESS
 129        bool "Show boot progress in a board-specific manner"
 130        help
 131          Defining this option allows to add some board-specific code (calling
 132          a user-provided function show_boot_progress(int) that enables you to
 133          show the system's boot progress on some display (for example, some
 134          LEDs) on your board. At the moment, the following checkpoints are
 135          implemented:
 136
 137          Legacy uImage format:
 138
 139          Arg   Where                   When
 140            1   common/cmd_bootm.c      before attempting to boot an image
 141           -1   common/cmd_bootm.c      Image header has bad     magic number
 142            2   common/cmd_bootm.c      Image header has correct magic number
 143           -2   common/cmd_bootm.c      Image header has bad     checksum
 144            3   common/cmd_bootm.c      Image header has correct checksum
 145           -3   common/cmd_bootm.c      Image data   has bad     checksum
 146            4   common/cmd_bootm.c      Image data   has correct checksum
 147           -4   common/cmd_bootm.c      Image is for unsupported architecture
 148            5   common/cmd_bootm.c      Architecture check OK
 149           -5   common/cmd_bootm.c      Wrong Image Type (not kernel, multi)
 150            6   common/cmd_bootm.c      Image Type check OK
 151           -6   common/cmd_bootm.c      gunzip uncompression error
 152           -7   common/cmd_bootm.c      Unimplemented compression type
 153            7   common/cmd_bootm.c      Uncompression OK
 154            8   common/cmd_bootm.c      No uncompress/copy overwrite error
 155           -9   common/cmd_bootm.c      Unsupported OS (not Linux, BSD, VxWorks, QNX)
 156
 157            9   common/image.c          Start initial ramdisk verification
 158          -10   common/image.c          Ramdisk header has bad     magic number
 159          -11   common/image.c          Ramdisk header has bad     checksum
 160           10   common/image.c          Ramdisk header is OK
 161          -12   common/image.c          Ramdisk data   has bad     checksum
 162           11   common/image.c          Ramdisk data   has correct checksum
 163           12   common/image.c          Ramdisk verification complete, start loading
 164          -13   common/image.c          Wrong Image Type (not PPC Linux ramdisk)
 165           13   common/image.c          Start multifile image verification
 166           14   common/image.c          No initial ramdisk, no multifile, continue.
 167
 168           15   arch/<arch>/lib/bootm.c All preparation done, transferring control to OS
 169
 170          -30   arch/powerpc/lib/board.c        Fatal error, hang the system
 171          -31   post/post.c             POST test failed, detected by post_output_backlog()
 172          -32   post/post.c             POST test failed, detected by post_run_single()
 173
 174           34   common/cmd_doc.c        before loading a Image from a DOC device
 175          -35   common/cmd_doc.c        Bad usage of "doc" command
 176           35   common/cmd_doc.c        correct usage of "doc" command
 177          -36   common/cmd_doc.c        No boot device
 178           36   common/cmd_doc.c        correct boot device
 179          -37   common/cmd_doc.c        Unknown Chip ID on boot device
 180           37   common/cmd_doc.c        correct chip ID found, device available
 181          -38   common/cmd_doc.c        Read Error on boot device
 182           38   common/cmd_doc.c        reading Image header from DOC device OK
 183          -39   common/cmd_doc.c        Image header has bad magic number
 184           39   common/cmd_doc.c        Image header has correct magic number
 185          -40   common/cmd_doc.c        Error reading Image from DOC device
 186           40   common/cmd_doc.c        Image header has correct magic number
 187           41   common/cmd_ide.c        before loading a Image from a IDE device
 188          -42   common/cmd_ide.c        Bad usage of "ide" command
 189           42   common/cmd_ide.c        correct usage of "ide" command
 190          -43   common/cmd_ide.c        No boot device
 191           43   common/cmd_ide.c        boot device found
 192          -44   common/cmd_ide.c        Device not available
 193           44   common/cmd_ide.c        Device available
 194          -45   common/cmd_ide.c        wrong partition selected
 195           45   common/cmd_ide.c        partition selected
 196          -46   common/cmd_ide.c        Unknown partition table
 197           46   common/cmd_ide.c        valid partition table found
 198          -47   common/cmd_ide.c        Invalid partition type
 199           47   common/cmd_ide.c        correct partition type
 200          -48   common/cmd_ide.c        Error reading Image Header on boot device
 201           48   common/cmd_ide.c        reading Image Header from IDE device OK
 202          -49   common/cmd_ide.c        Image header has bad magic number
 203           49   common/cmd_ide.c        Image header has correct magic number
 204          -50   common/cmd_ide.c        Image header has bad     checksum
 205           50   common/cmd_ide.c        Image header has correct checksum
 206          -51   common/cmd_ide.c        Error reading Image from IDE device
 207           51   common/cmd_ide.c        reading Image from IDE device OK
 208           52   common/cmd_nand.c       before loading a Image from a NAND device
 209          -53   common/cmd_nand.c       Bad usage of "nand" command
 210           53   common/cmd_nand.c       correct usage of "nand" command
 211          -54   common/cmd_nand.c       No boot device
 212           54   common/cmd_nand.c       boot device found
 213          -55   common/cmd_nand.c       Unknown Chip ID on boot device
 214           55   common/cmd_nand.c       correct chip ID found, device available
 215          -56   common/cmd_nand.c       Error reading Image Header on boot device
 216           56   common/cmd_nand.c       reading Image Header from NAND device OK
 217          -57   common/cmd_nand.c       Image header has bad magic number
 218           57   common/cmd_nand.c       Image header has correct magic number
 219          -58   common/cmd_nand.c       Error reading Image from NAND device
 220           58   common/cmd_nand.c       reading Image from NAND device OK
 221
 222          -60   common/env_common.c     Environment has a bad CRC, using default
 223
 224           64   net/eth.c               starting with Ethernet configuration.
 225          -64   net/eth.c               no Ethernet found.
 226           65   net/eth.c               Ethernet found.
 227
 228          -80   common/cmd_net.c        usage wrong
 229           80   common/cmd_net.c        before calling net_loop()
 230          -81   common/cmd_net.c        some error in net_loop() occurred
 231           81   common/cmd_net.c        net_loop() back without error
 232          -82   common/cmd_net.c        size == 0 (File with size 0 loaded)
 233           82   common/cmd_net.c        trying automatic boot
 234           83   common/cmd_net.c        running "source" command
 235          -83   common/cmd_net.c        some error in automatic boot or "source" command
 236           84   common/cmd_net.c        end without errors
 237
 238          FIT uImage format:
 239
 240          Arg   Where                   When
 241          100   common/cmd_bootm.c      Kernel FIT Image has correct format
 242          -100  common/cmd_bootm.c      Kernel FIT Image has incorrect format
 243          101   common/cmd_bootm.c      No Kernel subimage unit name, using configuration
 244          -101  common/cmd_bootm.c      Can't get configuration for kernel subimage
 245          102   common/cmd_bootm.c      Kernel unit name specified
 246          -103  common/cmd_bootm.c      Can't get kernel subimage node offset
 247          103   common/cmd_bootm.c      Found configuration node
 248          104   common/cmd_bootm.c      Got kernel subimage node offset
 249          -104  common/cmd_bootm.c      Kernel subimage hash verification failed
 250          105   common/cmd_bootm.c      Kernel subimage hash verification OK
 251          -105  common/cmd_bootm.c      Kernel subimage is for unsupported architecture
 252          106   common/cmd_bootm.c      Architecture check OK
 253          -106  common/cmd_bootm.c      Kernel subimage has wrong type
 254          107   common/cmd_bootm.c      Kernel subimage type OK
 255          -107  common/cmd_bootm.c      Can't get kernel subimage data/size
 256          108   common/cmd_bootm.c      Got kernel subimage data/size
 257          -108  common/cmd_bootm.c      Wrong image type (not legacy, FIT)
 258          -109  common/cmd_bootm.c      Can't get kernel subimage type
 259          -110  common/cmd_bootm.c      Can't get kernel subimage comp
 260          -111  common/cmd_bootm.c      Can't get kernel subimage os
 261          -112  common/cmd_bootm.c      Can't get kernel subimage load address
 262          -113  common/cmd_bootm.c      Image uncompress/copy overwrite error
 263
 264          120   common/image.c          Start initial ramdisk verification
 265          -120  common/image.c          Ramdisk FIT image has incorrect format
 266          121   common/image.c          Ramdisk FIT image has correct format
 267          122   common/image.c          No ramdisk subimage unit name, using configuration
 268          -122  common/image.c          Can't get configuration for ramdisk subimage
 269          123   common/image.c          Ramdisk unit name specified
 270          -124  common/image.c          Can't get ramdisk subimage node offset
 271          125   common/image.c          Got ramdisk subimage node offset
 272          -125  common/image.c          Ramdisk subimage hash verification failed
 273          126   common/image.c          Ramdisk subimage hash verification OK
 274          -126  common/image.c          Ramdisk subimage for unsupported architecture
 275          127   common/image.c          Architecture check OK
 276          -127  common/image.c          Can't get ramdisk subimage data/size
 277          128   common/image.c          Got ramdisk subimage data/size
 278          129   common/image.c          Can't get ramdisk load address
 279          -129  common/image.c          Got ramdisk load address
 280
 281          -130  common/cmd_doc.c        Incorrect FIT image format
 282          131   common/cmd_doc.c        FIT image format OK
 283
 284          -140  common/cmd_ide.c        Incorrect FIT image format
 285          141   common/cmd_ide.c        FIT image format OK
 286
 287          -150  common/cmd_nand.c       Incorrect FIT image format
 288          151   common/cmd_nand.c       FIT image format OK
 289
 290endmenu
 291
 292menu "Boot media"
 293
 294config NOR_BOOT
 295        bool "Support for booting from NOR flash"
 296        depends on NOR
 297        help
 298          Enabling this will make a U-Boot binary that is capable of being
 299          booted via NOR.  In this case we will enable certain pinmux early
 300          as the ROM only partially sets up pinmux.  We also default to using
 301          NOR for environment.
 302
 303config NAND_BOOT
 304        bool "Support for booting from NAND flash"
 305        default n
 306        imply MTD_RAW_NAND
 307        help
 308          Enabling this will make a U-Boot binary that is capable of being
 309          booted via NAND flash. This is not a must, some SoCs need this,
 310          some not.
 311
 312config ONENAND_BOOT
 313        bool "Support for booting from ONENAND"
 314        default n
 315        imply MTD_RAW_NAND
 316        help
 317          Enabling this will make a U-Boot binary that is capable of being
 318          booted via ONENAND. This is not a must, some SoCs need this,
 319          some not.
 320
 321config QSPI_BOOT
 322        bool "Support for booting from QSPI flash"
 323        default n
 324        help
 325          Enabling this will make a U-Boot binary that is capable of being
 326          booted via QSPI flash. This is not a must, some SoCs need this,
 327          some not.
 328
 329config SATA_BOOT
 330        bool "Support for booting from SATA"
 331        default n
 332        help
 333          Enabling this will make a U-Boot binary that is capable of being
 334          booted via SATA. This is not a must, some SoCs need this,
 335          some not.
 336
 337config SD_BOOT
 338        bool "Support for booting from SD/EMMC"
 339        default n
 340        help
 341          Enabling this will make a U-Boot binary that is capable of being
 342          booted via SD/EMMC. This is not a must, some SoCs need this,
 343          some not.
 344
 345config SPI_BOOT
 346        bool "Support for booting from SPI flash"
 347        default n
 348        help
 349          Enabling this will make a U-Boot binary that is capable of being
 350          booted via SPI flash. This is not a must, some SoCs need this,
 351          some not.
 352
 353endmenu
 354
 355config BOOTDELAY
 356        int "delay in seconds before automatically booting"
 357        default 2
 358        depends on AUTOBOOT
 359        help
 360          Delay before automatically running bootcmd;
 361          set to 0 to autoboot with no delay, but you can stop it by key input.
 362          set to -1 to disable autoboot.
 363          set to -2 to autoboot with no delay and not check for abort
 364
 365          If this value is >= 0 then it is also used for the default delay
 366          before starting the default entry in bootmenu. If it is < 0 then
 367          a default value of 10s is used.
 368
 369          See doc/README.autoboot for details.
 370
 371config USE_BOOTARGS
 372        bool "Enable boot arguments"
 373        help
 374          Provide boot arguments to bootm command. Boot arguments are specified
 375          in CONFIG_BOOTARGS option. Enable this option to be able to specify
 376          CONFIG_BOOTARGS string. If this option is disabled, CONFIG_BOOTARGS
 377          will be undefined and won't take any space in U-Boot image.
 378
 379config BOOTARGS
 380        string "Boot arguments"
 381        depends on USE_BOOTARGS
 382        help
 383          This can be used to pass arguments to the bootm command. The value of
 384          CONFIG_BOOTARGS goes into the environment value "bootargs". Note that
 385          this value will also override the "chosen" node in FDT blob.
 386
 387config USE_BOOTCOMMAND
 388        bool "Enable a default value for bootcmd"
 389        help
 390          Provide a default value for the bootcmd entry in the environment.  If
 391          autoboot is enabled this is what will be run automatically.  Enable
 392          this option to be able to specify CONFIG_BOOTCOMMAND as a string.  If
 393          this option is disabled, CONFIG_BOOTCOMMAND will be undefined and
 394          won't take any space in U-Boot image.
 395
 396config BOOTCOMMAND
 397        string "bootcmd value"
 398        depends on USE_BOOTCOMMAND
 399        default "run distro_bootcmd" if DISTRO_DEFAULTS
 400        help
 401          This is the string of commands that will be used as bootcmd and if
 402          AUTOBOOT is set, automatically run.
 403
 404config USE_PREBOOT
 405        bool "Enable preboot"
 406        help
 407          When this option is enabled, the existence of the environment
 408          variable "preboot" will be checked immediately before starting the
 409          CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp.
 410          entering interactive mode.
 411
 412          This feature is especially useful when "preboot" is automatically
 413          generated or modified. For example, the boot code can modify the
 414          "preboot" when a user holds down a certain combination of keys.
 415
 416config PREBOOT
 417        string "preboot default value"
 418        depends on USE_PREBOOT
 419        default ""
 420        help
 421          This is the default of "preboot" environment variable.
 422
 423menu "Console"
 424
 425config 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
 431config 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
 440config 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
 449config 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
 459config DISABLE_CONSOLE
 460        bool "Add functionality to disable console completely"
 461        help
 462                Disable console (in & out).
 463
 464config IDENT_STRING
 465        string "Board specific string to be added to uboot version string"
 466        help
 467          This options adds the board specific name to u-boot version.
 468
 469config LOGLEVEL
 470        int "loglevel"
 471        default 4
 472        range 0 8
 473        help
 474          All Messages with a loglevel smaller than the console loglevel will
 475          be compiled in. The loglevels are defined as follows:
 476
 477            0 - emergency
 478            1 - alert
 479            2 - critical
 480            3 - error
 481            4 - warning
 482            5 - note
 483            6 - info
 484            7 - debug
 485            8 - debug content
 486            9 - debug hardware I/O
 487
 488config SPL_LOGLEVEL
 489        int
 490        default LOGLEVEL
 491
 492config TPL_LOGLEVEL
 493        int
 494        default LOGLEVEL
 495
 496config SILENT_CONSOLE
 497        bool "Support a silent console"
 498        help
 499          This option allows the console to be silenced, meaning that no
 500          output will appear on the console devices. This is controlled by
 501          setting the environment variable 'silent' to a non-empty value.
 502          Note this also silences the console when booting Linux.
 503
 504          When the console is set up, the variable is checked, and the
 505          GD_FLG_SILENT flag is set. Changing the environment variable later
 506          will update the flag.
 507
 508config SILENT_U_BOOT_ONLY
 509        bool "Only silence the U-Boot console"
 510        depends on SILENT_CONSOLE
 511        help
 512          Normally when the U-Boot console is silenced, Linux's console is
 513          also silenced (assuming the board boots into Linux). This option
 514          allows the linux console to operate normally, even if U-Boot's
 515          is silenced.
 516
 517config SILENT_CONSOLE_UPDATE_ON_SET
 518        bool "Changes to the 'silent' environment variable update immediately"
 519        depends on SILENT_CONSOLE
 520        default y if SILENT_CONSOLE
 521        help
 522          When the 'silent' environment variable is changed, update the
 523          console silence flag immediately. This allows 'setenv' to be used
 524          to silence or un-silence the console.
 525
 526          The effect is that any change to the variable will affect the
 527          GD_FLG_SILENT flag.
 528
 529config SILENT_CONSOLE_UPDATE_ON_RELOC
 530        bool "Allow flags to take effect on relocation"
 531        depends on SILENT_CONSOLE
 532        help
 533          In some cases the environment is not available until relocation
 534          (e.g. NAND). This option makes the value of the 'silent'
 535          environment variable take effect at relocation.
 536
 537config PRE_CONSOLE_BUFFER
 538        bool "Buffer characters before the console is available"
 539        help
 540          Prior to the console being initialised (i.e. serial UART
 541          initialised etc) all console output is silently discarded.
 542          Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
 543          buffer any console messages prior to the console being
 544          initialised to a buffer. The buffer is a circular buffer, so
 545          if it overflows, earlier output is discarded.
 546
 547          Note that this is not currently supported in SPL. It would be
 548          useful to be able to share the pre-console buffer with SPL.
 549
 550config PRE_CON_BUF_SZ
 551        int "Sets the size of the pre-console buffer"
 552        depends on PRE_CONSOLE_BUFFER
 553        default 4096
 554        help
 555          The size of the pre-console buffer affects how much console output
 556          can be held before it overflows and starts discarding earlier
 557          output. Normally there is very little output at this early stage,
 558          unless debugging is enabled, so allow enough for ~10 lines of
 559          text.
 560
 561          This is a useful feature if you are using a video console and
 562          want to see the full boot output on the console. Without this
 563          option only the post-relocation output will be displayed.
 564
 565config PRE_CON_BUF_ADDR
 566        hex "Address of the pre-console buffer"
 567        depends on PRE_CONSOLE_BUFFER
 568        default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
 569        default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
 570        help
 571          This sets the start address of the pre-console buffer. This must
 572          be in available memory and is accessed before relocation and
 573          possibly before DRAM is set up. Therefore choose an address
 574          carefully.
 575
 576          We should consider removing this option and allocating the memory
 577          in board_init_f_init_reserve() instead.
 578
 579config CONSOLE_MUX
 580        bool "Enable console multiplexing"
 581        default y if DM_VIDEO || VIDEO || LCD
 582        help
 583          This allows multiple devices to be used for each console 'file'.
 584          For example, stdout can be set to go to serial and video.
 585          Similarly, stdin can be set to come from serial and keyboard.
 586          Input can be provided from either source. Console multiplexing
 587          adds a small amount of size to U-Boot.  Changes to the environment
 588          variables stdout, stdin and stderr will take effect immediately.
 589
 590config SYS_CONSOLE_IS_IN_ENV
 591        bool "Select console devices from the environment"
 592        default y if CONSOLE_MUX
 593        help
 594          This allows multiple input/output devices to be set at boot time.
 595          For example, if stdout is set to "serial,video" then output will
 596          be sent to both the serial and video devices on boot. The
 597          environment variables can be updated after boot to change the
 598          input/output devices.
 599
 600config SYS_CONSOLE_OVERWRITE_ROUTINE
 601        bool "Allow board control over console overwriting"
 602        help
 603          If this is enabled, and the board-specific function
 604          overwrite_console() returns 1, the stdin, stderr and stdout are
 605          switched to the serial port, else the settings in the environment
 606          are used. If this is not enabled, the console will not be switched
 607          to serial.
 608
 609config SYS_CONSOLE_ENV_OVERWRITE
 610        bool "Update environment variables during console init"
 611        help
 612          The console environment variables (stdout, stdin, stderr) can be
 613          used to determine the correct console devices on start-up. This
 614          option writes the console devices to these variables on console
 615          start-up (after relocation). This causes the environment to be
 616          updated to match the console devices actually chosen.
 617
 618config SYS_CONSOLE_INFO_QUIET
 619        bool "Don't display the console devices on boot"
 620        help
 621          Normally U-Boot displays the current settings for stdout, stdin
 622          and stderr on boot when the post-relocation console is set up.
 623          Enable this option to suppress this output. It can be obtained by
 624          calling stdio_print_current_devices() from board code.
 625
 626config SYS_STDIO_DEREGISTER
 627        bool "Allow deregistering stdio devices"
 628        default y if USB_KEYBOARD
 629        help
 630          Generally there is no need to deregister stdio devices since they
 631          are never deactivated. But if a stdio device is used which can be
 632          removed (for example a USB keyboard) then this option can be
 633          enabled to ensure this is handled correctly.
 634
 635endmenu
 636
 637menu "Logging"
 638
 639config LOG
 640        bool "Enable logging support"
 641        depends on DM
 642        help
 643          This enables support for logging of status and debug messages. These
 644          can be displayed on the console, recorded in a memory buffer, or
 645          discarded if not needed. Logging supports various categories and
 646          levels of severity.
 647
 648config SPL_LOG
 649        bool "Enable logging support in SPL"
 650        depends on LOG
 651        help
 652          This enables support for logging of status and debug messages. These
 653          can be displayed on the console, recorded in a memory buffer, or
 654          discarded if not needed. Logging supports various categories and
 655          levels of severity.
 656
 657config TPL_LOG
 658        bool "Enable logging support in TPL"
 659        depends on LOG
 660        help
 661          This enables support for logging of status and debug messages. These
 662          can be displayed on the console, recorded in a memory buffer, or
 663          discarded if not needed. Logging supports various categories and
 664          levels of severity.
 665
 666config LOG_MAX_LEVEL
 667        int "Maximum log level to record"
 668        depends on LOG
 669        default 5
 670        help
 671          This selects the maximum log level that will be recorded. Any value
 672          higher than this will be ignored. If possible log statements below
 673          this level will be discarded at build time. Levels:
 674
 675            0 - emergency
 676            1 - alert
 677            2 - critical
 678            3 - error
 679            4 - warning
 680            5 - note
 681            6 - info
 682            7 - debug
 683            8 - debug content
 684            9 - debug hardware I/O
 685
 686config SPL_LOG_MAX_LEVEL
 687        int "Maximum log level to record in SPL"
 688        depends on SPL_LOG
 689        default 3
 690        help
 691          This selects the maximum log level that will be recorded. Any value
 692          higher than this will be ignored. If possible log statements below
 693          this level will be discarded at build time. Levels:
 694
 695            0 - emergency
 696            1 - alert
 697            2 - critical
 698            3 - error
 699            4 - warning
 700            5 - note
 701            6 - info
 702            7 - debug
 703            8 - debug content
 704            9 - debug hardware I/O
 705
 706config TPL_LOG_MAX_LEVEL
 707        int "Maximum log level to record in TPL"
 708        depends on TPL_LOG
 709        default 3
 710        help
 711          This selects the maximum log level that will be recorded. Any value
 712          higher than this will be ignored. If possible log statements below
 713          this level will be discarded at build time. Levels:
 714
 715            0 - emergency
 716            1 - alert
 717            2 - critical
 718            3 - error
 719            4 - warning
 720            5 - note
 721            6 - info
 722            7 - debug
 723            8 - debug content
 724            9 - debug hardware I/O
 725
 726config LOG_DEFAULT_LEVEL
 727        int "Default logging level to display"
 728        default 6
 729        help
 730          This is the default logging level set when U-Boot starts. It can
 731          be adjusted later using the 'log level' command. Note that setting
 732          this to a value above LOG_MAX_LEVEL will be ineffective, since the
 733          higher levels are not compiled in to U-Boot.
 734
 735            0 - emergency
 736            1 - alert
 737            2 - critical
 738            3 - error
 739            4 - warning
 740            5 - note
 741            6 - info
 742            7 - debug
 743            8 - debug content
 744            9 - debug hardware I/O
 745
 746config LOG_CONSOLE
 747        bool "Allow log output to the console"
 748        depends on LOG
 749        default y
 750        help
 751          Enables a log driver which writes log records to the console.
 752          Generally the console is the serial port or LCD display. Only the
 753          log message is shown - other details like level, category, file and
 754          line number are omitted.
 755
 756config SPL_LOG_CONSOLE
 757        bool "Allow log output to the console in SPL"
 758        depends on SPL_LOG
 759        default y
 760        help
 761          Enables a log driver which writes log records to the console.
 762          Generally the console is the serial port or LCD display. Only the
 763          log message is shown - other details like level, category, file and
 764          line number are omitted.
 765
 766config TPL_LOG_CONSOLE
 767        bool "Allow log output to the console in TPL"
 768        depends on TPL_LOG
 769        default y
 770        help
 771          Enables a log driver which writes log records to the console.
 772          Generally the console is the serial port or LCD display. Only the
 773          log message is shown - other details like level, category, file and
 774          line number are omitted.
 775
 776config LOG_TEST
 777        bool "Provide a test for logging"
 778        depends on LOG
 779        default y if SANDBOX
 780        help
 781          This enables a 'log test' command to test logging. It is normally
 782          executed from a pytest and simply outputs logging information
 783          in various different ways to test that the logging system works
 784          correctly with various settings.
 785
 786config LOG_ERROR_RETURN
 787        bool "Log all functions which return an error"
 788        depends on LOG
 789        help
 790          When an error is returned in U-Boot it is sometimes difficult to
 791          figure out the root cause. For example, reading from SPI flash may
 792          fail due to a problem in the SPI controller or due to the flash part
 793          not returning the expected information. This option changes
 794          log_ret() to log any errors it sees. With this option disabled,
 795          log_ret() is a nop.
 796
 797          You can add log_ret() to all functions which return an error code.
 798
 799endmenu
 800
 801config SUPPORT_RAW_INITRD
 802        bool "Enable raw initrd images"
 803        help
 804          Note, defining the SUPPORT_RAW_INITRD allows user to supply
 805          kernel with raw initrd images. The syntax is slightly different, the
 806          address of the initrd must be augmented by it's size, in the following
 807          format: "<initrd address>:<initrd size>".
 808
 809config DEFAULT_FDT_FILE
 810        string "Default fdt file"
 811        help
 812          This option is used to set the default fdt file to boot OS.
 813
 814config MISC_INIT_R
 815        bool "Execute Misc Init"
 816        default y if ARCH_KEYSTONE || ARCH_SUNXI || MPC85xx
 817        default y if ARCH_OMAP2PLUS && !AM33XX
 818        help
 819          Enabling this option calls 'misc_init_r' function
 820
 821config VERSION_VARIABLE
 822        bool "add U-Boot environment variable vers"
 823        default n
 824        help
 825          If this variable is defined, an environment variable
 826          named "ver" is created by U-Boot showing the U-Boot
 827          version as printed by the "version" command.
 828          Any change to this variable will be reverted at the
 829          next reset.
 830
 831config BOARD_LATE_INIT
 832        bool "Execute Board late init"
 833        help
 834          Sometimes board require some initialization code that might
 835          require once the actual init done, example saving board specific env,
 836          boot-modes etc. which eventually done at late.
 837
 838          So this config enable the late init code with the help of board_late_init
 839          function which should defined on respective boards.
 840
 841config DISPLAY_CPUINFO
 842        bool "Display information about the CPU during start up"
 843        default y if ARC|| ARM || NIOS2 || X86 || XTENSA || M68K
 844        help
 845          Display information about the CPU that U-Boot is running on
 846          when U-Boot starts up. The function print_cpuinfo() is called
 847          to do this.
 848
 849config DISPLAY_BOARDINFO
 850        bool "Display information about the board during early start up"
 851        default y if ARC || ARM || M68K || MIPS || PPC || SANDBOX || XTENSA
 852        help
 853          Display information about the board that U-Boot is running on
 854          when U-Boot starts up. The board function checkboard() is called
 855          to do this.
 856
 857config DISPLAY_BOARDINFO_LATE
 858        bool "Display information about the board during late start up"
 859        help
 860          Display information about the board that U-Boot is running on after
 861          the relocation phase. The board function checkboard() is called to do
 862          this.
 863
 864config BOUNCE_BUFFER
 865        bool "Include bounce buffer API"
 866        help
 867          Some peripherals support DMA from a subset of physically
 868          addressable memory only.  To support such peripherals, the
 869          bounce buffer API uses a temporary buffer: it copies data
 870          to/from DMA regions while managing cache operations.
 871
 872          A second possible use of bounce buffers is their ability to
 873          provide aligned buffers for DMA operations.
 874
 875config BOARD_TYPES
 876        bool "Call get_board_type() to get and display the board type"
 877        help
 878          If this option is enabled, checkboard() will call get_board_type()
 879          to get a string containing the board type and this will be
 880          displayed immediately after the model is shown on the console
 881          early in boot.
 882
 883menu "Start-up hooks"
 884
 885config ARCH_EARLY_INIT_R
 886        bool "Call arch-specific init soon after relocation"
 887        help
 888          With this option U-Boot will call arch_early_init_r() soon after
 889          relocation. Driver model is running by this point, and the cache
 890          is on. Note that board_early_init_r() is called first, if
 891          enabled. This can be used to set up architecture-specific devices.
 892
 893config ARCH_MISC_INIT
 894        bool "Call arch-specific init after relocation, when console is ready"
 895        help
 896          With this option U-Boot will call arch_misc_init() after
 897          relocation to allow miscellaneous arch-dependent initialisation
 898          to be performed. This function should be defined by the board
 899          and will be called after the console is set up, after relocation.
 900
 901config BOARD_EARLY_INIT_F
 902        bool "Call board-specific init before relocation"
 903        help
 904          Some boards need to perform initialisation as soon as possible
 905          after boot. With this option, U-Boot calls board_early_init_f()
 906          after driver model is ready in the pre-relocation init sequence.
 907          Note that the normal serial console is not yet set up, but the
 908          debug UART will be available if enabled.
 909
 910config BOARD_EARLY_INIT_R
 911        bool "Call board-specific init after relocation"
 912        help
 913          Some boards need to perform initialisation as directly after
 914          relocation. With this option, U-Boot calls board_early_init_r()
 915          in the post-relocation init sequence.
 916
 917config LAST_STAGE_INIT
 918        bool "Call board-specific as last setup step"
 919        help
 920          Some boards need to perform initialisation immediately before control
 921          is passed to the command-line interpreter (e.g. for initializations
 922          that depend on later phases in the init sequence). With this option,
 923          U-Boot calls last_stage_init() before the command-line interpreter is
 924          started.
 925
 926endmenu
 927
 928menu "Security support"
 929
 930config HASH
 931        bool # "Support hashing API (SHA1, SHA256, etc.)"
 932        help
 933          This provides a way to hash data in memory using various supported
 934          algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
 935          and the algorithms it supports are defined in common/hash.c. See
 936          also CMD_HASH for command-line access.
 937
 938config AVB_VERIFY
 939        bool "Build Android Verified Boot operations"
 940        depends on LIBAVB && FASTBOOT
 941        depends on PARTITION_UUIDS
 942        help
 943          This option enables compilation of bootloader-dependent operations,
 944          used by Android Verified Boot 2.0 library (libavb). Includes:
 945            * Helpers to process strings in order to build OS bootargs.
 946            * Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c.
 947            * Helpers to alloc/init/free avb ops.
 948
 949config SPL_HASH
 950        bool # "Support hashing API (SHA1, SHA256, etc.)"
 951        help
 952          This provides a way to hash data in memory using various supported
 953          algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
 954          and the algorithms it supports are defined in common/hash.c. See
 955          also CMD_HASH for command-line access.
 956
 957config TPL_HASH
 958        bool # "Support hashing API (SHA1, SHA256, etc.)"
 959        help
 960          This provides a way to hash data in memory using various supported
 961          algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
 962          and the algorithms it supports are defined in common/hash.c. See
 963          also CMD_HASH for command-line access.
 964
 965endmenu
 966
 967menu "Update support"
 968
 969config UPDATE_TFTP
 970        bool "Auto-update using fitImage via TFTP"
 971        depends on FIT
 972        help
 973          This option allows performing update of NOR with data in fitImage
 974          sent via TFTP boot.
 975
 976config UPDATE_TFTP_CNT_MAX
 977        int "The number of connection retries during auto-update"
 978        default 0
 979        depends on UPDATE_TFTP
 980
 981config UPDATE_TFTP_MSEC_MAX
 982        int "Delay in mSec to wait for the TFTP server during auto-update"
 983        default 100
 984        depends on UPDATE_TFTP
 985
 986config ANDROID_AB
 987        bool "Android A/B updates"
 988        default n
 989        help
 990          If enabled, adds support for the new Android A/B update model. This
 991          allows the bootloader to select which slot to boot from based on the
 992          information provided by userspace via the Android boot_ctrl HAL. This
 993          allows a bootloader to try a new version of the system but roll back
 994          to previous version if the new one didn't boot all the way.
 995
 996endmenu
 997
 998menu "Blob list"
 999
1000config BLOBLIST
1001        bool "Support for a bloblist"
1002        help
1003          This enables support for a bloblist in U-Boot, which can be passed
1004          from TPL to SPL to U-Boot proper (and potentially to Linux). The
1005          blob list supports multiple binary blobs of data, each with a tag,
1006          so that different U-Boot components can store data which can survive
1007          through to the next stage of the boot.
1008
1009config SPL_BLOBLIST
1010        bool "Support for a bloblist in SPL"
1011        depends on BLOBLIST
1012        default y if SPL
1013        help
1014          This enables a bloblist in SPL. If this is the first part of U-Boot
1015          to run, then the bloblist is set up in SPL and passed to U-Boot
1016          proper. If TPL also has a bloblist, then SPL uses the one from there.
1017
1018config TPL_BLOBLIST
1019        bool "Support for a bloblist in TPL"
1020        depends on BLOBLIST
1021        default y if TPL
1022        help
1023          This enables a bloblist in TPL. The bloblist is set up in TPL and
1024          passed to SPL and U-Boot proper.
1025
1026config BLOBLIST_SIZE
1027        hex "Size of bloblist"
1028        depends on BLOBLIST
1029        default 0x400
1030        help
1031          Sets the size of the bloblist in bytes. This must include all
1032          overhead (alignment, bloblist header, record header). The bloblist
1033          is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
1034          proper), and this sane bloblist is used for subsequent stages.
1035
1036config BLOBLIST_ADDR
1037        hex "Address of bloblist"
1038        depends on BLOBLIST
1039        default 0xe000 if SANDBOX
1040        help
1041          Sets the address of the bloblist, set up by the first part of U-Boot
1042          which runs. Subsequent U-Boot stages typically use the same address.
1043
1044endmenu
1045
1046source "common/spl/Kconfig"
1047