Add a new Kconfig option that has to be selected by SoCs providing PM
hooks. This option will be now required to enable CONFIG_PM. Before this
change, CONFIG_PM could always be enabled, regardless of SoC providing
any kind of low-power support.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
NMI_INIT() is now a no-op, so remove it from all SoC code. Also remove
the irq lock/unlock pattern as it was likely a cause of copy&paste when
NMI_INIT() was called.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Added logging declaration to soc.c of stm32wl, which resolves build
errors when using this SOC with DEBUG logging level
Fixes: #57655
Signed-off-by: Oliver King <oliver.king@steadconnect.com>
Move STM32H7_DUAL_CORE to
soc/arm/st_stm32/stm32h7/Kconfig.soc
add select STM32H7_DUAL_CORE for SOC_STM32H745XX/H747XX
Cleanup old occurences where was set to y
Signed-off-by: Marc Desvaux <marc.desvaux-ext@st.com>
This new Kconfig option lets the developer configure if the Cortex M4
core should be force-booted during M7 init independent of the BCM4
option byte.
This allows to disable this default behaviour via Kconfig which was not
possible so far.
Signed-off-by: Jan Krautmacher <jan@krautmacher.org>
This prevents configuration errors if a board is configured when
the SoC indicates segger RTT support but the segger module is
not available.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Introduce the new stm32h5 soc serie from STMIcroelectronics.
Note that stm32h503x do not have TrustZone nor SAU
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Remove the manually created linker section, because it's already
automatically generated for all sram regions in the DTS with the
"zephyr,memory-region" compatibility.
Signed-off-by: Hein Wessels <heinwessels93@gmail.com>
Allow selecting between direct SMPS and LDO on the startup. This
enables selecting to use SMPS regulators which can save bit of power.
Signed-off-by: Miika Karanki <miika.karanki@vaisala.com>
The STM32H730 series has a variant built with SMPS. It uses
`stm32h730xxq.h` header file instead of `stm32h730xx.h`, which has the
SMPS macro defined.
This commit adds the `SOC_STM32H730XXQ` configuration option to allow
the build system include the proper header file. With this change,
boards can enable `CONFIG_POWER_SUPPLY_DIRECT_SMPS` to set up the power
supply for the CPU.
Signed-off-by: Chen Xingyu <hi@xingrz.me>
Add the stm32U5 serie for the support of the STM32_BACKUP_SRAM
The PWR peripheral is enabled by the soc/arm/st_stm32/stm32u5/soc.c
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Drop STM32 pinmux driver in favor of pinctrl. Some definitions located
in pinmux headers were used by the pinctrl driver, so they have been
moved there.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
PR #30403 implemented nocache regions for ethernet DMA buffers in sram3 to
fix issue #29915. Unfortunately, some STM32H7 variants do not have any
sram3 so they still suffer from #29915.
All H7 variants have sram2 though, so use that for targets without sram3.
Signed-off-by: Björn Stenberg <bjorn@haxx.se>
When running the blinky example on STM32H747, with the BOOT_CM4 bit set
to 0, the M4 core goes into panic.
Increasing the value of the hardware semaphore retry prevents this.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
This patch allows successive reflashing operation on stm32f3
boards by Enabling the Debug Module during SLEEP mode.
This will especially makes reflahing and debugging possible
with pyocd runner on west commands.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
On some STM32 MCUs SEGGER RTT is only working with realtime updates
when DMA is clocked. The STM32U5 series uses a new DMA controller
module called GPDMA.
Refs: #34324Fixes: #54316
Signed-off-by: Almin Iriskic <almin.iriskic@student.tugraz.at>
Added information about pin output direction into
Z_PINCTRL_STM32_PINCFG_INIT if output_low or output_high is provided.
GPIO output flag is set in configuration struct and this will end up
being loaded into MODE register. Because of that it is no longer
required for pinctrl_configure_pins() to set MODE register value for
GPIO input/output.
Fixes#53141.
Signed-off-by: Lukasz Mazur <lukasz.mazur@hidglobal.com>
EXTRA_IMGTOOL_ARGS is used to set additional options by the user.
Any user change will overwrite this option, which
is unintuitive.
Also option ROM_START_OFFSET will be overwritten which is also unintuitive.
Replace hardcoded config option MCUBOOT_EXTRA_IMGTOOL_ARGS
with proper config ROM_START_OFFSET.
Signed-off-by: Maciej Zagrabski <mzi@trackunit.com>
STM32WB Controller supports application to initiate the "PHY Update
Procedure" (BT_USER_PHY_UPDATE) while it doesn't support it to be
automatically triggered on connection establishment (BT_AUTO_PHY_UPDATE).
Default BT_USER_PHY_UPDATE to true, which automatically defaults
BT_AUTO_PHY_UPDATE to false.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Now that IPM drivers are enabled based on devicetree we can
remove any cases of them getting enabled by Kconfig, *defconfig*,
and *.conf files.
We need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Some files make use of NMI API (NMI_INIT()) without including the
appropriate headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Similarly to other drivers, use auto generated DT_HAS_<COMPAT> Kconfig
symbol to control use of STM32 lptim driver.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
The STM32G070 and STM32G0B0 Socs don't have USB power delivery support
but the PINs PD0, PD2, PB15, PA8 pins of these still have the same
pull down on boot configuration options as the SOCs with UCPD support.
This commit skips the check if such a peripheral is enabled,
therefore the configuration will always be applied on these SOCs
and the compile error is resolved.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
On STM32U5 series, when an image is build with mcuboot,
image starts at offset 0x400 instead of default 0x200.
This should be taken into account when calling imgtool by using
dedicated option to set header-size value.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Now that crypto drivers are enabled based on devicetree
we need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <galak@kernel.org>
Now that I2S drivers are enabled based on devicetree
we need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <galak@kernel.org>
Now that usb device drivers are enabled based on devicetree
we need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <galak@kernel.org>
