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