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>
Use of pipes is now configurable. All tests that use pipes must enable
that feature. (Note: no sample projects currently use pipes.)
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
The app_kernel benchmarking app has the config file for benchmarking
with floating point enabled, but it was never used. So add it
to the testcase.yaml.
Note that this also limits to run on one CPU on a SMP system as
the resulting numbers would be more consistent among runs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Some ARM platforms, now, enable HW Stack Protection by
default in the Board definition. So if some tests
need to run without stack protection, it is not
sufficient to disable TEST_HW_STACK_PROTECTION;
we need to explicitly disable HW_STACK_PROTECTION.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the Kconfig `FP_SHARING` symbol to `FPU_SHARING`,
since this symbol specifically refers to the hardware FPU sharing
support by means of FPU context preservation, and the "FP" prefix is
not fully descriptive of that; leaving room for ambiguity.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit renames the Kconfig `FLOAT` symbol to `FPU`, since this
symbol only indicates that the hardware Floating Point Unit (FPU) is
used and does not imply and/or indicate the general availability of
toolchain-level floating point support (i.e. this symbol is not
selected when building for an FPU-less platform that supports floating
point operations through the toolchain-provided software floating point
library).
Moreover, given that the symbol that indicates the availability of FPU
is named `CPU_HAS_FPU`, it only makes sense to use "FPU" in the name of
the symbol that enables the FPU.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Unlike CONFIG_HW_STACK_PROTECTION, which greatly helps
expose stack overflows in test code, activating
userspace without putting threads in user mode is of
very limited value.
Now CONFIG_TEST_USERSPACE is off by default. Any test
which puts threads in user mode will need to set
CONFIG_TEST_USERSPACE.
This should greatly increase sanitycheck build times
as there is non-trivial build time overhead to
enabling this feature. This also allows some tests
which failed the build on RAM-constrained platforms
to compile properly.
tests/drivers/build_all is a special case; it doesn't
put threads in user mode, but we want to ensure all
the syscall handlers compile properly.
Fixes: #15103 (and probably others)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These tests was written to try to eliminate timer interrupts, but the
mechanism chosen (setting TICKS_PER_SECOND to 1) is dangerously
susceptible to overflow conditions on systems with fast cycle counters
and high timeout durations.
Actually the tests pass just fine if you use a conventional tick rate
and use a tickless-capable driver (which eliminates interrupts too,
which is the whole point), but there's no easy way in kconfig to do an
"if" to select that condition for capable systems only. Just disable
tickless to keep the same behavior.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Disable userspace for benchmarks because it changes the KPI
numbers. It will be re-enabled once the required code is
in place.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Deleted the instance of app_kernel in tests/legacy/benchmark.
JIRA: ZEP-1980
Change-Id: I5a6e073d9b0c870be0cc7d8ae5bb352b11d7f97e
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
