The method ieee802154_radio_handle_ack() does not belong to the
PHY/radio layer but to the L2 layer. It is a callback called from the
radio layer into the L2 layer and to be implemented by all L2 stacks.
This is the same pattern as is used for ieee802154_init(). The
'_radio_' infix in this function is therefore confusing and
conceptually wrong.
This change fixes the naming inconsistency and extensively documents
its rationale.
It is assumed that the change can be made without prior deprecation of the
existing method as in the rare cases where users have implemented custom
radio drivers these will break in obvious ways and can easily be fixed.
Nevertheless such a rename would not be justified on its own if it were
not for an important conceptual reason:
The renamed function represents a generic "inversion-of-control" pattern
which will become important in the TSCH context: It allows for clean
separation of concerns between the PHY/radio driver layer and the
MAC/L2 layer even in situations where the radio driver needs to be
involved for performance or deterministic timing reasons. This
"inversion-of-control" pattern can be applied to negotiate timing
sensitive reception and transmission windows, it let's the L2 layer
deterministically timestamp information elements just-in-time with
internal radio timer counter values, etc.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
A mesh key type has been added to be able to choose the different
key representation for different security libraries.
The type as well as some functionality related to Mesh key
management has been added as a public API.
If tynicrypt is chosen then keys have representation
as 16 bytes array. If mbedTLS with PSA is used then keys are
the PSA key id. Raw value is not kept within BLE Mesh stack
for mbedTLS. Keys are imported into the security library
and key ids are gotten back. This refactoring has been done
for the network(including all derivated keys), application,
device, and session keys.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
This allows the MIPI Sys-T library to be built with minimal C
library. This is due to lack of support for wchar in our
minimal C library. This simply tells the library to skip any
wchar support.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The RSSI value in net_pkt (net_pkt_cb_ieee802154.rssi) was used
inconsistently across drivers. Some drivers did cast a signed dBm value
directly to net_pkt's unsigned byte value. Others were assigning the
negative value of the signed dBm value and again others were offsetting
and stretching the signed dBm value linearly onto the full unsigned byte
range.
This change standardizes net_pkt's rssi attribute to represent RSSI on
the RX path as an unsigned integer ranging from 0 (–174 dBm) to 254 (80
dBm) and lets 255 represent an "unknown RSSI" (IEEE 802.15.4-2020,
section 6.16.2.8). On the TX path the rssi attribute will always be
zero. Out-of-range values will be truncated to max/min values.
The change also introduces conversion functions to and from signed dBm
values and introduces these consistently to all existing call sites. The
"unknown RSSI" value is represented as INT16_MIN in this case.
In some cases drivers had to be changed to calculate dBm values from
internal hardware specific representations.
The conversion functions are fully covered by unit tests.
Fixes: #58494
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
It looks like LV_Z_DPI is not used anywhere and only lived in the
context of an incorrect board symbol definition so far (moved to
Kconfig.lvgl in the previous patch).
This was probably meant to be LV_DPI_DEF (which actually exists in the
LVGL module) and was renamed incorrectly, fix it by renaming it
everywhere.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Some boards override default for few LVGL LV_Z_* symbols. This causes
the build to fail if the module is not present in the system, and has
been worked around on one board by repeating the types in the board
Kconfig file.
Fix this properly by defining the known type for all symbols used in
boards in modules/Kconfig.lvgl.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
`tfm_fwu_api.c` was missing from the list of possible source files
to be exported from TF-M, which is required when
`CONFIG_TFM_PARTITION_FIRMWARE_UPDATE` is defined.
Signed-off-by: Kevin Townsend <kevin.townsend@linaro.org>
The IEEE802154_2015 option is misleading, as it does not introduce full
802.15.4-2015 standard compliance but only random bits, plus it's
defined at the radio driver level, which brings yet another confusion.
Because of that, the option will be deprecated, and respective parts of
code that made use of it converted to use more specific configurations:
* nRF driver will now use CONFIG_NRF_802154_ENCRYPTION to specify
whether to compile in TX security
* net_pkt will only add extra 802.15.4 control block fields if
OpenThread is used, as they were solely used by this L2
* OpenThread radio layer will now use the OpenThread version to
determine whether to compile in TX security.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Previously, Zephyr's mbedtls module's cmake build created a single static
library, rather than the collection of libraries (mbedtls, mbedcrypto,
and mbedx509) that upstream mbedTLS cmake provides.
To give better control at link time to choose the required libraries to
link, this commit updates the Zephyr MbedTLS module to also define a
collection of libraries rather than a single static MbedTLS library.
One benefit of the three library approach is that if mbedTLS is used in
Zephyr in the the non-secure application in addition to TFM's PSA Crypto
API on the secure side with TF-M, PSA API calls on the non-secure side
will be redirected to the TFM PSA implementation, and the mbedcrypto
library will only be linked to the secure (TF-M) binary, with the mbedtls
and mbedx509 libraries linked against the non-secure (Zephyr) binary,
enabling TLS calls to PSA crypto to be redirected to mbedcrypto in the
secure partition and avoiding function duplication in the non-secure
binary.
Signed-off-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@linaro.org>
nRF52 in case of USB CDC required `CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n`
Due to incorrect error check in `otPlatUartEnable`.
Signed-off-by: Przemyslaw Bida <przemyslaw.bida@nordicsemi.no>
After the MCUboot configuration options were moved out of the main
Kconfig.zephyr they were placed in a new Kconfig.mcuboot in the root of
the repo. This is not right, and the file belongs in the modules/
folder.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The LSM6DSV16X is a system-in-package featuring a 3-axis digital
accelerometer and a 3-axis digital gyroscope for industrial and IoT
solutions. The LSM6DSV16X embeds advanced dedicated features such as
a finite state machine (FSM) for configurable motion tracking and a
machine learning core (MLC) for context awareness.
https://www.st.com/en/mems-and-sensors/lsm6dsv16x.html
This driver is based on stmemsc HAL i/f v2.02
Signed-off-by: Armando Visconti <armando.visconti@st.com>
This commit adds implementation of following new api functions from
openthread:
- otPlatCryptoEcdsaGenerateAndImportKey
- otPlatCryptoEcdsaExportPublicKey
- otPlatCryptoEcdsaVerifyUsingKeyRef
- otPlatCryptoEcdsaSignUsingKeyRef
Signed-off-by: Przemyslaw Bida <przemyslaw.bida@nordicsemi.no>
The LSM6DSO16IS is a system-in-package featuring a 3-axis digital
accelerometer and a 3-axis digital gyroscope for industrial and IoT
solutions. The LSM6DSO16IS embeds a new ST category of processing,
ISPU (intelligent sensor processing unit) to support real-time applications
that rely on sensor data. The ISPU is an ultra-low-power, high-performance
programmable core which can execute signal processing and AI algorithms
in the edge.
https://www.st.com/en/mems-and-sensors/lsm6dso16is.html
This driver is based on stmemsc HAL i/f v2.02
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Enable UART on the DSP from the i.MX8MP target:
- add corresponding nodes in dtsi and dts;
- create a dts overlay for uart;
- add a config fragment for uart and console configuration.
So, in order to compile an application and enable UART
a user must run west build using DTC_OVERLAY_FILE and CONF_FILE.
Here's an example for hello_world:
west build -p always -b nxp_adsp_imx8m samples/hello_world/
-DDTC_OVERLAY_FILE="boards/xtensa/nxp_adsp_imx8m/
nxp_adsp_imx8m_uart.overlay" -DCONF_FILE="boards/xtensa/nxp_adsp_imx8m/
nxp_adsp_imx8m_uart.conf"
For other applications, like SOF, where we don't need UART, we simply run:
west build -p always -b nxp_adsp_imx8m ../modules/audio/sof/ --
-DTOOLCHAIN=/opt/zephyr-sdk-0.15.2/xtensa-nxp_imx8m_adsp_zephyr-elf/
bin/xtensa-nxp_imx8m_adsp_zephyr-elf -DINIT_CONFIG=imx8m_defconfig
The nxp_adsp_imx8m is using the nxp_imx_iuart driver.
For now, is used in poll mode.
Next step is to enable the interrupt controller in
DSP and use the interrupt driver UART.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
- Added initial version of Infineon CAT1 Flash driver
- Added binding file for infineon,cat1-flash-controller.yaml
- Added overlays for subsys/nvs and drivers/flash_shell
to support cy8cproto_063_ble, cy8cproto_062_4343w boards
- Defined erase-block-size in PSoC6 MPN dtsi.
Signed-off-by: Sreeram Tatapudi <sreeram.praveen@infineon.com>
Reworked QDEC SHIM to suppor multi-instance peripheral. Patch includes
Kconfig alignment for proper instance handling.
Signed-off-by: Adam Wojasinski <adam.wojasinski@nordicsemi.no>
Although existing nRF SoCs have only one I2S instance, the nrfx_i2s
driver has now multi-instance API and the related nrfx configuration
symbols need to be used appropriately.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add TF-M support for nrf9161 DK and enable it by default for the
non-secure board variant.
Disable UART1 since TF-M use this for output and it is configured
as a secure peripheral.
Enabling this will trigger a BusFault in TF-M.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Print the memory usage of TF-M built executables during build.
This is defaulting to OFF because we have CONFIG_TFM_BUILD_LOG_QUIET
set to ON.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
- This includes the driver, test app, and sample app
- Only the boards\arm\cy8cproto_062_4343w board is supported for now
Signed-off-by: Bill Waters <bill.waters@infineon.com>
Added a generic driver for RaspberryPi Pico PIO.
This driver is an intermediate driver for abstracting the PIO
device driver from physical pin configuration.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@fujitsu.com>
Signed-off-by: Yonatan Schachter <yonatan.schachter@gmail.com>
Signed-off-by: Ionut Catalin Pavel <iocapa@iocapa.com>
OpenThread requires that the `mTimestamp` parameter from the `mRxInfo`
struct points to the end of SFD, i.e. beggining of PHR.
Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
After `otPlatRadioSleep` was fixed to properly set radio state to sleep,
radios supporting `IEEE802154_HW_SLEEP_TO_TX` capability would not be
able to handle `PENDING_EVENT_TX_DONE` while in sleep state.
This commit fixes such case.
Signed-off-by: Eduardo Montoya <eduardo.montoya@nordicsemi.no>
In d540cf8877 I tried to optionally enable the cache management
functions in Open-AMP introducing a new CONFIG_OPENAMP_WITH_DCACHE
symbol.
This is not working. Introduce a proper fix to have this actually
working correctly as intended.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The nRF9161 is technically a SiP (System-in-Package) that consists of
the nRF9120 SoC and additional components like PMIC, FEM, and XTAL,
so for nrfx/MDK the nRF9120 SoC is to be selected as the build target,
but since the nRF9161 is what a user can actually see on a board, using
only nRF9120 in the Zephyr build infrastructure might be confusing.
That's why in the top level of SoC definitions (for user-configurable
options in Kconfig, for example) the nRF9161 term is used and nRF9120
underneath.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Commit adds experimental support mbedtls psa as crypto
backend for ble mesh. It were run only on bsim tests.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Move the Segger RTT module Kconfig to modules/segger/kconfig. The Segger
debug library is not a driver and should not reside under drivers/debug.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
MISRA Rule 5.7 requires uniqueness of tag identifiers. Shell is
frequently problematic because many code uses `const struct shell
*shell`. This causes CI noise every time one of these shell files is
edited, so let's update all of them with `const struct shell *sh`
instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@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>
With the stm32h5x, hal driver is xspi for octospi
Add a header file to map functions and constants.
The ospi driver of the stm32H5x serie does not support DMA yet.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This commit fixed Openthread kconfig option to use correct value and
description of units.
Signed-off-by: Przemyslaw Bida <przemyslaw.bida@nordicsemi.no>
