Add multiple channels in overlay to test the sequencer.
Change clock source to correctly pass the test.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Remove CHANNEL_COUNT limit used to check the channel bitmask.
This value was not applicable on STM32L1 where channel can go up to 31.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Add a property for STM32 ADC to indicate which type of sequencer is used
by the device (fully configurable or not).
Add defines to help with this setting.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
When `toolchain_is_ok` fails, the error message points the user at the
CMake logs. But those logs will be empty if the user tried to compile
more than once (typically: cleans everything and tries again). So tell
the user that cleaning the toolchain cache is required to see the error.
Tell the user to "move" the cache instead of removing it in case
technical support needs the cache for forensics.
Some finicky toolchains can be "non-deterministic" and fail
_sometimes_. For instance a license server can be flaky, or the
toolchain can require an "elaborate" set of environment variables
triggering some configuration "trial-and-error". In such a
non-deterministic case deleting the cache is enough to get rid of the
issue and move on! Looking at logs is not even required; even
better. Once the toolchain cache believes that the toolchain works, any
future toolchain glitch will be obvious at actual compilation time.
To test all this:
```
# Verify that the toolchain can compile a dummy file, if it is not we
# won't be able to test for compatibility with certain C flags.
-zephyr_check_compiler_flag(C "" toolchain_is_ok)
+zephyr_check_compiler_flag(C "-fubar" toolchain_is_ok)
assert(toolchain_is_ok "The toolchain is unable to build a dummy C file.\
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This is coming from devicetree and corrosponds to what we have in the
dts/bindings/vendor-prefixes.txt file.
This will allow for static filtering, especially with twister, i.e. no
need to build anything to know the vendor of a board
All of the vendor data was extracted automatically from the devicetree,
so some platforms might not have the right vendor or no vendor at all
right now, we need to fix some of the DTS information or do this
manually to get this 100% correct. But we are close.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a new option --vendor which allows filtering by vendors tracked in
the board/platform yaml file. The vendor string is compatible with DTS
and is what we have in dts/bindings/vendor-prefixes.txt.
Providing multiple vendors is also supported.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Let's make this official: we use the suffix `_MASK` for the define
carrying the GENMASK for the attributes, and the suffix `_GET(x)` for
the actual macro extracting the attributes.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Remove unwanted "pm_device_runtime_get" lock which makes i2c power
management working incorrectly.
Fixes: #62790
Signed-off-by: Petr Hlineny <development@hlineny.cz>
Align with other delayed TX modes, by specifying the transmit time as
the start of the frame PHR, not SHR.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The test_sem_take_timeout_isr depends on the thread's priority. But for
SMP platforms, the priority is different with no-SMP. High-priority
threads and low-priority threads might run simultaneously at different
cores. Set the test case run at 1cpu to fix such an issue.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
The stack guard report this testcase has the stack overflow issue. To
fix the issue, slightly increse the stack size.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
The heap size is not enough so that it will cause the testcase fail.
Increase to 32k to make sure it works for a long time in the future.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
The test case allocate struct k_thread thread in the stack. This will
lead the random initial value of thread and thus cause the test cases
randomly hang. To fix such issue, move the declartion of struct k_thread
thread outside the function as a stacic variable.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
To make the stack guard works well, clean and refine the MPU code. To
save the MPU regions (the number of MPU regions are limited), we choose
to remove the guard region. Comparing to add an individual region to
guard the stack, removing the guard region can at least save 2 regions
per core.
Similarly with userspace, the stack guard will leverage the dynamic
regions switching mechanism which means we need a region switch during
the context switch. Otherwise, the other option is using stack guard
region, but this is very limited since the number of MPU regions is
limited.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Refactor the stack relevant macros to prepare to introduce the stack
guard. Also add comments about the changes related to stack layout.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Add the stack check function z_arm64_stack_corruption_check at
z_arm64_fatal_error to handle the stack overflow triggered by the
hardware region.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Introduce the ARM64_STACK_PROTECTION config. This option leverages the
MMU or MPU to cause a system fatal error if the bounds of the current
process stack are overflowed. This is done by preceding all stack areas
with a fixed guard region. The config depends on MPU for now since MMU
stack protection is not ready.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Clean the thread->arch during the arch_new_thread to avoid unexpected
behavior. If the thread struct is allocated from heap or in stack, the
data in thread->arch might be dirty.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Accessing mem before mmu or mpu init will cause a cache coherence issue.
To avoid such a problem, move the safe exception stack init function
after the mmu or mpu is initiated.
Also change the data section attribute from INNER_SHAREABLE to
OUTER_SHAREABLE. Otherwise there will be a cache coherence issue during
the memory regions switch. Because we are using background region to do
the regions switch, and the default background region is
OUTER_SHAREABLE, if we use INNER_SHAREABLE as the foreground region,
then we have to flush all cache regions to make sure the cached values
are right. However, flushing all regions is too heavy, so we set
OUTER_SHAREABLE to fix this issue.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Use clock control API to retrieve the module's frequency and
update the boards using it to provide the source clocks.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
This fixes the following compile time warning;
drivers/mm/mm_drv_intel_adsp_mtl_tlb.c: In function 'sys_mm_drv_mm_init':
include/zephyr/sys/__assert.h:44:52: error: format '%p' expects argument
of type 'void *', but argument 2 has type
'long unsigned int' [-Werror=format=]
__ASSERT_PRINT("\t" fmt "\n", ##__VA_ARGS__)
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
The PIT maximum load value may not be always 32-bit. Allow the SoC to
define this value from devicetree.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Depending on the SoC design, the PIT channel interrupts can be
individual or OR'ed together to a single interrupt line.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
This periodic timer (PIT) has a single load value register for each
channel, which is currently used for both alarm and top callback APIs.
If using both APIs together (which is a valid use-case) it will write
to the same register causing unexpected behavior of the timer.
The nature of the PIT is to trigger an event (like interrupts) at a
certain rate, and not to produce single-shot events. Hence keep only top
callback functionality.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
