xtensa: move kernel memory layout to platform options
Currently kernel memory layout settings are split between "Processor type and features" and "Platform options" menus. Consolidate them under "Platform options". Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
This commit is contained in:
Max Filippov
Родитель
123b8db839
Коммит
76743c0e09
|
|
@ -213,151 +213,6 @@ config HOTPLUG_CPU
|
|||
|
||||
Say N if you want to disable CPU hotplug.
|
||||
|
||||
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 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_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.
|
||||
|
||||
config VECTORS_OFFSET
|
||||
hex "Kernel vectors offset"
|
||||
default 0x00003000
|
||||
help
|
||||
This is the offset of the kernel image from the relocatable vectors
|
||||
base.
|
||||
|
||||
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 FAST_SYSCALL_XTENSA
|
||||
bool "Enable fast atomic syscalls"
|
||||
default n
|
||||
|
|
@ -561,34 +416,6 @@ config SIMDISK1_FILENAME
|
|||
Another simulated disk in a host file for a buildroot-independent
|
||||
storage.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
config XTFPGA_LCD
|
||||
bool "Enable XTFPGA LCD driver"
|
||||
depends on XTENSA_PLATFORM_XTFPGA
|
||||
|
|
@ -619,6 +446,181 @@ config XTFPGA_LCD_8BIT_ACCESS
|
|||
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 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_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.
|
||||
|
||||
config VECTORS_OFFSET
|
||||
hex "Kernel vectors offset"
|
||||
default 0x00003000
|
||||
help
|
||||
This is the offset of the kernel image from the relocatable vectors
|
||||
base.
|
||||
|
||||
If unsure, leave the default value here.
|
||||
|
||||
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"
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче