Add SYS_POWER_ prefix to HAS_STATE_SLEEP_, HAS_STATE_DEEP_SLEEP_
options to align them with names of power states they control.
Following is a detailed list of string replacements used:
s/HAS_STATE_SLEEP_(\d)/HAS_SYS_POWER_STATE_SLEEP_$1/
s/HAS_STATE_DEEP_SLEEP_(\d)/HAS_SYS_POWER_STATE_DEEP_SLEEP_$1/
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This commit cleans up names of system power management functions by
assuring that:
- all functions start with 'sys_pm_' prefix
- API functions which should not be exposed to the user start with '_'
- name of the function hints at its purpose
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
There exists SoCs, e.g. STM32L4, where one of the low power modes
reduces CPU frequency and supply voltage but does not stop the CPU. Such
power modes are currently not supported by Zephyr.
To facilitate adding support for such class of power modes in the future
and to ensure the naming convention makes it clear that the currently
supported power modes stop the CPU this commit renames Low Power States
to Slep States and updates the documentation.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
Coverity was complaining that this function was not being checked only
in a specific case.
Coverity CID: 183066
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The 14 individual cases that use these four config files are now
passing reliably when SMP is enabled, after the "Mark sleeping threads
suspended" scheduler fix. Turn it back on.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
For obvious performance reasons, scheduler state changes (other than
aborting a thread) do not cause synchronous interrupts on the other
CPU. Doing a k_thread_wakeup() means that the current CPU will run it
synchronously if it's high priority, but if you want to see it run on
the other cores you need to wait for them to reach a scheduling point
on their own.
The test was written to assume that k_thread_wakeup() is synchronous,
but that's not right, and it needs to spin a bit. This bug was always
present in the test, but masked by a bug in the way that k_sleep() was
handled on SMP. See #9506.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A few more test cases that are measurably unreliable when run in SMP.
For the most part these work most of the time (though the semaphore
one was pretty borderline -- I measured about 25% failures), but are
measurably unstable against the backdrop of known qemu instability.
Something is clearly going on and we need to come back to these to fix
threadsafety issues.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add qemu_x86_64 to the platform whitelist so that this will actually
be built and tested with sanitycheck.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
There was a missing 'z_' renaming to
z_is_thread_prevented_from_running which would have caused
sanitycheck to fail but it is not being built at the moment.
Fix this first.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Most CPUs have instructions like LOCK, LDREX/STREX, etc which
allows for atomic operations without locking interrupts that
can be invoked from user mode without complication. They typically
use compiler builtin atomic operations, or custom assembly
to implement them.
However, some CPUs may lack these kinds of instructions, such
as Cortex-M0 or some ARC. They use these C-based atomic
operation implementations instead. Unfortunately these require
grabbing a spinlock to ensure proper concurrency with other
threads and ISRs. Hence, they will trigger an exception when
called from user mode.
For these platforms, which support user mode but not atomic
operation instructions, the atomic API has been exposed as
system calls.
Some of the implementations in atomic_c.c which can be instead
expressed in terms of other atomic operations have been removed.
The kernel test of atomic operations now runs in user mode to
prove that this works.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This test isn't SMP-safe and won't pass reliably on x86_64 by default
(though it does pass often enough to get CI passes on most things, it
fails spuriously in ways that aren't timing related). Turn off the
second CPU. Fixes#14501
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Qemu just can't handle 1000 Hz ticks. On our CI machines, CONFIG_HZ
on the host (which is the limit of timing precision for things like
idle wakeups and signal delivery, both of which qemu seems to use for
timing) is 250. When the mismatch gets this large, we start seeing
artifacts like interrupts being delivered "in the past" (i.e. code
sees a z_clock_elapsed() value of "2" ticks before getting a
z_clock_announce() call for "1").
As it happens, this test doesn't actually require timing with that
precision, it just wants "lots of context switching" to exercise the
threadsafety of the mem_pool APIs. So decrease the tick rate to the
100Hz default, but put a loop counter in the worker threads to force
them to do 10x more work, keeping the number of preemptions constant.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing device_set_power_state() API works only in synchronous
mode and this is not desirable for devices(ex: Gyro) which take
longer time (few 100 mSec) to suspend/resume.
To support async mode, a new callback argument is added to the API.
The device drivers can asynchronously suspend/resume and call the
callback function upon completion of the async request.
This commit adds the missing callback parameter to all the drivers
to make it compliant with the new API.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
We needed to add support for the RV32M1_LPTMR_TIMER to the test so its
knows what the IRQ of the timer is.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The various tests would all do a "wait for threads to exit" step
before checking the results, but this was implemented with a simple
busy wait that turns out to need careful tuning (because there was
busy waiting in the threads).
Rather than try to synchronize this, white box the issue (it's a low
level SMP test, after all) by spinning on the thread states directly
watching for the kernel to flag them dead. The downside here is that
if the process fails for some reason we'll get a hang and a timeout
reported from sanitycheck and not a synchronous ztest assertion. But
in return, successful tests run much faster and I don't need to worry
about how to tune them for IPI latency on different platforms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This case was predicated on a mistake. The behavior of k_wakeup() has
always been NOT to wake up threads that are "pending" on a wait queue,
only ones blocked on a timeout in k_sleep(). As written, this test
case could never pass.
(Really there's no good reason for that. It seems reasonable to me to
expect wakeup to work symmetrically, and the docs are sort of
ambiguous on the subject. But the code in k_wakeup() is clear:
threads flagged pending get an early exit and the call becomes a
noop.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was a test-created thread that wasn't including this. It's a
huge stack and doesn't overflow (though I thought briefly that it
was), but it's a rule that we need to have that buffer and I'm trying
to fix these as I find them.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
Minnowboard should not run the XIP test as it doesn't execute-in-place.
Updated the test specification to exclude Minnowboard.
Fixes#14099.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Fix multiple definitions of `ram_console'. The ram_console
array is already defined in drivers/console/ram_console.c.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
These tests fail on hardware. An appropriate issue will be filed on
GitHub, but it doesn't make sense to hold the CI from going green.
Fixes#13960.
Signed-off-by: Piotr Zierhoffer <pzierhoffer@antmicro.com>
We want to show that performing various memory domain
operations, and then either dropping to user mode, or
swapping to a user thread in the same domain, has the
correct memory policy for the user context.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Removing the build_only option for tickless broke CI (for reasons
unrelated to the new tests I added in the prior commit).
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
In some circumstances (e.g., a tickless kernel), k_timer_remaining_get()
would not account for time passed that didn't involve clock interrupts.
This adds a simple fix for that, and adds a test case. In addition, the
return value of k_timer_remaining_get() is clamped at 0 in the case of
overdue timers and the API description is adjusted to reflect this.
Fixes: #13353
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
This test was written to wait on a fifo with a timeout, return, and
check the timing between the start and end using k_cycle_get_32() to
see that it didn't run long. But timeouts expire on tick boundaries,
and so if tick expires between the start of the test and the entry to
k_fifo_get(), the timeout will take one full tick longer than expected
due to aliasing.
As it happened this passed everywhere except nRF (whose cycle timer is
32 kHz and thus more susceptible to coarser aliasing like this), and
even there it passed for a while until the spinlock validation layer
went in and added just enough time to the userspace code paths
(i.e. the code between the start time fetch and the point where the
fifo blocks takes longer) to open the window and push us over the
limit.
The workaround here is just to add a k_sleep(1) call, which is
guaranteed to block and wake up synchronously at the next tick.
Fixes#13289
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
(Chunk 2 of 3 - this patch was split across pull requests to address
CI build time limitations)
Zephyr has always been a uniprocessor system, and its kernel tests are
rife with assumptions and outright dependence on single-CPU operation
(for example: "low priority threads will never run until this high
priority thread blocks" -- not true if there's another processor to
run it!)
About 1/3 of our tests fail right now on x86_64 when dual processor
operation is made default. Most of those can probably be recovered on
a case-by-case basis with simple changes (and a few of them might
represent real bugs in SMP!), but for now let's make sure the full
test suite passes by turning the second CPU off. There's still plenty
of SMP coverage in the remaining cases.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit removes the #ifdefs for ARM platforms in
tests/kernel/fatal/main.c, as all the tests suite can be
executed for platforms supporting the ARM and the NXP MPU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Commit 0cc362f873 ("tests/kernel: Simplify timer spinning") was
added to work around a qemu bug with dropped interrupts on x86_64.
But it turns out that the tick alignment that the original
implementation provided (fundamentally, it spins waiting on the timer
driver to report tick changes) was needed for correct operation on
nRF52.
The effectively revert that commit (and refactors all the spinning
into a single utility) and replaces it with a workaround targeted to
qemu on x86_64 only. Fixes#11721
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
(Chunk 1 of 3 - this patch was split across pull requests to address
CI build time limitations)
Zephyr has always been a uniprocessor system, and its kernel tests are
rife with assumptions and outright dependence on single-CPU operation
(for example: "low priority threads will never run until this high
priority thread blocks" -- not true if there's another processor to
run it!)
About 1/3 of our tests fail right now on x86_64 when dual processor
operation is made default. Most of those can probably be recovered on
a case-by-case basis with simple changes (and a few of them might
represent real bugs in SMP!), but for now let's make sure the full
test suite passes by turning the second CPU off. There's still plenty
of SMP coverage in the remaining cases.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
MISRA rules (see #9892) forbid alloca() and family, even though those
features can be valuable performance and memory size optimizations
useful to Zephyr.
Introduce a MISRA_SANE kconfig, which when true enables a gcc error
condition whenever a variable length array is used.
When enabled, the mempool code will use a theoretical-maximum array
size on the stack instead of one tailored to the current pool
configuration.
The rbtree code will do similarly, but because the theoretical maximum
is quite a bit larger (236 bytes on 32 bit platforms) the array is
placed into struct rbtree instead so it can live in static data (and
also so I don't have to go and retune all the test stack sizes!).
Current code only uses at most two of these (one in the scheduler when
SCHED_SCALABLE is selected, and one for dynamic kernel objects when
USERSPACE and DYNAMIC_OBJECTS are set).
This tunable is false by default, but is selected in a single test (a
subcase of tests/kernel/common) for coverage. Note that the I2C and
SPI subsystems contain uncorrected VLAs, so a few platforms need to be
blacklisted with a filter.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit extends the arm_irq_vector_table test,
so it can run successfully in nRF9160-based platforms.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit adds the Clock Control Interrupt Service
Routine into the customized vector table, when building
for nRF52X-based platforms. As a result, the interrupts
generated by the clock control will not interfere with
the test.
Fixes#13823.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Minor typo and style fixes in the test logging, stressing
that the test is applicable for Cortex-M MCUs, in general.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
In order to make this test easy to extend for additional
Cortex-M-based platforms, we apply the following minor
refactoring to the test:
- we introduce the _ISR_OFFSET macro to denote the offset
inside the interrupts' vector table (starting from IRQ
line 0) of the first manually installed ISR.
- we move the asserts that ensure the validity of the custom
vector table to build-time and place them in the beginning
of the text, outside source code.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
(Chunk 3 of 3 - this patch was split across pull requests to address
CI build time limitations)
Zephyr has always been a uniprocessor system, and its kernel tests are
rife with assumptions and outright dependence on single-CPU operation
(for example: "low priority threads will never run until this high
priority thread blocks" -- not true if there's another processor to
run it!)
About 1/3 of our tests fail right now on x86_64 when dual processor
operation is made default. Most of those can probably be recovered on
a case-by-case basis with simple changes (and a few of them might
represent real bugs in SMP!), but for now let's make sure the full
test suite passes by turning the second CPU off. There's still plenty
of SMP coverage in the remaining cases.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Reworked platform_whitelist to enable the "test kernel.device" for
qemu_x86_64
kernel.device.pm is not yet enabled for qemu_x86_64 because
there is a link error
undefined symbol `_DEVICE_STRUCT_SIZEOF'
referenced in expression
Signed-off-by: Cinly Ooi <cinly.ooi@intel.com>
The intent of this Kconfig is to allow libc stdout
functions like printf() to send their output to the
active console driver instead of discarding it.
This somehow evolved into preferring to use
printf() instead of printk() for all test case output
if enabled. Libc printf() implementation for both
minimal libc and newlib use considerably more stack
space than printk(), with nothing gained by using
them.
Remove all instances where we are conditionally
sending test case output based on this config, enable
it by default, and adjust a few tests that disabled
this because they were blowing stack.
printk() and vprintk() now work as expected for
unit_testing targets, they are just wrappers for
host printf().
Fixes: #13701
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
CPU_LPS_n name used to indicate a low power state is cryptic and
incorrect. The low power states act on the whole SoC and not exclusively
on the CPU. This patch renames CPU_LPS_n states to LOW_POWER_n. Also
HAS_ pattern for Kconfig options is used in favor of a non standard
_SUPPORTED. Naming of deep sleep states was adjusted accordingly.
Following is a detailed list of string replacements used:
s/SYS_POWER_STATE_CPU_LPS_(\d)_SUPPORTED/HAS_STATE_LOW_POWER_$1/
s/SYS_POWER_STATE_CPU_LPS_(\d)/SYS_POWER_STATE_LOW_POWER_$1/
s/SYS_POWER_STATE_DEEP_SLEEP_(\d)_SUPPORTED/HAS_STATE_DEEP_SLEEP_$1/
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This commit removes dependency on SYS_POWER_LOW_POWER_STATES_SUPPORTED,
SYS_POWER_DEEP_SLEEP_STATES_SUPPORTED Kconfig options. Power management
SYS_POWER_LOW_POWER_STATES, SYS_POWER_DEEP_SLEEP_STATES options depend
now directly on specific power states supported by the given SoC. This
simplifies maintenance of SoC Kconfig files.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This is an integral part of userspace and cannot be used
on its own. Fold into the main userspace configuration.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Test was failing on nios2 with:
../app/libapp.a(test_stack_contexts.c.obj): in function `tstack_pop':
/home/galak/git/zephyr/tests/kernel/stack/stack_api/src/test_stack_contexts.c:31:
warning: unable to reach (null) (at 0x004002f4) from the global pointer
(at 0x004082fc) because the offset (-32776) is out of the allowed range,
-32678 to 32767
Fixes#13595
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit fixes a test in kernel/mem_protect/userspace,
which was attempting to read from an address that was not
necessarily within the image memory range, causing faults
in ARM TrustZone-enabled builds.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit disables system-level power management in the device power
management test as it is not used.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Some of power states used numerical suffix while otthers not.
This commit adds proper suffix to all power state names.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
f
This commit simplifies OS <-> Application interface controlling power
management. In the previous approach application-based PM required
overriding sys_suspend() and sys_resume() functions. As these functions
actually implemented power state change, in such case application
basically had to provide own implementation of all PM-related stuff,
which was not portable and hard to maintain.
This commit changes this scheme: The sys_suspend() and sys_resume()
are now system functions while the application could either use
built-in power management policies or provide its own. All details
of power mode switching are now handled by the OS.
Also, this commit cleans up the Kconfig options related to system-level
power management grouping them under common CONFIG_SYS_PM_ prefix.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
We weren't testing whether stack overflows in user mode
were correctly reported.
A more aggressive stack overflow logic is enabled if
HW-based stack overflow detection is enabled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
