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