DT config for MPS4 corstone315 boards which can be tested with simulation.
Creates a custom section in the unused SRAM region. Executing code
in this region in privileged mode will result in an MPU fault while,
execution in unprivileged mode should work fine.
Signed-off-by: Shaunak saha <ssaha@tsavoritesi.com>
What is changed?
Added config for Ethos-U65 for Corstone315 which has default 256 MACs
as per FVP.
Why do we need this change?
This will help in validating the NPU when we add support for FVP
testing for Ethos-U65.
Signed-off-by: Shaunak saha <ssaha@tsavoritesi.com>
What is changed?
- Add initial support for the MPS4 Corstone-315 FVP platform, including
board and SoC definitions.The qualifier to build/run application
with board mps4/corstone315 is
`mps4/corstone315/fvp` for secure and
`mps3/corstone315/fvp/ns` for non-secure.
- FVP testing with corstone315 uses the ARM FVP
`FVP_Corstone_SSE-315`.
Why do we need this change?
- This enables FVP support for corstone315.
- A separate FVP variant was added for corstone315 as the TFM board
used for non-secure variant differs for FPGA and FVP.
TFM board `arm/mps4/corstone315` support is present but no FVP support
yet. We can test this by building TF-M with
-DTFM_PLATFORM=arm/mps4/corstone315 and then lauching FVP:
FVP_Corstone_SSE-315 --data "bl1_1.bin"@0x11000000
--data "cm_provisioning_bundle.bin"@0x12024000
--data "dm_provisioning_bundle.bin"@0x1202aa00
--data "bl2_signed.bin"@0x12031400
--data "tfm_s_ns_signed.bin"@0x38000000
Signed-off-by: Shaunak saha <ssaha@tsavoritesi.com>
Comments and documentation mention compatibility with several
Sharp LS0xxx references, such as LS012B7DD06, a 64-color 6-bit
parallel display, and LS013B7DH06 a 8-color serial display.
The ls0xx driver supports serial and monochrome only.
Signed-off-by: Eve Redero <eve.redero@gmail.com>
Allow setting fifo-highres from DT, also unify the
naming of all registers and expand to a more complete list.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Add initial support for i2c on Renesas RX MCU
This driver is controlling the RIIC HW of RX MCU for i2c bus
interface on Zephyr
Only master mode is supported
Signed-off-by: Duy Nguyen <duy.nguyen.xa@renesas.com>
Add a missing assignment of the return value of zms_write() to rc
variable so that potential error is actually checked and returned.
Fixes CID 524778
Fixeszephyrproject-rtos/zephyr#90474
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Implement I2C target mode in STM32 I2C RTIO drivers. The implementation
in respectively i2c_ll_stm32_v1_rtio.c and i2c_ll_stm32_v2_rtio.c is
based on the implementation of the non-RTIO drivers, respectively
i2c_ll_stm32_v1.c and i2c_ll_stm32_v2_rtio.c.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Correct management of I2C write transfers that are driven from 2
I2C messages, one for the transfer of the address to write
to and a following message for the transfer of the data to be written.
In this case, no START and STOP bit should be triggered between the 2
I2C transfers.
In STM32 I2C v1 driver, this simply means not emitting a START
condition when the input sequence does not set the RESTART flag.
In STM32 I2C v2 driver, this can only be achieved using the SoC I2C
controller Reload Mode feature, hence update Reload Mode implementation
to use reload mode for both transfers over 255 bytes (splitted in
chunks) and for cases where no STOP and START bits are emitted between
2 transfer in the same transaction.
Regarding STM32 I2C v2 driver, the reload mode must be enable before the
first transaction, known that it's needed due to the following
transaction. Therefore we need to parse the messages grouped in the same
transaction to detect such sequences (a message without STOP flag
followed by a message without RESTART flag) and when so, pass the
information to the I2C driver through RTIO framework. To achieve that,
let's use a free bit from I2C message flags (bit 7) in the message
for which we need to enable SoC ReloadMode from the first transfer.
We check that this bit flag is not used by the I2C framework prior
using it.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
The first transfer in an I2C transaction series must always set
the RESTART flag. Since this is not always done by callers,
enforce the flag is set, both in the I2C API and RTIO API entry
points of STM32 I2C RTIO drivers.
Add a sanity test in STM32 I2C v2 RTIO driver on transaction
chunks regarding RESTART and STOP flags, as done on the non-RTIO
driver.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Raising event from driver itself after successful AP start,
instead of waiting for an event from SDK/TA FW. TA used to send an
asynchronous event earlier but currently does not.
Signed-off-by: Muzaffar Ahmed <muzaffar.ahmed@silabs.com>
Fixes: commit a73f20214 ("drivers: wifi: siwx91x: Fix boot_config")
Disabled the 160 MHz feature due to stability issues (mode change)
Signed-off-by: Muzaffar Ahmed <muzaffar.ahmed@silabs.com>
Mark bt_hci_cmd_create() as deprecated (superceded by bt_hci_cmd_alloc()),
and update any references to the new function.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
These tests have some sort of simple host implementation, which reuses the
bt_hci_cmd_create() API name, but the implementation is actually local and
something that can be made static. Change the function to be static and
rename it to be more in line with other internal functions.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
The command buffer was incorrectly encoded due to the recent change to H:4
encoding. Instead of fixing the header offset, just use the newly
introduced bt_hci_cmd_alloc() API, since that takes care of correctly
encoding the command header when it gets sent.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Introduce a new bt_hci_cmd_alloc() API which only allocates a command
buffer and reserves sufficient headroom for H:4 and command headers, but
doesn't actually encode any of those headers into the buffer. Additionally,
modify bt_hci_cmd_send() and bt_hci_cmd_send_sync() so that they handle
such buffers and perform the header encoding correctly. To avoid
duplication, bt_hci_cmd_send_sync() now builds upon (i.e. calls internally)
the bt_hci_cmd_send() API.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Commit be40d854c2ccacf14ca3fcfb01bffdc9b075c6c9 introduced the ability
of building Zephyr with deprecation warnings enabled, by making
COMPILER_WARNINGS_AS_ERRORS depend on the newly added DEPRECATION_TEST
Kconfig option. This has the downside of disabling **all** warnings, not
only the deprecation ones.
This patch instead makes DEPRECATION_TEST disable only the deprecation
warning, but leaves COMPILER_WARNINGS_AS_ERRORS enabled.
This has the advantage of being able to see other unrelated warnings
(and fail if they appear) but has the disadvantage of not printing out
the deprecation warnings themselves (since they are disabled).
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
