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