diff options
Diffstat (limited to 'arch/xtensa/Kconfig')
| -rw-r--r-- | arch/xtensa/Kconfig | 813 |
1 files changed, 813 insertions, 0 deletions
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig new file mode 100644 index 000000000..7d792077e --- /dev/null +++ b/arch/xtensa/Kconfig @@ -0,0 +1,813 @@ +# SPDX-License-Identifier: GPL-2.0 +config XTENSA + def_bool y + select ARCH_32BIT_OFF_T + select ARCH_HAS_BINFMT_FLAT if !MMU + select ARCH_HAS_CURRENT_STACK_POINTER + select ARCH_HAS_DEBUG_VM_PGTABLE + select ARCH_HAS_DMA_PREP_COHERENT if MMU + select ARCH_HAS_GCOV_PROFILE_ALL + select ARCH_HAS_KCOV + select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU + select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU + select ARCH_HAS_DMA_SET_UNCACHED if MMU + select ARCH_HAS_STRNCPY_FROM_USER if !KASAN + select ARCH_HAS_STRNLEN_USER + select ARCH_USE_MEMTEST + select ARCH_USE_QUEUED_RWLOCKS + select ARCH_USE_QUEUED_SPINLOCKS + select ARCH_WANT_IPC_PARSE_VERSION + select BUILDTIME_TABLE_SORT + select CLONE_BACKWARDS + select COMMON_CLK + select DMA_NONCOHERENT_MMAP if MMU + select GENERIC_ATOMIC64 + select GENERIC_IRQ_SHOW + select GENERIC_LIB_CMPDI2 + select GENERIC_LIB_MULDI3 + select GENERIC_LIB_UCMPDI2 + select GENERIC_PCI_IOMAP + select GENERIC_SCHED_CLOCK + select GENERIC_IOREMAP if MMU + select HAVE_ARCH_AUDITSYSCALL + select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL + select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL + select HAVE_ARCH_KCSAN + select HAVE_ARCH_SECCOMP_FILTER + select HAVE_ARCH_TRACEHOOK + select HAVE_ASM_MODVERSIONS + select HAVE_CONTEXT_TRACKING_USER + select HAVE_DEBUG_KMEMLEAK + select HAVE_DMA_CONTIGUOUS + select HAVE_EXIT_THREAD + select HAVE_FUNCTION_TRACER + select HAVE_GCC_PLUGINS if GCC_VERSION >= 120000 + select HAVE_HW_BREAKPOINT if PERF_EVENTS + select HAVE_IRQ_TIME_ACCOUNTING + select HAVE_PCI + select HAVE_PERF_EVENTS + select HAVE_STACKPROTECTOR + select HAVE_SYSCALL_TRACEPOINTS + select HAVE_VIRT_CPU_ACCOUNTING_GEN + select IRQ_DOMAIN + select LOCK_MM_AND_FIND_VMA + select MODULES_USE_ELF_RELA + select PERF_USE_VMALLOC + select TRACE_IRQFLAGS_SUPPORT + help + Xtensa processors are 32-bit RISC machines designed by Tensilica + primarily for embedded systems. These processors are both + configurable and extensible. The Linux port to the Xtensa + architecture supports all processor configurations and extensions, + with reasonable minimum requirements. The Xtensa Linux project has + a home page at <http://www.linux-xtensa.org/>. + +config GENERIC_HWEIGHT + def_bool y + +config ARCH_HAS_ILOG2_U32 + def_bool n + +config ARCH_HAS_ILOG2_U64 + def_bool n + +config ARCH_MTD_XIP + def_bool y + +config NO_IOPORT_MAP + def_bool n + +config HZ + int + default 100 + +config LOCKDEP_SUPPORT + def_bool y + +config STACKTRACE_SUPPORT + def_bool y + +config MMU + def_bool n + select PFAULT + +config HAVE_XTENSA_GPIO32 + def_bool n + +config KASAN_SHADOW_OFFSET + hex + default 0x6e400000 + +config CPU_BIG_ENDIAN + def_bool $(success,test "$(shell,echo __XTENSA_EB__ | $(CC) -E -P -)" = 1) + +config CPU_LITTLE_ENDIAN + def_bool !CPU_BIG_ENDIAN + +config CC_HAVE_CALL0_ABI + def_bool $(success,test "$(shell,echo __XTENSA_CALL0_ABI__ | $(CC) -mabi=call0 -E -P - 2>/dev/null)" = 1) + +menu "Processor type and features" + +choice + prompt "Xtensa Processor Configuration" + default XTENSA_VARIANT_FSF + +config XTENSA_VARIANT_FSF + bool "fsf - default (not generic) configuration" + select MMU + +config XTENSA_VARIANT_DC232B + bool "dc232b - Diamond 232L Standard Core Rev.B (LE)" + select MMU + select HAVE_XTENSA_GPIO32 + help + This variant refers to Tensilica's Diamond 232L Standard core Rev.B (LE). + +config XTENSA_VARIANT_DC233C + bool "dc233c - Diamond 233L Standard Core Rev.C (LE)" + select MMU + select HAVE_XTENSA_GPIO32 + help + This variant refers to Tensilica's Diamond 233L Standard core Rev.C (LE). + +config XTENSA_VARIANT_CUSTOM + bool "Custom Xtensa processor configuration" + select HAVE_XTENSA_GPIO32 + help + Select this variant to use a custom Xtensa processor configuration. + You will be prompted for a processor variant CORENAME. +endchoice + +config XTENSA_VARIANT_CUSTOM_NAME + string "Xtensa Processor Custom Core Variant Name" + depends on XTENSA_VARIANT_CUSTOM + help + Provide the name of a custom Xtensa processor variant. + This CORENAME selects arch/xtensa/variant/CORENAME. + Don't forget you have to select MMU if you have one. + +config XTENSA_VARIANT_NAME + string + default "dc232b" if XTENSA_VARIANT_DC232B + default "dc233c" if XTENSA_VARIANT_DC233C + default "fsf" if XTENSA_VARIANT_FSF + default XTENSA_VARIANT_CUSTOM_NAME if XTENSA_VARIANT_CUSTOM + +config XTENSA_VARIANT_MMU + bool "Core variant has a Full MMU (TLB, Pages, Protection, etc)" + depends on XTENSA_VARIANT_CUSTOM + default y + select MMU + help + Build a Conventional Kernel with full MMU support, + ie: it supports a TLB with auto-loading, page protection. + +config XTENSA_VARIANT_HAVE_PERF_EVENTS + bool "Core variant has Performance Monitor Module" + depends on XTENSA_VARIANT_CUSTOM + default n + help + Enable if core variant has Performance Monitor Module with + External Registers Interface. + + If unsure, say N. + +config XTENSA_FAKE_NMI + bool "Treat PMM IRQ as NMI" + depends on XTENSA_VARIANT_HAVE_PERF_EVENTS + default n + help + If PMM IRQ is the only IRQ at EXCM level it is safe to + treat it as NMI, which improves accuracy of profiling. + + If there are other interrupts at or above PMM IRQ priority level + but not above the EXCM level, PMM IRQ still may be treated as NMI, + but only if these IRQs are not used. There will be a build warning + saying that this is not safe, and a bugcheck if one of these IRQs + actually fire. + + If unsure, say N. + +config PFAULT + bool "Handle protection faults" if EXPERT && !MMU + default y + help + Handle protection faults. MMU configurations must enable it. + noMMU configurations may disable it if used memory map never + generates protection faults or faults are always fatal. + + If unsure, say Y. + +config XTENSA_UNALIGNED_USER + bool "Unaligned memory access in user space" + help + The Xtensa architecture currently does not handle unaligned + memory accesses in hardware but through an exception handler. + Per default, unaligned memory accesses are disabled in user space. + + Say Y here to enable unaligned memory access in user space. + +config XTENSA_LOAD_STORE + bool "Load/store exception handler for memory only readable with l32" + help + The Xtensa architecture only allows reading memory attached to its + instruction bus with l32r and l32i instructions, all other + instructions raise an exception with the LoadStoreErrorCause code. + This makes it hard to use some configurations, e.g. store string + literals in FLASH memory attached to the instruction bus. + + Say Y here to enable exception handler that allows transparent + byte and 2-byte access to memory attached to instruction bus. + +config HAVE_SMP + bool "System Supports SMP (MX)" + depends on XTENSA_VARIANT_CUSTOM + select XTENSA_MX + help + This option is used to indicate that the system-on-a-chip (SOC) + supports Multiprocessing. Multiprocessor support implemented above + the CPU core definition and currently needs to be selected manually. + + Multiprocessor support is implemented with external cache and + interrupt controllers. + + The MX interrupt distributer adds Interprocessor Interrupts + and causes the IRQ numbers to be increased by 4 for devices + like the open cores ethernet driver and the serial interface. + + You still have to select "Enable SMP" to enable SMP on this SOC. + +config SMP + bool "Enable Symmetric multi-processing support" + depends on HAVE_SMP + select GENERIC_SMP_IDLE_THREAD + help + Enabled SMP Software; allows more than one CPU/CORE + to be activated during startup. + +config NR_CPUS + depends on SMP + int "Maximum number of CPUs (2-32)" + range 2 32 + default "4" + +config HOTPLUG_CPU + bool "Enable CPU hotplug support" + depends on SMP + help + Say Y here to allow turning CPUs off and on. CPUs can be + controlled through /sys/devices/system/cpu. + + Say N if you want to disable CPU hotplug. + +config SECONDARY_RESET_VECTOR + bool "Secondary cores use alternative reset vector" + default y + depends on HAVE_SMP + help + Secondary cores may be configured to use alternative reset vector, + or all cores may use primary reset vector. + Say Y here to supply handler for the alternative reset location. + +config FAST_SYSCALL_XTENSA + bool "Enable fast atomic syscalls" + default n + help + fast_syscall_xtensa is a syscall that can make atomic operations + on UP kernel when processor has no s32c1i support. + + This syscall is deprecated. It may have issues when called with + invalid arguments. It is provided only for backwards compatibility. + Only enable it if your userspace software requires it. + + If unsure, say N. + +config FAST_SYSCALL_SPILL_REGISTERS + bool "Enable spill registers syscall" + default n + help + fast_syscall_spill_registers is a syscall that spills all active + register windows of a calling userspace task onto its stack. + + This syscall is deprecated. It may have issues when called with + invalid arguments. It is provided only for backwards compatibility. + Only enable it if your userspace software requires it. + + If unsure, say N. + +choice + prompt "Kernel ABI" + default KERNEL_ABI_DEFAULT + help + Select ABI for the kernel code. This ABI is independent of the + supported userspace ABI and any combination of the + kernel/userspace ABI is possible and should work. + + In case both kernel and userspace support only call0 ABI + all register windows support code will be omitted from the + build. + + If unsure, choose the default ABI. + +config KERNEL_ABI_DEFAULT + bool "Default ABI" + help + Select this option to compile kernel code with the default ABI + selected for the toolchain. + Normally cores with windowed registers option use windowed ABI and + cores without it use call0 ABI. + +config KERNEL_ABI_CALL0 + bool "Call0 ABI" if CC_HAVE_CALL0_ABI + help + Select this option to compile kernel code with call0 ABI even with + toolchain that defaults to windowed ABI. + When this option is not selected the default toolchain ABI will + be used for the kernel code. + +endchoice + +config USER_ABI_CALL0 + bool + +choice + prompt "Userspace ABI" + default USER_ABI_DEFAULT + help + Select supported userspace ABI. + + If unsure, choose the default ABI. + +config USER_ABI_DEFAULT + bool "Default ABI only" + help + Assume default userspace ABI. For XEA2 cores it is windowed ABI. + call0 ABI binaries may be run on such kernel, but signal delivery + will not work correctly for them. + +config USER_ABI_CALL0_ONLY + bool "Call0 ABI only" + select USER_ABI_CALL0 + help + Select this option to support only call0 ABI in userspace. + Windowed ABI binaries will crash with a segfault caused by + an illegal instruction exception on the first 'entry' opcode. + + Choose this option if you're planning to run only user code + built with call0 ABI. + +config USER_ABI_CALL0_PROBE + bool "Support both windowed and call0 ABI by probing" + select USER_ABI_CALL0 + help + Select this option to support both windowed and call0 userspace + ABIs. When enabled all processes are started with PS.WOE disabled + and a fast user exception handler for an illegal instruction is + used to turn on PS.WOE bit on the first 'entry' opcode executed by + the userspace. + + This option should be enabled for the kernel that must support + both call0 and windowed ABIs in userspace at the same time. + + Note that Xtensa ISA does not guarantee that entry opcode will + raise an illegal instruction exception on cores with XEA2 when + PS.WOE is disabled, check whether the target core supports it. + +endchoice + +endmenu + +config XTENSA_CALIBRATE_CCOUNT + def_bool n + help + On some platforms (XT2000, for example), the CPU clock rate can + vary. The frequency can be determined, however, by measuring + against a well known, fixed frequency, such as an UART oscillator. + +config SERIAL_CONSOLE + def_bool n + +config PLATFORM_HAVE_XIP + def_bool n + +menu "Platform options" + +choice + prompt "Xtensa System Type" + default XTENSA_PLATFORM_ISS + +config XTENSA_PLATFORM_ISS + bool "ISS" + select XTENSA_CALIBRATE_CCOUNT + select SERIAL_CONSOLE + help + ISS is an acronym for Tensilica's Instruction Set Simulator. + +config XTENSA_PLATFORM_XT2000 + bool "XT2000" + help + XT2000 is the name of Tensilica's feature-rich emulation platform. + This hardware is capable of running a full Linux distribution. + +config XTENSA_PLATFORM_XTFPGA + bool "XTFPGA" + select ETHOC if ETHERNET + select PLATFORM_WANT_DEFAULT_MEM if !MMU + select SERIAL_CONSOLE + select XTENSA_CALIBRATE_CCOUNT + select PLATFORM_HAVE_XIP + help + XTFPGA is the name of Tensilica board family (LX60, LX110, LX200, ML605). + This hardware is capable of running a full Linux distribution. + +endchoice + +config PLATFORM_NR_IRQS + int + default 3 if XTENSA_PLATFORM_XT2000 + default 0 + +config XTENSA_CPU_CLOCK + int "CPU clock rate [MHz]" + depends on !XTENSA_CALIBRATE_CCOUNT + default 16 + +config GENERIC_CALIBRATE_DELAY + bool "Auto calibration of the BogoMIPS value" + help + The BogoMIPS value can easily be derived from the CPU frequency. + +config CMDLINE_BOOL + bool "Default bootloader kernel arguments" + +config CMDLINE + string "Initial kernel command string" + depends on CMDLINE_BOOL + default "console=ttyS0,38400 root=/dev/ram" + help + On some architectures (EBSA110 and CATS), there is currently no way + for the boot loader to pass arguments to the kernel. For these + architectures, you should supply some command-line options at build + time by entering them here. As a minimum, you should specify the + memory size and the root device (e.g., mem=64M root=/dev/nfs). + +config USE_OF + bool "Flattened Device Tree support" + select OF + select OF_EARLY_FLATTREE + help + Include support for flattened device tree machine descriptions. + +config BUILTIN_DTB_SOURCE + string "DTB to build into the kernel image" + depends on OF + +config PARSE_BOOTPARAM + bool "Parse bootparam block" + default y + help + Parse parameters passed to the kernel from the bootloader. It may + be disabled if the kernel is known to run without the bootloader. + + If unsure, say Y. + +choice + prompt "Semihosting interface" + default XTENSA_SIMCALL_ISS + depends on XTENSA_PLATFORM_ISS + help + Choose semihosting interface that will be used for serial port, + block device and networking. + +config XTENSA_SIMCALL_ISS + bool "simcall" + help + Use simcall instruction. simcall is only available on simulators, + it does nothing on hardware. + +config XTENSA_SIMCALL_GDBIO + bool "GDBIO" + help + Use break instruction. It is available on real hardware when GDB + is attached to it via JTAG. + +endchoice + +config BLK_DEV_SIMDISK + tristate "Host file-based simulated block device support" + default n + depends on XTENSA_PLATFORM_ISS && BLOCK + help + Create block devices that map to files in the host file system. + Device binding to host file may be changed at runtime via proc + interface provided the device is not in use. + +config BLK_DEV_SIMDISK_COUNT + int "Number of host file-based simulated block devices" + range 1 10 + depends on BLK_DEV_SIMDISK + default 2 + help + This is the default minimal number of created block devices. + Kernel/module parameter 'simdisk_count' may be used to change this + value at runtime. More file names (but no more than 10) may be + specified as parameters, simdisk_count grows accordingly. + +config SIMDISK0_FILENAME + string "Host filename for the first simulated device" + depends on BLK_DEV_SIMDISK = y + default "" + help + Attach a first simdisk to a host file. Conventionally, this file + contains a root file system. + +config SIMDISK1_FILENAME + string "Host filename for the second simulated device" + depends on BLK_DEV_SIMDISK = y && BLK_DEV_SIMDISK_COUNT != 1 + default "" + help + Another simulated disk in a host file for a buildroot-independent + storage. + +config XTFPGA_LCD + bool "Enable XTFPGA LCD driver" + depends on XTENSA_PLATFORM_XTFPGA + default n + help + There's a 2x16 LCD on most of XTFPGA boards, kernel may output + progress messages there during bootup/shutdown. It may be useful + during board bringup. + + If unsure, say N. + +config XTFPGA_LCD_BASE_ADDR + hex "XTFPGA LCD base address" + depends on XTFPGA_LCD + default "0x0d0c0000" + help + Base address of the LCD controller inside KIO region. + Different boards from XTFPGA family have LCD controller at different + addresses. Please consult prototyping user guide for your board for + the correct address. Wrong address here may lead to hardware lockup. + +config XTFPGA_LCD_8BIT_ACCESS + bool "Use 8-bit access to XTFPGA LCD" + depends on XTFPGA_LCD + default n + help + LCD may be connected with 4- or 8-bit interface, 8-bit access may + only be used with 8-bit interface. Please consult prototyping user + guide for your board for the correct interface width. + +comment "Kernel memory layout" + +config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + bool "Initialize Xtensa MMU inside the Linux kernel code" + depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B + default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM + help + Earlier version initialized the MMU in the exception vector + before jumping to _startup in head.S and had an advantage that + it was possible to place a software breakpoint at 'reset' and + then enter your normal kernel breakpoints once the MMU was mapped + to the kernel mappings (0XC0000000). + + This unfortunately won't work for U-Boot and likely also won't + work for using KEXEC to have a hot kernel ready for doing a + KDUMP. + + So now the MMU is initialized in head.S but it's necessary to + use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. + xt-gdb can't place a Software Breakpoint in the 0XD region prior + to mapping the MMU and after mapping even if the area of low memory + was mapped gdb wouldn't remove the breakpoint on hitting it as the + PC wouldn't match. Since Hardware Breakpoints are recommended for + Linux configurations it seems reasonable to just assume they exist + and leave this older mechanism for unfortunate souls that choose + not to follow Tensilica's recommendation. + + Selecting this will cause U-Boot to set the KERNEL Load and Entry + address at 0x00003000 instead of the mapped std of 0xD0003000. + + If in doubt, say Y. + +config XIP_KERNEL + bool "Kernel Execute-In-Place from ROM" + depends on PLATFORM_HAVE_XIP + help + Execute-In-Place allows the kernel to run from non-volatile storage + directly addressable by the CPU, such as NOR flash. This saves RAM + space since the text section of the kernel is not loaded from flash + to RAM. Read-write sections, such as the data section and stack, + are still copied to RAM. The XIP kernel is not compressed since + it has to run directly from flash, so it will take more space to + store it. The flash address used to link the kernel object files, + and for storing it, is configuration dependent. Therefore, if you + say Y here, you must know the proper physical address where to + store the kernel image depending on your own flash memory usage. + + Also note that the make target becomes "make xipImage" rather than + "make Image" or "make uImage". The final kernel binary to put in + ROM memory will be arch/xtensa/boot/xipImage. + + If unsure, say N. + +config MEMMAP_CACHEATTR + hex "Cache attributes for the memory address space" + depends on !MMU + default 0x22222222 + help + These cache attributes are set up for noMMU systems. Each hex digit + specifies cache attributes for the corresponding 512MB memory + region: bits 0..3 -- for addresses 0x00000000..0x1fffffff, + bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on. + + Cache attribute values are specific for the MMU type. + For region protection MMUs: + 1: WT cached, + 2: cache bypass, + 4: WB cached, + f: illegal. + For full MMU: + bit 0: executable, + bit 1: writable, + bits 2..3: + 0: cache bypass, + 1: WB cache, + 2: WT cache, + 3: special (c and e are illegal, f is reserved). + For MPU: + 0: illegal, + 1: WB cache, + 2: WB, no-write-allocate cache, + 3: WT cache, + 4: cache bypass. + +config KSEG_PADDR + hex "Physical address of the KSEG mapping" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU + default 0x00000000 + help + This is the physical address where KSEG is mapped. Please refer to + the chosen KSEG layout help for the required address alignment. + Unpacked kernel image (including vectors) must be located completely + within KSEG. + Physical memory below this address is not available to linux. + + If unsure, leave the default value here. + +config KERNEL_VIRTUAL_ADDRESS + hex "Kernel virtual address" + depends on MMU && XIP_KERNEL + default 0xd0003000 + help + This is the virtual address where the XIP kernel is mapped. + XIP kernel may be mapped into KSEG or KIO region, virtual address + provided here must match kernel load address provided in + KERNEL_LOAD_ADDRESS. + +config KERNEL_LOAD_ADDRESS + hex "Kernel load address" + default 0x60003000 if !MMU + default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + This is the address where the kernel is loaded. + It is virtual address for MMUv2 configurations and physical address + for all other configurations. + + If unsure, leave the default value here. + +choice + prompt "Relocatable vectors location" + default XTENSA_VECTORS_IN_TEXT + help + Choose whether relocatable vectors are merged into the kernel .text + or placed separately at runtime. This option does not affect + configurations without VECBASE register where vectors are always + placed at their hardware-defined locations. + +config XTENSA_VECTORS_IN_TEXT + bool "Merge relocatable vectors into kernel text" + depends on !MTD_XIP + help + This option puts relocatable vectors into the kernel .text section + with proper alignment. + This is a safe choice for most configurations. + +config XTENSA_VECTORS_SEPARATE + bool "Put relocatable vectors at fixed address" + help + This option puts relocatable vectors at specific virtual address. + Vectors are merged with the .init data in the kernel image and + are copied into their designated location during kernel startup. + Use it to put vectors into IRAM or out of FLASH on kernels with + XIP-aware MTD support. + +endchoice + +config VECTORS_ADDR + hex "Kernel vectors virtual address" + default 0x00000000 + depends on XTENSA_VECTORS_SEPARATE + help + This is the virtual address of the (relocatable) vectors base. + It must be within KSEG if MMU is used. + +config XIP_DATA_ADDR + hex "XIP kernel data virtual address" + depends on XIP_KERNEL + default 0x00000000 + help + This is the virtual address where XIP kernel data is copied. + It must be within KSEG if MMU is used. + +config PLATFORM_WANT_DEFAULT_MEM + def_bool n + +config DEFAULT_MEM_START + hex + prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM + default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM + default 0x00000000 + help + This is the base address used for both PAGE_OFFSET and PHYS_OFFSET + in noMMU configurations. + + If unsure, leave the default value here. + +choice + prompt "KSEG layout" + depends on MMU + default XTENSA_KSEG_MMU_V2 + +config XTENSA_KSEG_MMU_V2 + bool "MMUv2: 128MB cached + 128MB uncached" + help + MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting + at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000 + without cache. + KSEG_PADDR must be aligned to 128MB. + +config XTENSA_KSEG_256M + bool "256MB cached + 256MB uncached" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000 + with cache and to 0xc0000000 without cache. + KSEG_PADDR must be aligned to 256MB. + +config XTENSA_KSEG_512M + bool "512MB cached + 512MB uncached" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000 + with cache and to 0xc0000000 without cache. + KSEG_PADDR must be aligned to 256MB. + +endchoice + +config HIGHMEM + bool "High Memory Support" + depends on MMU + select KMAP_LOCAL + help + Linux can use the full amount of RAM in the system by + default. However, the default MMUv2 setup only maps the + lowermost 128 MB of memory linearly to the areas starting + at 0xd0000000 (cached) and 0xd8000000 (uncached). + When there are more than 128 MB memory in the system not + all of it can be "permanently mapped" by the kernel. + The physical memory that's not permanently mapped is called + "high memory". + + If you are compiling a kernel which will never run on a + machine with more than 128 MB total physical RAM, answer + N here. + + If unsure, say Y. + +config ARCH_FORCE_MAX_ORDER + int "Order of maximal physically contiguous allocations" + default "10" + help + The kernel page allocator limits the size of maximal physically + contiguous allocations. The limit is called MAX_ORDER and it + defines the maximal power of two of number of pages that can be + allocated as a single contiguous block. This option allows + overriding the default setting when ability to allocate very + large blocks of physically contiguous memory is required. + + Don't change if unsure. + +endmenu + +menu "Power management options" + +config ARCH_HIBERNATION_POSSIBLE + def_bool y + +source "kernel/power/Kconfig" + +endmenu |