2019-11-01 13:45:29 +01:00
# General architecture configuration options
2015-05-20 11:40:39 -05:00
# Copyright (c) 2014-2015 Wind River Systems, Inc.
# Copyright (c) 2015 Intel Corporation
2017-01-13 12:14:33 +01:00
# Copyright (c) 2016 Cadence Design Systems, Inc.
2017-01-18 17:01:01 -08:00
# SPDX-License-Identifier: Apache-2.0
2015-05-20 11:40:39 -05:00
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
# Include these first so that any properties (e.g. defaults) below can be
2019-06-18 14:45:40 -04:00
# overridden (by defining symbols in multiple locations)
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
2024-11-14 08:48:17 +00:00
source "$(KCONFIG_BINARY_DIR)/arch/Kconfig"
2022-09-14 22:23:15 +02:00
# ToDo: Generate a Kconfig.arch for loading of additional arch in HWMv2.
osource "$(KCONFIG_BINARY_DIR)/Kconfig.arch"
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
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
# Architecture symbols
#
# Should be 'select'ed by low-level symbols like SOC_SERIES_* or, lacking that,
# by SOC_*.
2015-10-09 06:20:52 -04:00
config ARC
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2020-08-02 10:45:10 -04:00
imply XIP
2020-10-30 10:21:40 -07:00
select ARCH_HAS_THREAD_LOCAL_STORAGE
2023-06-04 00:52:43 +03:00
select ARCH_SUPPORTS_ROM_START
2024-03-04 10:52:24 -05:00
select ARCH_HAS_DIRECTED_IPIS
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
ARC architecture
2015-10-09 06:20:52 -04:00
config ARM
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2020-08-18 12:55:08 -07:00
select ARCH_SUPPORTS_COREDUMP if CPU_CORTEX_M
2024-07-10 11:52:17 -07:00
select ARCH_SUPPORTS_COREDUMP_THREADS if CPU_CORTEX_M
2025-04-14 15:25:48 +02:00
select ARCH_SUPPORTS_COREDUMP_STACK_PTR if CPU_CORTEX_M
2020-03-11 10:56:19 -07:00
# FIXME: current state of the code for all ARM requires this, but
# is really only necessary for Cortex-M with ARM MPU!
2021-03-25 11:56:15 +01:00
select GEN_PRIV_STACKS
2021-12-20 14:56:39 -08:00
select ARCH_HAS_THREAD_LOCAL_STORAGE if CPU_AARCH32_CORTEX_R || CPU_CORTEX_M || CPU_AARCH32_CORTEX_A
2023-05-02 09:35:30 +02:00
select BARRIER_OPERATIONS_ARCH
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
ARM architecture
2015-10-09 06:20:52 -04:00
2021-03-25 11:56:15 +01:00
config ARM64
bool
select ARCH_IS_SET
select 64BIT
2023-06-30 17:51:25 +02:00
select ARCH_SUPPORTS_COREDUMP
2021-03-25 11:56:15 +01:00
select HAS_ARM_SMCCC
select ARCH_HAS_THREAD_LOCAL_STORAGE
select USE_SWITCH
select USE_SWITCH_SUPPORTED
2023-05-02 11:00:08 +02:00
select BARRIER_OPERATIONS_ARCH
2024-03-04 10:52:24 -05:00
select ARCH_HAS_DIRECTED_IPIS
2024-05-28 22:19:56 -04:00
select ARCH_HAS_DEMAND_PAGING
select ARCH_HAS_DEMAND_MAPPING
2024-11-12 14:06:11 -08:00
select ARCH_SUPPORTS_EVICTION_TRACKING
select EVICTION_TRACKING if DEMAND_PAGING
2026-04-09 05:57:00 -04:00
select MEM_DOMAIN_HAS_THREAD_LIST if ARM_MPU && USERSPACE
2021-03-25 11:56:15 +01:00
help
ARM64 (AArch64) architecture
2020-12-01 13:29:58 +03:00
config MIPS
bool
select ARCH_IS_SET
select ATOMIC_OPERATIONS_C
help
MIPS architecture
2025-10-23 14:44:12 -07:00
config OPENRISC
bool
select ARCH_IS_SET
select ATOMIC_OPERATIONS_BUILTIN
select BIG_ENDIAN
select USE_SWITCH
select USE_SWITCH_SUPPORTED
2026-03-27 09:08:26 +01:00
select ARCH_HAS_THREAD_LOCAL_STORAGE
2025-10-23 14:44:12 -07:00
help
OpenRISC architecture
2020-10-16 20:53:59 +02:00
config SPARC
bool
select ARCH_IS_SET
select USE_SWITCH
select USE_SWITCH_SUPPORTED
select BIG_ENDIAN
select ATOMIC_OPERATIONS_BUILTIN if SPARC_CASA
select ATOMIC_OPERATIONS_C if !SPARC_CASA
2020-10-27 12:31:41 +01:00
select ARCH_HAS_THREAD_LOCAL_STORAGE
2021-02-16 15:38:58 +01:00
select ARCH_HAS_EXTRA_EXCEPTION_INFO
2020-10-16 20:53:59 +02:00
help
SPARC architecture
2015-10-09 06:20:52 -04:00
config X86
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2016-07-15 13:15:00 -07:00
select ATOMIC_OPERATIONS_BUILTIN
2020-08-13 19:18:52 -07:00
select ARCH_SUPPORTS_COREDUMP
2024-09-16 12:37:52 -07:00
select ARCH_SUPPORTS_COREDUMP_PRIV_STACKS
2023-06-04 00:52:43 +03:00
select ARCH_SUPPORTS_ROM_START if !X86_64
2020-06-12 16:50:16 -07:00
select CPU_HAS_MMU
2020-10-27 11:27:37 -07:00
select ARCH_MEM_DOMAIN_DATA if USERSPACE && !X86_COMMON_PAGE_TABLE
2020-08-25 17:02:38 -07:00
select ARCH_MEM_DOMAIN_SYNCHRONOUS_API if USERSPACE
2020-05-21 16:55:28 -07:00
select ARCH_HAS_GDBSTUB if !X86_64
2020-08-27 23:07:01 -04:00
select ARCH_HAS_TIMING_FUNCTIONS
2020-09-29 15:32:35 -07:00
select ARCH_HAS_THREAD_LOCAL_STORAGE
2024-03-12 16:23:17 -07:00
select ARCH_HAS_DEMAND_PAGING if !X86_64
2024-09-10 23:00:06 -04:00
select ARCH_HAS_DEMAND_MAPPING if ARCH_HAS_DEMAND_PAGING
2021-03-31 14:51:58 -07:00
select NEED_LIBC_MEM_PARTITION if USERSPACE && TIMING_FUNCTIONS \
&& !BOARD_HAS_TIMING_FUNCTIONS \
&& !SOC_HAS_TIMING_FUNCTIONS
2023-08-01 15:07:57 -07:00
select ARCH_HAS_STACK_CANARIES_TLS
2024-04-01 13:05:43 -07:00
select ARCH_SUPPORTS_MEM_MAPPED_STACKS if X86_MMU && !DEMAND_PAGING
2024-07-30 12:30:32 -07:00
select ARCH_HAS_THREAD_PRIV_STACK_SPACE_GET if USERSPACE
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
x86 architecture
2015-10-09 06:20:52 -04:00
2019-07-17 13:17:05 -04:00
config RISCV
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2025-06-26 12:04:24 +02:00
select ATOMIC_OPERATIONS_C if !RISCV_ISA_EXT_A
select ATOMIC_OPERATIONS_BUILTIN if RISCV_ISA_EXT_A
2021-11-12 13:21:43 -08:00
select ARCH_SUPPORTS_COREDUMP
2024-09-18 09:32:49 -07:00
select ARCH_SUPPORTS_COREDUMP_PRIV_STACKS
2026-02-12 23:36:49 -05:00
select ARCH_SUPPORTS_COREDUMP_THREADS if !SMP
select ARCH_SUPPORTS_COREDUMP_STACK_PTR
2024-05-29 17:58:15 -03:00
select ARCH_SUPPORTS_ROM_START if !SOC_FAMILY_ESPRESSIF_ESP32
2024-06-21 16:06:03 +02:00
select ARCH_SUPPORTS_EMPTY_IRQ_SPURIOUS
2022-08-19 15:29:10 +10:00
select ARCH_HAS_CODE_DATA_RELOCATION
2020-10-02 13:09:32 -07:00
select ARCH_HAS_THREAD_LOCAL_STORAGE
2022-03-07 17:01:36 -05:00
select USE_SWITCH_SUPPORTED
select USE_SWITCH
2022-01-05 14:33:11 -08:00
select SCHED_IPI_SUPPORTED if SMP
2024-03-04 10:52:24 -05:00
select ARCH_HAS_DIRECTED_IPIS
2026-02-20 16:43:43 -07:00
select BARRIER_OPERATIONS_BUILTIN if RISCV_ISA_BASE_FENCE
2024-07-31 12:57:24 -07:00
select ARCH_HAS_THREAD_PRIV_STACK_SPACE_GET if USERSPACE
2026-01-19 15:05:42 +01:00
depends on DT_HAS_RISCV_ENABLED
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
RISCV architecture
arch: added support for the riscv32 architecture
RISC-V is an open-source instruction set architecture.
Added support for the 32bit version of RISC-V to Zephyr.
1) exceptions/interrupts/faults are handled at the architecture
level via the __irq_wrapper handler. Context saving/restoring
of registers can be handled at both architecture and SOC levels.
If SOC-specific registers need to be saved, SOC level needs to
provide __soc_save_context and __soc_restore_context functions
that shall be accounted by the architecture level, when
corresponding config variable RISCV_SOC_CONTEXT_SAVE is set.
2) As RISC-V architecture does not provide a clear ISA specification
about interrupt handling, each RISC-V SOC handles it in its own
way. Hence, at the architecture level, the __irq_wrapper handler
expects the following functions to be provided by the SOC level:
__soc_is_irq: to check if the exception is the result of an
interrupt or not.
__soc_handle_irq: handle pending IRQ at SOC level (ex: clear
pending IRQ in SOC-specific IRQ register)
3) Thread/task scheduling, as well as IRQ offloading are handled via
the RISC-V system call ("ecall"), which is also handled via the
__irq_wrapper handler. The _Swap asm function just calls "ecall"
to generate an exception.
4) As there is no conventional way of handling CPU power save in
RISC-V, the default nano_cpu_idle and nano_cpu_atomic_idle
functions just unlock interrupts and return to the caller, without
issuing any CPU power saving instruction. Nonetheless, to allow
SOC-level to implement proper CPU power save, nano_cpu_idle and
nano_cpu_atomic_idle functions are defined as __weak
at the architecture level.
Change-Id: I980a161d0009f3f404ad22b226a6229fbb492389
Signed-off-by: Jean-Paul Etienne <fractalclone@gmail.com>
2017-01-11 00:24:30 +01:00
2017-01-13 12:14:33 +01:00
config XTENSA
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2019-08-13 14:02:29 -07:00
select USE_SWITCH
select USE_SWITCH_SUPPORTED
2022-10-19 12:25:12 -07:00
select ARCH_HAS_CODE_DATA_RELOCATION
2022-06-06 07:49:27 -07:00
select ARCH_HAS_TIMING_FUNCTIONS
2022-12-14 00:35:36 -08:00
select ARCH_MEM_DOMAIN_DATA if USERSPACE
2024-03-04 10:52:24 -05:00
select ARCH_HAS_DIRECTED_IPIS
2024-03-29 13:52:33 -07:00
select THREAD_STACK_INFO
2024-07-31 12:17:40 -07:00
select ARCH_HAS_THREAD_PRIV_STACK_SPACE_GET if USERSPACE
2025-08-06 11:39:21 -07:00
select ARCH_SUPPORTS_COREDUMP_STACK_PTR if !SMP
2025-10-31 10:06:27 -07:00
select ARCH_HAS_USERSPACE if XTENSA_MMU || XTENSA_MPU
2025-10-31 10:13:27 -07:00
imply ARCH_HAS_RESERVED_PAGE_FRAMES if XTENSA_MMU
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
Xtensa architecture
2017-01-13 12:14:33 +01:00
2017-10-03 16:31:55 +02:00
config ARCH_POSIX
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
bool
2020-02-07 00:48:22 +01:00
select ARCH_IS_SET
2017-10-03 16:31:55 +02:00
select ATOMIC_OPERATIONS_BUILTIN
select ARCH_HAS_CUSTOM_SWAP_TO_MAIN
select ARCH_HAS_CUSTOM_BUSY_WAIT
select ARCH_HAS_THREAD_ABORT
2024-08-07 23:07:01 +02:00
select ARCH_HAS_THREAD_NAME_HOOK
2023-05-26 13:23:43 +02:00
select NATIVE_BUILD
2019-02-03 13:04:17 +01:00
select HAS_COVERAGE_SUPPORT
2023-05-25 10:38:53 +02:00
select BARRIER_OPERATIONS_BUILTIN
2023-12-05 17:10:46 +01:00
# POSIX arch based targets get their memory cleared on entry by the host OS
2023-10-27 18:33:15 +03:00
select SKIP_BSS_CLEAR
kconfig: Remove assignments to CONFIG_<arch> syms and hide them
All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-06 18:26:14 +01:00
help
POSIX (native) architecture
2017-09-08 21:14:06 -04:00
2025-03-31 16:30:38 +07:00
config RX
bool
select ARCH_IS_SET
select ATOMIC_OPERATIONS_C
select USE_SWITCH
select USE_SWITCH_SUPPORTED
help
Renesas RX architecture
2020-02-07 00:48:22 +01:00
config ARCH_IS_SET
bool
help
Helper symbol to detect SoCs forgetting to select one of the arch
symbols above. See the top-level CMakeLists.txt.
2017-09-08 21:14:06 -04:00
menu "General Architecture Options"
2022-08-05 10:56:30 +02:00
source "arch/common/Kconfig"
2022-03-30 17:51:54 +10:00
2018-09-17 09:56:20 -05:00
module = ARCH
module-str = arch
source "subsys/logging/Kconfig.template.log_config"
2018-10-09 18:59:16 +09:00
config BIG_ENDIAN
2019-11-01 10:24:07 +01:00
bool
help
This option tells the build system that the target system is big-endian.
Little-endian architecture is the default and should leave this option
unselected. This option is selected by arch/$ARCH/Kconfig,
soc/**/Kconfig, or boards/**/Kconfig and the user should generally avoid
2024-05-31 17:42:41 +09:00
modifying it. The option is used to select linker script OUTPUT_FORMAT,
the toolchain flags (TOOLCHAIN_C_FLAGS, TOOLCHAIN_LD_FLAGS), and command
line option for gen_isr_tables.py.
2018-10-09 18:59:16 +09:00
2022-10-28 10:27:41 +02:00
config LITTLE_ENDIAN
# Hidden Kconfig option representing the default little-endian architecture
# This is just the opposite of BIG_ENDIAN and is used for non-negative
# conditional compilation
bool
depends on !BIG_ENDIAN
default y
2019-05-17 15:15:24 -04:00
config 64BIT
bool
help
This option tells the build system that the target system is
using a 64-bit address space, meaning that pointer and long types
are 64 bits wide. This option is selected by arch/$ARCH/Kconfig,
soc/**/Kconfig, or boards/**/Kconfig and the user should generally
avoid modifying it.
2019-08-28 09:29:26 -05:00
# Workaround for not being able to have commas in macro arguments
DT_CHOSEN_Z_SRAM := zephyr,sram
2018-12-07 10:35:04 -06:00
config SRAM_SIZE
int "SRAM Size in kB"
2019-10-23 15:15:59 -05:00
default $(dt_chosen_reg_size_int,$(DT_CHOSEN_Z_SRAM),0,K)
2018-12-07 10:35:04 -06:00
help
2019-12-26 16:08:19 +01:00
The SRAM size in kB. The default value comes from /chosen/zephyr,sram in
devicetree. The user should generally avoid changing it via menuconfig or
in configuration files.
2018-12-07 10:35:04 -06:00
config SRAM_BASE_ADDRESS
hex "SRAM Base Address"
2019-10-23 15:15:59 -05:00
default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_SRAM))
2018-12-07 10:35:04 -06:00
help
2024-06-21 18:37:21 +10:00
The SRAM base address. The default value comes from
2019-12-26 16:08:19 +01:00
/chosen/zephyr,sram in devicetree. The user should generally avoid
changing it via menuconfig or in configuration files.
2025-07-16 21:19:28 -04:00
config XIP
bool "Execute in place"
help
This option allows zephyr to operate with its text and read-only
sections residing in ROM (or similar read-only memory). Not all boards
support this option so it must be used with care; you must also
supply a linker command file when building your image. Enabling this
option increases both the code and data footprint of the image.
2025-10-23 14:44:12 -07:00
if ARC || ARM || ARM64 || X86 || RISCV || RX || OPENRISC || ARCH_POSIX
2018-12-07 10:35:04 -06:00
2019-08-28 09:29:26 -05:00
# Workaround for not being able to have commas in macro arguments
DT_CHOSEN_Z_FLASH := zephyr,flash
2018-12-07 10:35:04 -06:00
config FLASH_SIZE
int "Flash Size in kB"
2021-03-25 11:56:15 +01:00
default $(dt_chosen_reg_size_int,$(DT_CHOSEN_Z_FLASH),0,K) if (XIP && (ARM ||ARM64)) || !ARM
2024-06-11 15:21:33 +12:00
default 0 if !XIP
2018-12-07 10:35:04 -06:00
help
This option specifies the size of the flash in kB. It is normally set by
the board's defconfig file and the user should generally avoid modifying
it via the menu configuration.
config FLASH_BASE_ADDRESS
hex "Flash Base Address"
2021-03-25 11:56:15 +01:00
default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_FLASH)) if (XIP && (ARM || ARM64)) || !ARM
2024-06-11 15:21:33 +12:00
default 0 if !XIP
2018-12-07 10:35:04 -06:00
help
2019-02-12 15:16:16 +01:00
This option specifies the base address of the flash on the board. It is
2018-12-07 10:35:04 -06:00
normally set by the board's defconfig file and the user should generally
avoid modifying it via the menu configuration.
2025-10-23 14:44:12 -07:00
endif # ARM || ARM64 || ARC || X86 || RISCV || RX || OPENRISC || ARCH_POSIX
2018-12-07 10:35:04 -06:00
2018-10-12 09:27:28 +02:00
if ARCH_HAS_TRUSTED_EXECUTION
config TRUSTED_EXECUTION_SECURE
bool "Trusted Execution: Secure firmware image"
help
Select this option to enable building a Secure firmware
image for a platform that supports Trusted Execution. A
Secure firmware image will execute in Secure state. It may
allow the CPU to execute in Non-Secure (Normal) state.
Therefore, a Secure firmware image shall be able to
configure security attributions of CPU resources (memory
areas, peripherals, interrupts, etc.) as well as to handle
faults, related to security violations. It may optionally
allow certain functions to be called from the Non-Secure
(Normal) domain.
config TRUSTED_EXECUTION_NONSECURE
depends on !TRUSTED_EXECUTION_SECURE
bool "Trusted Execution: Non-Secure firmware image"
help
Select this option to enable building a Non-Secure
firmware image for a platform that supports Trusted
Execution. A Non-Secure firmware image will execute
in Non-Secure (Normal) state. Therefore, it shall not
access CPU resources (memory areas, peripherals,
interrupts etc.) belonging to the Secure domain.
endif # ARCH_HAS_TRUSTED_EXECUTION
2017-09-08 21:14:06 -04:00
config HW_STACK_PROTECTION
bool "Hardware Stack Protection"
depends on ARCH_HAS_STACK_PROTECTION
help
2017-12-13 10:08:21 -05:00
Select this option to enable hardware-based platform features to
catch stack overflows when the system is running in privileged
mode. If CONFIG_USERSPACE is not enabled, the system is always
running in privileged mode.
2017-11-06 11:42:54 -08:00
2017-12-13 10:08:21 -05:00
Note that this does not necessarily prevent corruption and assertions
about the overall system state when a fault is triggered cannot be
made.
2017-09-08 21:14:06 -04:00
2017-09-11 10:34:49 -07:00
config USERSPACE
2019-01-18 11:41:06 -08:00
bool "User mode threads"
2017-09-11 10:34:49 -07:00
depends on ARCH_HAS_USERSPACE
2019-11-24 11:28:38 -05:00
depends on RUNTIME_ERROR_CHECKS
2020-11-05 14:30:20 -08:00
depends on SRAM_REGION_PERMISSIONS
2020-11-12 14:44:14 +01:00
select THREAD_STACK_INFO
2023-01-12 07:28:36 -08:00
select LINKER_USE_NO_RELAX
2017-09-11 10:34:49 -07:00
help
2017-12-13 10:08:21 -05:00
When enabled, threads may be created or dropped down to user mode,
which has significantly restricted permissions and must interact
with the kernel via system calls. See Zephyr documentation for more
2021-07-15 10:08:48 +00:00
details about this feature.
2017-09-11 10:34:49 -07:00
2017-12-13 10:08:21 -05:00
If a user thread overflows its stack, this will be caught and the
kernel itself will be shielded from harm. Enabling this option
may or may not catch stack overflows when the system is in
privileged mode or handling a system call; to ensure these are always
caught, enable CONFIG_HW_STACK_PROTECTION.
2017-11-06 11:42:54 -08:00
2025-07-22 16:24:59 -07:00
config NOINIT_SNIPPET_FIRST
bool "Place the no-init linker script snippet first"
help
By default the include/zephyr/linker/common-noinit.ld file inserts the
snippets-noinit.ld file at the end of the section. There are times when
the directives in the snippets-noinit.ld file apply to the other directives
in this file. And in that case the include statement for the snippets-noinit.ld
file needs to come at the start of the section. This configuration option
allows that to happen.
2018-02-01 01:19:49 -06:00
config PRIVILEGED_STACK_SIZE
int "Size of privileged stack"
2023-01-27 16:23:54 -07:00
default 2048 if EMUL
2019-03-28 16:48:43 -07:00
default 1024
2025-03-04 11:02:12 +10:00
depends on USERSPACE
2018-02-01 01:19:49 -06:00
help
2018-02-15 07:36:16 -06:00
This option sets the privileged stack region size that will be used
in addition to the user mode thread stack. During normal execution,
this region will be inaccessible from user mode. During system calls,
2020-03-11 10:56:19 -07:00
this region will be utilized by the system call. This value must be
a multiple of the minimum stack alignment.
2018-10-07 11:41:18 -04:00
config KOBJECT_TEXT_AREA
2021-03-18 14:00:07 -07:00
int "Size of kobject text area"
2025-04-07 15:23:02 -07:00
default 1024 if UBSAN
2018-08-29 16:44:16 +05:30
default 512 if COVERAGE_GCOV
2019-03-15 10:54:06 +01:00
default 512 if NO_OPTIMIZATIONS
2020-10-29 19:20:06 +01:00
default 512 if STACK_CANARIES && RISCV
2019-02-20 14:49:36 -08:00
default 256
2025-03-04 11:02:12 +10:00
depends on USERSPACE
2018-10-07 11:41:18 -04:00
help
Size of kernel object text area. Used in linker script.
2021-03-18 14:00:07 -07:00
config KOBJECT_DATA_AREA_RESERVE_EXTRA_PERCENT
int "Reserve extra kobject data area (in percentage)"
default 100
2025-03-04 11:02:12 +10:00
depends on USERSPACE
2021-03-18 14:00:07 -07:00
help
Multiplication factor used to calculate the size of placeholder to
reserve space for kobject metadata hash table. The hash table is
generated via gperf is highly dependent on the absolute addresses of
kobjects which might change between prebuilts. To reserve enough
space for the hash table during final linking passes to keep
kobjects in same place, the size of reserved space is calculated
from the first prebuilt plus additional space calculated with
this percentage (of the kobject data area in first prebuilt).
config KOBJECT_RODATA_AREA_EXTRA_BYTES
int "Reserve extra bytes for kobject rodata area"
default 16
2025-03-04 11:02:12 +10:00
depends on USERSPACE
2021-03-18 14:00:07 -07:00
help
Reserve a few more bytes for the RODATA region for kobject metadata.
This is to account for the uncertainty of tables generated by gperf.
2020-03-11 10:56:19 -07:00
config GEN_PRIV_STACKS
bool
help
Selected if the architecture requires that privilege elevation stacks
be allocated in a separate memory area. This is typical of arches
whose MPUs require regions to be power-of-two aligned/sized.
FIXME: This should be removed and replaced with checks against
CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT, but both ARM and ARC
changes will be necessary for this.
2018-03-06 13:17:57 -08:00
config STACK_GROWS_UP
bool "Stack grows towards higher memory addresses"
help
Select this option if the architecture has upward growing thread
stacks. This is not common.
2020-02-05 10:41:58 -08:00
config NO_UNUSED_STACK_INSPECTION
bool
help
Selected if the architecture will generate a fault if unused stack
memory is examined, which is the region between the current stack
pointer and the deepest available address in the current stack
region.
2017-09-11 10:34:49 -07:00
config MAX_THREAD_BYTES
int "Bytes to use when tracking object thread permissions"
default 2
depends on USERSPACE
help
2017-12-13 10:08:21 -05:00
Every kernel object will have an associated bitfield to store
thread permissions for that object. This controls the size of the
bitfield (in bytes) and imposes a limit on how many threads can
be created in the system.
2017-09-11 10:34:49 -07:00
2017-11-08 16:38:03 -08:00
config DYNAMIC_OBJECTS
2018-04-24 17:01:37 -07:00
bool "Allow kernel objects to be allocated at runtime"
2017-11-08 16:38:03 -08:00
depends on USERSPACE
help
2019-11-01 10:24:07 +01:00
Enabling this option allows for kernel objects to be requested from
the calling thread's resource pool, at a slight cost in performance
due to the supplemental run-time tables required to validate such
objects.
Objects allocated in this way can be freed with a supervisor-only
API call, or when the number of references to that object drops to
zero.
2017-11-08 16:38:03 -08:00
2026-02-17 11:34:14 -08:00
config DYNAMIC_OBJECTS_FORCE_STACK_CACHED
bool "Force allocated thread stack objects to be in cached area"
default y
depends on USERSPACE
depends on KERNEL_COHERENCE
help
With kernel coherence enabled, it is possible that the stack has been
allocated on uncached area, which has performance implications.
If this is enabled, the stack pointer will be forcibly converted to be
in cached area.
2018-11-07 23:40:43 +01:00
config NOCACHE_MEMORY
bool "Support for uncached memory"
2020-02-09 22:26:07 +01:00
depends on ARCH_HAS_NOCACHE_MEMORY_SUPPORT
2018-11-07 23:40:43 +01:00
help
Add a "nocache" read-write memory section that is configured to
not be cached. This memory section can be used to perform DMA
transfers when cache coherence issues are not optimal or can not
be solved using cache maintenance operations.
2024-05-13 13:12:12 +08:00
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
select OVERRIDE_FRAME_POINTER_DEFAULT
help
Select Y here to gain precise stack traces at the expense of slightly
increased size and decreased speed.
2024-08-14 16:39:03 +08:00
config ARCH_STACKWALK
bool "Compile the stack walking function"
default y
depends on ARCH_HAS_STACKWALK
help
Select Y here to compile the `arch_stack_walk()` function
2024-05-31 18:01:06 +08:00
config ARCH_STACKWALK_MAX_FRAMES
int "Max depth for stack walk function"
default 8
2024-08-14 16:39:03 +08:00
depends on ARCH_STACKWALK
2024-05-31 18:01:06 +08:00
help
Depending on implementation, this can place a hard limit on the depths of the stack
for the stack walk function to examine.
2017-09-09 08:39:38 -04:00
menu "Interrupt Configuration"
2019-12-21 08:17:02 +01:00
2025-06-05 11:47:56 -06:00
config TOOLCHAIN_SUPPORTS_ISR_TABLES_LOCAL_DECLARATION
bool
help
Hidden option to signal that toolchain supports local declaration of
interrupt tables.
2023-10-17 17:41:17 +02:00
config ISR_TABLES_LOCAL_DECLARATION_SUPPORTED
bool
default y
# Userspace is currently not supported
depends on !USERSPACE
# List of currently supported architectures
2025-06-03 06:03:00 -07:00
depends on ARM || ARM64 || RISCV
2023-10-17 17:41:17 +02:00
# List of currently supported toolchains
2025-06-05 11:47:56 -06:00
depends on "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "zephyr" || "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "gnuarmemb" || "$(ZEPHYR_TOOLCHAIN_VARIANT)" = "llvm" || TOOLCHAIN_SUPPORTS_ISR_TABLES_LOCAL_DECLARATION
2023-10-17 17:41:17 +02:00
config ISR_TABLES_LOCAL_DECLARATION
2024-11-29 15:14:43 +01:00
bool "ISR tables created locally and placed by linker"
2023-10-17 17:41:17 +02:00
depends on ISR_TABLES_LOCAL_DECLARATION_SUPPORTED
2026-03-06 13:48:33 +01:00
depends on GEN_IRQ_VECTOR_TABLE
2023-10-17 17:41:17 +02:00
help
Enable new scheme of interrupt tables generation.
This is totally different generator that would create tables entries locally
where the IRQ_CONNECT macro is called and then use the linker script to position it
in the right place in memory.
The most important advantage of such approach is that the generated interrupt tables
are LTO compatible.
The drawback is that the support on the architecture port is required.
2018-10-30 16:53:56 -07:00
config DYNAMIC_INTERRUPTS
2022-03-09 12:05:12 +01:00
bool "Installation of IRQs at runtime"
2025-07-30 10:05:04 +02:00
select SRAM_SW_ISR_TABLE
2018-10-30 16:53:56 -07:00
help
Enable installation of interrupts at runtime, which will move some
interrupt-related data structures to RAM instead of ROM, and
on some architectures increase code size.
2023-08-11 11:58:34 +03:00
config SHARED_INTERRUPTS
bool "Set this to enable support for shared interrupts"
depends on GEN_SW_ISR_TABLE
select EXPERIMENTAL
help
Set this to enable support for shared interrupts. Use this with
caution as enabling this will increase the image size by a
non-negligible amount.
config SHARED_IRQ_MAX_NUM_CLIENTS
int "Maximum number of clients allowed per shared interrupt"
default 2
depends on SHARED_INTERRUPTS
help
This option controls the maximum number of clients allowed
per shared interrupt. Set this according to your needs.
2017-09-09 08:39:38 -04:00
config GEN_ISR_TABLES
2018-08-14 16:19:20 +02:00
bool "Use generated IRQ tables"
2017-09-09 08:39:38 -04:00
help
2017-12-13 10:08:21 -05:00
This option controls whether a platform uses the gen_isr_tables
script to generate its interrupt tables. This mechanism will create
an appropriate hardware vector table and/or software IRQ table.
2017-09-09 08:39:38 -04:00
config GEN_IRQ_VECTOR_TABLE
2018-08-14 16:19:20 +02:00
bool "Generate an interrupt vector table"
2017-09-09 08:39:38 -04:00
default y
depends on GEN_ISR_TABLES
help
2017-12-13 10:08:21 -05:00
This option controls whether a platform using gen_isr_tables
needs an interrupt vector table created. Only disable this if the
platform does not use a vector table at all, or requires the vector
table to be in a format that is not an array of function pointers
indexed by IRQ line. In the latter case, the vector table must be
supplied by the application or architecture code.
2017-09-09 08:39:38 -04:00
2022-06-21 14:26:03 +02:00
config ARCH_IRQ_VECTOR_TABLE_ALIGN
int "Alignment size of the interrupt vector table"
2022-06-24 09:36:09 +02:00
default 4
2022-06-21 14:26:03 +02:00
depends on GEN_IRQ_VECTOR_TABLE
help
This option controls alignment size of generated
_irq_vector_table. Some architecture needs an IRQ vector table
to be aligned to architecture specific size. The default
size is 0 for no alignment.
2025-03-10 21:13:50 +00:00
config ARCH_DEVICE_STATE_ALIGN
int "Alignment size of device state"
default 4
help
This option controls alignment size of device state.
2022-06-27 10:43:22 +02:00
choice IRQ_VECTOR_TABLE_TYPE
prompt "IRQ vector table type"
depends on GEN_IRQ_VECTOR_TABLE
2022-07-11 17:54:11 +02:00
default IRQ_VECTOR_TABLE_JUMP_BY_CODE if (RISCV && !RISCV_HAS_CLIC)
2022-06-27 10:43:22 +02:00
default IRQ_VECTOR_TABLE_JUMP_BY_ADDRESS
config IRQ_VECTOR_TABLE_JUMP_BY_ADDRESS
bool "Jump by address"
help
The IRQ vector table contains the address of the interrupt handler.
config IRQ_VECTOR_TABLE_JUMP_BY_CODE
bool "Jump by code"
help
The IRQ vector table contains the opcode of a jump instruction to the
interrupt handler address.
endchoice
2017-09-09 08:39:38 -04:00
config GEN_SW_ISR_TABLE
2018-08-14 16:19:20 +02:00
bool "Generate a software ISR table"
2017-09-09 08:39:38 -04:00
default y
depends on GEN_ISR_TABLES
help
2017-12-13 10:08:21 -05:00
This option controls whether a platform using gen_isr_tables
2026-04-02 12:23:35 +02:00
needs a software ISR table created.
It can be generated as either an array or a switch-case.
See CONFIG_GEN_SW_ISR_TABLE_TYPE.
choice GEN_SW_ISR_TABLE_TYPE
prompt "Allows to chose how ISR table is implemented"
depends on GEN_SW_ISR_TABLE
default GEN_SW_ISR_TABLE_ARRAY
help
CONFIG_GEN_SW_ISR_TABLE_ARRAY is a default option.
It should be used when in doubt.
GEN_SW_ISR_TABLE_SWITCH allows for binary size optimization
in certain scenarios, but may also increase latency, to execution of ISR with higher number, if there is significant number of ISR assigned in your system.
config GEN_SW_ISR_TABLE_ARRAY
bool "Generate an array of ISR entries"
help
This is an array of struct _isr_table_entry containing
the interrupt service routine and supplied parameter.
All interrupts have their own entry.
config GEN_SW_ISR_TABLE_SWITCH
bool "Generate a function with a switch-case"
help
Use a switch-case instead of an array.
This helps to limit binary size when most of the IRQs are not used.
In such case common, duplicated entries are grouped in a single default block
while few used interrupts have their own case blocks.
endchoice
2017-09-09 08:39:38 -04:00
2019-06-20 18:28:37 +09:00
config ARCH_SW_ISR_TABLE_ALIGN
int "Alignment size of a software ISR table"
2023-06-06 21:52:06 +02:00
default 64 if RISCV_HAS_CLIC
2022-06-24 09:36:09 +02:00
default 4
2019-06-20 18:28:37 +09:00
depends on GEN_SW_ISR_TABLE
help
This option controls alignment size of generated
_sw_isr_table. Some architecture needs a software ISR table
to be aligned to architecture specific size. The default
2023-06-06 21:52:06 +02:00
size is 4.
2019-06-20 18:28:37 +09:00
2017-09-09 08:39:38 -04:00
config GEN_IRQ_START_VECTOR
int
default 0
depends on GEN_ISR_TABLES
help
2017-12-13 10:08:21 -05:00
On some architectures, part of the vector table may be reserved for
system exceptions and is declared separately from the tables
created by gen_isr_tables.py. When creating these tables, this value
will be subtracted from CONFIG_NUM_IRQS to properly size them.
This is a hidden option which needs to be set per architecture and
left alone.
2017-09-09 08:39:38 -04:00
2017-11-23 12:05:55 -05:00
config IRQ_OFFLOAD
2022-03-09 12:05:12 +01:00
bool "IRQ offload"
2019-11-07 10:33:09 -08:00
depends on TEST
2017-11-23 12:05:55 -05:00
help
Enable irq_offload() API which allows functions to be synchronously
2019-11-07 10:33:09 -08:00
run in interrupt context. Only useful for test cases that need
to validate the correctness of kernel objects in IRQ context.
2017-11-23 12:05:55 -05:00
2025-04-15 11:12:34 +02:00
config SRAM_VECTOR_TABLE
bool "Place the vector table in SRAM instead of flash"
depends on ARCH_HAS_VECTOR_TABLE_RELOCATION
depends on XIP
depends on !ROMSTART_RELOCATION_ROM
help
When XiP is enabled, this option will result in the vector table being
relocated from Flash to SRAM.
2025-07-30 10:05:04 +02:00
config SRAM_SW_ISR_TABLE
bool "Place the software ISR table in SRAM instead of flash"
help
The option specifies that the software interrupts vector table will be
placed inside SRAM instead of the flash.
2022-02-14 14:30:34 -08:00
config IRQ_OFFLOAD_NESTED
bool "irq_offload() supports nested IRQs"
depends on IRQ_OFFLOAD
2024-06-10 12:33:16 -07:00
default y if ARM64 || X86 || RISCV || XTENSA
2022-02-14 14:30:34 -08:00
help
2024-06-10 12:33:16 -07:00
When set by the platform layers, indicates that
irq_offload() may legally be called in interrupt context to
cause a synchronous nested interrupt on the current CPU.
Not all hardware is capable.
2020-08-28 09:02:20 -04:00
2023-12-11 13:32:43 -05:00
config EXCEPTION_DEBUG
bool "Unhandled exception debugging"
default y
depends on PRINTK || LOG
help
Install handlers for various CPU exception/trap vectors to
make debugging them easier, at a small expense in code size.
This prints out the specific exception vector and any associated
error codes.
2020-08-28 09:02:20 -04:00
config EXTRA_EXCEPTION_INFO
bool "Collect extra exception info"
depends on ARCH_HAS_EXTRA_EXCEPTION_INFO
help
This option enables the collection of extra information, such as
register state, when a fault occurs. This information can be useful
to collect for post-mortem analysis and debug of issues.
2023-01-26 10:10:57 +10:00
config SIMPLIFIED_EXCEPTION_CODES
bool "Convert arch specific exception codes to K_ERR_CPU_EXCEPTION"
default y if ZTEST
help
The same piece of faulty code (NULL dereference, etc) can result in
a multitude of potential exception codes at the CPU level, depending
upon whether addresses exist, an MPU is configured, the particular
implementation of the CPU or any number of other reasons. Enabling
this option collapses all the architecture specific exception codes
down to the generic K_ERR_CPU_EXCEPTION, which makes testing code
much more portable.
2024-06-21 16:06:03 +02:00
config EMPTY_IRQ_SPURIOUS
bool "Create empty spurious interrupt handler"
depends on ARCH_SUPPORTS_EMPTY_IRQ_SPURIOUS
help
This option changes body of spurious interrupt handler. When enabled,
handler contains only an infinite while loop, when disabled, handler
contains the whole Zephyr fault handling procedure.
2017-09-09 08:39:38 -04:00
endmenu # Interrupt configuration
2020-10-21 15:48:41 +02:00
config INIT_ARCH_HW_AT_BOOT
bool "Initialize internal architecture state at boot"
depends on ARCH_SUPPORTS_ARCH_HW_INIT
help
This option instructs Zephyr to force the initialization
of the internal architectural state (for example ARCH-level
HW registers and system control blocks) during boot to
the reset values as specified by the corresponding
architecture manual. The option is useful when the Zephyr
firmware image is chain-loaded, for example, by a debugger
or a bootloader, and we need to guarantee that the internal
states of the architecture core blocks are restored to the
reset values (as specified by the architecture).
Note: the functionality is architecture-specific. For the
implementation details refer to each architecture where
this feature is supported.
2017-09-08 21:14:06 -04:00
endmenu
2017-09-09 08:39:38 -04:00
#
# Architecture Capabilities
#
2026-03-11 04:47:44 -04:00
config ARCH_MEM_DOMAIN_SUPPORTS_ISOLATED_STACKS
bool
help
This hidden option is selected by the target architecture if
the architecture supports isolating thread stacks for threads
within the same memory domain.
config ARCH_MEM_DOMAIN_SUPPORTS_DEINIT
bool
select MEM_DOMAIN_HAS_THREAD_LIST
help
This hidden option is selected by the target architecture if
the architecture supports de-initializing a memory domain.
2019-12-21 08:17:02 +01:00
2021-05-19 17:45:25 +02:00
config ARCH_HAS_SINGLE_THREAD_SUPPORT
bool
2020-08-27 23:07:01 -04:00
config ARCH_HAS_TIMING_FUNCTIONS
bool
2018-10-12 09:27:28 +02:00
config ARCH_HAS_TRUSTED_EXECUTION
bool
2017-09-08 21:14:06 -04:00
config ARCH_HAS_STACK_PROTECTION
bool
2017-09-11 10:34:49 -07:00
config ARCH_HAS_USERSPACE
bool
2017-10-17 17:01:48 -07:00
config ARCH_HAS_EXECUTABLE_PAGE_BIT
bool
2018-11-07 23:40:43 +01:00
config ARCH_HAS_NOCACHE_MEMORY_SUPPORT
bool
2019-02-10 11:05:51 +01:00
config ARCH_HAS_RAMFUNC_SUPPORT
bool
2025-04-15 11:12:34 +02:00
config ARCH_HAS_VECTOR_TABLE_RELOCATION
bool
2019-10-17 19:13:12 +02:00
config ARCH_HAS_NESTED_EXCEPTION_DETECTION
bool
2020-08-07 10:47:37 -07:00
config ARCH_SUPPORTS_COREDUMP
bool
2024-07-10 11:52:17 -07:00
config ARCH_SUPPORTS_COREDUMP_THREADS
bool
2024-09-16 09:43:52 -07:00
config ARCH_SUPPORTS_COREDUMP_PRIV_STACKS
bool
2025-04-14 15:25:48 +02:00
config ARCH_SUPPORTS_COREDUMP_STACK_PTR
bool
2020-10-21 15:48:41 +02:00
config ARCH_SUPPORTS_ARCH_HW_INIT
bool
2023-06-04 00:52:43 +03:00
config ARCH_SUPPORTS_ROM_START
bool
2024-06-21 16:06:03 +02:00
config ARCH_SUPPORTS_EMPTY_IRQ_SPURIOUS
bool
2024-11-12 14:06:11 -08:00
config ARCH_SUPPORTS_EVICTION_TRACKING
bool
help
Architecture code supports page tracking for eviction algorithms
when demand paging is enabled.
2020-08-28 09:02:20 -04:00
config ARCH_HAS_EXTRA_EXCEPTION_INFO
bool
2020-05-21 16:55:28 -07:00
config ARCH_HAS_GDBSTUB
bool
2020-09-28 11:03:52 -07:00
config ARCH_HAS_THREAD_LOCAL_STORAGE
bool
2022-05-04 14:25:59 +02:00
config ARCH_HAS_SUSPEND_TO_RAM
bool
help
When selected, the architecture supports suspend-to-RAM (S2RAM).
2023-08-01 15:07:57 -07:00
config ARCH_HAS_STACK_CANARIES_TLS
bool
2024-03-18 15:58:48 -07:00
config ARCH_SUPPORTS_MEM_MAPPED_STACKS
bool
help
Select when the architecture supports memory mapped stacks.
2024-07-30 12:26:09 -07:00
config ARCH_HAS_THREAD_PRIV_STACK_SPACE_GET
bool
help
Select when the architecture implements arch_thread_priv_stack_space_get().
2025-04-01 18:01:10 -07:00
config ARCH_HAS_HW_SHADOW_STACK
bool
2017-12-05 09:07:39 -05:00
#
# Other architecture related options
#
config ARCH_HAS_THREAD_ABORT
bool
2022-08-22 11:24:51 +10:00
config ARCH_HAS_CODE_DATA_RELOCATION
bool
help
When selected, the architecture/SoC implements support for
CODE_DATA_RELOCATION in its linker scripts.
2019-12-21 08:17:02 +01:00
#
# Hidden CPU family configs
2017-11-23 17:43:54 -05:00
#
2018-10-12 09:27:28 +02:00
config CPU_HAS_TEE
bool
help
This option is enabled when the CPU has support for Trusted
Execution Environment (e.g. when it has a security attribution
unit).
2019-10-09 00:52:18 +09:00
config CPU_HAS_DCLS
bool
help
2022-06-18 23:09:49 +07:00
This option is enabled when the processor hardware has support for
2019-10-09 00:52:18 +09:00
Dual-redundant Core Lock-step (DCLS) topology.
2017-11-23 17:43:54 -05:00
config CPU_HAS_FPU
bool
help
This option is enabled when the CPU has hardware floating point
unit.
2023-11-16 09:16:42 -05:00
config CPU_HAS_DSP
bool
help
This option is enabled when the CPU has hardware DSP unit.
2020-04-14 11:06:23 -07:00
config CPU_HAS_FPU_DOUBLE_PRECISION
bool
select CPU_HAS_FPU
help
When enabled, this indicates that the CPU has a double floating point
precision unit.
2017-11-23 17:43:54 -05:00
config CPU_HAS_MPU
bool
help
This option is enabled when the CPU has a Memory Protection Unit (MPU).
2020-06-12 16:50:16 -07:00
config CPU_HAS_MMU
bool
help
This hidden option is selected when the CPU has a Memory Management Unit
(MMU).
2020-11-05 14:30:20 -08:00
2020-11-16 11:30:35 -08:00
config ARCH_HAS_DEMAND_PAGING
bool
help
This hidden configuration should be selected by the architecture if
demand paging is supported.
2024-07-17 00:06:42 -04:00
config ARCH_HAS_DEMAND_MAPPING
bool
help
This hidden configuration should be selected by the architecture if
demand paging is supported and arch_mem_map() supports
K_MEM_MAP_UNPAGED.
2020-11-18 13:11:56 -08:00
config ARCH_HAS_RESERVED_PAGE_FRAMES
bool
help
This hidden configuration should be selected by the architecture if
certain RAM page frames need to be marked as reserved and never used for
memory mappings. The architecture will need to implement
arch_reserved_pages_update().
2024-03-04 10:52:24 -05:00
config ARCH_HAS_DIRECTED_IPIS
bool
help
This hidden configuration should be selected by the architecture if
it has an implementation for arch_sched_directed_ipi() which allows
for IPIs to be directed to specific CPUs.
2022-07-25 10:42:08 +02:00
config CPU_HAS_DCACHE
bool
help
This hidden configuration should be selected when the CPU has a d-cache.
2024-01-24 21:46:14 -05:00
config CPU_CACHE_INCOHERENT
bool
help
This hidden configuration should be selected when the CPU has
incoherent cache. This applies to intra-CPU multiprocessing
2024-09-18 00:07:25 +08:00
incoherence and makes only sense when MP_MAX_NUM_CPUS > 1.
2024-01-24 21:46:14 -05:00
2022-07-25 10:42:08 +02:00
config CPU_HAS_ICACHE
bool
help
This hidden configuration should be selected when the CPU has an i-cache.
2021-01-23 14:08:12 -08:00
config ARCH_MAPS_ALL_RAM
bool
help
This hidden option is selected by the architecture to inform the kernel
that all RAM is mapped at boot, and not just the bounds of the Zephyr image.
If RAM starts at 0x0, the first page must remain un-mapped to catch NULL
pointer dereferences. With this enabled, the kernel will not assume that
virtual memory addresses past the kernel image are available for mappings,
but instead takes into account an entire RAM mapping instead.
This is typically set by architectures which need direct access to all memory.
It is the architecture's responsibility to mark reserved memory regions
as such in arch_reserved_pages_update().
Although the kernel will not disturb this RAM mapping by re-mapping the associated
virtual addresses elsewhere, this is limited to only management of the
virtual address space. The kernel's page frame ontology will not consider
this mapping at all; non-kernel pages will be considered free (unless marked
2024-06-07 10:55:06 -07:00
as reserved) and K_MEM_PAGE_FRAME_MAPPED will not be set.
2021-01-23 14:08:12 -08:00
2022-06-18 23:09:49 +07:00
config DCLS
bool "Processor is configured in DCLS mode"
depends on CPU_HAS_DCLS
default y
help
This option is enabled when the processor hardware is configured in
Dual-redundant Core Lock-step (DCLS) topology. For the processor that
supports DCLS, but is configured in split-lock mode (by default or
changed at flash time), this option should be disabled.
2020-11-05 14:30:20 -08:00
menuconfig MPU
2022-03-09 12:05:12 +01:00
bool "MPU features"
2020-11-05 14:30:20 -08:00
depends on CPU_HAS_MPU
2018-11-27 15:45:36 +01:00
help
2020-11-05 14:30:20 -08:00
This option, when enabled, indicates to the core kernel that an MPU
is enabled.
2018-11-27 15:45:36 +01:00
2020-11-05 14:30:20 -08:00
if MPU
2022-07-20 07:37:09 -04:00
module = MPU
module-str = mpu
source "subsys/logging/Kconfig.template.log_config"
2018-02-01 01:12:32 -06:00
config MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT
bool
help
2018-02-15 07:36:16 -06:00
This option is enabled when the MPU requires a power of two alignment
and size for MPU regions.
2018-02-01 01:12:32 -06:00
2018-09-25 14:05:56 +02:00
config MPU_REQUIRES_NON_OVERLAPPING_REGIONS
bool
help
This option is enabled when the MPU requires the active (i.e. enabled)
MPU regions to be non-overlapping with each other.
2018-02-01 01:12:32 -06:00
2019-10-24 15:17:09 +02:00
config MPU_GAP_FILLING
bool "Force MPU to be filling in background memory regions"
depends on MPU_REQUIRES_NON_OVERLAPPING_REGIONS
2019-11-11 12:46:31 +01:00
default y if !USERSPACE
2019-10-24 15:17:09 +02:00
help
This Kconfig option instructs the MPU driver to enforce
a full kernel SRAM partitioning, when it programs the
dynamic MPU regions (user thread stack, PRIV stack guard
and application memory domains) during context-switch. We
allow this to be a configurable option, in order to be able
to switch the option off and have an increased number of MPU
regions available for application memory domain programming.
Notes:
An increased number of MPU regions should only be required,
2019-11-11 12:46:31 +01:00
when building with USERSPACE support. As a result, when we
build without USERSPACE support, gap filling should always
be required.
2019-10-24 15:17:09 +02:00
When the option is switched off, access to memory areas not
covered by explicit MPU regions is restricted to privileged
code on an ARCH-specific basis. Refer to ARCH-specific
documentation for more information on how this option is
used.
2020-11-05 14:30:20 -08:00
endif # MPU
config SRAM_REGION_PERMISSIONS
bool "Assign appropriate permissions to kernel areas in SRAM"
depends on MMU || MPU
default y
help
This option indicates that memory protection hardware
is present, enabled, and regions have been configured at boot for memory
ranges within the kernel image.
If this option is turned on, certain areas of the kernel image will
have the following access policies applied for all threads, including
supervisor threads:
1) All program text will be have read-only, execute memory permission
2) All read-only data will have read-only permission, and execution
disabled if the hardware supports it.
3) All other RAM addresses will have read-write permission, and
execution disabled if the hardware supports it.
Options such as USERSPACE or HW_STACK_PROTECTION may additionally
impose additional policies on the memory map, which may be global
or local to the current running thread.
This option may consume additional memory to satisfy memory protection
hardware alignment constraints.
If this option is disabled, the entire kernel will have default memory
access permissions set, typically read/write/execute. It may be desirable
to turn this off on MMU systems which are using the MMU for demand
paging, do not need memory protection, and would rather not use up
RAM for the alignment between regions.
2022-08-22 11:24:51 +10:00
config CODE_DATA_RELOCATION
bool "Support code/data section relocation"
depends on ARCH_HAS_CODE_DATA_RELOCATION
help
Enable support for relocating .text, data and .bss sections from specified
files and placing them in a chosen memory region. Files to relocate and
the target regions should be specified in CMakeLists.txt using
zephyr_code_relocate().
2023-11-16 09:16:42 -05:00
menu "DSP Options"
config DSP_SHARING
bool "DSP register sharing"
depends on CPU_HAS_DSP
help
This option enables preservation of the hardware DSP registers
across context switches to allow multiple threads to perform concurrent
DSP operations.
endmenu
2020-04-24 14:06:37 +09:00
menu "Floating Point Options"
config FPU
2022-03-09 12:05:12 +01:00
bool "Floating point unit (FPU)"
2018-12-27 16:13:25 +01:00
depends on CPU_HAS_FPU
2017-11-23 17:43:54 -05:00
help
2020-04-24 14:06:37 +09:00
This option enables the hardware Floating Point Unit (FPU), in order to
support using the floating point registers and instructions.
When this option is enabled, by default, threads may use the floating
point registers only in an exclusive manner, and this usually means that
only one thread may perform floating point operations.
If it is necessary for multiple threads to perform concurrent floating
point operations, the "FPU register sharing" option must be enabled to
preserve the floating point registers across context switches.
2017-11-23 17:43:54 -05:00
2020-04-24 14:06:37 +09:00
Note that this option cannot be selected for the platforms that do not
include a hardware floating point unit; the floating point support for
those platforms is dependent on the availability of the toolchain-
provided software floating point library.
2017-11-23 17:43:54 -05:00
2020-05-03 18:03:19 +09:00
config FPU_SHARING
2020-04-24 14:06:37 +09:00
bool "FPU register sharing"
2025-01-22 08:38:12 -08:00
depends on FPU
2017-11-23 17:43:54 -05:00
help
2020-04-24 14:06:37 +09:00
This option enables preservation of the hardware floating point registers
across context switches to allow multiple threads to perform concurrent
floating point operations.
2021-04-07 21:41:06 -04:00
Note that some compiler configurations may activate a floating point
context by generating FP instructions for any thread, and that
context must be preserved when switching such threads in and out.
The developers can still disable the FP sharing mode in their
application projects, and switch to Unshared FP registers mode,
if it is guaranteed that the image code does not generate FP
instructions outside the single thread context that is allowed
to do so.
2021-01-27 14:24:59 +01:00
2020-04-24 14:06:37 +09:00
endmenu
2020-12-02 13:05:37 +01:00
menu "Cache Options"
2022-04-08 12:29:28 +02:00
config DCACHE
2022-07-25 10:42:08 +02:00
bool "Data cache (d-cache) support"
depends on CPU_HAS_DCACHE
2022-04-08 12:29:28 +02:00
default y
help
2022-07-25 10:42:08 +02:00
This option enables the support for the data cache (d-cache).
config ICACHE
bool "Instruction cache (i-cache) support"
depends on CPU_HAS_ICACHE
default y
help
This option enables the support for the instruction cache (i-cache).
2022-04-08 12:29:28 +02:00
2025-10-30 14:47:58 -07:00
config CACHE_HAS_MIRRORED_MEMORY_REGIONS
bool "Mirrored memory region(s) for both cached and uncached access"
depends on CPU_CACHE_INCOHERENT
help
Enable this if hardware has mirrored memory regions at different
addressed when accessing one would go through cache, but accessing
the other would go to memory directly. A pointer can be cheaply
converted to cached or uncached access.
This applies to intra-CPU multiprocessing incoherence and makes only
sense when MP_MAX_NUM_CPUS > 1.
2024-01-24 21:46:14 -05:00
config CACHE_DOUBLEMAP
bool "Cache double-mapping support"
2025-10-30 14:47:58 -07:00
select CACHE_HAS_MIRRORED_MEMORY_REGIONS
select DEPRECATED
2024-01-24 21:46:14 -05:00
help
Double-mapping behavior where a pointer can be cheaply converted to
point to the same cached/uncached memory at different locations.
This applies to intra-CPU multiprocessing incoherence and makes only
2024-09-18 00:07:25 +08:00
sense when MP_MAX_NUM_CPUS > 1.
2024-01-24 21:46:14 -05:00
2020-12-02 12:38:58 +01:00
config CACHE_MANAGEMENT
2022-03-09 12:05:12 +01:00
bool "Cache management features"
2022-07-25 10:42:08 +02:00
depends on DCACHE || ICACHE
2020-12-02 12:38:58 +01:00
help
2022-10-05 10:08:29 +02:00
This option enables the cache management functions backed by arch or
driver code.
2020-12-02 12:38:58 +01:00
2025-09-02 12:55:40 +02:00
if CACHE_MANAGEMENT
if DCACHE
2020-12-02 12:38:58 +01:00
config DCACHE_LINE_SIZE_DETECT
bool "Detect d-cache line size at runtime"
2020-12-02 13:05:37 +01:00
help
This option enables querying some architecture-specific hardware for
2020-12-02 12:38:58 +01:00
finding the d-cache line size at the expense of taking more memory and
2020-12-02 13:05:37 +01:00
code and a slightly increased boot time.
2020-12-02 12:38:58 +01:00
If the CPU's d-cache line size is known in advance, disable this option and
manually enter the value for DCACHE_LINE_SIZE or set it in the DT
using the 'd-cache-line-size' property.
2020-12-02 13:05:37 +01:00
2020-12-02 12:38:58 +01:00
config DCACHE_LINE_SIZE
2022-07-25 10:42:08 +02:00
int "d-cache line size"
2025-09-02 12:55:40 +02:00
depends on !DCACHE_LINE_SIZE_DETECT
2025-09-02 12:58:14 +02:00
default $(dt_node_int_prop_int,/cpus/cpu@0,d-cache-line-size) \
if $(dt_node_has_prop,/cpus/cpu@0,d-cache-line-size)
2020-12-02 13:05:37 +01:00
default 0
help
2025-09-02 12:58:14 +02:00
Size in bytes of a CPU d-cache line.
2020-12-02 13:05:37 +01:00
2020-12-02 12:38:58 +01:00
Detect automatically at runtime by selecting DCACHE_LINE_SIZE_DETECT.
2025-09-02 12:55:40 +02:00
endif # DCACHE
if ICACHE
2020-12-02 12:38:58 +01:00
config ICACHE_LINE_SIZE_DETECT
bool "Detect i-cache line size at runtime"
2020-12-02 13:05:37 +01:00
help
2020-12-02 12:38:58 +01:00
This option enables querying some architecture-specific hardware for
finding the i-cache line size at the expense of taking more memory and
code and a slightly increased boot time.
If the CPU's i-cache line size is known in advance, disable this option and
manually enter the value for ICACHE_LINE_SIZE or set it in the DT
using the 'i-cache-line-size' property.
config ICACHE_LINE_SIZE
2022-07-25 10:42:08 +02:00
int "i-cache line size"
2025-09-02 12:55:40 +02:00
depends on !ICACHE_LINE_SIZE_DETECT
2025-09-02 12:58:14 +02:00
default $(dt_node_int_prop_int,/cpus/cpu@0,i-cache-line-size) \
if $(dt_node_has_prop,/cpus/cpu@0,i-cache-line-size)
2020-12-02 12:38:58 +01:00
default 0
help
2025-09-02 12:58:14 +02:00
Size in bytes of a CPU i-cache line.
2020-12-02 12:38:58 +01:00
Detect automatically at runtime by selecting ICACHE_LINE_SIZE_DETECT.
2020-12-02 13:05:37 +01:00
2025-09-02 12:55:40 +02:00
endif # ICACHE
2021-07-13 15:20:47 +08:00
choice CACHE_TYPE
2021-04-28 10:38:27 +02:00
prompt "Cache type"
2022-10-05 10:08:29 +02:00
default ARCH_CACHE
2021-04-28 10:38:27 +02:00
2022-10-05 10:08:29 +02:00
config ARCH_CACHE
2021-04-28 10:38:27 +02:00
bool "Integrated cache controller"
help
2022-10-05 10:08:29 +02:00
Integrated on-core cache controller
2021-04-28 10:38:27 +02:00
2025-10-29 13:31:21 -07:00
config SOC_CACHE
bool "SoC specific cache controller"
depends on SOC_HAS_CACHE_FUNCTIONS
help
SoC specific cache controller.
This requires soc_cache.h file to exist in search path.
2022-10-05 10:08:29 +02:00
config EXTERNAL_CACHE
2021-04-28 10:38:27 +02:00
bool "External cache controller"
help
2022-10-05 10:08:29 +02:00
External cache controller
2021-04-28 10:38:27 +02:00
endchoice
2025-10-29 11:52:18 -07:00
config CACHE_CAN_SAY_MEM_COHERENCE
bool
help
sys_cache_is_mem_coherent() is defined when enabled. This function can be
used to determine if a pointer lies inside "coherence regions" and can be
safely used in multiprocessor code without explicit flush or invalidate
operations.
2025-09-02 12:55:40 +02:00
endif # CACHE_MANAGEMENT
2020-12-02 13:05:37 +01:00
endmenu
2017-11-23 17:43:54 -05:00
2015-10-09 06:20:52 -04:00
config ARCH
string
help
2017-12-13 10:08:21 -05:00
System architecture string.
2015-10-09 06:20:52 -04:00
2021-04-23 20:52:38 -07:00
config TOOLCHAIN_HAS_BUILTIN_FFS
bool
default y if !(64BIT && RISCV)
help
Hidden option to signal that toolchain has __builtin_ffs*().
2023-11-03 13:53:54 +08:00
2024-07-05 05:52:13 -04:00
config ARCH_HAS_CUSTOM_CPU_IDLE
bool
2023-11-03 13:53:54 +08:00
help
This options allows applications to override the default arch idle implementation with
a custom one.
2024-07-04 14:37:08 -04:00
2024-07-05 05:52:13 -04:00
config ARCH_HAS_CUSTOM_CPU_ATOMIC_IDLE
bool
2024-07-04 14:37:08 -04:00
help
This options allows applications to override the default arch idle implementation with
a custom one.
2024-07-05 05:53:35 -04:00
config ARCH_HAS_CUSTOM_SWAP_TO_MAIN
bool
help
2025-02-03 10:41:55 -08:00
It's possible that an architecture port cannot use z_swap_unlocked()
to swap to the main thread (bg_thread_main), but instead must do
something custom. It must enable this option in that case.
2024-07-05 05:53:35 -04:00
config ARCH_HAS_CUSTOM_BUSY_WAIT
bool
help
It's possible that an architecture port cannot or does not want to use
the provided k_busy_wait(), but instead must do something custom. It must
enable this option in that case.
2024-11-01 12:12:29 +08:00
config ARCH_HAS_CUSTOM_CURRENT_IMPL
bool
help
Select when architecture implements arch_current_thread() &
arch_current_thread_set().
2025-06-10 12:26:30 -07:00
config ARCH_IPI_LAZY_COPROCESSORS_SAVE
bool
help
Select when the architecture has multi-CPU lazy context switching
of coprocessor registers.