Define configuration symbols for enabling STM32 PSA Crypto Drivers.
CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS is experimental, it is
disabled by default.
CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS is a generic config switch
to embed or not STM32 PSA Crypto Drivers. Config switches are defined
per hardware resources in STM32 SoCs:
- CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS_AES for STM32 AES
- CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS_CRYP for STM32 CRYP
- CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS_SAES for STM32 SAES
- CONFIG_USE_STM32_HAL_PSA_CRYPTO_DRIVERS_HASH for STM32 HASH
Enabling of one of those latter are conditioned to the presence
of a related enabled node in the DT and prevents the node is
integrated in the Zephyr native crypto framework.
STM32 RNG is out of scope since Zephyr integration of PSA Crypto
makes the PSA Crypto library to rely on the already existing STM32
entropy driver.
Update manifest to sync on the STM32 HAL module that provides
PSA Crypto drivers implementation for STM32 HASH and AES/CRYP/SAES
(transparent key).
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
On reset, the CH32V series starts executing from address 0x0 which is
aliased to the main flash. The startup code immediately jumps into the
corresponding non-aliased address at 0x08000000. This assumes that the
application is linked at the start of flash.
Add support for linking at a non-zero offset. This is required for
boards like the Comu that use the first 2 KiB for a bootloader.
Signed-off-by: Michael Hope <michaelh@juju.nz>
Add CONFIG_ESP_MBEDTLS_HEAP_ALLOC_EXT_RAM, a convenience option for
Espressif SoCs with external RAM (PSRAM). When enabled it selects
MBEDTLS_HEAP_CUSTOM_SECTION, placing the mbed TLS heap in the
.mbedtls_heap linker section that the esp32, esp32c5, esp32c61,
esp32p4, esp32s2 and esp32s3 linker scripts already map into their
PSRAM memory region. This frees internal SRAM for other allocations
and lets MBEDTLS_HEAP_SIZE grow well beyond what internal RAM alone
can provide, which matters for TLS handshakes (e.g. MQTT over TLS)
on memory-constrained boards.
The option is defined next to ESP_SPIRAM in soc/espressif/common,
rather than in the generic tf-psa-crypto Kconfig, since it is an
Espressif-specific convenience symbol and only makes sense on SoCs
that both support PSRAM and already wire .mbedtls_heap into their
linker scripts.
It depends explicitly on MBEDTLS_ENABLE_HEAP: since it lives outside
the Mbed TLS Kconfig tree, its "select" of MBEDTLS_HEAP_CUSTOM_SECTION
would otherwise not be gated by that symbol's own
(MBEDTLS_ENABLE_HEAP && MBEDTLS) dependency. Kconfig's "select" does
not respect a target's "depends on", so enabling PSRAM and this
option while leaving Mbed TLS disabled would otherwise produce a
fatal Kconfig warning:
warning: MBEDTLS_HEAP_CUSTOM_SECTION ... has direct dependencies
(MBEDTLS_ENABLE_HEAP && MBEDTLS) ... with value n, but is
currently being y-selected by ESP_MBEDTLS_HEAP_ALLOC_EXT_RAM ...
Verified with a real board configure (esp32s3_eye) that PSRAM-only
builds with Mbed TLS disabled configure cleanly, and that builds
with MBEDTLS_ENABLE_HEAP=y still select MBEDTLS_HEAP_CUSTOM_SECTION
as expected.
Signed-off-by: Pedro Ramos <pedrohq.r@hotmail.com>
Assisted-by: Claude-Code:Sonnet-5 [Read] [Edit] [Bash]
Complete soc.yml and Kconfig.soc to add stm32mp13 SoC variants
newly added in device trees.
Note: today only stm32mp135f_dk is upstreamed so other variants
are not used in today's tests.
Signed-off-by: Erwan SZYMANSKI <erwan.szymanski@st.com>
Storing the Bluetooth identity through settings writes to flash
from the system workqueue and peaks at about 1.3-1.5 KiB on
Espressif SoCs, overflowing the 1 KiB default into the adjacent
stack. Raise the default to 2048 when BT_SETTINGS is enabled.
The Bluetooth shell peaks above the 2 KiB shell stack default
during bt init, so raise it to 4096 when BT_SHELL is enabled.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
RT266x boots from an AHAB container at a fixed 0x1000 offset
(ROM-mandated, not user-configurable), so hard-code that value
rather than adding a new Kconfig symbol. RT118x continues to
use CONFIG_IMAGE_CONTAINER_OFFSET unchanged.
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
Add the i.MX RT266x SoC series for the single Cortex-M85 core: SoC
Kconfig and defconfig, the memory linker script, the pinctrl SoC glue,
and the early bring-up in soc.c. The clock bring-up programs every CGU
root to its steady state in the early init hook, before the clock
controller runs, reading the steady-state values back from devicetree.
Register RT266x in soc.yml and extend the shared boot-header linker
script to emit the RT266x boot container.
The pinctrl SoC glue comes with a dedicated nxp,mcux-rt266x-pinctrl
binding: RT266x drives each pad through a single combined IOMUXC PIO
register whose PULLENA polarity and four-level drive-strength / slew-rate
encodings differ from the RT11xx parts, so it cannot reuse the RT11xx
binding. drive-strength is expressed as named impedances ("100-ohm" /
"66-ohm" / "50-ohm" / "33-ohm") and slew-rate as low/medium/fast/high,
both ordered to map directly onto the register fields.
Only the PIO5/PIO6/PIO7 pads have a DRIVE field, and only the others have
ODENA, so the glue writes a field a pad does not have. Asking for one is
a mistake rather than a no-op, so a build assertion per pin rejects
drive-strength on a pad without DRIVE and drive-open-drain on a pad
without ODENA, instead of silently dropping the request.
The core implements double-precision floating point and both Helium
extensions, so the series selects CPU_HAS_FPU_DOUBLE_PRECISION,
ARMV8_1_M_MVEI and ARMV8_1_M_MVEF together with FPU. Both L1 caches are
enabled from the early init hook, which SystemInit() leaves off.
The clock bring-up window parks both XSPI controllers, so no PSRAM or NOR
XIP access is permitted while it runs. Its functions live in ITCM and are
marked noinline: the section attribute alone does not keep the compiler
from inlining them into their flash-resident caller, which would leave
.itcm empty and run the park sequence out of the flash it just disabled.
The stacks the window uses are in DTCM through the board's
zephyr,kernel-stacks chosen node, so no stack-switch trampoline is
needed.
Register the S3MU_Type and LLC_Type HAL types in the checkpatch
typedefs file: soc.c dereferences them as "Type *const", but their
typedefs live in the HAL headers outside the commit diff, so checkpatch
otherwise misreads the '*' as multiplication and reports a spurious
SPACING error.
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
Add the pin controller for the MT8188, with the full pin table and the
devicetree macros that turn a pinmux property into a pin and function pair.
The register window is mapped with device_map() at PRE_KERNEL_1 priority 0
rather than reached through its physical address. There is no struct
device to hang DEVICE_MMIO off, because pinctrl_configure_pins() is called
from other drivers' init before any pin controller device would exist, but
the window still has to be mapped rather than assumed; a static
mmu_regions.c entry would do the same job less portably and only on arm64.
The cluster directory goes on the include path here because the pinctrl
framework includes pinctrl_soc.h, which this commit adds.
Co-authored-by: Felix Freimann <felix.freimann@mediatek.com>
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
Describe the Cortex-A55 cluster of the MT8188 alongside the audio DSP that
already lives on this die: soc.yml gains the cluster, and a Kconfig.soc
symbol, an arm64 selects block and a defconfig follow it.
The timer frequency is deliberately not set here. The cluster selects
TIMER_READS_ITS_FREQUENCY_AT_RUNTIME, so the architected timer publishes
CNTFRQ_EL0 into z_clock_hw_cycles_per_sec during its own init and
sys_clock_hw_cycles_per_sec() reads that, not the Kconfig value.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
The family symbol carried the Xtensa selects and guarded the
Kconfig.defconfig body. That was accurate while every cpucluster in the
family was an audio DSP, but the same dies carry Arm cpuclusters, which
cannot join the family without inheriting an Xtensa toolchain. Move the
architecture selects onto the cpucluster symbols, so a cpucluster asks for
the architecture it runs, and move the shared audio DSP defaults into
common/adsp beside the sources they configure, sourced by each audio DSP
cpucluster from its own defconfig.
The family symbol is left describing the silicon rather than one cpucluster
type, and no symbol stands for "this is an audio DSP": the cpuclusters that
are one say so themselves. A cpucluster on another architecture, or a chip
in the family with no audio DSP at all, needs nothing added here. No
functional change: all five DSP targets produce byte-identical images.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
The family directory held eight audio DSP files - the soc, irq, mailbox and
IPI sources, the shared header, the shared linker script and the two image
tools - beside the Kconfig files that describe the family as a whole. That
read correctly while every cpucluster in the family was an audio DSP, and
stops reading correctly as soon as one is not. Move them under common/adsp
and give each SoC a CMakeLists for the cpucluster files it owns: its own
cpuclk.c where it has one, and its own linker script. The shared directory
is entered only for the cpuclusters that need it.
Each cpucluster has a thin soc.h and linker.ld including the shared ones,
so those relative paths move with them, and each SoC's CMakeLists puts its
cluster directory on the include path so <soc.h> still resolves. The load
script is named in the board documentation, so that path moves too. Pure
relocation otherwise: no source line changes beyond those shim includes.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
One Kconfig symbol per SoC was enough while every cluster in the family was
an Xtensa audio DSP. These dies also carry Arm clusters, so configuration
has to attach per cluster rather than per SoC.
Give every cluster its own symbol, with SOC_<soc>_<cluster> selecting
SOC_<soc>. The per-SoC symbols move out of the family Kconfig.soc into one
file per SoC, sourced with rsource, and the audio DSP defaults move
alongside them into Kconfig.defconfig.<soc>_adsp. The boards select the
cluster symbol in the same commit, since the bare SoC symbols stop being
selectable targets.
No functional change: all five DSP targets produce byte-identical images.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
soc/mediatek/mt8xxx/ held each SoC's files flat, which only worked while
every SoC exposed one cluster. These dies also carry Arm clusters, and
SOC_LINKER_SCRIPT cannot name a linker.ld once two share a directory.
Push each SoC's files into an adsp/ subdirectory, leaving room for an a55/
counterpart alongside. Almost pure movement: the linker.ld and soc.h
shims gain one level of "../", and the two cpuclk.c files are reformatted,
since compliance treats a moved file as entirely added lines.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
soc.yml names this family mt8xxx, so the hardware model v2 symbol for it is
SOC_FAMILY_MT8XXX. The tree used SOC_FAMILY_MTK, which names no family
present in soc.yml, and never set the SOC_FAMILY string at all.
Rename the symbol and add the missing default. No functional change: the
only references are inside soc/mediatek and the two audio DSP driver
Kconfig files.
Signed-off-by: Aary Patil <aary.patil@mediatek.com>
CONFIG_CBPRINTF_CONVERT_CHECK_PTR is by default enabled and allows to
detect use of %p with char pointer in logging macros. It's benefitial
but takes >650 bytes of code and VPR cores have little memory.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The RT11xx SoC series unconditionally sourced the generic
soc/nxp/imxrt/mpu_regions.c fallback MPU table. A board that ships its
own static MPU region table (guarded by
CONFIG_BOARD_NXP_SPECIFIC_MPU_SETTINGS) would then link two
mpu_config definitions and fail.
Gate the generic table on CONFIG_ARM_MPU AND NOT
CONFIG_BOARD_NXP_SPECIFIC_MPU_SETTINGS so board-specific tables replace
the fallback cleanly. Cores and boards without a board table (cm4,
vmu_rt1170) keep using the generic file unchanged.
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
Add PSA Crypto driver for HSE devices. Use the PSA Crypto dispatch
layer from hal_silabs when the driver is enabled.
The driver is enabled by default if the `se` or `symcrypto` nodes
are enabled in devicetree.
Signed-off-by: Aksel Skauge Mellbye <aksel.mellbye@silabs.com>
Only take the crypto mutex once the library takes ownership
of the hardware. Previously, the mutex could be held indefinitely
if the subsequent crypto call was rejected (e.g. due to invalid
parameters) before calling into the library. By taking the mutex
in the library acquire function, it is guaranteed to be released
by the library release function.
Make the fact that yield shouldn't be used on LPWAES explicit.
Signed-off-by: Aksel Skauge Mellbye <aksel.mellbye@silabs.com>
The 5 GHz gate used a soc capability defined only by the HAL.
Add it to the esp32c5 caps, the only part that has it, under
the SOC_ESP32 prefix the soc folder uses.
Read the modem sleep frequency from the HAL as well, dropping
a second option that the HAL provided.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Wire the STM32WBA PM implementation to the new feature of the
PWRC Wake-up Controller module to trigger GPIO callbacks corresponding
to wake-up pins after resuming from S2RAM sleep.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
In some low-power states such as STANDBY on STM32WBA series, the GPIO
port controllers are not active and cannot detect interrupts to wake-up
the SoC (or just trigger a software callback). On the other hand, the
Power Controller (PWRC) remains active in all states and can monitor
specific "wake-up pins" for wake-up events: a rising OR falling edge.
When a wake-up event occurs, PWRC will set a (usually per-pin) flag in
a register and initiate the low-power state exit procedure.
Since regular GPIO interrupts are also edge-triggered, a wake-up event
on a pin should be treated as a GPIO interrupt, but this is not handled
by the hardware; however, it is possible to emulate this in software by
looking at which wake-up pins an event has occurred on, and calling the
registered GPIO callbacks for these pins manually.
Implement the logic to trigger GPIO callbacks based on wake-up events in
the PWRC Wake-up Controller module since it is generic:
- find the active wake-up flag(s)
- find the corresponding GPIO port and pin
- obtain the corresponding GPIO port controller device
- call gpio_fire_callback() as the GPIO driver would do
The function is not wired to any SoC's PM implementation yet; it should
be called from the pm_state_exit_post_ops() function which runs after
the system has been fully resumed (but before any thread gets the chance
to run).
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Rework the implementation of routine configure_wkup_line_source(), which
is renamed to set_wkup_line_source():
- make some assumptions about the register layout appear explicitly in
the code
- combine description split across two comments into a single one before
the function, shorten it and improve wording.
- gate function behind #if HAS_MUXED_WKUP_LINES
This rework will allow a cleaner introduction of the get() counterpart
of this function which will be needed for IRQ dispatching.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Instead of being a function-specific static, move the wake-up pins table
to file level so it can be accessed from other functions. This will be
used to implement GPIO interrupt dispatch.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
The function exported by this module was branded as `gpioport` and its
signature was in `stm32_gpio_shared.h`, even though the function can
work with all GPIO port controllers disabled since it only operates
on PWRC registers.
Rebrand the function as `pwrc` instead of `gpioport` and move it to the
`stm32_common.h` header instead, for lack of a better location...
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Create a dedicated Kconfig option which controls compilation of the
STM32 GPIO port manager module, and select this option explicitly in
the Kconfig for the STM32 GPIO and PINCTRL drivers which require this
module.
This replaces the previous approach where the SoC common CMakeLists
would add the GPIO port manage module to the build automatically if
either of the STM32 GPIO or PINCTRL module was enabled; an explicit
select at Kconfig level makes the dependency more visible.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
esp_appcpu_image_load() bounds-checked the appcpu iram
segment and the entry point with esp_ptr_in_iram(), which
tests against SOC_IRAM_HIGH. That is the ceiling of the
SRAM0 instruction view and it falls inside SRAM1, below
where the appcpu image is placed, so the loader aborted
before starting the appcpu unless
CONFIG_ESP_APPCPU_DRAM_SIZE was inflated far past what the
appcpu application needs.
A valid placement can also cross that ceiling, which no
single esp_ptr_in_*() helper covers, so test the range from
SOC_IRAM_LOW to SOC_DIRAM_IRAM_HIGH instead. Placements
reaching below SOC_IRAM_LOW stay rejected, as they fall
into the SRAM0 cache area. The dram check already uses a
range that spans SRAM1 and is left alone.
The esp32s3 loader needs no equivalent change: there
SOC_IRAM_HIGH equals SOC_DIRAM_IRAM_HIGH, so the appcpu
placement always passes.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
The appcpu area sizes were gated on
CONFIG_SOC_ESP32S3_APPCPU, which is only set on the appcpu
image's own build. On the procpu image APPCPU_SRAM_SIZE and
APPCPU_ROM_SIZE resolved to 0, so every subtraction meant
to keep the procpu regions clear of the appcpu was a no-op:
iram, dram, irom and drom all covered the areas the
bootloader loads and maps the appcpu image into. Gate them
on CONFIG_SOC_ENABLE_APPCPU instead, which is set on both
images of a pair.
The same branch redefines DRAM_USER_END to the start of the
IPC shared memory, which the procpu image did not evaluate
before. Its DRAM ceiling therefore drops from the end of
the shared buffers to the start of ipmmem0, 18180 bytes
lower, and the heap shrinks with it. That is intended: the
old ceiling let the procpu place data over the ipmmem0,
shm0, ipm0 and mbox0 windows the pair communicates
through, and the two images disagreed on where user DRAM
ended.
A procpu image that grew into any of those bytes shared
them with the running appcpu. Such an image now fails to
link instead, which is the intended behaviour. Non-AMP
builds keep the sizes at 0 and are unaffected.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
APPCPU_IRAM_SIZE and APPCPU_DRAM_SIZE were gated on
CONFIG_SOC_ESP32_APPCPU, which is only set on the appcpu
image's own build. On the procpu image both resolved to 0,
so the APPCPU_SRAM_SIZE subtraction that keeps iram0_0_seg
clear of the appcpu was a no-op and the region covered the
memory the bootloader loads the appcpu image into. Gate
them on CONFIG_SOC_ENABLE_APPCPU instead, which is set on
both images of a pair.
The appcpu dram segment also has to be carved out of
dram1_0_seg, which started at the very address the
bootloader loads it to. Its iram segment lands in SRAM0
rather than SRAM1, so only APPCPU_DRAM_SIZE is subtracted
there.
Without this a procpu image whose static data or heap
reaches into dram1_0_seg shares those bytes with the
running appcpu. Non-AMP builds keep APPCPU_SRAM_SIZE at 0
and are unaffected.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
The Zephyr memory region with nodelabel `pm_s2ram` contains the S2RAM
context and must be preserved. Make sure the SoC-specific code for
STM32WBA series accounts for it when configuring which SRAM pages
(or banks) should be preserved in addition to the Zephyr SRAM itself.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Enable the dma2d node in the stm32l4r9i_disco board and allow
enabling it from within LVGL by setting LV_USE_DRAW_DMA2D=y
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Enable the dma2d node in the stm32f769i_disco board and allow
enabling it from within LVGL by setting LV_USE_DRAW_DMA2D=y
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Enable the dma2d node in the stm32h7s78_dk board and allow
enabling it from within LVGL by setting LV_USE_DRAW_DMA2D=y
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Enable the dma2d node in the stm32u5g9j_dk2 board and allow
enabling it from within LVGL by setting LV_USE_DRAW_DMA2D=y
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Enable the dma2d node in the stm32f429i_disc1 board and allow
enabling it from within LVGL by setting LV_USE_DRAW_DMA2D=y
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Update the west yaml to point to the new LVGL version.
Fix the Kconfig symbol deprecation around color formatting/depth
in all boards/shields.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
soc_crypto.c includes sli_sxsymcrypt.h, whose include path hal_silabs
adds only with CONFIG_SILABS_SISDK_PROTOCOL_CRYPTO, but it was also
built with CONFIG_MBEDTLS. Series 3 builds with mbed TLS and without
the radio crypto failed, e.g. crypto.secp256r1.mbedtls on
sixg301_rb4407a. The radio crypto glue is the driver's only user.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
The SYSTEM_MANAGER MMU region is mapped with MT_P_RW_U_RW, giving
userspace direct read/write access to the system manager peripheral.
This looks like a copy/paste mistake from other boards and is not
appropriate for a peripheral of this kind. Change it to MT_P_RW_U_NA
so only the kernel can access it.
Signed-off-by: Muhammad Waleed Badar <muhammadx.waleedbadar@altera.com>
The Cortex-M55's branch cache is disabled upon reset. Enable it during
SoC initialization to gain some performance. A Kconfig gate is provided
to keep the old behavior (i.e., disabled) for scenarios where enabling
it could make performance worse.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
The dedicated DLM region is shared by hardware crypto
algorithms (SHA, RSA...etc), rather than being used
exclusively by SHA-256. Therefore, this change renames
`SOC_IT51XXX_SHA256_HW_ACCELERATE` to
`SOC_IT51XXX_HW_CRYPTO_ACCELERATE`.
Signed-off-by: Ren Chen <Ren.Chen@ite.com.tw>
esp32s2 and esp32s3 are windowed-ABI Xtensa cores and can use the
generic Xtensa unwinder, but neither implemented the SoC
validation hooks, so the weak stubs accepted any pointer as sane
and the option was never implied.
Move the checks to a single file under common, built by every
Xtensa target and by both core variants of the dual core ones, so
the second core validates pointers too, and imply the option on
esp32s2 and esp32s3. The shared version also accepts external RAM
stacks, which esp_stack_ptr_is_sane() does not do in this build,
and runs from iram. Both are new for esp32.
Verified on hardware: a four-deep fault unwinds to z_thread_entry
on esp32, esp32s2 and esp32s3, and on an esp32s3 with octal psram
a fault on a psram stack unwinds instead of reporting CORRUPTED.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
The MCXA and MCXN SoC devicetrees are about to declare a power domain node
for the CORE domain, and a device that names it in power-domains takes a
reference to the domain's device object. That object only exists if the
power domain driver is built, so a devicetree that names the domain and a
configuration that leaves CONFIG_POWER_DOMAIN off do not link.
Default it on wherever device PM is on. It costs nothing when nothing needs
it: the domain node follows &deeppowerdown, which the SoC devicetree leaves
disabled, and PM_STATE_FROM_DT skips power states that are not okay, so the
domain has an empty state list and never acts until an application enables
Deep Power Down.
The devices on the domain are resumed from the idle thread, and one that
reconfigures and recalibrates its hardware from its TURN_ON handler needs
more stack than the 256 to 320 bytes an Arm target gets by default.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Every low-power state these SoCs offer gates the core clock, and with it
SysTick, so a sleep only ends if timekeeping has been handed over to the
companion timer the devicetree names in
/chosen/zephyr,system-timer-companion. That timer is driven through the
Counter API, which nothing in a PM build selects, and
CONFIG_SYSTEM_TIMER_LPM_COMPANION_COUNTER depends on it: without
CONFIG_COUNTER the companion choice falls back to none with no warning, the
kernel keeps arming a SysTick that has stopped, and the first sleep deeper
than idle never returns.
Default the Counter API on when a companion is chosen, so a board that
names one gets a working PM build from CONFIG_PM alone.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Add SOC_MCXN546, SOC_MCXN946 and SOC_MCXN235 Kconfig/soc.yml entries
for these real MCXN silicon parts, which previously had no Zephyr
representation. Give each a composer dtsi overriding flash/SRAM sizes
over its series file, and give mcxn547, mcxn947 and mcxn236 the same
per-part composer dtsi treatment (previously included the generic
series file directly), pointing their boards at the new files.
Validated by building affected boards and confirming expected FLASH
and RAM region sizes.
Signed-off-by: Wei Feng <wei.feng_5@nxp.com>
Before NPCX4, two deep sleep sub-states have to be listed in
cpu-power-states because the 'Instant' wake-up path is only valid for
a residency shorter than 200 ms:
- suspend_to_idle0: Deep Sleep with 'Instant' wake-up
- suspend_to_idle1: Deep Sleep with 'Standard' wake-up
The PM policy picks between them from the min-residency-us property,
so a sleep the kernel expects to last longer than 200 ms falls back to
the standard wake-up sub-state.
NPCX4 and later lift that restriction with PMCSR bit 4, reserved on
earlier series, so 'Instant' wake-up can be used for an unlimited
residency. Describe the capability with a new
"nuvoton,npcx-power-state" binding that extends "zephyr,power-state"
with an "unlimited-instant-wakeup" property, and pass it down to the
clock controller.
suspend_to_idle0 alone would therefore give the best power figures on
NPCX4.
However, erratum 2.21 prevents that when eSPI is in use: two eSPI
transactions issued shortly after the EC entered Deep Sleep with
instant wake-up can produce a CRC error. Boards with eSPI enabled
must select one of
- suspend_to_idle1: Deep Sleep with 'Standard' wake-up
- suspend_to_idle2: Sleep, added here, which keeps HFCLK running
so npcx4.dtsi keeps cpu-power-states at suspend_to_idle1 and leaves
the other two sub-states for boards to opt into.
Assisted-by: Copilot:claude-opus-5
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Add DeviceTree and Kconfig support for the STM32F401XB variant of
the STM32F4 series.
The STM32F401XB provides 128 KiB of flash and 64 KiB of SRAM.
Origin: Original
Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
On CYW20829/CYW89829 B0 silicon the BLE controller boot switches CLK_HF0
onto the 48 MHz BLE ECO (ALTHF) path. The btstack-integration HCI layer
already restores CLK_HF0 to the 96 MHz FLL path on CY_BT_IPC_BOOT_FULLY_UP,
but that restore is guarded by COMPONENT_CYW20829B0 / COMPONENT_CYW89829B0,
which the build never defined. As a result the Cortex-M33 SysTick keeps
running at 48 MHz while the kernel still assumes
CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC (96 MHz), so every k_sleep()/timeout
takes twice as long once Bluetooth is enabled.
Add SOC_CYW20829_B0 / SOC_CYW89829_B0 helper symbols that track the
B0-silicon MPNs, and define COMPONENT_CYW20829B0 / COMPONENT_CYW89829B0 as
private compile definitions on the hal_infineon library, next to the
btstack-integration sources that consume them, instead of as global
defines. This compiles in the existing HAL restore only for the library
that needs it, and only on B0 silicon. B1 silicon is not covered because
the HAL has no corresponding restore path.
Verified on CYW920829M2EVK-02: with Bluetooth enabled, a
k_sleep(K_SECONDS(5)) loop was spaced about 10 s apart before the change
and about 5 s apart after. Confirmed COMPONENT_CYW20829B0 reaches the
btstack-integration HCI source on a B0 build and is absent on a B1 build.
Assisted-by: AI (GitHub Copilot)
Signed-off-by: Bill Waters <bill.waters@infineon.com>
