michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/arch/xtensa/Kconfig

283 lines
7.3 KiB
Plaintext
Raw Permalink Normal View History

kconfig: Clean up header comments and make them consistent Use this short header style in all Kconfig files: # <description> # <copyright> # <license> ... Also change all <description>s from # Kconfig[.extension] - Foo-related options to just # Foo-related options It's clear enough that it's about Kconfig. The <description> cleanup was done with this command, along with some manual cleanup (big letter at the start, etc.) git ls-files '*Kconfig*' | \ xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /' Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-01 13:45:29 +01:00
# XTENSA architecture configuration options
Xtensa port: Started port to for Xtensa cores family. Added arch sub folder, make files and Kconfig files for a set of standard SoCs. Change-Id: I4ee9cba966860072e55c95795d87356b665e4d49 Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
2017-01-13 12:14:33 +01:00
# Copyright (c) 2016 Cadence Design Systems, Inc.
xtensa: fixup license identifiers Master branch changed requirements for license headers while this branch has been in development. Change-Id: I9bce16ff275057a4bb664019628fc9b6de7aef7c Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-01-25 00:10:39 +01:00
# SPDX-License-Identifier: Apache-2.0
Xtensa port: Started port to for Xtensa cores family. Added arch sub folder, make files and Kconfig files for a set of standard SoCs. Change-Id: I4ee9cba966860072e55c95795d87356b665e4d49 Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
2017-01-13 12:14:33 +01:00
menu "XTENSA Options"
depends on XTENSA
config ARCH
default "xtensa"
xtensa: xt-sim: mark it as a board with simulator features Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-05-11 15:01:09 +02:00
config SIMULATOR_XTENSA
xtensa: cleanup Kconfig file * Wording on CONFIG_SIMULATOR_XTENSA * Remove "default n" as default is no anyway. * Remove some tabs as we almost never indent inside a if block in Zephyr. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-12-06 20:33:11 +01:00
bool "Simulator Target"
xtensa: xt-sim: mark it as a board with simulator features Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-05-11 15:01:09 +02:00
help
xtensa: cleanup Kconfig file * Wording on CONFIG_SIMULATOR_XTENSA * Remove "default n" as default is no anyway. * Remove some tabs as we almost never indent inside a if block in Zephyr. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-12-06 20:33:11 +01:00
Enable if building to run on simulator.
xtensa: xt-sim: mark it as a board with simulator features Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-05-11 15:01:09 +02:00
xtensa: optionally build reset vector code In real-world use-cases this isn't always needed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-05-11 18:46:08 +02:00
config XTENSA_RESET_VECTOR
Kconfig: Use the first default with a satisfied condition Up until now, Zephyr has patched Kconfig to use the last 'default' with a satisfied condition, instead of the first one. I'm not sure why the patch was added (it predates Kconfiglib), but I suspect it's related to Kconfig.defconfig files. There are at least three problems with the patch: 1. It's inconsistent with how Kconfig works in other projects, which might confuse newcomers. 2. Due to oversights, earlier 'range' properties are still preferred, as well as earlier 'default' properties on choices. In addition to being inconsistent, this makes it impossible to override 'range' properties and choice 'default' properties if the base definition of the symbol/choice already has 'range'/'default' properties. I've seen errors caused by the inconsistency, and I suspect there are more. 3. A fork of Kconfiglib that adds the patch needs to be maintained. Get rid of the patch and go back to standard Kconfig behavior, as follows: 1. Include the Kconfig.defconfig files first instead of last in Kconfig.zephyr. 2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of last in arch/Kconfig. 3. Include arch/<arch>/soc/*/Kconfig first instead of last in arch/<arch>/Kconfig. 4. Swap a few other 'source's to preserve behavior for some scattered symbols with multiple definitions. Swap 'source's in some no-op cases too, where it might match the intent. 5. Reverse the defaults on symbol definitions that have more than one default. Skip defaults that are mutually exclusive, e.g. where each default has an 'if <some board>' condition. They are already safe. 6. Remove the prefer-later-defaults patch from Kconfiglib. Testing was done with a Python script that lists all Kconfig symbols/choices with multiple defaults, along with a whitelist of fixed symbols. The script also verifies that there are no "unreachable" defaults hidden by defaults without conditions As an additional test, zephyr/.config was generated before and after the change for several samples and checked to be identical (after sorting). This commit includes some default-related cleanups as well: - Simplify some symbol definitions, e.g. where a default has 'if FOO' when the symbol already has 'depends on FOO'. - Remove some redundant 'default ""' for string symbols. This is the implicit default. Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and BT_L2CAP_TX_MTU (caused by confusing inconsistency). Piggyback some fixes for style nits too, e.g. unindented help texts. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
bool "Build reset vector code"
xtensa: optionally build reset vector code In real-world use-cases this isn't always needed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-05-11 18:46:08 +02:00
default y
help
kconfig: fix help syntax and add spaces Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-13 16:08:21 +01:00
This option controls whether the initial reset vector code is built.
This is always needed for the simulator. Real boards may already
implement this in boot ROM.
xtensa: optionally build reset vector code In real-world use-cases this isn't always needed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-05-11 18:46:08 +02:00
arch/xtensa: Automatically generate interrupt handlers (finally) The script to generate the _soc_inthandlers.h header has been run manually for years, only because I was a cmake novice at the time and unsure how to integrate it into the build. So every new platform has to find the script and template file and figure out how to generate the file. And in a few cases it looks like we've tried to EDIT the resulting files in the tree. Let's finally do this right. The file is now dropped (for every xtensa platform) as a "xtensa_handlers.h" file, and there is a Kconfig to control whether the original/manual file or the new one is used by the platform code. We can migrate the other platforms slowly as people have time to validate. Signed-off-by: Andy Ross <andyross@google.com>
2023-07-31 17:34:28 +02:00
config XTENSA_GEN_HANDLERS
bool "Automatically generate interrupt handlers"
default n
help
When set, an "xtensa_handlers.h" file is generated
containing definitions for the interrupt entry code of the
target Xtensa core, based automatically on the details in
the core-isa.h file. This replaces the previous scheme
where a _soc_inthandlers.h file would be generated offline.
soc: esp32: Define __start as a C function The first stage bootloader, part of the ESP32 ROM, already sets up a stack that's sufficient to execute C programs. So, instead of implementing __stack() in assembly, do it in C to simplify things slightly. This ESP32-specific initialization will perform the following: - Disable the watchdog timer that's enabled by the bootloader - Move exception handlers to IRAM - Disable normal interrupts - Disable the second CPU - Zero out the BSS segment Things that might be performed in the future include setting up the CPU frequency, memory protection regions, and enabling the flash cache. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-06-13 19:48:38 +02:00
config XTENSA_USE_CORE_CRT1
Kconfig: Use the first default with a satisfied condition Up until now, Zephyr has patched Kconfig to use the last 'default' with a satisfied condition, instead of the first one. I'm not sure why the patch was added (it predates Kconfiglib), but I suspect it's related to Kconfig.defconfig files. There are at least three problems with the patch: 1. It's inconsistent with how Kconfig works in other projects, which might confuse newcomers. 2. Due to oversights, earlier 'range' properties are still preferred, as well as earlier 'default' properties on choices. In addition to being inconsistent, this makes it impossible to override 'range' properties and choice 'default' properties if the base definition of the symbol/choice already has 'range'/'default' properties. I've seen errors caused by the inconsistency, and I suspect there are more. 3. A fork of Kconfiglib that adds the patch needs to be maintained. Get rid of the patch and go back to standard Kconfig behavior, as follows: 1. Include the Kconfig.defconfig files first instead of last in Kconfig.zephyr. 2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of last in arch/Kconfig. 3. Include arch/<arch>/soc/*/Kconfig first instead of last in arch/<arch>/Kconfig. 4. Swap a few other 'source's to preserve behavior for some scattered symbols with multiple definitions. Swap 'source's in some no-op cases too, where it might match the intent. 5. Reverse the defaults on symbol definitions that have more than one default. Skip defaults that are mutually exclusive, e.g. where each default has an 'if <some board>' condition. They are already safe. 6. Remove the prefer-later-defaults patch from Kconfiglib. Testing was done with a Python script that lists all Kconfig symbols/choices with multiple defaults, along with a whitelist of fixed symbols. The script also verifies that there are no "unreachable" defaults hidden by defaults without conditions As an additional test, zephyr/.config was generated before and after the change for several samples and checked to be identical (after sorting). This commit includes some default-related cleanups as well: - Simplify some symbol definitions, e.g. where a default has 'if FOO' when the symbol already has 'depends on FOO'. - Remove some redundant 'default ""' for string symbols. This is the implicit default. Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and BT_L2CAP_TX_MTU (caused by confusing inconsistency). Piggyback some fixes for style nits too, e.g. unindented help texts. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
bool "Use crt1.S from core"
soc: esp32: Define __start as a C function The first stage bootloader, part of the ESP32 ROM, already sets up a stack that's sufficient to execute C programs. So, instead of implementing __stack() in assembly, do it in C to simplify things slightly. This ESP32-specific initialization will perform the following: - Disable the watchdog timer that's enabled by the bootloader - Move exception handlers to IRAM - Disable normal interrupts - Disable the second CPU - Zero out the BSS segment Things that might be performed in the future include setting up the CPU frequency, memory protection regions, and enabling the flash cache. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-06-13 19:48:38 +02:00
default y
help
kconfig: fix help syntax and add spaces Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-13 16:08:21 +01:00
SoC or boards might define their own __start by setting this setting
to false.
soc: esp32: Define __start as a C function The first stage bootloader, part of the ESP32 ROM, already sets up a stack that's sufficient to execute C programs. So, instead of implementing __stack() in assembly, do it in C to simplify things slightly. This ESP32-specific initialization will perform the following: - Disable the watchdog timer that's enabled by the bootloader - Move exception handlers to IRAM - Disable normal interrupts - Disable the second CPU - Zero out the BSS segment Things that might be performed in the future include setting up the CPU frequency, memory protection regions, and enabling the flash cache. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-06-13 19:48:38 +02:00
arch: xtensa: Print backtrace from panic handler This change uses stack frame to print backtrace once exception occurs Printing backtrace helps to identify the cause of exception Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
2021-01-07 07:11:11 +01:00
config XTENSA_ENABLE_BACKTRACE
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "Backtrace on panic exception"
arch: xtensa: Print backtrace from panic handler This change uses stack frame to print backtrace once exception occurs Printing backtrace helps to identify the cause of exception Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
2021-01-07 07:11:11 +01:00
default y
xtensa: dc233c: enable backtrace support Adds the necessary bits to enable backtrace support for Xtensa DC233C core. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-08-24 22:58:26 +02:00
depends on SOC_SERIES_ESP32 || SOC_FAMILY_INTEL_ADSP || SOC_XTENSA_DC233C
arch: xtensa: Print backtrace from panic handler This change uses stack frame to print backtrace once exception occurs Printing backtrace helps to identify the cause of exception Signed-off-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
2021-01-07 07:11:11 +01:00
help
Enable this config option to print backtrace on panic exception
arch: xtensa: add workaround for small vector table entries For some platforms, like NXP's IMX8 or Mediatek's MT8195, the size of an interrupt vector table entry is 0x1C bytes, less than usual (0x30 for Intel's platforms). So, the interrupt handlers don't fit in the vector table entries. I've added a small indirection to bypass this size constraint and moved the default handlers to the end of vector table, renaming them to _Level\LVL\()VectorHelper. For this, I've added a generic configuration - XTENSA_SMALL_VECTOR_TABLE_ENTRY. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
2021-09-10 12:58:53 +02:00
config XTENSA_SMALL_VECTOR_TABLE_ENTRY
kconfig: remove Enable from boolean prompts According to Kconfig guidelines, boolean prompts must not start with "Enable...". The following command has been used to automate the changes in this patch: sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig* Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 12:05:12 +01:00
bool "Workaround for small vector table entries"
arch: xtensa: add workaround for small vector table entries For some platforms, like NXP's IMX8 or Mediatek's MT8195, the size of an interrupt vector table entry is 0x1C bytes, less than usual (0x30 for Intel's platforms). So, the interrupt handlers don't fit in the vector table entries. I've added a small indirection to bypass this size constraint and moved the default handlers to the end of vector table, renaming them to _Level\LVL\()VectorHelper. For this, I've added a generic configuration - XTENSA_SMALL_VECTOR_TABLE_ENTRY. Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
2021-09-10 12:58:53 +02:00
help
This option enables a small indirection to bypass the size
constraint of the vector table entry and moved the default
handlers to the end of vector table, renaming them to
_Level\LVL\()VectorHelper.
xtensa: make xtensa cache/uncache operations optional Do not build those on platforms not supporting them. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2022-08-25 15:29:11 +02:00
config XTENSA_RPO_CACHE
bool "Cached/uncached RPO mapping"
help
Support Cached/uncached RPO mapping.
A design trick on multi-core hardware is to map memory twice
so that it can be seen in both (incoherent) cached mappings
and a coherent "shared" area.
if XTENSA_RPO_CACHE
arch/xtensa: Promote adsp RPO/cache utilities to an arch API This is trick (mapping RAM twice so you can use alternate Region Protection Option addresses to control cacheability) is something any Xtensa hardware designer might productively choose to do. And as it works really well, we should encourage that by making this a generic architecture feature for Zephyr. Now everything works by setting two kconfig values at the soc level defining the cached and uncached regions. As long as these are correct, you can then use the new arch_xtensa_un/cached_ptr() APIs to convert between them and a ARCH_XTENSA_SET_RPO_TLB() macro that provides much smaller initialization code (in C!) than the HAL assembly macros. The conversion routines have been generalized to support conversion between any two regions. Note that full KERNEL_COHERENCE still requires support from the platform linker script, that can't be made generic given the way Zephyr does linkage. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2022-01-07 14:09:39 +01:00
config XTENSA_CACHED_REGION
int "Cached RPO mapping"
range 0 7
help
xtensa: make xtensa cache/uncache operations optional Do not build those on platforms not supporting them. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2022-08-25 15:29:11 +02:00
This specifies which 512M region (0-7, as defined by the Xtensa
Region Protection Option) contains the "cached" mapping.
arch/xtensa: Promote adsp RPO/cache utilities to an arch API This is trick (mapping RAM twice so you can use alternate Region Protection Option addresses to control cacheability) is something any Xtensa hardware designer might productively choose to do. And as it works really well, we should encourage that by making this a generic architecture feature for Zephyr. Now everything works by setting two kconfig values at the soc level defining the cached and uncached regions. As long as these are correct, you can then use the new arch_xtensa_un/cached_ptr() APIs to convert between them and a ARCH_XTENSA_SET_RPO_TLB() macro that provides much smaller initialization code (in C!) than the HAL assembly macros. The conversion routines have been generalized to support conversion between any two regions. Note that full KERNEL_COHERENCE still requires support from the platform linker script, that can't be made generic given the way Zephyr does linkage. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2022-01-07 14:09:39 +01:00
config XTENSA_UNCACHED_REGION
int "Uncached RPO mapping"
range 0 7
help
As for XTENSA_CACHED_REGION, this specifies which 512M
region (0-7) contains the "uncached" mapping.
xtensa: make xtensa cache/uncache operations optional Do not build those on platforms not supporting them. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2022-08-25 15:29:11 +02:00
endif
arch/xtensa: Add CCOUNT-based timing API Expose the Xtenesa CCOUNT timing register (the lowest level CPU cycle counter) using the arch_timing_*() API. This is the simplest possible way to get this working. Future work might focus on moving the rate configuration into devicetree in a standard way, integrating with the platform clock driver on intel_adsp such that the reported cycle rate tracks runtime changes (though IIRC this is not a SOF requirement), and adding better test coverage to the timing layer, which right now isn't exercised anywhere but in benchmarks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2022-06-06 16:49:27 +02:00
config XTENSA_CCOUNT_HZ
int "CCOUNT cycle rate"
default 1000000
help
Rate in HZ of the Xtensa core as measured by the value of
the CCOUNT register.
xtensa: allow arch-specific arch_spin_relax() with more NOPs This adds a Kconfig to introduce the Xtensa specific arch_spin_relax() which can do more NOPs. Some Xtensa SoCs may need more NOPs after failure to lock a spinlock, especially under SMP. This gives the bus extra time to propagate the RCW transactions among CPUs. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-07-19 02:44:58 +02:00
config XTENSA_MORE_SPIN_RELAX_NOPS
bool "Use Xtensa specific arch_spin_relax() with more NOPs"
help
Some Xtensa SoCs, especially under SMP, may need extra
NOPs after failure to lock a spinlock. This gives
the bus extra time to synchronize the RCW transaction
among CPUs.
config XTENSA_NUM_SPIN_RELAX_NOPS
int "Number of NOPs to be used in arch_spin_relax()"
default 1
depends on XTENSA_MORE_SPIN_RELAX_NOPS
help
Specify the number of NOPs in Xtensa specific
arch_spin_relax().
arch: xtensa: Add HiFi Kconfig options Adds HiFi Kconfig options to xtensa Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
2024-01-18 20:50:06 +01:00
menu "Xtensa HiFi Options"
config XTENSA_CPU_HAS_HIFI
bool
config XTENSA_CPU_HAS_HIFI3
select XTENSA_CPU_HAS_HIFI
bool
config XTENSA_CPU_HAS_HIFI4
select XTENSA_CPU_HAS_HIFI
bool
# Selected when at least one XTENSA_HIFIn version has been configured
config XTENSA_HIFI
bool
if XTENSA_CPU_HAS_HIFI
config XTENSA_HIFI3
bool "HiFi3 AudioEngine instructions"
depends on XTENSA_CPU_HAS_HIFI3
default y
select XTENSA_HIFI
help
This option enables HiFi 3 instruction support.
config XTENSA_HIFI4
bool "HiFi4 AudioEngine instructions"
depends on XTENSA_CPU_HAS_HIFI4
default y
select XTENSA_HIFI
help
This option enables HiFi 4 instruction support.
config XTENSA_HIFI_SHARING
bool "HiFi register sharing"
depends on XTENSA_HIFI
help
This option enables preservation of the hardware HiFi registers
across context switches to allow multiple threads to perform
concurrent HiFi operations.
endif # XTENSA_CPU_HAS_HIFI
endmenu # Xtensa HiFi Options
xtensa: mmu: Initial implementation Initial support for Xtensa MMU version 3. It is using a two level page table based on fact that the page table is in the virtual space. Only the top level (page directory) is wired mapped in the TLB to avoid second level page miss. The mapped memory is completely fragmented in multiple sections, maybe we find a better way in future. The exception handler is where we effectively map the memory, the way it works is: 1) SW try to access some memory address 2) The address is not mapped, so the MMU will try the auto-refill, looking the page table 3) The page table contents is not mapped (remember, just the top-level page is mapped) 4) An exception will be triggered, in the exception we try to read the portion of the page table that maps the original address 5) The address is not mapped, so the MMU will try again the auto-refill. This time though, the address is mapped by the top level page that is properly mapped. (The top-level page maps the page table itself). Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-05-09 23:44:22 +02:00
if CPU_HAS_MMU
config XTENSA_MMU
bool "Xtensa MMU Support"
select MMU
xtensa: Enable userspace Userspace support for Xtensa architecture using Xtensa MMU. Some considerations: - Syscalls are not inline functions like in other architectures because some compiler issues when using multiple registers to pass parameters to the syscall. So here we have a function call so we can use registers as we need. - TLS is not supported by xcc in xtensa and reading PS register is a privileged instruction. So, we have to use threadptr to know if a thread is an user mode thread. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com> Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2022-12-14 09:35:36 +01:00
select ARCH_MEM_DOMAIN_SYNCHRONOUS_API if USERSPACE
xtensa: mmu: handle TLB misses in C exception handler This moves the TLB miss handling to the C exception handler. This also allows us to handle page faults (for example, unmapped pages) during this time as any more exceptions handled in the C handler will not trigger the double exception handler but the same C handler. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-01-27 03:04:08 +01:00
select XTENSA_SMALL_VECTOR_TABLE_ENTRY
xtensa: add custom mem range check functions This provides custom memory range check functions as it gets a bit complicated with cached/uncached regions. These functions are marked as __weak so SoC or board can override these if needed. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-10-12 20:00:45 +02:00
select KERNEL_VM_USE_CUSTOM_MEM_RANGE_CHECK if XTENSA_RPO_CACHE
arch: xtensa: Not use TLS to store current thread Xtensa clears out threadptr durint ISR when userspace is enabled. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-09-30 06:33:45 +02:00
select CURRENT_THREAD_USE_NO_TLS if USERSPACE
xtensa: mmu: Initial implementation Initial support for Xtensa MMU version 3. It is using a two level page table based on fact that the page table is in the virtual space. Only the top level (page directory) is wired mapped in the TLB to avoid second level page miss. The mapped memory is completely fragmented in multiple sections, maybe we find a better way in future. The exception handler is where we effectively map the memory, the way it works is: 1) SW try to access some memory address 2) The address is not mapped, so the MMU will try the auto-refill, looking the page table 3) The page table contents is not mapped (remember, just the top-level page is mapped) 4) An exception will be triggered, in the exception we try to read the portion of the page table that maps the original address 5) The address is not mapped, so the MMU will try again the auto-refill. This time though, the address is mapped by the top level page that is properly mapped. (The top-level page maps the page table itself). Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-05-09 23:44:22 +02:00
help
Enable support for Xtensa Memory Management Unit.
if XTENSA_MMU
xtensa: cleanup Kconfig file * Wording on CONFIG_SIMULATOR_XTENSA * Remove "default n" as default is no anyway. * Remove some tabs as we almost never indent inside a if block in Zephyr. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-12-06 20:33:11 +01:00
choice
prompt "PageTable virtual address"
default XTENSA_MMU_PTEVADDR_20000000
help
The virtual address for Xtensa page table (PTEVADDR).
config XTENSA_MMU_PTEVADDR_20000000
bool "0x20000000"
endchoice
config XTENSA_MMU_PTEVADDR
hex
default 0x20000000 if XTENSA_MMU_PTEVADDR_20000000
help
The virtual address for Xtensa page table (PTEVADDR).
config XTENSA_MMU_PTEVADDR_SHIFT
int
default 29 if XTENSA_MMU_PTEVADDR_20000000
help
The bit shift number for the virtual address for Xtensa
page table (PTEVADDR).
config XTENSA_MMU_NUM_L1_TABLES
int "Number of L1 page tables"
default 1 if !USERSPACE
default 4
help
This option specifies the maximum number of traslation tables.
Translation tables are directly related to the number of
memory domains in the target, considering the kernel itself requires one.
config XTENSA_MMU_NUM_L2_TABLES
int "Number of L2 page tables"
default 20 if USERSPACE
default 10
help
Each table can address up to 4MB memory address.
config XTENSA_MMU_DOUBLE_MAP
bool "Map memory in cached and uncached region"
help
This option specifies that the memory is mapped in two
distinct region, cached and uncached.
xtensa: mmu: Add option to map memory in cached/uncached Add a build option to tell if memory should be mapped in cached and uncachedr regions. If the memory is neither in cached nor uncached region it is not double mapped. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2022-11-17 23:49:35 +01:00
xtensa: mmu: invalidate mem domain TLBs during page table swap This adds a kconfig to enable invalidating the TLBs related to the incoming thread's memory domain during page table swaps. It provides a workaround, if needed, to clear out stale TLB entries used by the thread being swapped out. Those stale entries may contain incorrect permissions and rings. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2023-12-02 01:51:46 +01:00
config XTENSA_INVALIDATE_MEM_DOMAIN_TLB_ON_SWAP
bool
help
This invalidates all TLBs referred by the incoming thread's
memory domain when swapping page tables.
xtensa: use CONFIG_PRIVILEGED_STACK_SIZE for stack size Instead of using CONFIG_MMU_PAGE_SIZE for size of the privileged stack, use the actual kconfig CONFIG_PRIVILEGED_STACK_SIZE. This allows for changing the size of privileged stack, and also aligns to the usage of CONFIG_PRIVILEGED_STACK_SIZE. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-03-04 20:32:42 +01:00
config PRIVILEGED_STACK_SIZE
# Must be multiple of CONFIG_MMU_PAGE_SIZE
default 4096
xtensa: mmu: Initial implementation Initial support for Xtensa MMU version 3. It is using a two level page table based on fact that the page table is in the virtual space. Only the top level (page directory) is wired mapped in the TLB to avoid second level page miss. The mapped memory is completely fragmented in multiple sections, maybe we find a better way in future. The exception handler is where we effectively map the memory, the way it works is: 1) SW try to access some memory address 2) The address is not mapped, so the MMU will try the auto-refill, looking the page table 3) The page table contents is not mapped (remember, just the top-level page is mapped) 4) An exception will be triggered, in the exception we try to read the portion of the page table that maps the original address 5) The address is not mapped, so the MMU will try again the auto-refill. This time though, the address is mapped by the top level page that is properly mapped. (The top-level page maps the page table itself). Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-05-09 23:44:22 +02:00
endif # XTENSA_MMU
xtensa: move two kconfigs out of CPU_HAS_MMU block Both CONFIG_XTENSA_SYSCALL_USE_HELPER and CONFIG_XTENSA_INSECURE_USERSPACE are also applicable to MPU. So move them out of the CPU_HAS_MMU block. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-29 21:14:15 +01:00
endif # CPU_HAS_MMU
xtensa: add MPU support for kernel mode This enables support for MPU on Xtensa. Currently this is for kernel mode only. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-03-16 01:37:23 +01:00
if CPU_HAS_MPU
menuconfig XTENSA_MPU
bool "Xtensa MPU Support"
select MPU
select SRAM_REGION_PERMISSIONS
select XTENSA_SMALL_VECTOR_TABLE_ENTRY
xtensa: mpu: enable userspace support This extends the Xtensa MPU to support userspace. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-30 23:33:42 +01:00
select ARCH_MEM_DOMAIN_SYNCHRONOUS_API if USERSPACE
select CURRENT_THREAD_USE_NO_TLS if USERSPACE
xtensa: add MPU support for kernel mode This enables support for MPU on Xtensa. Currently this is for kernel mode only. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-03-16 01:37:23 +01:00
select EXPERIMENTAL
# TODO: the target the MPU code developed on (basically sample_controller
# plus MPU minus s32c1i) does not have cache or SMP capability.
# Need to verify functionalities with targets supporting these.
depends on !CACHE && !SMP
help
Enable support for Xtensa Memory Protection Unit.
if XTENSA_MPU
config XTENSA_MPU_DEFAULT_MEM_TYPE
hex "Default Memory Type"
default 0x18
help
Default memory type for memory regions: non-cacheable memory,
non-shareable, non-bufferable and interruptible.
xtensa: mpu: enable userspace support This extends the Xtensa MPU to support userspace. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-30 23:33:42 +01:00
If userspace is enabled, it will be used to restore the memory type of
the region being removed from a memory domain.
xtensa: mpu: introduce CONFIG_XTENSA_MPU_ONLY_SOC_RANGES This allows the SoC to have total control on what MPU ranges to be programmed at boot. This overrides the generic ranges in the architecture core code. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-02-16 21:30:18 +01:00
config XTENSA_MPU_ONLY_SOC_RANGES
bool
help
Enable this by the SoC to indicate to the architecture code to use
the MPU ranges specified by SoC only, and skip the common ranges
defined in the core architecture code. This gives total control to
the SoC on the MPU ranges.
xtensa: add MPU support for kernel mode This enables support for MPU on Xtensa. Currently this is for kernel mode only. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-03-16 01:37:23 +01:00
endif # XTENSA_MPU
endif # CPU_HAS_MPU
xtensa: Enable userspace Userspace support for Xtensa architecture using Xtensa MMU. Some considerations: - Syscalls are not inline functions like in other architectures because some compiler issues when using multiple registers to pass parameters to the syscall. So here we have a function call so we can use registers as we need. - TLS is not supported by xcc in xtensa and reading PS register is a privileged instruction. So, we have to use threadptr to know if a thread is an user mode thread. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com> Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2022-12-14 09:35:36 +01:00
config XTENSA_SYSCALL_USE_HELPER
bool "Use userspace syscall helper"
arch: xtensa: check for xt-clang instead of xcc-clang Check against new variant name. xcc-clang usage is deprecated. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2023-02-25 01:42:14 +01:00
default y if "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "xt-clang"
xtensa: mpu: enable userspace support This extends the Xtensa MPU to support userspace. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-30 23:33:42 +01:00
depends on (XTENSA_MMU || XTENSA_MPU) && USERSPACE
xtensa: Enable userspace Userspace support for Xtensa architecture using Xtensa MMU. Some considerations: - Syscalls are not inline functions like in other architectures because some compiler issues when using multiple registers to pass parameters to the syscall. So here we have a function call so we can use registers as we need. - TLS is not supported by xcc in xtensa and reading PS register is a privileged instruction. So, we have to use threadptr to know if a thread is an user mode thread. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com> Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2022-12-14 09:35:36 +01:00
help
Use syscall helpers for passing more then 3 arguments.
This is a workaround for toolchains where they have
issue modeling register usage.
xtensa: userspace: Warning about impl security Add a Kconfig option (and build warning) alerting about the problem of the kernel spilling register in behave of the userspace. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-10-18 00:50:31 +02:00
config XTENSA_INSECURE_USERSPACE
bool
xtensa: move two kconfigs out of CPU_HAS_MMU block Both CONFIG_XTENSA_SYSCALL_USE_HELPER and CONFIG_XTENSA_INSECURE_USERSPACE are also applicable to MPU. So move them out of the CPU_HAS_MMU block. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-29 21:14:15 +01:00
default y
xtensa: mpu: enable userspace support This extends the Xtensa MPU to support userspace. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2024-01-30 23:33:42 +01:00
depends on (XTENSA_MMU || XTENSA_MPU) && USERSPACE
xtensa: mmu: Initial implementation Initial support for Xtensa MMU version 3. It is using a two level page table based on fact that the page table is in the virtual space. Only the top level (page directory) is wired mapped in the TLB to avoid second level page miss. The mapped memory is completely fragmented in multiple sections, maybe we find a better way in future. The exception handler is where we effectively map the memory, the way it works is: 1) SW try to access some memory address 2) The address is not mapped, so the MMU will try the auto-refill, looking the page table 3) The page table contents is not mapped (remember, just the top-level page is mapped) 4) An exception will be triggered, in the exception we try to read the portion of the page table that maps the original address 5) The address is not mapped, so the MMU will try again the auto-refill. This time though, the address is mapped by the top level page that is properly mapped. (The top-level page maps the page table itself). Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-05-09 23:44:22 +02:00
Xtensa port: Started port to for Xtensa cores family. Added arch sub folder, make files and Kconfig files for a set of standard SoCs. Change-Id: I4ee9cba966860072e55c95795d87356b665e4d49 Signed-off-by: Mazen NEIFER <mazen@nestwave.com>
2017-01-13 12:14:33 +01:00
endmenu
Copy permalink