Change for loops of the form:
for (i = 0; i < CONFIG_MP_NUM_CPUS; i++)
...
to
unsigned int num_cpus = arch_num_cpus();
for (i = 0; i < num_cpus; i++)
...
We do the call outside of the for loop so that it only happens once,
rather than on every iteration.
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 _SYS_INIT_LEVEL* definitions were used to indicate the index entry
into the levels array defined in init.c (z_sys_init_run_level). init.c
uses this information internally, so there is no point in exposing this
in a public header. It has been replaced with an enum inside init.c. The
device shell was re-using the same defines to index its own array. This
is a fragile design, the shell needs to be responsible of its own data
indexing. A similar situation happened with some unit tests.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
We have cases where some devices needs to be initialized very early and
before c_start is call, i.e. to setup very early console or to setup
memory. Traditionally this would be hardcoded as part of the soc layer
and not using device model or the init levels.
This patch adds a new level ARCH, which will be called in early
architecture code and before we jump to the kernel code.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This commit updates all deprecated `K_THREAD_STACK_EXTERN` macro usages
to use the `K_THREAD_STACK_DECLARE` macro instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Documentation specifies that aborting/terminating/exiting essential
threads is a system panic condition, but we didn't actually implement
that and allowed it as for other threads. At least one app wants to
exploit this documented behavior as a "watchdog" kind of condition,
and that seems reasonable. Do what we say we're supposed to do.
This also includes a small fix to a test, which seemed like it was
written to exercise exactly this condition. Except that it failed to
detect whether or not a system fatal error was actually signaled and
was (incorrectly) indicating "success". Check that we actually enter
the handler.
Fixes#45545
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A separate privileged stack is used when CONFIG_GEN_PRIV_STACKS=y. The
main stack guard area is no longer needed and can be made available to
the application upon transitioning to user mode. And that's actually
required if we want a naturally aligned power-of-two buffer to let the
PMP map a NAPOT entry on it which is the whole point of having this
CONFIG_PMP_POWER_OF_TWO_ALIGNMENT option in the first place.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
When threads are in more than one state at a time, k_thread_state_str()
returns a string that lists each of its states delimited by a '+'.
This in turn necessitates a change to the API that includes both a
pointer to the buffer to use for the string and the size of the buffer.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
This test was working by accident onarm64 and riscv64. Those
architectures have large register files, even more so considering
their 64-bit nature.
This test works by calling k_object_alloc(K_OBJ_THREAD) until thread
index exhaustion. However here it exhausted heap memory before running
out of thread indexes. There was a test to make sure that wasn't the
case by attempting a k_malloc(256). But here that succeeded just
because 256 is far smaller than a struct k_thread on the above
architectures.
Fix this by:
- attempting an additional allocation with the actual object size
instead of an arbitrary 256 bites
- increasing the heap size as 8192 was clearly insufficient for the
above platforms.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Thread APIs test for k_busy_wait incorrectly asserted that a delay of
100 us should produce a delay in cycles less than or equal to to 100 cycles
of the hardware clock. Since most hardware clocks are fast, this assertion
was valid, but it does not test for the actual delay.
Fix the assertion to verify that a delay of 100 us produces a delay in
cycles less than or equal to 100 us worth of hardware clock cycles.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Clang 12.0.0 complains about
"cast to smaller integer type 'enum control_method' from 'void *'
[-Werror,-Wvoid-pointer-to-enum-cast]".
Cast it to intptr_t type first.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
This changes k_mem_domain_init() to return error values
instead of asserting when errors are encountered.
This gives applications a chance to recover if needed.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The thread_apis tests of the RUNTIME_STATS feature weren't really
testing the right behavior.
+ It assumed that accounting would only happen at context switch time
and required that the returned values not change for running threads
(even CLEARLY running threads like _current!). But that's not a
documented feature! It's actually sort of a wart that we'd like to
be able to fix (and have fixed, the new backend returns realtime
values so you can track CPU-bound processes on another CPU).
+ It assumed that k_thread_runtime_stats_all_get() would return time
that includes idle time (or conversely it forgot that
k_thread_foreach enumerates over idle threads). This was sort of a
bug in the original (because it means that the result is always the
system uptime multiplied by the number of CPUs)
Broadly, instead of testing the result of a "time" function for
equality (never a good idea) test it via appropriate bounds given the
usage.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add testing for the PIN_ONLY API variant (which has a separate run
queue per CPU). Predicate on SMP systems only, to keep needless
duplicate testing to a minimum.
Note that one of the cases in this test exercises an "all cpus" option
for the cpu mask, which is illegal when CONFIG_SCHED_CPU_MASK_PIN_ONLY
is set. Skip.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Fix the broken logic in the kernel/thread_stack test
The modified test should do direct read & write from estimated stack
pointer to highest address in the stack buffer.
Previously this test was start from lowest address in the stack
which would trigger exception of hardware stack checking scheme
violation on ARC boards and other targets with hardware stack
overflow detection.
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
In the file variable val is not initialized,
causing the variable stack_ptr, pos, points to uninitialized data.
Initialize the variable val according to the code and commits.
Fixes#37916
Signed-off-by: Naiyuan Tian <naiyuan.tian@intel.com>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
If calling function k_thread_resume() when the thread is not suspend,
it takes no effect. This change improve coverage of function
k_thread_resume() in sched.c
Signed-off-by: Ying ming <mingx.ying@intel.com>
Extended test to validate following functionality:
- k_busy_wait
- k_timer
- irq_lock/irq_unlock
- k_cpu_idle
- SYS_INIT()
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The comment in this test says that it cannot use ztest, as the latter
spawns some threads. However, still format the output in a way
compatible with ztest output, by using tc_util.h macros. This is
similar to a few other tests which can't use ztest library directly.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
This functions is being called across the tree, no reason why it should
not be a public API.
The current usage violates a few MISRA rules.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This test understood that it can't demand equality in timing because
of races against real time, so it simply validated that the test
started at or later than the expected timeout expiration.
But when calculating the expected time, it called k_uptime_ticks()
AFTER the timeout was registered. So on systems with fast ticks (or
just bad luck) a tick expiring between the two steps will look like an
"early" expiration and fail the test. Do things in the proper order.
Also, use the correct APIs for unit conversion and timeout
construction.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is a race between k_sem_take() and k_object_access_grant() so it
is possible (especially when testing SMP) that the thread tries to take
the semaphore before the originating thread has had the chance to
grant it permission.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Allow the test to run for non-secure firmware builds, by
removing the test-case for nonsense string, as this test-case
will likely produce a secure fault which will crash the kernel.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
THIS COMMIT DELIBERATELY BREAKS BISECTABILITY FOR EASE OF REVIEW.
SKIP IF YOU LAND HERE.
Remove the existing implementatoin of k_thread_abort(),
k_thread_join(), and the attendant facilities in the thread subsystem
and idle thread that support them.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Thread stack memory on coherence platforms needs to be linked into a
special section (so it can be cached).
Also, the test_idle_stack case just can't work with coherence. It's
measuring the CPU's idle stack's unused data, which was initialized at
boot from CPU0, and not necessarily the CPU on which the test is
running. In practice on intel_adsp_cavs15, our CPU has stale zeroes
in the cache for its unused stack area (presumably from a firmware
memory clear at boot or something?). Making this work would require a
cache invalidate on all CPUs at boot time before the idle threads
start, we can't do it here in the test because we don't know where the
idle stack pointer is.
Too much work for an esoteric stack size test, basically. Just
disable on these platforms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
