xref: /openbmc/u-boot/common/Kconfig (revision 9d922450)
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 BOOTSTAGE_REPORT
22	bool "Display a detailed boot timing report before booting the OS"
23	depends on BOOTSTAGE
24	help
25	  Enable output of a boot time report just before the OS is booted.
26	  This shows how long it took U-Boot to go through each stage of the
27	  boot process. The report looks something like this:
28
29		Timer summary in microseconds:
30		       Mark    Elapsed  Stage
31			  0          0  reset
32		  3,575,678  3,575,678  board_init_f start
33		  3,575,695         17  arch_cpu_init A9
34		  3,575,777         82  arch_cpu_init done
35		  3,659,598     83,821  board_init_r start
36		  3,910,375    250,777  main_loop
37		 29,916,167 26,005,792  bootm_start
38		 30,361,327    445,160  start_kernel
39
40config BOOTSTAGE_USER_COUNT
41	hex "Number of boot ID numbers available for user use"
42	default 20
43	help
44	  This is the number of available user bootstage records.
45	  Each time you call bootstage_mark(BOOTSTAGE_ID_ALLOC, ...)
46	  a new ID will be allocated from this stash. If you exceed
47	  the limit, recording will stop.
48
49config BOOTSTAGE_FDT
50	bool "Store boot timing information in the OS device tree"
51	depends on BOOTSTAGE
52	help
53	  Stash the bootstage information in the FDT. A root 'bootstage'
54	  node is created with each bootstage id as a child. Each child
55	  has a 'name' property and either 'mark' containing the
56	  mark time in microseconds, or 'accum' containing the
57	  accumulated time for that bootstage id in microseconds.
58	  For example:
59
60		bootstage {
61			154 {
62				name = "board_init_f";
63				mark = <3575678>;
64			};
65			170 {
66				name = "lcd";
67				accum = <33482>;
68			};
69		};
70
71	  Code in the Linux kernel can find this in /proc/devicetree.
72
73config BOOTSTAGE_STASH
74	bool "Stash the boot timing information in memory before booting OS"
75	depends on BOOTSTAGE
76	help
77	  Some OSes do not support device tree. Bootstage can instead write
78	  the boot timing information in a binary format at a given address.
79	  This happens through a call to bootstage_stash(), typically in
80	  the CPU's cleanup_before_linux() function. You can use the
81	  'bootstage stash' and 'bootstage unstash' commands to do this on
82	  the command line.
83
84config BOOTSTAGE_STASH_ADDR
85	hex "Address to stash boot timing information"
86	default 0
87	help
88	  Provide an address which will not be overwritten by the OS when it
89	  starts, so that it can read this information when ready.
90
91config BOOTSTAGE_STASH_SIZE
92	hex "Size of boot timing stash region"
93	default 0x1000
94	help
95	  This should be large enough to hold the bootstage stash. A value of
96	  4096 (4KiB) is normally plenty.
97
98endmenu
99
100menu "Boot media"
101
102config NOR_BOOT
103	bool "Support for booting from NOR flash"
104	depends on NOR
105	help
106	  Enabling this will make a U-Boot binary that is capable of being
107	  booted via NOR.  In this case we will enable certain pinmux early
108	  as the ROM only partially sets up pinmux.  We also default to using
109	  NOR for environment.
110
111config NAND_BOOT
112	bool "Support for booting from NAND flash"
113	default n
114	help
115	  Enabling this will make a U-Boot binary that is capable of being
116	  booted via NAND flash. This is not a must, some SoCs need this,
117	  some not.
118
119config ONENAND_BOOT
120	bool "Support for booting from ONENAND"
121	default n
122	help
123	  Enabling this will make a U-Boot binary that is capable of being
124	  booted via ONENAND. This is not a must, some SoCs need this,
125	  some not.
126
127config QSPI_BOOT
128	bool "Support for booting from QSPI flash"
129	default n
130	help
131	  Enabling this will make a U-Boot binary that is capable of being
132	  booted via QSPI flash. This is not a must, some SoCs need this,
133	  some not.
134
135config SATA_BOOT
136	bool "Support for booting from SATA"
137	default n
138	help
139	  Enabling this will make a U-Boot binary that is capable of being
140	  booted via SATA. This is not a must, some SoCs need this,
141	  some not.
142
143config SD_BOOT
144	bool "Support for booting from SD/EMMC"
145	default n
146	help
147	  Enabling this will make a U-Boot binary that is capable of being
148	  booted via SD/EMMC. This is not a must, some SoCs need this,
149	  some not.
150
151config SPI_BOOT
152	bool "Support for booting from SPI flash"
153	default n
154	help
155	  Enabling this will make a U-Boot binary that is capable of being
156	  booted via SPI flash. This is not a must, some SoCs need this,
157	  some not.
158
159endmenu
160
161menu "Environment"
162
163if ARCH_SUNXI
164
165choice
166	prompt "Environment Device"
167	default ENV_IS_IN_MMC if ARCH_SUNXI
168
169config ENV_IS_IN_MMC
170	bool "Environment in an MMC device"
171	depends on CMD_MMC
172	help
173	  Define this if you have an MMC device which you want to use for the
174	  environment.
175
176config ENV_IS_IN_NAND
177	bool "Environment in a NAND device"
178	depends on CMD_NAND
179	help
180	  Define this if you have a NAND device which you want to use for the
181	  environment.
182
183config ENV_IS_IN_UBI
184	bool "Environment in a UBI volume"
185	depends on CMD_UBI
186	depends on CMD_MTDPARTS
187	help
188	  Define this if you have a UBI volume which you want to use for the
189	  environment.
190
191config ENV_IS_NOWHERE
192	bool "Environment is not stored"
193	help
194	  Define this if you don't want to or can't have an environment stored
195	  on a storage medium
196
197endchoice
198
199config ENV_OFFSET
200	hex "Environment Offset"
201	depends on !ENV_IS_IN_UBI
202	depends on !ENV_IS_NOWHERE
203	default 0x88000 if ARCH_SUNXI
204	help
205	  Offset from the start of the device (or partition)
206
207config ENV_SIZE
208	hex "Environment Size"
209	depends on !ENV_IS_NOWHERE
210	default 0x20000 if ARCH_SUNXI
211	help
212	  Size of the environment storage area
213
214config ENV_UBI_PART
215	string "UBI partition name"
216	depends on ENV_IS_IN_UBI
217	help
218	  MTD partition containing the UBI device
219
220config ENV_UBI_VOLUME
221	string "UBI volume name"
222	depends on ENV_IS_IN_UBI
223	help
224	  Name of the volume that you want to store the environment in.
225
226endif
227
228endmenu
229
230config BOOTDELAY
231	int "delay in seconds before automatically booting"
232	default 2
233	depends on AUTOBOOT
234	help
235	  Delay before automatically running bootcmd;
236	  set to 0 to autoboot with no delay, but you can stop it by key input.
237	  set to -1 to disable autoboot.
238	  set to -2 to autoboot with no delay and not check for abort
239
240	  See doc/README.autoboot for details.
241
242menu "Console"
243
244config MENU
245	bool
246	help
247	  This is the library functionality to provide a text-based menu of
248	  choices for the user to make choices with.
249
250config CONSOLE_RECORD
251	bool "Console recording"
252	help
253	  This provides a way to record console output (and provide console
254	  input) through circular buffers. This is mostly useful for testing.
255	  Console output is recorded even when the console is silent.
256	  To enable console recording, call console_record_reset_enable()
257	  from your code.
258
259config CONSOLE_RECORD_OUT_SIZE
260	hex "Output buffer size"
261	depends on CONSOLE_RECORD
262	default 0x400 if CONSOLE_RECORD
263	help
264	  Set the size of the console output buffer. When this fills up, no
265	  more data will be recorded until some is removed. The buffer is
266	  allocated immediately after the malloc() region is ready.
267
268config CONSOLE_RECORD_IN_SIZE
269	hex "Input buffer size"
270	depends on CONSOLE_RECORD
271	default 0x100 if CONSOLE_RECORD
272	help
273	  Set the size of the console input buffer. When this contains data,
274	  tstc() and getc() will use this in preference to real device input.
275	  The buffer is allocated immediately after the malloc() region is
276	  ready.
277
278config IDENT_STRING
279	string "Board specific string to be added to uboot version string"
280	help
281	  This options adds the board specific name to u-boot version.
282
283config SILENT_CONSOLE
284	bool "Support a silent console"
285	help
286	  This option allows the console to be silenced, meaning that no
287	  output will appear on the console devices. This is controlled by
288	  setting the environment vaariable 'silent' to a non-empty value.
289	  Note this also silences the console when booting Linux.
290
291	  When the console is set up, the variable is checked, and the
292	  GD_FLG_SILENT flag is set. Changing the environment variable later
293	  will update the flag.
294
295config SILENT_U_BOOT_ONLY
296	bool "Only silence the U-Boot console"
297	depends on SILENT_CONSOLE
298	help
299	  Normally when the U-Boot console is silenced, Linux's console is
300	  also silenced (assuming the board boots into Linux). This option
301	  allows the linux console to operate normally, even if U-Boot's
302	  is silenced.
303
304config SILENT_CONSOLE_UPDATE_ON_SET
305	bool "Changes to the 'silent' environment variable update immediately"
306	depends on SILENT_CONSOLE
307	default y if SILENT_CONSOLE
308	help
309	  When the 'silent' environment variable is changed, update the
310	  console silence flag immediately. This allows 'setenv' to be used
311	  to silence or un-silence the console.
312
313	  The effect is that any change to the variable will affect the
314	  GD_FLG_SILENT flag.
315
316config SILENT_CONSOLE_UPDATE_ON_RELOC
317	bool "Allow flags to take effect on relocation"
318	depends on SILENT_CONSOLE
319	help
320	  In some cases the environment is not available until relocation
321	  (e.g. NAND). This option makes the value of the 'silent'
322	  environment variable take effect at relocation.
323
324config PRE_CONSOLE_BUFFER
325	bool "Buffer characters before the console is available"
326	help
327	  Prior to the console being initialised (i.e. serial UART
328	  initialised etc) all console output is silently discarded.
329	  Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
330	  buffer any console messages prior to the console being
331	  initialised to a buffer. The buffer is a circular buffer, so
332	  if it overflows, earlier output is discarded.
333
334	  Note that this is not currently supported in SPL. It would be
335	  useful to be able to share the pre-console buffer with SPL.
336
337config PRE_CON_BUF_SZ
338	int "Sets the size of the pre-console buffer"
339	depends on PRE_CONSOLE_BUFFER
340	default 4096
341	help
342	  The size of the pre-console buffer affects how much console output
343	  can be held before it overflows and starts discarding earlier
344	  output. Normally there is very little output at this early stage,
345	  unless debugging is enabled, so allow enough for ~10 lines of
346	  text.
347
348	  This is a useful feature if you are using a video console and
349	  want to see the full boot output on the console. Without this
350	  option only the post-relocation output will be displayed.
351
352config PRE_CON_BUF_ADDR
353	hex "Address of the pre-console buffer"
354	depends on PRE_CONSOLE_BUFFER
355	default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
356	default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
357	help
358	  This sets the start address of the pre-console buffer. This must
359	  be in available memory and is accessed before relocation and
360	  possibly before DRAM is set up. Therefore choose an address
361	  carefully.
362
363	  We should consider removing this option and allocating the memory
364	  in board_init_f_init_reserve() instead.
365
366config CONSOLE_MUX
367	bool "Enable console multiplexing"
368	default y if DM_VIDEO || VIDEO || LCD
369	help
370	  This allows multiple devices to be used for each console 'file'.
371	  For example, stdout can be set to go to serial and video.
372	  Similarly, stdin can be set to come from serial and keyboard.
373	  Input can be provided from either source. Console multiplexing
374	  adds a small amount of size to U-Boot.  Changes to the environment
375	  variables stdout, stdin and stderr will take effect immediately.
376
377config SYS_CONSOLE_IS_IN_ENV
378	bool "Select console devices from the environment"
379	default y if CONSOLE_MUX
380	help
381	  This allows multiple input/output devices to be set at boot time.
382	  For example, if stdout is set to "serial,video" then output will
383	  be sent to both the serial and video devices on boot. The
384	  environment variables can be updated after boot to change the
385	  input/output devices.
386
387config SYS_CONSOLE_OVERWRITE_ROUTINE
388	bool "Allow board control over console overwriting"
389	help
390	  If this is enabled, and the board-specific function
391	  overwrite_console() returns 1, the stdin, stderr and stdout are
392	  switched to the serial port, else the settings in the environment
393	  are used. If this is not enabled, the console will not be switched
394	  to serial.
395
396config SYS_CONSOLE_ENV_OVERWRITE
397	bool "Update environment variables during console init"
398	help
399	  The console environment variables (stdout, stdin, stderr) can be
400	  used to determine the correct console devices on start-up. This
401	  option writes the console devices to these variables on console
402	  start-up (after relocation). This causes the environment to be
403	  updated to match the console devices actually chosen.
404
405config SYS_CONSOLE_INFO_QUIET
406	bool "Don't display the console devices on boot"
407	help
408	  Normally U-Boot displays the current settings for stdout, stdin
409	  and stderr on boot when the post-relocation console is set up.
410	  Enable this option to supress this output. It can be obtained by
411	  calling stdio_print_current_devices() from board code.
412
413config SYS_STDIO_DEREGISTER
414	bool "Allow deregistering stdio devices"
415	default y if USB_KEYBOARD
416	help
417	  Generally there is no need to deregister stdio devices since they
418	  are never deactivated. But if a stdio device is used which can be
419	  removed (for example a USB keyboard) then this option can be
420	  enabled to ensure this is handled correctly.
421
422endmenu
423
424config DEFAULT_FDT_FILE
425	string "Default fdt file"
426	help
427	  This option is used to set the default fdt file to boot OS.
428
429config VERSION_VARIABLE
430	bool "add U-Boot environment variable vers"
431	default n
432	help
433	  If this variable is defined, an environment variable
434	  named "ver" is created by U-Boot showing the U-Boot
435	  version as printed by the "version" command.
436	  Any change to this variable will be reverted at the
437	  next reset.
438
439config BOARD_LATE_INIT
440	bool
441	help
442	  Sometimes board require some initialization code that might
443	  require once the actual init done, example saving board specific env,
444	  boot-modes etc. which eventually done at late.
445
446	  So this config enable the late init code with the help of board_late_init
447	  function which should defined on respective boards.
448
449config DISPLAY_CPUINFO
450	bool "Display information about the CPU during start up"
451	default y if ARM || NIOS2 || X86 || XTENSA || MPC5xxx
452	help
453	  Display information about the CPU that U-Boot is running on
454	  when U-Boot starts up. The function print_cpuinfo() is called
455	  to do this.
456
457config DISPLAY_BOARDINFO
458	bool "Display information about the board during start up"
459	default y if ARM || M68K || MIPS || PPC || XTENSA
460	help
461	  Display information about the board that U-Boot is running on
462	  when U-Boot starts up. The board function checkboard() is called
463	  to do this.
464
465menu "Start-up hooks"
466
467config ARCH_EARLY_INIT_R
468	bool "Call arch-specific init soon after relocation"
469	default y if X86
470	help
471	  With this option U-Boot will call arch_early_init_r() soon after
472	  relocation. Driver model is running by this point, and the cache
473	  is on. Note that board_early_init_r() is called first, if
474	  enabled. This can be used to set up architecture-specific devices.
475
476config ARCH_MISC_INIT
477	bool "Call arch-specific init after relocation, when console is ready"
478	help
479	  With this option U-Boot will call arch_misc_init() after
480	  relocation to allow miscellaneous arch-dependent initialisation
481	  to be performed. This function should be defined by the board
482	  and will be called after the console is set up, after relocaiton.
483
484config BOARD_EARLY_INIT_F
485	bool "Call board-specific init before relocation"
486	default y if X86
487	help
488	  Some boards need to perform initialisation as soon as possible
489	  after boot. With this option, U-Boot calls board_early_init_f()
490	  after driver model is ready in the pre-relocation init sequence.
491	  Note that the normal serial console is not yet set up, but the
492	  debug UART will be available if enabled.
493
494endmenu
495
496menu "Security support"
497
498config HASH
499	bool # "Support hashing API (SHA1, SHA256, etc.)"
500	help
501	  This provides a way to hash data in memory using various supported
502	  algorithms (such as SHA1, MD5, CRC32). The API is defined in hash.h
503	  and the algorithms it supports are defined in common/hash.c. See
504	  also CMD_HASH for command-line access.
505
506endmenu
507
508source "common/spl/Kconfig"
509