798 lines
24 KiB
Plaintext
798 lines
24 KiB
Plaintext
# 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_FRAME_POINTERS
|
|
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 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_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 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 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 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 "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"
|
|
|
|
config ARCH_HIBERNATION_POSSIBLE
|
|
def_bool y
|
|
|
|
source "kernel/power/Kconfig"
|
|
|
|
endmenu
|