xref: /openbmc/linux/arch/xtensa/Kconfig (revision cde2f928)
1# SPDX-License-Identifier: GPL-2.0
2config XTENSA
3	def_bool y
4	select ARCH_32BIT_OFF_T
5	select ARCH_HAS_BINFMT_FLAT if !MMU
6	select ARCH_HAS_CURRENT_STACK_POINTER
7	select ARCH_HAS_DEBUG_VM_PGTABLE
8	select ARCH_HAS_DMA_PREP_COHERENT if MMU
9	select ARCH_HAS_GCOV_PROFILE_ALL
10	select ARCH_HAS_KCOV
11	select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU
12	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU
13	select ARCH_HAS_DMA_SET_UNCACHED if MMU
14	select ARCH_HAS_STRNCPY_FROM_USER if !KASAN
15	select ARCH_HAS_STRNLEN_USER
16	select ARCH_USE_MEMTEST
17	select ARCH_USE_QUEUED_RWLOCKS
18	select ARCH_USE_QUEUED_SPINLOCKS
19	select ARCH_WANT_IPC_PARSE_VERSION
20	select BUILDTIME_TABLE_SORT
21	select CLONE_BACKWARDS
22	select COMMON_CLK
23	select DMA_NONCOHERENT_MMAP if MMU
24	select GENERIC_ATOMIC64
25	select GENERIC_IRQ_SHOW
26	select GENERIC_LIB_CMPDI2
27	select GENERIC_LIB_MULDI3
28	select GENERIC_LIB_UCMPDI2
29	select GENERIC_PCI_IOMAP
30	select GENERIC_SCHED_CLOCK
31	select HAVE_ARCH_AUDITSYSCALL
32	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
33	select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
34	select HAVE_ARCH_KCSAN
35	select HAVE_ARCH_SECCOMP_FILTER
36	select HAVE_ARCH_TRACEHOOK
37	select HAVE_ASM_MODVERSIONS
38	select HAVE_CONTEXT_TRACKING_USER
39	select HAVE_DEBUG_KMEMLEAK
40	select HAVE_DMA_CONTIGUOUS
41	select HAVE_EXIT_THREAD
42	select HAVE_FUNCTION_TRACER
43	select HAVE_GCC_PLUGINS if GCC_VERSION >= 120000
44	select HAVE_HW_BREAKPOINT if PERF_EVENTS
45	select HAVE_IRQ_TIME_ACCOUNTING
46	select HAVE_PCI
47	select HAVE_PERF_EVENTS
48	select HAVE_STACKPROTECTOR
49	select HAVE_SYSCALL_TRACEPOINTS
50	select HAVE_VIRT_CPU_ACCOUNTING_GEN
51	select IRQ_DOMAIN
52	select LOCK_MM_AND_FIND_VMA
53	select MODULES_USE_ELF_RELA
54	select PERF_USE_VMALLOC
55	select TRACE_IRQFLAGS_SUPPORT
56	help
57	  Xtensa processors are 32-bit RISC machines designed by Tensilica
58	  primarily for embedded systems.  These processors are both
59	  configurable and extensible.  The Linux port to the Xtensa
60	  architecture supports all processor configurations and extensions,
61	  with reasonable minimum requirements.  The Xtensa Linux project has
62	  a home page at <http://www.linux-xtensa.org/>.
63
64config GENERIC_HWEIGHT
65	def_bool y
66
67config ARCH_HAS_ILOG2_U32
68	def_bool n
69
70config ARCH_HAS_ILOG2_U64
71	def_bool n
72
73config NO_IOPORT_MAP
74	def_bool n
75
76config HZ
77	int
78	default 100
79
80config LOCKDEP_SUPPORT
81	def_bool y
82
83config STACKTRACE_SUPPORT
84	def_bool y
85
86config MMU
87	def_bool n
88	select PFAULT
89
90config HAVE_XTENSA_GPIO32
91	def_bool n
92
93config KASAN_SHADOW_OFFSET
94	hex
95	default 0x6e400000
96
97config CPU_BIG_ENDIAN
98	def_bool $(success,test "$(shell,echo __XTENSA_EB__ | $(CC) -E -P -)" = 1)
99
100config CPU_LITTLE_ENDIAN
101	def_bool !CPU_BIG_ENDIAN
102
103config CC_HAVE_CALL0_ABI
104	def_bool $(success,test "$(shell,echo __XTENSA_CALL0_ABI__ | $(CC) -mabi=call0 -E -P - 2>/dev/null)" = 1)
105
106menu "Processor type and features"
107
108choice
109	prompt "Xtensa Processor Configuration"
110	default XTENSA_VARIANT_FSF
111
112config XTENSA_VARIANT_FSF
113	bool "fsf - default (not generic) configuration"
114	select MMU
115
116config XTENSA_VARIANT_DC232B
117	bool "dc232b - Diamond 232L Standard Core Rev.B (LE)"
118	select MMU
119	select HAVE_XTENSA_GPIO32
120	help
121	  This variant refers to Tensilica's Diamond 232L Standard core Rev.B (LE).
122
123config XTENSA_VARIANT_DC233C
124	bool "dc233c - Diamond 233L Standard Core Rev.C (LE)"
125	select MMU
126	select HAVE_XTENSA_GPIO32
127	help
128	  This variant refers to Tensilica's Diamond 233L Standard core Rev.C (LE).
129
130config XTENSA_VARIANT_CUSTOM
131	bool "Custom Xtensa processor configuration"
132	select HAVE_XTENSA_GPIO32
133	help
134	  Select this variant to use a custom Xtensa processor configuration.
135	  You will be prompted for a processor variant CORENAME.
136endchoice
137
138config XTENSA_VARIANT_CUSTOM_NAME
139	string "Xtensa Processor Custom Core Variant Name"
140	depends on XTENSA_VARIANT_CUSTOM
141	help
142	  Provide the name of a custom Xtensa processor variant.
143	  This CORENAME selects arch/xtensa/variant/CORENAME.
144	  Don't forget you have to select MMU if you have one.
145
146config XTENSA_VARIANT_NAME
147	string
148	default "dc232b"			if XTENSA_VARIANT_DC232B
149	default "dc233c"			if XTENSA_VARIANT_DC233C
150	default "fsf"				if XTENSA_VARIANT_FSF
151	default XTENSA_VARIANT_CUSTOM_NAME	if XTENSA_VARIANT_CUSTOM
152
153config XTENSA_VARIANT_MMU
154	bool "Core variant has a Full MMU (TLB, Pages, Protection, etc)"
155	depends on XTENSA_VARIANT_CUSTOM
156	default y
157	select MMU
158	help
159	  Build a Conventional Kernel with full MMU support,
160	  ie: it supports a TLB with auto-loading, page protection.
161
162config XTENSA_VARIANT_HAVE_PERF_EVENTS
163	bool "Core variant has Performance Monitor Module"
164	depends on XTENSA_VARIANT_CUSTOM
165	default n
166	help
167	  Enable if core variant has Performance Monitor Module with
168	  External Registers Interface.
169
170	  If unsure, say N.
171
172config XTENSA_FAKE_NMI
173	bool "Treat PMM IRQ as NMI"
174	depends on XTENSA_VARIANT_HAVE_PERF_EVENTS
175	default n
176	help
177	  If PMM IRQ is the only IRQ at EXCM level it is safe to
178	  treat it as NMI, which improves accuracy of profiling.
179
180	  If there are other interrupts at or above PMM IRQ priority level
181	  but not above the EXCM level, PMM IRQ still may be treated as NMI,
182	  but only if these IRQs are not used. There will be a build warning
183	  saying that this is not safe, and a bugcheck if one of these IRQs
184	  actually fire.
185
186	  If unsure, say N.
187
188config PFAULT
189	bool "Handle protection faults" if EXPERT && !MMU
190	default y
191	help
192	  Handle protection faults. MMU configurations must enable it.
193	  noMMU configurations may disable it if used memory map never
194	  generates protection faults or faults are always fatal.
195
196	  If unsure, say Y.
197
198config XTENSA_UNALIGNED_USER
199	bool "Unaligned memory access in user space"
200	help
201	  The Xtensa architecture currently does not handle unaligned
202	  memory accesses in hardware but through an exception handler.
203	  Per default, unaligned memory accesses are disabled in user space.
204
205	  Say Y here to enable unaligned memory access in user space.
206
207config XTENSA_LOAD_STORE
208	bool "Load/store exception handler for memory only readable with l32"
209	help
210	  The Xtensa architecture only allows reading memory attached to its
211	  instruction bus with l32r and l32i instructions, all other
212	  instructions raise an exception with the LoadStoreErrorCause code.
213	  This makes it hard to use some configurations, e.g. store string
214	  literals in FLASH memory attached to the instruction bus.
215
216	  Say Y here to enable exception handler that allows transparent
217	  byte and 2-byte access to memory attached to instruction bus.
218
219config HAVE_SMP
220	bool "System Supports SMP (MX)"
221	depends on XTENSA_VARIANT_CUSTOM
222	select XTENSA_MX
223	help
224	  This option is used to indicate that the system-on-a-chip (SOC)
225	  supports Multiprocessing. Multiprocessor support implemented above
226	  the CPU core definition and currently needs to be selected manually.
227
228	  Multiprocessor support is implemented with external cache and
229	  interrupt controllers.
230
231	  The MX interrupt distributer adds Interprocessor Interrupts
232	  and causes the IRQ numbers to be increased by 4 for devices
233	  like the open cores ethernet driver and the serial interface.
234
235	  You still have to select "Enable SMP" to enable SMP on this SOC.
236
237config SMP
238	bool "Enable Symmetric multi-processing support"
239	depends on HAVE_SMP
240	select GENERIC_SMP_IDLE_THREAD
241	help
242	  Enabled SMP Software; allows more than one CPU/CORE
243	  to be activated during startup.
244
245config NR_CPUS
246	depends on SMP
247	int "Maximum number of CPUs (2-32)"
248	range 2 32
249	default "4"
250
251config HOTPLUG_CPU
252	bool "Enable CPU hotplug support"
253	depends on SMP
254	help
255	  Say Y here to allow turning CPUs off and on. CPUs can be
256	  controlled through /sys/devices/system/cpu.
257
258	  Say N if you want to disable CPU hotplug.
259
260config SECONDARY_RESET_VECTOR
261	bool "Secondary cores use alternative reset vector"
262	default y
263	depends on HAVE_SMP
264	help
265	  Secondary cores may be configured to use alternative reset vector,
266	  or all cores may use primary reset vector.
267	  Say Y here to supply handler for the alternative reset location.
268
269config FAST_SYSCALL_XTENSA
270	bool "Enable fast atomic syscalls"
271	default n
272	help
273	  fast_syscall_xtensa is a syscall that can make atomic operations
274	  on UP kernel when processor has no s32c1i support.
275
276	  This syscall is deprecated. It may have issues when called with
277	  invalid arguments. It is provided only for backwards compatibility.
278	  Only enable it if your userspace software requires it.
279
280	  If unsure, say N.
281
282config FAST_SYSCALL_SPILL_REGISTERS
283	bool "Enable spill registers syscall"
284	default n
285	help
286	  fast_syscall_spill_registers is a syscall that spills all active
287	  register windows of a calling userspace task onto its stack.
288
289	  This syscall is deprecated. It may have issues when called with
290	  invalid arguments. It is provided only for backwards compatibility.
291	  Only enable it if your userspace software requires it.
292
293	  If unsure, say N.
294
295choice
296	prompt "Kernel ABI"
297	default KERNEL_ABI_DEFAULT
298	help
299	  Select ABI for the kernel code. This ABI is independent of the
300	  supported userspace ABI and any combination of the
301	  kernel/userspace ABI is possible and should work.
302
303	  In case both kernel and userspace support only call0 ABI
304	  all register windows support code will be omitted from the
305	  build.
306
307	  If unsure, choose the default ABI.
308
309config KERNEL_ABI_DEFAULT
310	bool "Default ABI"
311	help
312	  Select this option to compile kernel code with the default ABI
313	  selected for the toolchain.
314	  Normally cores with windowed registers option use windowed ABI and
315	  cores without it use call0 ABI.
316
317config KERNEL_ABI_CALL0
318	bool "Call0 ABI" if CC_HAVE_CALL0_ABI
319	help
320	  Select this option to compile kernel code with call0 ABI even with
321	  toolchain that defaults to windowed ABI.
322	  When this option is not selected the default toolchain ABI will
323	  be used for the kernel code.
324
325endchoice
326
327config USER_ABI_CALL0
328	bool
329
330choice
331	prompt "Userspace ABI"
332	default USER_ABI_DEFAULT
333	help
334	  Select supported userspace ABI.
335
336	  If unsure, choose the default ABI.
337
338config USER_ABI_DEFAULT
339	bool "Default ABI only"
340	help
341	  Assume default userspace ABI. For XEA2 cores it is windowed ABI.
342	  call0 ABI binaries may be run on such kernel, but signal delivery
343	  will not work correctly for them.
344
345config USER_ABI_CALL0_ONLY
346	bool "Call0 ABI only"
347	select USER_ABI_CALL0
348	help
349	  Select this option to support only call0 ABI in userspace.
350	  Windowed ABI binaries will crash with a segfault caused by
351	  an illegal instruction exception on the first 'entry' opcode.
352
353	  Choose this option if you're planning to run only user code
354	  built with call0 ABI.
355
356config USER_ABI_CALL0_PROBE
357	bool "Support both windowed and call0 ABI by probing"
358	select USER_ABI_CALL0
359	help
360	  Select this option to support both windowed and call0 userspace
361	  ABIs. When enabled all processes are started with PS.WOE disabled
362	  and a fast user exception handler for an illegal instruction is
363	  used to turn on PS.WOE bit on the first 'entry' opcode executed by
364	  the userspace.
365
366	  This option should be enabled for the kernel that must support
367	  both call0 and windowed ABIs in userspace at the same time.
368
369	  Note that Xtensa ISA does not guarantee that entry opcode will
370	  raise an illegal instruction exception on cores with XEA2 when
371	  PS.WOE is disabled, check whether the target core supports it.
372
373endchoice
374
375endmenu
376
377config XTENSA_CALIBRATE_CCOUNT
378	def_bool n
379	help
380	  On some platforms (XT2000, for example), the CPU clock rate can
381	  vary.  The frequency can be determined, however, by measuring
382	  against a well known, fixed frequency, such as an UART oscillator.
383
384config SERIAL_CONSOLE
385	def_bool n
386
387config PLATFORM_HAVE_XIP
388	def_bool n
389
390menu "Platform options"
391
392choice
393	prompt "Xtensa System Type"
394	default XTENSA_PLATFORM_ISS
395
396config XTENSA_PLATFORM_ISS
397	bool "ISS"
398	select XTENSA_CALIBRATE_CCOUNT
399	select SERIAL_CONSOLE
400	help
401	  ISS is an acronym for Tensilica's Instruction Set Simulator.
402
403config XTENSA_PLATFORM_XT2000
404	bool "XT2000"
405	help
406	  XT2000 is the name of Tensilica's feature-rich emulation platform.
407	  This hardware is capable of running a full Linux distribution.
408
409config XTENSA_PLATFORM_XTFPGA
410	bool "XTFPGA"
411	select ETHOC if ETHERNET
412	select PLATFORM_WANT_DEFAULT_MEM if !MMU
413	select SERIAL_CONSOLE
414	select XTENSA_CALIBRATE_CCOUNT
415	select PLATFORM_HAVE_XIP
416	help
417	  XTFPGA is the name of Tensilica board family (LX60, LX110, LX200, ML605).
418	  This hardware is capable of running a full Linux distribution.
419
420endchoice
421
422config PLATFORM_NR_IRQS
423	int
424	default 3 if XTENSA_PLATFORM_XT2000
425	default 0
426
427config XTENSA_CPU_CLOCK
428	int "CPU clock rate [MHz]"
429	depends on !XTENSA_CALIBRATE_CCOUNT
430	default 16
431
432config GENERIC_CALIBRATE_DELAY
433	bool "Auto calibration of the BogoMIPS value"
434	help
435	  The BogoMIPS value can easily be derived from the CPU frequency.
436
437config CMDLINE_BOOL
438	bool "Default bootloader kernel arguments"
439
440config CMDLINE
441	string "Initial kernel command string"
442	depends on CMDLINE_BOOL
443	default "console=ttyS0,38400 root=/dev/ram"
444	help
445	  On some architectures (EBSA110 and CATS), there is currently no way
446	  for the boot loader to pass arguments to the kernel. For these
447	  architectures, you should supply some command-line options at build
448	  time by entering them here. As a minimum, you should specify the
449	  memory size and the root device (e.g., mem=64M root=/dev/nfs).
450
451config USE_OF
452	bool "Flattened Device Tree support"
453	select OF
454	select OF_EARLY_FLATTREE
455	help
456	  Include support for flattened device tree machine descriptions.
457
458config BUILTIN_DTB_SOURCE
459	string "DTB to build into the kernel image"
460	depends on OF
461
462config PARSE_BOOTPARAM
463	bool "Parse bootparam block"
464	default y
465	help
466	  Parse parameters passed to the kernel from the bootloader. It may
467	  be disabled if the kernel is known to run without the bootloader.
468
469	  If unsure, say Y.
470
471choice
472	prompt "Semihosting interface"
473	default XTENSA_SIMCALL_ISS
474	depends on XTENSA_PLATFORM_ISS
475	help
476	  Choose semihosting interface that will be used for serial port,
477	  block device and networking.
478
479config XTENSA_SIMCALL_ISS
480	bool "simcall"
481	help
482	  Use simcall instruction. simcall is only available on simulators,
483	  it does nothing on hardware.
484
485config XTENSA_SIMCALL_GDBIO
486	bool "GDBIO"
487	help
488	  Use break instruction. It is available on real hardware when GDB
489	  is attached to it via JTAG.
490
491endchoice
492
493config BLK_DEV_SIMDISK
494	tristate "Host file-based simulated block device support"
495	default n
496	depends on XTENSA_PLATFORM_ISS && BLOCK
497	help
498	  Create block devices that map to files in the host file system.
499	  Device binding to host file may be changed at runtime via proc
500	  interface provided the device is not in use.
501
502config BLK_DEV_SIMDISK_COUNT
503	int "Number of host file-based simulated block devices"
504	range 1 10
505	depends on BLK_DEV_SIMDISK
506	default 2
507	help
508	  This is the default minimal number of created block devices.
509	  Kernel/module parameter 'simdisk_count' may be used to change this
510	  value at runtime. More file names (but no more than 10) may be
511	  specified as parameters, simdisk_count grows accordingly.
512
513config SIMDISK0_FILENAME
514	string "Host filename for the first simulated device"
515	depends on BLK_DEV_SIMDISK = y
516	default ""
517	help
518	  Attach a first simdisk to a host file. Conventionally, this file
519	  contains a root file system.
520
521config SIMDISK1_FILENAME
522	string "Host filename for the second simulated device"
523	depends on BLK_DEV_SIMDISK = y && BLK_DEV_SIMDISK_COUNT != 1
524	default ""
525	help
526	  Another simulated disk in a host file for a buildroot-independent
527	  storage.
528
529config XTFPGA_LCD
530	bool "Enable XTFPGA LCD driver"
531	depends on XTENSA_PLATFORM_XTFPGA
532	default n
533	help
534	  There's a 2x16 LCD on most of XTFPGA boards, kernel may output
535	  progress messages there during bootup/shutdown. It may be useful
536	  during board bringup.
537
538	  If unsure, say N.
539
540config XTFPGA_LCD_BASE_ADDR
541	hex "XTFPGA LCD base address"
542	depends on XTFPGA_LCD
543	default "0x0d0c0000"
544	help
545	  Base address of the LCD controller inside KIO region.
546	  Different boards from XTFPGA family have LCD controller at different
547	  addresses. Please consult prototyping user guide for your board for
548	  the correct address. Wrong address here may lead to hardware lockup.
549
550config XTFPGA_LCD_8BIT_ACCESS
551	bool "Use 8-bit access to XTFPGA LCD"
552	depends on XTFPGA_LCD
553	default n
554	help
555	  LCD may be connected with 4- or 8-bit interface, 8-bit access may
556	  only be used with 8-bit interface. Please consult prototyping user
557	  guide for your board for the correct interface width.
558
559comment "Kernel memory layout"
560
561config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
562	bool "Initialize Xtensa MMU inside the Linux kernel code"
563	depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B
564	default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM
565	help
566	  Earlier version initialized the MMU in the exception vector
567	  before jumping to _startup in head.S and had an advantage that
568	  it was possible to place a software breakpoint at 'reset' and
569	  then enter your normal kernel breakpoints once the MMU was mapped
570	  to the kernel mappings (0XC0000000).
571
572	  This unfortunately won't work for U-Boot and likely also won't
573	  work for using KEXEC to have a hot kernel ready for doing a
574	  KDUMP.
575
576	  So now the MMU is initialized in head.S but it's necessary to
577	  use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup.
578	  xt-gdb can't place a Software Breakpoint in the  0XD region prior
579	  to mapping the MMU and after mapping even if the area of low memory
580	  was mapped gdb wouldn't remove the breakpoint on hitting it as the
581	  PC wouldn't match. Since Hardware Breakpoints are recommended for
582	  Linux configurations it seems reasonable to just assume they exist
583	  and leave this older mechanism for unfortunate souls that choose
584	  not to follow Tensilica's recommendation.
585
586	  Selecting this will cause U-Boot to set the KERNEL Load and Entry
587	  address at 0x00003000 instead of the mapped std of 0xD0003000.
588
589	  If in doubt, say Y.
590
591config XIP_KERNEL
592	bool "Kernel Execute-In-Place from ROM"
593	depends on PLATFORM_HAVE_XIP
594	help
595	  Execute-In-Place allows the kernel to run from non-volatile storage
596	  directly addressable by the CPU, such as NOR flash. This saves RAM
597	  space since the text section of the kernel is not loaded from flash
598	  to RAM. Read-write sections, such as the data section and stack,
599	  are still copied to RAM. The XIP kernel is not compressed since
600	  it has to run directly from flash, so it will take more space to
601	  store it. The flash address used to link the kernel object files,
602	  and for storing it, is configuration dependent. Therefore, if you
603	  say Y here, you must know the proper physical address where to
604	  store the kernel image depending on your own flash memory usage.
605
606	  Also note that the make target becomes "make xipImage" rather than
607	  "make Image" or "make uImage". The final kernel binary to put in
608	  ROM memory will be arch/xtensa/boot/xipImage.
609
610	  If unsure, say N.
611
612config MEMMAP_CACHEATTR
613	hex "Cache attributes for the memory address space"
614	depends on !MMU
615	default 0x22222222
616	help
617	  These cache attributes are set up for noMMU systems. Each hex digit
618	  specifies cache attributes for the corresponding 512MB memory
619	  region: bits 0..3 -- for addresses 0x00000000..0x1fffffff,
620	  bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on.
621
622	  Cache attribute values are specific for the MMU type.
623	  For region protection MMUs:
624	    1: WT cached,
625	    2: cache bypass,
626	    4: WB cached,
627	    f: illegal.
628	  For full MMU:
629	    bit 0: executable,
630	    bit 1: writable,
631	    bits 2..3:
632	      0: cache bypass,
633	      1: WB cache,
634	      2: WT cache,
635	      3: special (c and e are illegal, f is reserved).
636	  For MPU:
637	    0: illegal,
638	    1: WB cache,
639	    2: WB, no-write-allocate cache,
640	    3: WT cache,
641	    4: cache bypass.
642
643config KSEG_PADDR
644	hex "Physical address of the KSEG mapping"
645	depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU
646	default 0x00000000
647	help
648	  This is the physical address where KSEG is mapped. Please refer to
649	  the chosen KSEG layout help for the required address alignment.
650	  Unpacked kernel image (including vectors) must be located completely
651	  within KSEG.
652	  Physical memory below this address is not available to linux.
653
654	  If unsure, leave the default value here.
655
656config KERNEL_VIRTUAL_ADDRESS
657	hex "Kernel virtual address"
658	depends on MMU && XIP_KERNEL
659	default 0xd0003000
660	help
661	  This is the virtual address where the XIP kernel is mapped.
662	  XIP kernel may be mapped into KSEG or KIO region, virtual address
663	  provided here must match kernel load address provided in
664	  KERNEL_LOAD_ADDRESS.
665
666config KERNEL_LOAD_ADDRESS
667	hex "Kernel load address"
668	default 0x60003000 if !MMU
669	default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
670	default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
671	help
672	  This is the address where the kernel is loaded.
673	  It is virtual address for MMUv2 configurations and physical address
674	  for all other configurations.
675
676	  If unsure, leave the default value here.
677
678choice
679	prompt "Relocatable vectors location"
680	default XTENSA_VECTORS_IN_TEXT
681	help
682	  Choose whether relocatable vectors are merged into the kernel .text
683	  or placed separately at runtime. This option does not affect
684	  configurations without VECBASE register where vectors are always
685	  placed at their hardware-defined locations.
686
687config XTENSA_VECTORS_IN_TEXT
688	bool "Merge relocatable vectors into kernel text"
689	depends on !MTD_XIP
690	help
691	  This option puts relocatable vectors into the kernel .text section
692	  with proper alignment.
693	  This is a safe choice for most configurations.
694
695config XTENSA_VECTORS_SEPARATE
696	bool "Put relocatable vectors at fixed address"
697	help
698	  This option puts relocatable vectors at specific virtual address.
699	  Vectors are merged with the .init data in the kernel image and
700	  are copied into their designated location during kernel startup.
701	  Use it to put vectors into IRAM or out of FLASH on kernels with
702	  XIP-aware MTD support.
703
704endchoice
705
706config VECTORS_ADDR
707	hex "Kernel vectors virtual address"
708	default 0x00000000
709	depends on XTENSA_VECTORS_SEPARATE
710	help
711	  This is the virtual address of the (relocatable) vectors base.
712	  It must be within KSEG if MMU is used.
713
714config XIP_DATA_ADDR
715	hex "XIP kernel data virtual address"
716	depends on XIP_KERNEL
717	default 0x00000000
718	help
719	  This is the virtual address where XIP kernel data is copied.
720	  It must be within KSEG if MMU is used.
721
722config PLATFORM_WANT_DEFAULT_MEM
723	def_bool n
724
725config DEFAULT_MEM_START
726	hex
727	prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM
728	default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM
729	default 0x00000000
730	help
731	  This is the base address used for both PAGE_OFFSET and PHYS_OFFSET
732	  in noMMU configurations.
733
734	  If unsure, leave the default value here.
735
736choice
737	prompt "KSEG layout"
738	depends on MMU
739	default XTENSA_KSEG_MMU_V2
740
741config XTENSA_KSEG_MMU_V2
742	bool "MMUv2: 128MB cached + 128MB uncached"
743	help
744	  MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting
745	  at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000
746	  without cache.
747	  KSEG_PADDR must be aligned to 128MB.
748
749config XTENSA_KSEG_256M
750	bool "256MB cached + 256MB uncached"
751	depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
752	help
753	  TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000
754	  with cache and to 0xc0000000 without cache.
755	  KSEG_PADDR must be aligned to 256MB.
756
757config XTENSA_KSEG_512M
758	bool "512MB cached + 512MB uncached"
759	depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
760	help
761	  TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000
762	  with cache and to 0xc0000000 without cache.
763	  KSEG_PADDR must be aligned to 256MB.
764
765endchoice
766
767config HIGHMEM
768	bool "High Memory Support"
769	depends on MMU
770	select KMAP_LOCAL
771	help
772	  Linux can use the full amount of RAM in the system by
773	  default. However, the default MMUv2 setup only maps the
774	  lowermost 128 MB of memory linearly to the areas starting
775	  at 0xd0000000 (cached) and 0xd8000000 (uncached).
776	  When there are more than 128 MB memory in the system not
777	  all of it can be "permanently mapped" by the kernel.
778	  The physical memory that's not permanently mapped is called
779	  "high memory".
780
781	  If you are compiling a kernel which will never run on a
782	  machine with more than 128 MB total physical RAM, answer
783	  N here.
784
785	  If unsure, say Y.
786
787config ARCH_FORCE_MAX_ORDER
788	int "Order of maximal physically contiguous allocations"
789	default "10"
790	help
791	  The kernel page allocator limits the size of maximal physically
792	  contiguous allocations. The limit is called MAX_ORDER and it
793	  defines the maximal power of two of number of pages that can be
794	  allocated as a single contiguous block. This option allows
795	  overriding the default setting when ability to allocate very
796	  large blocks of physically contiguous memory is required.
797
798	  Don't change if unsure.
799
800endmenu
801
802menu "Power management options"
803
804config ARCH_HIBERNATION_POSSIBLE
805	def_bool y
806
807source "kernel/power/Kconfig"
808
809endmenu
810