SDK 1.0.0's GCC compiler flags a warning about 'cfg' being used without
being set. The compiler is wrong, but let's assign the variable to NULL
to avoid the warning.
Signed-off-by: Keith Packard <keithp@keithp.com>
This pulls in a build fix for linking when GCC is configured to use
picolibc by default. This fix is not needed upstream as they've already
fixed it in a different fashion due to some clang LTO related work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add an entropy driver for Bouffalo Lab BL70X that reads
random data from the SEC TRNG block and wires it into
Zephyr's entropy API.
Signed-off-by: William Markezana <william.markezana@gmail.com>
New GPPI does not support cpuppr. It is expected that cpuapp will
setup PPI connections for cpuppr but current sysbuild does not support
injecting custom code to vpr_launcher so it cannot be easily done in
the test. Use GPPIv1 on cpuppr until it is solved.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Remove redundant DPPI configuration from the devicetree. GPPI supports
dynamic allocation of channels without need for the DT configuration.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add support for dynamic allocation and freeing of DPPI connections
on nrf54h20. It is not longer required to use devicetree to allocate
specific channels that will be used by the application. nrfx_gppi on
nrf54h20 cpuapp behaves in almost the same way as on other targets.
The main difference is that allocating PPI connection requires
communication with Ironside through IPC.
It means that:
- allocation and freeing can only be done from the thread context
- allocation and freeing is slower
Currently, there is no support for controlling PPI connections in
global domain on other cores. It is expected that cpuapp will
setup PPI for VPR (ppr, flpr) as such approach reduces the need for
nrfx_gppi driver being present on ppr/flpr and those cores are
memory constrained.
Regarding cpurad, it is expected that PPI connections are static so
they can be setup manually, using DT and HAL. During initialization
nrfx_gppi on cpuapp gets the information about all PPI resources that
are statically allocated (using the devicetree) and they are excluded
from the pool of available channels.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Extend bindings for dppic and ppib to include channels and groups property.
Set channels and groups property in devices with DPPI.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add support for handling connections within the radio domain
using the new GPPI helper.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Add the support of DBI bus color coding configuration, also
pass down height/width/pitch of the frmae buffer descriptor
during frame update. Some DBI controller may need this configuration.
Signed-off-by: Kate Wang <yumeng.wang@nxp.com>
This sample makes use of the sensor_read() API, which is implementing
the read_and_decode polling method.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
This sample uses the sensor_stream() API (not sensor_read()), so we rename
it as accel_stream to reflect the sample�s behavior.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Use printf to print the floating point numbers, instead of printk.
This is how it is done in the magn_polling sample.
Otherwise the sample hangs indefinitely after printing the first time,
when running the LPS22 sensor on an adafruit_feather_rp2040 board.
Signed-off-by: Jonas Berg <jonas.s.t.berg@gmail.com>
Add initial support for Renesas R-Car V4H SoC.
Support Zephyr RTOS on Cortex R52, 1.4GHz core.
For more information and documentation, please visit the product page:
https://www.renesas.com/en/products/r-car-v4h
Signed-off-by: Duy Dang <duy.dang.yw@renesas.com>
The `mt8196/mt8196/adsp` board was missing the board yml file and hence not
testable using Twister.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Add a mikroBUS shield definition for the MikroElektronika LTE IoT 7
Click board.
The shield instantiates a u-blox SARA-R4 modem on the mikroBUS UART
and maps required modem control signals through mikroBUS header pins
for Zephyr modem use.
Signed-off-by: Bobo Bäck Engström <bobo@id8-engineering.io>
stm32-iocell has no bus address so move it out of /soc to fix a warning
Warning (simple_bus_reg): /soc/iocell: missing or empty reg/ranges property
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
For STM32H5 series, only the cell compensation can be configured,
as the HSLV configuration is controlled on a per pin basis and
not on a per domain basis as for other STM32 series.
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Fixes the counter running after initialization and the counter running
after calling counter_set_top_value, regardless of previous state.
Also adjusts the tests.
Signed-off-by: Jan Behrens <jan.behrens@navimatix.de>
The nRF54L series devices require to reserve 2 KMU slots which are
filled with random data used for invalidating the Protected RAM.
Until now the provisioning of these slots happends in firmware which
costs in both volatile and non volatile memory.
Instead of doing this nrfutil recently added the funcionality to
provision these slots using a .json file which means that everything
can be handled by the build system now.
This is preparation work, that is needed before the full integration
arrives. The change checks if a json file with the name:
"prot_ram_inv_slots.json" exists and if it does it invokes nrfutil
with the provisioning command.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
USE_SWITCH is a new feature and needs more testing before enabling it by
default. While all tests in upstream Zephyr CI passed, keeping this
config disabled helps in getting majority of the work in without causing
regression on upstream boards that are not tested in ci.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
Fix below issues when trying to build hello world with armclang:
```
Error: L6218E: Undefined symbol z_arm_exc_exit (referred from reset.o).
Error: L6218E: Undefined symbol z_arm_int_exit (referred from reset.o).
Error: L6218E: Undefined symbol z_arm_pendsv (referred from reset.o).
```
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
orr fix is as reported in review:
```
The add causes a crash with IAR tools as the address loaded to r8
already has the lowest bit set, and the add causes it to be set to ARM
mode. The orr instruction works fine with both scenarios
```
`UDF 0` seems to break on IAR but `UDF #0` works for all.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
Change the MPU alignment to fix below ci failure for
nrf52840dk/nrf52840:
```
padding_section' will not fit in region `RAM'
arm-zephyr-eabi/bin/ld.bfd: region `RAM' overflowed by 54928 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
```
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
USE_SWITCH code unconditionally applied interrupt locking, which altered
BASEPRI handling and broke expected interrupt behavior on both
Baseline and Mainline CPUs when USE_SWITCH was disabled.
This commit restores the original behavior with USE_SWITCH disabled and
fixes tests/arch/arm/arm_interrupt failures.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
A nested exception can occur in arm_m_exc_exit after interrupts are
re-enabled but before branching to the EXC_RETURN value. In that case,
the nested exception stacks an exception stack frame (ESF) on MSP.
arm_m_exc_tail() unconditionally rewrites the LR slot on the active
stack to redirect execution to arm_m_exc_exit. If a nested exception
has stacked an ESF on MSP, this rewrite corrupts the stacked xPSR
field, leading to a UsageFault ("Illegal use of EPSR") on exception
return.
Guard the LR rewrite so that it is only performed when the exception
is returning to Thread mode using PSP. This ensures that the rewrite
does not interfere with ESFs stacked on MSP during nested exceptions.
Signed-off-by: Sudan Landge <sudan.landge@arm.com>
The ARM Ltd. FVP emulator (at least the variants run in Zephyr CI)
appears to have a bug with the stack alignment bit in xPSR. It's
common (it fails in the first 4-6 timer interrupts in
tests.syscalls.timeslicing) that we'll take an interrupt from a
seemingly aligned (!) stack with the bit set. If we then switch and
resume the thread from a different context later, popping the stack
goes wrong (more so than just a misalignment of four bytes: I usually
see it too low by 20 bytes) in a way that it doesn't if we return
synchronously. Presumably legacy PendSV didn't see this because it
used the unmodified exception frame.
Work around this by simply assuming all interrupted stacks were
aligned and clearing the bit. That is NOT correct in the general
case, but in practice it's enough to get tests to pass.
Signed-off-by: Andy Ross <andyross@google.com>
The exit from the SVC exception used for syscalls back into the
calling thread is done without locking. This means that the
intermediate states can be interrupted while the kernel-mode code is
still managing thread state like the mode bit, leading to mismatches.
This seems mostly robust when used with PendSV (though I'm a little
dubious), but the new arch_switch() code needs to be able to suspend
such an interrupted thread and restore it without going through a full
interrupt entry/exit again, so it needs locking for sure.
Take the lock unconditionally before exiting the call, and release it
in the thread once the magic is finished, just before calling the
handler. Then take it again before swapping stacks and dropping
privilege.
Even then there is a one-cycle race where the interrupted thread has
dropped the lock but still has privilege (the nPRIV bit is clear in
CONTROL). This thread will be resumed later WITHOUT privilege, which
means that trying to set CONTROL will fail. So there's detection of
this 1-instruction race that will skip over it.
Signed-off-by: Andy Ross <andyross@google.com>
I'm at a loss here. The feature this test case wants to see (on
ARMv7M, not ARMv6M) is the ability to take a irq_lock() inside a
system call and then see that future system calls from the same thread
continue to hold the lock.
That's not documented AFAICT. It's also just a terrible idea because
either:
1. The obvious denial of service implications if user code is allowed
to run in an unpreemptible mode, or:
2. The broken locking promise if this is implemented to release the
lock and reacquire it in an attempt to avoid #1.
(FWIW: my read of the code is that #1 is the current implementation.
But hilariously the test isn't able to tell the difference!)
And in any case it's not how any of our other platforms work (or can
work, in some cases), making this a non-portable system call
API/feature at best.
Leave it in place for now out of conservatism, but disable with the
new arch_switch() code, whose behavior matches that of other Zephyr
userspaces.
Signed-off-by: Andy Ross <andyross@google.com>
Some toolchains don't support an __asm__(...) block at the top level
of a file and require that they live within function scope. That's
not a hardship as these two blocks were defining callable functions
anyway. Exploit the "naked" attribute to avoid wasted bytes in unused
entry/exit code.
Signed-off-by: Andy Ross <andyross@google.com>
Late-arriving clang-format-demanded changes that are too hard to split
and squash into the original patches. No behavior changes.
Signed-off-by: Andy Ross <andyross@google.com>
Some nitpicky hand-optimizations, no logic changes:
+ Shrink the assembly entry to put more of the logic into
compiler-optimizable C.
+ Split arm_m_must_switch() into two functions so that the first
doesn't look so big to the compiler. That allows it to spill (many)
fewer register on entry and speeds the (very) common early-exit case
where an interrupt returns without context switch.
Signed-off-by: Andy Ross <andyross@google.com>
This function was a little clumsy, taking the scheduler lock,
releasing it, and then calling z_reschedule_unlocked() instead of the
normal locked variant of reschedule. Don't take the lock twice.
Mostly this is a code size and hygiene win. Obviously the sched lock
is not normally a performance path, but I happened to have picked this
API for my own microbenchmark in tests/benchmarks/swap and so noticed
the double-lock while staring at disassembly.
Signed-off-by: Andy Ross <andyross@google.com>
z_reschedule() is the basic kernel entry point for context switch,
wrapping z_swap(), and thence arch_switch(). It's currently defined
as a first class function for entry from other files in the kernel and
elsewhere (e.g. IPC library code).
But in practice it's actually a very thin wrapper without a lot of
logic of its own, and the context switch layers of some of the more
obnoxiously clever architectures are designed to interoperate with the
compiler's own spill/fill logic to avoid double saving. And with a
small z_reschedule() there's not a lot to work with.
Make reschedule() an inlinable static, so the compiler has more
options.
Signed-off-by: Andy Ross <andyross@google.com>
