OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/soc/arm/nordic_nrf/Kconfig.defconfig

46 lines
719 B
Plaintext
Raw Normal View History

arch: arm: nrf: Rename nrf5 SoC Family to nrf Upcoming Nordic ICs that share many of the peripherals and architecture with the currently supported nRF5x ones are no longer part of the nRF5 family. In order to accomodate that, rename the SoC family from nrf5 to nrf, so that it can contain all of the members of the wider Nordic family. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-19 20:51:25 +08:00
# Kconfig.defconfig - Nordic Semiconductor nRFx MCU line
#
arch: arm: nordic_nrf: Restore copyright years A previous commit had mistakenly overwritten the copyright years instead of extending the range. Fix this mistake so that the proper range is recorded. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-20 19:17:05 +08:00
# Copyright (c) 2016-2018 Nordic Semiconductor ASA
arch: arm: nrf: Rename nrf5 SoC Family to nrf Upcoming Nordic ICs that share many of the peripherals and architecture with the currently supported nRF5x ones are no longer part of the nRF5 family. In order to accomodate that, rename the SoC family from nrf5 to nrf, so that it can contain all of the members of the wider Nordic family. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-19 20:51:25 +08:00
#
# SPDX-License-Identifier: Apache-2.0
#
if SOC_FAMILY_NRF
arm: soc: move arm SoCs to top-dir Move the SoC outside of the architecture tree and put them at the same level as boards and architectures allowing both SoCs and boards to be maintained outside the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 04:47:02 +08:00
source "soc/arm/nordic_nrf/*/Kconfig.defconfig.series"
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
soc: nrf: Conditionally enable clock control and timer The CONFIG_CLOCK_CONTROL and CONFIG_NRF_RTC_TIMER were unconditionally selected when enabling any nRF SoC. But since timers can be disabled in the kernel, depend instead on CONFIG_SYS_CLOCK_EXISTS, which is only defined when kernel timer support is included. Note that ideally we would enable CONFIG_NRF_RTC_TIMER only, and that would select CONFIG_CLOCK_CONTROL (on which the RTC timer depends) but there is a circular Kconfig dependency that prevents us from doing so. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-05-10 01:50:43 +08:00
if SYS_CLOCK_EXISTS
# If the kernel has timer support, enable both clock control and timer
config CLOCK_CONTROL
default y
config NRF_RTC_TIMER
default y
endif # SYS_CLOCK_EXISTS
soc: arm: nordic_nrf: change default SYS_CLOCKS_PER_SEC The default system clock on all Nordic devices is based on a 32 KiHz (2^15 Hz) timer. Scheduling ticks requires that deadlines be specified with a timer counter that aligns to a system clock. With the Zephyr default 100 clocks-per-sec configuration this results in 100 ticks every 32700 ticks of the cycle timer. This reveals two problems: * The uptime clock misrepresents elapsed time because it runs 0.208% (68/32768) faster than the best available clock; * Calculation of timer counter compare values often requires an integer division and multiply operation to produce a value that's a multiple of clock-ticks-per-second. Integer division on the Cortex-M1 nRF51 is done in software with a (value-dependent) algorithm with a non-constant runtime that can be significant. This can produce missed Bluetooth deadlines as discussed in upstream #14577 and others. By changing the default divisor to one that evenly divides the 2^15 clock rate the time interrupts are disabled to manage timers is significantly reduced, as is the error between uptime and real time. Do this at the top level, moving SYS_CLOCK_HW_CYCLES_PER_SEC there as well since the two parameters are related. Note that the central_hr configuration described in upstream #13610 does not distinguish latency due to timer management from other irq_block/spinlock regions, and the maximum observed latency will still exceed the nominal 10 us allowed maximum. However this does occur much less frequently than changing the timer deadline which can happen multiple times per tick. Signed-off-by: Peter A. Bigot <pab@pabigot.com>
2019-04-20 22:25:38 +08:00
config SYS_CLOCK_HW_CYCLES_PER_SEC
int
default 32768
config SYS_CLOCK_TICKS_PER_SEC
int
soc/arm: Increase nRF timer default to the cycle rate. The nRF timer runs at only 32 kHz, so there's little reason to try to divide it to get a synthesized tick rate. Just use the raw clock as the tick rate, which provides maximal precision and very singnificantly simplifies the generated code for the ISR. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-06-12 02:44:59 +08:00
default 32768
soc: arm: nordic_nrf: change default SYS_CLOCKS_PER_SEC The default system clock on all Nordic devices is based on a 32 KiHz (2^15 Hz) timer. Scheduling ticks requires that deadlines be specified with a timer counter that aligns to a system clock. With the Zephyr default 100 clocks-per-sec configuration this results in 100 ticks every 32700 ticks of the cycle timer. This reveals two problems: * The uptime clock misrepresents elapsed time because it runs 0.208% (68/32768) faster than the best available clock; * Calculation of timer counter compare values often requires an integer division and multiply operation to produce a value that's a multiple of clock-ticks-per-second. Integer division on the Cortex-M1 nRF51 is done in software with a (value-dependent) algorithm with a non-constant runtime that can be significant. This can produce missed Bluetooth deadlines as discussed in upstream #14577 and others. By changing the default divisor to one that evenly divides the 2^15 clock rate the time interrupts are disabled to manage timers is significantly reduced, as is the error between uptime and real time. Do this at the top level, moving SYS_CLOCK_HW_CYCLES_PER_SEC there as well since the two parameters are related. Note that the central_hr configuration described in upstream #13610 does not distinguish latency due to timer management from other irq_block/spinlock regions, and the maximum observed latency will still exceed the nominal 10 us allowed maximum. However this does occur much less frequently than changing the timer deadline which can happen multiple times per tick. Signed-off-by: Peter A. Bigot <pab@pabigot.com>
2019-04-20 22:25:38 +08:00
soc: arm: nordic_nrf: unrevert provide custom busy_wait implementations This reverts commit bd24b31139c1946bd9fe4c336c697b69608fac5e. While the test case failure described in #14186 is associated with the cycle-based busy-wait implementation, that test is fragile, and fails less frequently once the incongruence between ticks-per-second and the 32 KiHz RTC clock are resolved. It also assumes that the system clock is more stable than the infrastructure underlying the the busy-wait implementation, which is not necessarily true. The gross inaccuracies in the standard busy-wait on Nordic described in issue #11626 justify restoring the custom solution. As this applies to all Nordic devices, move the setting to the top-level Kconfig.defconfig. See: https://github.com/zephyrproject-rtos/zephyr/issues/11626#issuecomment-487243369 Signed-off-by: Peter A. Bigot <pab@pabigot.com>
2019-04-27 08:07:43 +08:00
config ARCH_HAS_CUSTOM_BUSY_WAIT
default y
soc: nrf: Conditionally enable clock control and timer The CONFIG_CLOCK_CONTROL and CONFIG_NRF_RTC_TIMER were unconditionally selected when enabling any nRF SoC. But since timers can be disabled in the kernel, depend instead on CONFIG_SYS_CLOCK_EXISTS, which is only defined when kernel timer support is included. Note that ideally we would enable CONFIG_NRF_RTC_TIMER only, and that would select CONFIG_CLOCK_CONTROL (on which the RTC timer depends) but there is a circular Kconfig dependency that prevents us from doing so. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-05-10 01:50:43 +08:00
config SYS_POWER_MANAGEMENT
default y
arch: arm: nrf: Rename nrf5 SoC Family to nrf Upcoming Nordic ICs that share many of the peripherals and architecture with the currently supported nRF5x ones are no longer part of the nRF5 family. In order to accomodate that, rename the SoC family from nrf5 to nrf, so that it can contain all of the members of the wider Nordic family. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-19 20:51:25 +08:00
config BUILD_OUTPUT_HEX
default y
soc: nordic: default GPIO when SPI enabled SPI devices almost always require chip selects, which are configured through GPIOs. Make the GPIO infrastructure available by default when SPI is enabled. Signed-off-by: Peter A. Bigot <pab@pabigot.com>
2018-12-24 04:20:13 +08:00
if SPI
config GPIO
default y
endif # SPI
arch: arm: nrf: Rename nrf5 SoC Family to nrf Upcoming Nordic ICs that share many of the peripherals and architecture with the currently supported nRF5x ones are no longer part of the nRF5 family. In order to accomodate that, rename the SoC family from nrf5 to nrf, so that it can contain all of the members of the wider Nordic family. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-19 20:51:25 +08:00
endif # SOC_FAMILY_NRF