xref: /openbmc/u-boot/common/Kconfig (revision e5350145)
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 BOOTSTAGE_FDT
73	bool "Store boot timing information in the OS device tree"
74	depends on BOOTSTAGE
75	help
76	  Stash the bootstage information in the FDT. A root 'bootstage'
77	  node is created with each bootstage id as a child. Each child
78	  has a 'name' property and either 'mark' containing the
79	  mark time in microseconds, or 'accum' containing the
80	  accumulated time for that bootstage id in microseconds.
81	  For example:
82
83		bootstage {
84			154 {
85				name = "board_init_f";
86				mark = <3575678>;
87			};
88			170 {
89				name = "lcd";
90				accum = <33482>;
91			};
92		};
93
94	  Code in the Linux kernel can find this in /proc/devicetree.
95
96config BOOTSTAGE_STASH
97	bool "Stash the boot timing information in memory before booting OS"
98	depends on BOOTSTAGE
99	help
100	  Some OSes do not support device tree. Bootstage can instead write
101	  the boot timing information in a binary format at a given address.
102	  This happens through a call to bootstage_stash(), typically in
103	  the CPU's cleanup_before_linux() function. You can use the
104	  'bootstage stash' and 'bootstage unstash' commands to do this on
105	  the command line.
106
107config BOOTSTAGE_STASH_ADDR
108	hex "Address to stash boot timing information"
109	default 0
110	help
111	  Provide an address which will not be overwritten by the OS when it
112	  starts, so that it can read this information when ready.
113
114config BOOTSTAGE_STASH_SIZE
115	hex "Size of boot timing stash region"
116	default 0x1000
117	help
118	  This should be large enough to hold the bootstage stash. A value of
119	  4096 (4KiB) is normally plenty.
120
121endmenu
122
123menu "Boot media"
124
125config NOR_BOOT
126	bool "Support for booting from NOR flash"
127	depends on NOR
128	help
129	  Enabling this will make a U-Boot binary that is capable of being
130	  booted via NOR.  In this case we will enable certain pinmux early
131	  as the ROM only partially sets up pinmux.  We also default to using
132	  NOR for environment.
133
134config NAND_BOOT
135	bool "Support for booting from NAND flash"
136	default n
137	imply NAND
138	help
139	  Enabling this will make a U-Boot binary that is capable of being
140	  booted via NAND flash. This is not a must, some SoCs need this,
141	  some not.
142
143config ONENAND_BOOT
144	bool "Support for booting from ONENAND"
145	default n
146	imply NAND
147	help
148	  Enabling this will make a U-Boot binary that is capable of being
149	  booted via ONENAND. This is not a must, some SoCs need this,
150	  some not.
151
152config QSPI_BOOT
153	bool "Support for booting from QSPI flash"
154	default n
155	help
156	  Enabling this will make a U-Boot binary that is capable of being
157	  booted via QSPI flash. This is not a must, some SoCs need this,
158	  some not.
159
160config SATA_BOOT
161	bool "Support for booting from SATA"
162	default n
163	help
164	  Enabling this will make a U-Boot binary that is capable of being
165	  booted via SATA. This is not a must, some SoCs need this,
166	  some not.
167
168config SD_BOOT
169	bool "Support for booting from SD/EMMC"
170	default n
171	help
172	  Enabling this will make a U-Boot binary that is capable of being
173	  booted via SD/EMMC. This is not a must, some SoCs need this,
174	  some not.
175
176config SPI_BOOT
177	bool "Support for booting from SPI flash"
178	default n
179	help
180	  Enabling this will make a U-Boot binary that is capable of being
181	  booted via SPI flash. This is not a must, some SoCs need this,
182	  some not.
183
184endmenu
185
186config BOOTDELAY
187	int "delay in seconds before automatically booting"
188	default 2
189	depends on AUTOBOOT
190	help
191	  Delay before automatically running bootcmd;
192	  set to 0 to autoboot with no delay, but you can stop it by key input.
193	  set to -1 to disable autoboot.
194	  set to -2 to autoboot with no delay and not check for abort
195
196	  If this value is >= 0 then it is also used for the default delay
197	  before starting the default entry in bootmenu. If it is < 0 then
198	  a default value of 10s is used.
199
200	  See doc/README.autoboot for details.
201
202config USE_BOOTARGS
203	bool "Enable boot arguments"
204	help
205	  Provide boot arguments to bootm command. Boot arguments are specified
206	  in CONFIG_BOOTARGS option. Enable this option to be able to specify
207	  CONFIG_BOOTARGS string. If this option is disabled, CONFIG_BOOTARGS
208	  will be undefined and won't take any space in U-Boot image.
209
210config BOOTARGS
211	string "Boot arguments"
212	depends on USE_BOOTARGS
213	help
214	  This can be used to pass arguments to the bootm command. The value of
215	  CONFIG_BOOTARGS goes into the environment value "bootargs". Note that
216	  this value will also override the "chosen" node in FDT blob.
217
218config USE_BOOTCOMMAND
219	bool "Enable a default value for bootcmd"
220	help
221	  Provide a default value for the bootcmd entry in the environment.  If
222	  autoboot is enabled this is what will be run automatically.  Enable
223	  this option to be able to specify CONFIG_BOOTCOMMAND as a string.  If
224	  this option is disabled, CONFIG_BOOTCOMMAND will be undefined and
225	  won't take any space in U-Boot image.
226
227config BOOTCOMMAND
228	string "bootcmd value"
229	depends on USE_BOOTCOMMAND
230	default "run distro_bootcmd" if DISTRO_DEFAULTS
231	help
232	  This is the string of commands that will be used as bootcmd and if
233	  AUTOBOOT is set, automatically run.
234
235menu "Console"
236
237config MENU
238	bool
239	help
240	  This is the library functionality to provide a text-based menu of
241	  choices for the user to make choices with.
242
243config CONSOLE_RECORD
244	bool "Console recording"
245	help
246	  This provides a way to record console output (and provide console
247	  input) through circular buffers. This is mostly useful for testing.
248	  Console output is recorded even when the console is silent.
249	  To enable console recording, call console_record_reset_enable()
250	  from your code.
251
252config CONSOLE_RECORD_OUT_SIZE
253	hex "Output buffer size"
254	depends on CONSOLE_RECORD
255	default 0x400 if CONSOLE_RECORD
256	help
257	  Set the size of the console output buffer. When this fills up, no
258	  more data will be recorded until some is removed. The buffer is
259	  allocated immediately after the malloc() region is ready.
260
261config CONSOLE_RECORD_IN_SIZE
262	hex "Input buffer size"
263	depends on CONSOLE_RECORD
264	default 0x100 if CONSOLE_RECORD
265	help
266	  Set the size of the console input buffer. When this contains data,
267	  tstc() and getc() will use this in preference to real device input.
268	  The buffer is allocated immediately after the malloc() region is
269	  ready.
270
271config DISABLE_CONSOLE
272	bool "Add functionality to disable console completely"
273	help
274		Disable console (in & out).
275
276config IDENT_STRING
277	string "Board specific string to be added to uboot version string"
278	help
279	  This options adds the board specific name to u-boot version.
280
281config LOGLEVEL
282	int "loglevel"
283	default 4
284	range 0 8
285	help
286	  All Messages with a loglevel smaller than the console loglevel will
287	  be compiled in. The loglevels are defined as follows:
288
289	  0 (KERN_EMERG)          system is unusable
290	  1 (KERN_ALERT)          action must be taken immediately
291	  2 (KERN_CRIT)           critical conditions
292	  3 (KERN_ERR)            error conditions
293	  4 (KERN_WARNING)        warning conditions
294	  5 (KERN_NOTICE)         normal but significant condition
295	  6 (KERN_INFO)           informational
296	  7 (KERN_DEBUG)          debug-level messages
297
298config SPL_LOGLEVEL
299	int
300	default LOGLEVEL
301
302config TPL_LOGLEVEL
303	int
304	default LOGLEVEL
305
306config SILENT_CONSOLE
307	bool "Support a silent console"
308	help
309	  This option allows the console to be silenced, meaning that no
310	  output will appear on the console devices. This is controlled by
311	  setting the environment variable 'silent' to a non-empty value.
312	  Note this also silences the console when booting Linux.
313
314	  When the console is set up, the variable is checked, and the
315	  GD_FLG_SILENT flag is set. Changing the environment variable later
316	  will update the flag.
317
318config SILENT_U_BOOT_ONLY
319	bool "Only silence the U-Boot console"
320	depends on SILENT_CONSOLE
321	help
322	  Normally when the U-Boot console is silenced, Linux's console is
323	  also silenced (assuming the board boots into Linux). This option
324	  allows the linux console to operate normally, even if U-Boot's
325	  is silenced.
326
327config SILENT_CONSOLE_UPDATE_ON_SET
328	bool "Changes to the 'silent' environment variable update immediately"
329	depends on SILENT_CONSOLE
330	default y if SILENT_CONSOLE
331	help
332	  When the 'silent' environment variable is changed, update the
333	  console silence flag immediately. This allows 'setenv' to be used
334	  to silence or un-silence the console.
335
336	  The effect is that any change to the variable will affect the
337	  GD_FLG_SILENT flag.
338
339config SILENT_CONSOLE_UPDATE_ON_RELOC
340	bool "Allow flags to take effect on relocation"
341	depends on SILENT_CONSOLE
342	help
343	  In some cases the environment is not available until relocation
344	  (e.g. NAND). This option makes the value of the 'silent'
345	  environment variable take effect at relocation.
346
347config PRE_CONSOLE_BUFFER
348	bool "Buffer characters before the console is available"
349	help
350	  Prior to the console being initialised (i.e. serial UART
351	  initialised etc) all console output is silently discarded.
352	  Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
353	  buffer any console messages prior to the console being
354	  initialised to a buffer. The buffer is a circular buffer, so
355	  if it overflows, earlier output is discarded.
356
357	  Note that this is not currently supported in SPL. It would be
358	  useful to be able to share the pre-console buffer with SPL.
359
360config PRE_CON_BUF_SZ
361	int "Sets the size of the pre-console buffer"
362	depends on PRE_CONSOLE_BUFFER
363	default 4096
364	help
365	  The size of the pre-console buffer affects how much console output
366	  can be held before it overflows and starts discarding earlier
367	  output. Normally there is very little output at this early stage,
368	  unless debugging is enabled, so allow enough for ~10 lines of
369	  text.
370
371	  This is a useful feature if you are using a video console and
372	  want to see the full boot output on the console. Without this
373	  option only the post-relocation output will be displayed.
374
375config PRE_CON_BUF_ADDR
376	hex "Address of the pre-console buffer"
377	depends on PRE_CONSOLE_BUFFER
378	default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
379	default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
380	help
381	  This sets the start address of the pre-console buffer. This must
382	  be in available memory and is accessed before relocation and
383	  possibly before DRAM is set up. Therefore choose an address
384	  carefully.
385
386	  We should consider removing this option and allocating the memory
387	  in board_init_f_init_reserve() instead.
388
389config CONSOLE_MUX
390	bool "Enable console multiplexing"
391	default y if DM_VIDEO || VIDEO || LCD
392	help
393	  This allows multiple devices to be used for each console 'file'.
394	  For example, stdout can be set to go to serial and video.
395	  Similarly, stdin can be set to come from serial and keyboard.
396	  Input can be provided from either source. Console multiplexing
397	  adds a small amount of size to U-Boot.  Changes to the environment
398	  variables stdout, stdin and stderr will take effect immediately.
399
400config SYS_CONSOLE_IS_IN_ENV
401	bool "Select console devices from the environment"
402	default y if CONSOLE_MUX
403	help
404	  This allows multiple input/output devices to be set at boot time.
405	  For example, if stdout is set to "serial,video" then output will
406	  be sent to both the serial and video devices on boot. The
407	  environment variables can be updated after boot to change the
408	  input/output devices.
409
410config SYS_CONSOLE_OVERWRITE_ROUTINE
411	bool "Allow board control over console overwriting"
412	help
413	  If this is enabled, and the board-specific function
414	  overwrite_console() returns 1, the stdin, stderr and stdout are
415	  switched to the serial port, else the settings in the environment
416	  are used. If this is not enabled, the console will not be switched
417	  to serial.
418
419config SYS_CONSOLE_ENV_OVERWRITE
420	bool "Update environment variables during console init"
421	help
422	  The console environment variables (stdout, stdin, stderr) can be
423	  used to determine the correct console devices on start-up. This
424	  option writes the console devices to these variables on console
425	  start-up (after relocation). This causes the environment to be
426	  updated to match the console devices actually chosen.
427
428config SYS_CONSOLE_INFO_QUIET
429	bool "Don't display the console devices on boot"
430	help
431	  Normally U-Boot displays the current settings for stdout, stdin
432	  and stderr on boot when the post-relocation console is set up.
433	  Enable this option to suppress this output. It can be obtained by
434	  calling stdio_print_current_devices() from board code.
435
436config SYS_STDIO_DEREGISTER
437	bool "Allow deregistering stdio devices"
438	default y if USB_KEYBOARD
439	help
440	  Generally there is no need to deregister stdio devices since they
441	  are never deactivated. But if a stdio device is used which can be
442	  removed (for example a USB keyboard) then this option can be
443	  enabled to ensure this is handled correctly.
444
445endmenu
446
447menu "Logging"
448
449config LOG
450	bool "Enable logging support"
451	depends on DM
452	help
453	  This enables support for logging of status and debug messages. These
454	  can be displayed on the console, recorded in a memory buffer, or
455	  discarded if not needed. Logging supports various categories and
456	  levels of severity.
457
458config SPL_LOG
459	bool "Enable logging support in SPL"
460	depends on LOG
461	help
462	  This enables support for logging of status and debug messages. These
463	  can be displayed on the console, recorded in a memory buffer, or
464	  discarded if not needed. Logging supports various categories and
465	  levels of severity.
466
467config TPL_LOG
468	bool "Enable logging support in TPL"
469	depends on LOG
470	help
471	  This enables support for logging of status and debug messages. These
472	  can be displayed on the console, recorded in a memory buffer, or
473	  discarded if not needed. Logging supports various categories and
474	  levels of severity.
475
476config LOG_MAX_LEVEL
477	int "Maximum log level to record"
478	depends on LOG
479	default 5
480	help
481	  This selects the maximum log level that will be recorded. Any value
482	  higher than this will be ignored. If possible log statements below
483	  this level will be discarded at build time. Levels:
484
485	    0 - panic
486	    1 - critical
487	    2 - error
488	    3 - warning
489	    4 - note
490	    5 - info
491	    6 - detail
492	    7 - debug
493
494config SPL_LOG_MAX_LEVEL
495	int "Maximum log level to record in SPL"
496	depends on SPL_LOG
497	default 3
498	help
499	  This selects the maximum log level that will be recorded. Any value
500	  higher than this will be ignored. If possible log statements below
501	  this level will be discarded at build time. Levels:
502
503	    0 - panic
504	    1 - critical
505	    2 - error
506	    3 - warning
507	    4 - note
508	    5 - info
509	    6 - detail
510	    7 - debug
511
512config TPL_LOG_MAX_LEVEL
513	int "Maximum log level to record in TPL"
514	depends on TPL_LOG
515	default 3
516	help
517	  This selects the maximum log level that will be recorded. Any value
518	  higher than this will be ignored. If possible log statements below
519	  this level will be discarded at build time. Levels:
520
521	    0 - panic
522	    1 - critical
523	    2 - error
524	    3 - warning
525	    4 - note
526	    5 - info
527	    6 - detail
528	    7 - debug
529
530config LOG_CONSOLE
531	bool "Allow log output to the console"
532	depends on LOG
533	default y
534	help
535	  Enables a log driver which writes log records to the console.
536	  Generally the console is the serial port or LCD display. Only the
537	  log message is shown - other details like level, category, file and
538	  line number are omitted.
539
540config SPL_LOG_CONSOLE
541	bool "Allow log output to the console in SPL"
542	depends on SPL_LOG
543	default y
544	help
545	  Enables a log driver which writes log records to the console.
546	  Generally the console is the serial port or LCD display. Only the
547	  log message is shown - other details like level, category, file and
548	  line number are omitted.
549
550config TPL_LOG_CONSOLE
551	bool "Allow log output to the console in SPL"
552	depends on TPL_LOG
553	default y
554	help
555	  Enables a log driver which writes log records to the console.
556	  Generally the console is the serial port or LCD display. Only the
557	  log message is shown - other details like level, category, file and
558	  line number are omitted.
559
560config LOG_TEST
561	bool "Provide a test for logging"
562	depends on LOG
563	default y if SANDBOX
564	help
565	  This enables a 'log test' command to test logging. It is normally
566	  executed from a pytest and simply outputs logging information
567	  in various different ways to test that the logging system works
568	  correctly with various settings.
569
570config LOG_ERROR_RETURN
571	bool "Log all functions which return an error"
572	depends on LOG
573	help
574	  When an error is returned in U-Boot it is sometimes difficult to
575	  figure out the root cause. For example, reading from SPI flash may
576	  fail due to a problem in the SPI controller or due to the flash part
577	  not returning the expected information. This option changes
578	  log_ret() to log any errors it sees. With this option disabled,
579	  log_ret() is a nop.
580
581	  You can add log_ret() to all functions which return an error code.
582
583endmenu
584
585config SUPPORT_RAW_INITRD
586	bool "Enable raw initrd images"
587	help
588	  Note, defining the SUPPORT_RAW_INITRD allows user to supply
589	  kernel with raw initrd images. The syntax is slightly different, the
590	  address of the initrd must be augmented by it's size, in the following
591	  format: "<initrd address>:<initrd size>".
592
593config DEFAULT_FDT_FILE
594	string "Default fdt file"
595	help
596	  This option is used to set the default fdt file to boot OS.
597
598config MISC_INIT_R
599	bool "Execute Misc Init"
600	default y if ARCH_KEYSTONE || ARCH_SUNXI || MPC85xx
601	default y if ARCH_OMAP2PLUS && !AM33XX
602	help
603	  Enabling this option calls 'misc_init_r' function
604
605config VERSION_VARIABLE
606	bool "add U-Boot environment variable vers"
607	default n
608	help
609	  If this variable is defined, an environment variable
610	  named "ver" is created by U-Boot showing the U-Boot
611	  version as printed by the "version" command.
612	  Any change to this variable will be reverted at the
613	  next reset.
614
615config BOARD_LATE_INIT
616	bool "Execute Board late init"
617	help
618	  Sometimes board require some initialization code that might
619	  require once the actual init done, example saving board specific env,
620	  boot-modes etc. which eventually done at late.
621
622	  So this config enable the late init code with the help of board_late_init
623	  function which should defined on respective boards.
624
625config DISPLAY_CPUINFO
626	bool "Display information about the CPU during start up"
627	default y if ARC|| ARM || NIOS2 || X86 || XTENSA || M68K
628	help
629	  Display information about the CPU that U-Boot is running on
630	  when U-Boot starts up. The function print_cpuinfo() is called
631	  to do this.
632
633config DISPLAY_BOARDINFO
634	bool "Display information about the board during early start up"
635	default y if ARC || ARM || M68K || MIPS || PPC || SANDBOX || XTENSA
636	help
637	  Display information about the board that U-Boot is running on
638	  when U-Boot starts up. The board function checkboard() is called
639	  to do this.
640
641config DISPLAY_BOARDINFO_LATE
642	bool "Display information about the board during late start up"
643	help
644	  Display information about the board that U-Boot is running on after
645	  the relocation phase. The board function checkboard() is called to do
646	  this.
647
648config BOUNCE_BUFFER
649	bool "Include bounce buffer API"
650	help
651	  Some peripherals support DMA from a subset of physically
652	  addressable memory only.  To support such peripherals, the
653	  bounce buffer API uses a temporary buffer: it copies data
654	  to/from DMA regions while managing cache operations.
655
656	  A second possible use of bounce buffers is their ability to
657	  provide aligned buffers for DMA operations.
658
659menu "Start-up hooks"
660
661config ARCH_EARLY_INIT_R
662	bool "Call arch-specific init soon after relocation"
663	help
664	  With this option U-Boot will call arch_early_init_r() soon after
665	  relocation. Driver model is running by this point, and the cache
666	  is on. Note that board_early_init_r() is called first, if
667	  enabled. This can be used to set up architecture-specific devices.
668
669config ARCH_MISC_INIT
670	bool "Call arch-specific init after relocation, when console is ready"
671	help
672	  With this option U-Boot will call arch_misc_init() after
673	  relocation to allow miscellaneous arch-dependent initialisation
674	  to be performed. This function should be defined by the board
675	  and will be called after the console is set up, after relocation.
676
677config BOARD_EARLY_INIT_F
678	bool "Call board-specific init before relocation"
679	help
680	  Some boards need to perform initialisation as soon as possible
681	  after boot. With this option, U-Boot calls board_early_init_f()
682	  after driver model is ready in the pre-relocation init sequence.
683	  Note that the normal serial console is not yet set up, but the
684	  debug UART will be available if enabled.
685
686config BOARD_EARLY_INIT_R
687	bool "Call board-specific init after relocation"
688	help
689	  Some boards need to perform initialisation as directly after
690	  relocation. With this option, U-Boot calls board_early_init_r()
691	  in the post-relocation init sequence.
692
693config LAST_STAGE_INIT
694	bool "Call board-specific as last setup step"
695	help
696	  Some boards need to perform initialisation immediately before control
697	  is passed to the command-line interpreter (e.g. for initializations
698	  that depend on later phases in the init sequence). With this option,
699	  U-Boot calls last_stage_init() before the command-line interpreter is
700	  started.
701
702endmenu
703
704menu "Security support"
705
706config HASH
707	bool # "Support hashing API (SHA1, SHA256, etc.)"
708	help
709	  This provides a way to hash data in memory using various supported
710	  algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
711	  and the algorithms it supports are defined in common/hash.c. See
712	  also CMD_HASH for command-line access.
713
714config AVB_VERIFY
715	bool "Build Android Verified Boot operations"
716	depends on LIBAVB && FASTBOOT
717	depends on PARTITION_UUIDS
718	help
719	  This option enables compilation of bootloader-dependent operations,
720	  used by Android Verified Boot 2.0 library (libavb). Includes:
721	    * Helpers to process strings in order to build OS bootargs.
722	    * Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c.
723	    * Helpers to alloc/init/free avb ops.
724
725config SPL_HASH
726	bool # "Support hashing API (SHA1, SHA256, etc.)"
727	help
728	  This provides a way to hash data in memory using various supported
729	  algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
730	  and the algorithms it supports are defined in common/hash.c. See
731	  also CMD_HASH for command-line access.
732
733config TPL_HASH
734	bool # "Support hashing API (SHA1, SHA256, etc.)"
735	help
736	  This provides a way to hash data in memory using various supported
737	  algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
738	  and the algorithms it supports are defined in common/hash.c. See
739	  also CMD_HASH for command-line access.
740
741endmenu
742
743menu "Update support"
744
745config UPDATE_TFTP
746	bool "Auto-update using fitImage via TFTP"
747	depends on FIT
748	help
749	  This option allows performing update of NOR with data in fitImage
750	  sent via TFTP boot.
751
752config UPDATE_TFTP_CNT_MAX
753	int "The number of connection retries during auto-update"
754	default 0
755	depends on UPDATE_TFTP
756
757config UPDATE_TFTP_MSEC_MAX
758	int "Delay in mSec to wait for the TFTP server during auto-update"
759	default 100
760	depends on UPDATE_TFTP
761
762endmenu
763
764menu "Blob list"
765
766config BLOBLIST
767	bool "Support for a bloblist"
768	help
769	  This enables support for a bloblist in U-Boot, which can be passed
770	  from TPL to SPL to U-Boot proper (and potentially to Linux). The
771	  blob list supports multiple binary blobs of data, each with a tag,
772	  so that different U-Boot components can store data which can survive
773	  through to the next stage of the boot.
774
775config SPL_BLOBLIST
776	bool "Support for a bloblist in SPL"
777	depends on BLOBLIST
778	default y if SPL
779	help
780	  This enables a bloblist in SPL. If this is the first part of U-Boot
781	  to run, then the bloblist is set up in SPL and passed to U-Boot
782	  proper. If TPL also has a bloblist, then SPL uses the one from there.
783
784config TPL_BLOBLIST
785	bool "Support for a bloblist in TPL"
786	depends on BLOBLIST
787	default y if TPL
788	help
789	  This enables a bloblist in TPL. The bloblist is set up in TPL and
790	  passed to SPL and U-Boot proper.
791
792config BLOBLIST_SIZE
793	hex "Size of bloblist"
794	depends on BLOBLIST
795	default 0x400
796	help
797	  Sets the size of the bloblist in bytes. This must include all
798	  overhead (alignment, bloblist header, record header). The bloblist
799	  is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
800	  proper), and this sane bloblist is used for subsequent stages.
801
802config BLOBLIST_ADDR
803	hex "Address of bloblist"
804	depends on BLOBLIST
805	default 0xe000 if SANDBOX
806	help
807	  Sets the address of the bloblist, set up by the first part of U-Boot
808	  which runs. Subsequent U-Boot stages typically use the same address.
809
810endmenu
811
812source "common/spl/Kconfig"
813