zephyr/arch/xtensa/Kconfig

101 lines
3.1 KiB
Plaintext
Raw Normal View History

# Kconfig - XTENSA architecture configuration options
#
# Copyright (c) 2016 Cadence Design Systems, Inc.
# SPDX-License-Identifier: Apache-2.0
menu "XTENSA Options"
depends on XTENSA
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 16:57:47 +08:00
menu "Specific core configuration"
config IRQ_OFFLOAD_INTNUM
int "IRQ offload SW interrupt index"
help
The index of the software interrupt to be used for IRQ offload.
Please note that in order for IRQ offload to work correctly the selected
interrupt shall have its priority shall not exceed XCHAL_EXCM_LEVEL.
config XTENSA_OMIT_HIGH_INTERRUPTS
bool "Skip generation of vectors for high priority interrupts"
help
Setting this to y causes the interrupt vectors for "high
priority" Xtensa interrupts (those not masked by the EXCM bit
in PS) to be left ungenerated, so they can be handled by
application code instead. Note that high priority interrupts
cannot safely be handled by C code anyway (they will interrupt
register window exceptions, which cannot be made reentrant, so
the code under the handler must not emit them), though some
devices might still want to use built-in handling for things
like watchdogs which do not need to return into interrupted
code. Default is "n" for legacy compatibility. Consider
changing to "y" in the future.
config XTENSA_ASM2
bool "New-style Xtensa context switch & interrupt layer"
select USE_SWITCH
select USE_SWITCH_SUPPORTED
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 16:57:47 +08:00
help
This selects a new implementation of context switching and
interrupt handling. Advantages are a much lower interrupt
overhead and smaller code size, and this scheme is required
for SMP. Assumes/requires hardware that implements the
register window extension, however.
endmenu
config ARCH
default "xtensa"
config SIMULATOR_XTENSA
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 16:57:47 +08:00
bool "Simulator Configuration"
help
Specify if the board configuration should be treated as a simulator.
config SYS_CLOCK_HW_CYCLES_PER_SEC
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 16:57:47 +08:00
int "Hardware clock cycles per second, 2000000 for ISS"
default 2000000
range 1000000 1000000000
help
This option specifies hardware clock.
config XTENSA_NO_IPC
bool "Core has no IPC support"
select ATOMIC_OPERATIONS_C
help
Uncheck this if you core does not implement "SCOMPARE1" register and "s32c1i"
instruction.
config SW_ISR_TABLE
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 16:57:47 +08:00
bool "Enable software interrupt handler table"
default y
help
Enable an interrupt handler table implemented in software. This
table, unlike ISRs connected directly in the vector table, allow
a parameter to be passed to the interrupt handlers. Also, invoking
the exception/interrupt exit stub is automatically done.
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 16:57:47 +08:00
bool "Build reset vector code"
default y
help
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.
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 16:57:47 +08:00
bool "Use crt1.S from core"
default y
help
SoC or boards might define their own __start by setting this setting
to false.
config XTENSA_KERNEL_CPU_PTR_SR
string
default "MISC0"
help
Specify which special register to store the pointer to
_kernel.cpus[] for the current CPU.
endmenu