As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The number of NXP DTSI files is growing rapidly, with over 150
files currently. To improve maintainability and discoverability,
we reorganized NXP DTSI files by moving them into family-specific
subdirectories under 'dts/arm/nxp'. This directory structure is
now consistent with the structure under 'soc/nxp'.
This commit updates the migration guide and release notes to
document this change.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Update file paths in MAINTAINERS.yml to reflect the reorganization of
NXP DTSI files into family-specific subdirectories. The following paths
are updated:
- dts/arm/nxp/nxp_imx* -> dts/arm/nxp/imx/nxp_imx*
- dts/arm/nxp/nxp_k* -> dts/arm/nxp/kinetis/nxp_k*
- dts/arm/nxp/nxp_lpc* -> dts/arm/nxp/lpc/nxp_lpc*
This ensures maintainer file patterns correctly match the new directory
structure introduced in the DTSI reorganization.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize LPC DTSI files into lpc subdirectory
2. Update boards/lpc devicetree references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize IMX RT DTSI files into imxrt subdirectory
2. Update boards/imxrt devicetree references to use new paths
3. Update samples/imxrt overlay references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize MCX DTSI files into mcx subdirectory
2. Update boards/mcx devicetree references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize RW DTSI files into rw subdirectory
2. Update boards/rw devicetree references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize IMX DTSI files into imx subdirectory
2. Update boards/imx devicetree references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
1. Reorganize S32 DTSI files into s32 subdirectory
2. Update boards/s32 devicetree references to use new paths
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
Combine register address and data in one buffer and use i2c_write_dt()
instead of i2c_burst_write_dt() so the transfer is a single I2C
transaction. Some I2C controllers (e.g. Infineon) split burst write
into two transactions with a STOP in between, which causes failure.
Signed-off-by: Oleksandr Skopets <skopets.sasha@gmail.com>
Below warning is reported in Zephyr upstream weekly CI after
34985a73b836b7f44b3314854fc760270e38fb26 was merged:
```
ld.bfd: warning: orphan section .TEXT.pm_s2ram_mark_check_and_clear'
from zephyr/libzephyr.a(s2ram_marking.S.obj)' being placed in section
`.TEXT.pm_s2ram_mark_check_and_clear'
```
Fix the warning by adding the appropriate headers.
Signed-off-by: Anjali Kashyap <anjkas23@gmail.com>
Add documentation for using Zephyr as Xen Dom0 on the Raspberry Pi 5 to
describe how to build and configure Zephyr for Dom0 functionality.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Since snippet device tree overlays are applied last, this made it
impossible for applications to override boot addresses in their own
overlays.
This approach has been removed, so update the documentation with a
dedicated section explaining how applications should set device tree
nodes using runtime information provided by Xen.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Snippets allow modification of Kconfig build options and board device
trees during application or sample builds. However, in the case of device
trees, snippet modifications are applied at the end of device tree
generation.
This prevents the final application from setting correct values for memory
and hypervisor nodes, which may be changed at runtime by the Xen
hypervisor (depends on the final configuration, such as image size, memory
bank sizes, and load addresses, etc) since these are allocated
dynamically.
Remove these nodes from the snippet to enable applications to set these
values through their own application overlay.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Snippets allow modification of Kconfig build options and board device
trees during application or sample builds. However, in the case of device
trees, snippet modifications are applied at the end of device tree
generation.
This prevents the final application from setting correct values for memory
and hypervisor nodes, which may be changed at runtime by the Xen
hypervisor (depends on the final configuration, such as image size, memory
bank sizes, and load addresses, etc) since these are allocated
dynamically.
Remove these nodes from the snippet to enable applications to set these
values through their own application overlay.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Snippets allow modification of Kconfig build options and board device
trees during application or sample builds. However, in the case of device
trees, snippet modifications are applied at the end of device tree
generation.
This prevents the final application from setting correct values for memory
and hypervisor nodes, which may be changed at runtime by the Xen
hypervisor (depends on the final configuration, such as image size, memory
bank sizes, and load addresses, etc) since these are allocated
dynamically.
Remove these nodes from the snippet to enable applications to set these
values through their own application overlay.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Snippets allow modification of Kconfig build options and board device
trees during application or sample builds. However, in the case of device
trees, snippet modifications are applied at the end of device tree
generation.
This prevents the final application from setting correct values for memory
and hypervisor nodes, which may be changed at runtime by the Xen
hypervisor (depends on the final configuration, such as image size, memory
bank sizes, and load addresses, etc) since these are allocated
dynamically.
Remove these nodes from the snippet to enable applications to set these
values through their own application overlay.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Signed-off-by: Svitlana Drozd <svitlana_drozd@epam.com>
Snippets in zephyr should be globally usable for general purpose,
snippets for a single application are not a valid use-case (that
is intended for user applications in their own repositories),
therefore remove these
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Doing this increases the QSPI peripheral clock from 40 MHz to 80 MHz.
This improves flash access throughput and overall performance
on siwx91x devices, as QSPI is used for external flash operations.
Signed-off-by: Sai Santhosh Malae <Santhosh.Malae@silabs.com>
Reduce the transfer duration scaling used by
test_spi_complete_multiple_timed. The recent increase in QSPI frequency
improves overall siwx91x performance, resulting in faster SPI transfers.
Adjust the scaling factor to keep the test timing expectations aligned
with the updated SPI transfer rates.
Signed-off-by: Sai Santhosh Malae <Santhosh.Malae@silabs.com>
The Siwx91x GSPI controller requires the FIFO reset bits to be
held high for a minimum of one GSPI bus clock cycle.
Currently, the driver asserts and deasserts the reset back-to-back,
which may result in an insufficient reset pulse width at higher
frequencies.
Add a small, frequency-based delay after asserting the FIFO reset
bits to guarantee the minimum reset duration, ensuring reliable
FIFO reset behavior.
Signed-off-by: Sai Santhosh Malae <Santhosh.Malae@silabs.com>
Update the GSPI DMA configuration to conditionally register the DMA
callback based on transfer direction and RX buffer presence. The
callback is enabled for TX-only transfers when the RX buffer is NULL
and for RX transfers when a valid RX buffer is provided.
Signed-off-by: Sai Santhosh Malae <Santhosh.Malae@silabs.com>
On Cortex-M with NVIC, if a peripheral sets its interrupt
flag again while the current handler is executing, the NVIC
pending bit is set. Even after the current handler clears
the flags, the pending bit still remain set. The current
implementation manually clears the pending bit to avoid
unneccesary extra handler calls when no additional
processing is required.
On other Arm GIC-based platforms like Cortex-R52, the GIC
automatically clears the pending bit when the peripheral
flag is cleared since these interrupts are level-sensitive.
Therefore, manually clearing the pending bit is unneccesary.
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
The current stm32 drivers will only enable soft NSS support if
the device is using a Zephyr managed GPIO for CS, or if the
CONFIG_SPI_STM32_USE_HW_SS flag is set. Neither of these are
actually appropriate for a peripheral, which doesn't control CS.
With this change, it is possible for the SPI interface to be
configured as a peripheral but still use soft NSS -- otherwise,
short of creating a "fake" GPIO configuration, the peripheral
will always use hard NSS, and for some boards/configurations,
that is unworkable. In the case of a board where the CS
is not hooked up, we can use soft NSS to allow the peripheral
to assume CS and be driven by the SPI clock signal alone.
Our board has only three signals (clock, COPI, POCI) enabled
on one of the SPI interfaces (it is communicating with another
MCU on the same board), and works with this change. Without
the change, we must enable a "fake" GPIO driver configuration
(which is never used for anything, and really makes little
sense for a peripheral, but it just happens to force the
driver to go down that code path). We cannot disable the
CONFIG_SPI_STM32_USE_HW_SS mechanism, as that impacts ALL
interfaces, and we have a second interface in controller
mode that speaks to flash and requires the NSS_HARD codepath.
Signed-off-by: Rob Newberry <rob@zenomoto.com>
Use lowercase 'a' instead of uppercase 'A' in hexadecimal notation
for consistency with coding style conventions.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
The user red led on the stm32n6570_dk is LD2 hence rename the
as red_led_2 instead of red_led_1. Moreover add an alias led1
pointing to this led, since this is a USER LED, allowing to
use samples requiring two leds.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
For P2P provisional discovery make the retries configurable, in case the
peer doesn't respond we can reduce to avoid airtime.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
