| # 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_DMA_PREP_COHERENT if MMU |
| select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU |
| select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU |
| select ARCH_HAS_UNCACHED_SEGMENT if MMU |
| select ARCH_USE_QUEUED_RWLOCKS |
| select ARCH_USE_QUEUED_SPINLOCKS |
| select ARCH_WANT_FRAME_POINTERS |
| select ARCH_WANT_IPC_PARSE_VERSION |
| select BUILDTIME_TABLE_SORT |
| select CLONE_BACKWARDS |
| select COMMON_CLK |
| select DMA_REMAP if MMU |
| select GENERIC_ATOMIC64 |
| select GENERIC_CLOCKEVENTS |
| select GENERIC_IRQ_SHOW |
| select GENERIC_PCI_IOMAP |
| select GENERIC_SCHED_CLOCK |
| select GENERIC_STRNCPY_FROM_USER if KASAN |
| select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL |
| select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL |
| select HAVE_ARCH_TRACEHOOK |
| select HAVE_COPY_THREAD_TLS |
| select HAVE_DEBUG_KMEMLEAK |
| select HAVE_DMA_CONTIGUOUS |
| select HAVE_EXIT_THREAD |
| select HAVE_FUNCTION_TRACER |
| select HAVE_FUTEX_CMPXCHG if !MMU |
| select HAVE_HW_BREAKPOINT if PERF_EVENTS |
| select HAVE_IRQ_TIME_ACCOUNTING |
| select HAVE_OPROFILE |
| select HAVE_PCI |
| select HAVE_PERF_EVENTS |
| select HAVE_STACKPROTECTOR |
| select HAVE_SYSCALL_TRACEPOINTS |
| select IRQ_DOMAIN |
| select MODULES_USE_ELF_RELA |
| select PERF_USE_VMALLOC |
| select VIRT_TO_BUS |
| 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 NO_IOPORT_MAP |
| def_bool n |
| |
| config HZ |
| int |
| default 100 |
| |
| config LOCKDEP_SUPPORT |
| def_bool y |
| |
| config STACKTRACE_SUPPORT |
| def_bool y |
| |
| config TRACE_IRQFLAGS_SUPPORT |
| def_bool y |
| |
| config MMU |
| def_bool n |
| |
| config HAVE_XTENSA_GPIO32 |
| def_bool n |
| |
| config KASAN_SHADOW_OFFSET |
| hex |
| default 0x6e400000 |
| |
| 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. |
| Dont 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 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 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 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. |
| |
| 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" |
| select HAVE_IDE |
| 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. |
| |
| 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 wont |
| 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 ful 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 |
| 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 FORCE_MAX_ZONEORDER |
| int "Maximum zone order" |
| default "11" |
| help |
| The kernel memory allocator divides physically contiguous memory |
| blocks into "zones", where each zone is a power of two number of |
| pages. This option selects the largest power of two that the kernel |
| keeps in the memory allocator. If you need to allocate very large |
| blocks of physically contiguous memory, then you may need to |
| increase this value. |
| |
| This config option is actually maximum order plus one. For example, |
| a value of 11 means that the largest free memory block is 2^10 pages. |
| |
| endmenu |
| |
| menu "Power management options" |
| |
| source "kernel/power/Kconfig" |
| |
| endmenu |