The mr_canhubk3 board enables by default an off-chip watchdog that must
be serviced to avoid triggering a reset and cannot be disabled on a
per-test basis.
To add the needed ISR for this test involve doing modifications to the
LPSPI MCUX driver that does not worth the trouble for this test only,
so exclude this board.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This commit follows the parent commit work.
This commit introduces the following major changes.
1. Move all directories and files in 'include/zephyr/arch/arm/aarch32'
to the 'include/zephyr/arch/arm' directory.
2. Change the path string which is influenced by the changement 1.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
It doesn't make sense to keep the aarch32 directory in the
'arch/arm/core' directory as the aarch64 has been moved out.
This commit introduces the following major changes.
1. Move all directories and files in 'arch/arm/core/aarch32' to
'arch/arm/core' and remove the 'arch/arm/core/aarch32' directory.
2. Move all directories and files in 'arch/include/aarch32' to
'arch/include' and remove the 'arch/include/aarch32' directory.
3. Remove the nested including in the 'arch/include/kernel_arch_func.h'
and 'arch/include/offsets_short_arch.h' header files.
4. Change the path string which is influenced by the changement 1
and 2.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
The CMSIS module glue code was part of arch/ directory. Move it to
modules/cmsis, and provide a single entry point for it: cmsis_core.h.
This entry header will include the right CMSIS header (M or A/R).
To make this change possible, CMSIS module Kconfig/CMake are declared as
external, allowing us to add a new Zephyr include directory.
All files including CMSIS have been updated.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The profile type "not set" uses the "default crypto config" header.
However platform may set their own crypto configuration headers.
SHA-512 algorithm is not the most common algorithm to support and
are for example disabled in profile types medium and small.
Change to SHA-256 which is much more common and is even needed
internally by TF-M for protected storage and sub-key derivation.
Update the QEMU icount setting to make the interrupt occur during
the secure call to TF-M.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
- Add integration_platforms to avoid excessive filtering
- Make sure integration platforms are actually part of the filter
- Fix some tags and test meta data
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Testing NMI on emulated QEMU platforms brings some interesting and wrong
results like:
START - test_arm_runtime_nmi
Trigger NMI in 10s: 0 s
Trigger NMI in 10s: 1 s
Trigger NMI in 10s: 2 s
Trigger NMI in 10s: 3 s
Trigger NMI in 10s: 4 s
Trigger NMI in 10s: 5 s
Trigger NMI in 10s: 6 s
Trigger NMI in 10s: 7 s
Trigger NMI in 10s: 8 s
Trigger NMI in 10s: 9 s
NMI triggered (test_handler_isr)!
Assertion failed at ... arm_runtime_nmi_fn_test_arm_runtime_nmi:
(nmi_triggered is false)
Isr not triggered!
where the NMI handler is correctly called, see `NMI triggered`, but the
assert still fails on `nmi_triggered` being false.
This is due to a limitation in the emulation but also in the test not
being strictly architecturally compliant (you need a DSB;ISB sequence
after writing to SCB).
Add the proper barriers after writing to `SCB->ISCR` to make it
compliant and making it pass on QEMU as well.
Also reduce the timing to 2 sec.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The current approach of failing the build on ztest with no optimization
broke coverage builds, and generally raised some concerns about being
too aggressive.
Downgrade the error to a warning and rework the option to inhibit the
warning, while also dropping it automatically for POSIX (that are not
really affected by stack size) and coverage run (that always runs with
no optimization).
Will reconsider this down the road if we still see issues filed for the
tests broken with no optimization and no further tuning.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Many tests are known to fail when built and no compiler optimizations.
Add a CMake check to error out when building a ztest based test with no
optimization, ask not file issues about it but also adds an opt-out
option to bypass the error for tests are actually designed to work in
this setup.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The page tables test checks to make sure the various page permissions are
set as expected, but when there's a malloc heap, things don't match the
test expectations. As this test doesn't require a heap, just disable it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
With picolibc moving to using the common malloc implementation, samples and
tests with picolibc-specific settings need to switch to using the common
malloc settings instead.
Signed-off-by: Keith Packard <keithp@keithp.com>
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.com>
rename the function that sets the handler for the nmi.
It should be namespaced and not camel-case:
z_NmiHandlerSet to z_arm_nmi_set_handler
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Product URL: https://www.ti.com/product/CC1352P7
Datasheet : https://www.ti.com/lit/ds/symlink/cc1352p7.pdf
Features:
Powerful 48-MHz Arm® Cortex®-M4F processor
* 704KB flash program memory
* 256KB of ROM for protocols and library functions
* 8KB of cache SRAM
* 144KB of ultra-low leakage SRAM with parity for
high-reliability operation
* Dual-band Sub-1 GHz and 2.4 GHz operation
Updates:
* Remove CC1352P7_LaunchXL due to compliance checks
* Add CC1352P7 updates
* Update hal_ti for CC1352P7 support
* Remove blank line at end of modules/Kconfig.simplelink
* Split struct and typedef for pinctrl_soc_pin/pinctrl_soc_pin_t
* Reference cc13x2_cc26x2/pinctrl_soc.h
* Reference cc13x2_cc26x2/soc.h
Signed-off-by: Vaishnav Achath <vaishnav@beagleboard.org>
llvm will generate a different div instruction than gcc does and than
the number of types that the div instruction opcode takes is not 2.
Move to using inline asm with a idivl instruction to ensure the opcode
size is what we expect so that exc_divide_error_handler() can properly
skip over the instruction.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
The RISC-V FPU context switching code is intricate and sometimes subtle.
Here's a test that exercizes various code paths to ensure they work as
intended, and to confirm that the target hardware does behave as
expected too.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add another clause in the test_ram_perms code to verify that any pinned
regions have the correct flags.
Signed-off-by: Keith Packard <keithp@keithp.com>
Fix all line-length errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(line-length)'
Using a limit is set to 100 columns, not touching the commandlines in
GitHub workflows (at least for now).
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Fix all thruthy errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(truthy)'
This only accepts true/false for boolean properties. Seems like python
takes all sort of formats:
https://github.com/yaml/pyyaml/blob/master/lib/yaml/constructor.py#L224-L235
But the current specs only mention "true" or "false"
https://yaml.org/spec/1.2.2/#10212-boolean
Which is the standard yamllint config.
Excluding codeconv and workflow files, as some are using yes/no instead
in the respective documentation.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
integration_platforms help us control what get built/executed in CI and
for each PR submitted. They do not filter out platforms, instead they
just minimize the amount of builds/testing for a particular
tests/sample.
Tests still run on all supported platforms when not in integration mode.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Picolibc uses the libc partition for some variables, so make sure
the test allows references to that data.
Signed-off-by: Keith Packard <keithp@keithp.com>
Move runtime checks to use arch_num_cpus() and build checks
to use CONFIG_MP_MAX_NUM_CPUS. This is to allow runtime
determination of the number of CPUs in the future.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
For tests that set CONFIG_MP_NUM_CPUS, switch to using
CONFIG_MP_MAX_NUM_CPUS instead as we work to phase out
CONFIG_MP_NUM_CPUS.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
The thread swap test was making use of a register to point to
ztest_thread_callee_saved_regs_container, which was being clobbered
in the inline assembly code, causing a hard-fault in certain cases.
This commit adds a clobber list of the registers used, causing the
compiler to assign ztest_thread_callee_saved_regs_container to an
appropriate (unclobbered) register.
It also addresses an issue in the v6-m and v8-m.baseline inline
assembler where only 4 of the 8 callee-saved registers were being
set from ztest_thread_callee_saved_regs_container, due to a double
use of `ldmia` on the same four registers. Since v6-m devices can't
operate outside r0-r7 on most instructions, the upper 4 callee-saved
registers are set first with `ldmia`, before setting the lower 4.
Signed-off-by: Kevin Townsend <kevin.townsend@linaro.org>
The current stm32l562_dk_ns has no flash partitions defined. This add
flash partitions following partition sizes that are compatible with
the TF-M platform defined at flash_layout.h and removes the redundant
overlays board files.
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
... and tests are built with no optimizations. The standard size may
not be sufficient in such circumstances.
Commit 4b1103547c addressed the same
issue in a single test and used a higher value (1024) that turns out
to be not necessary, so revert also that change to make the cleanup
easier when the workaround will no longer be needed.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
