This tests the situation when there are multiple threads calling
k_queue_get which was causing issues when using k_poll.
Jira: ZEP-2553
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This is necessary in order for k_queue_get to work properly since that
is used with buffer pools which might be used by multiple threads asking
for buffers.
Jira: ZEP-2553
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Arguments are not needed and in some cases are being set as unused in
the same function. The test_main function is called from ztest main
routine without any arguments.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The array of k_thread "t" was declared non-static in 2 different
C files. Make them static.
Semaphores only used in local C file now declared static.
Use of variable 't' in thread_tslice() no longer shadows global
definition.
Fixes build errors with XCC compiler.
Increase RAM requirement to 20K.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Per ZEP-1958, Phase 2 of adding CC3220sf LaunchXL support,
was to "deprecate the CC3200 launchxl support in Zephyr
(redundant to the CC3220)."
Effectively, the CC3220 SOC replaces the CC3200.
This patch removes the following:
* the imported CC3200 SDK
* CC3200 SOC, board, DTS files.
* adjusts other files where cc3200 was mentioned.
Also, it fixes explicit references to CC3200 in generic
CC32xx driver files.
Jira: ZEP-1958
Signed-off-by: Gil Pitney <gil.pitney@linaro.org>
This adds a test that attempts to submit a work with 0 timeout thus
causing it to immediatelly be submitted to the queue so it is pending
execution which is then cancelled with k_delayed_work_cancel.
Note this can only be done with coop threads with the same or higher
priority otherwise the work_q thread is wakeup before
k_delayed_work_cancel takes place, thus why test_delayed_cancel uses
K_HIGHEST_THREAD_PRIO.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This has been a limitation caused by k_fifo which could only remove
items from the beggining, but with the change to use k_queue in
k_work_q it is now possible to remove items from any position with
use of k_queue_remove.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This makes use of POLL_EVENT in case k_poll is enabled which is
preferable over wait_q as that allows objects to be removed for the
data_q at any time.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
* add nested interrupt support for interrupts
+ use a varibale exc_nest_count to trace nest interrupt and exception
+ regular interrupts can be nested by regular interrupts and fast
interrupts
+ fast interrupt's priority is the highest, cannot be nested
* remove the firq stack and exception stack
+ remove the coressponding kconfig option
+ all interrupts (normal and fast) and exceptions will be handled
in the same stack (_interrupt stack)
+ the pros are, smaller memory footprint (no firq stack), simpler
stack management, simpler codes, etc.. The cons are, possible
10-15 instructions overhead for the case where fast irq nests
regular irq
* add the case of ARC in test/kernel/gen_isr_table
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Tests if preemptive threads are picked up as per priority.
This creates 10 threads with priority in increasing order
from 1 to N and each thread prints an Alphabet.
This test fails when threads are picked up out of order.
Jira: ZEP-2370
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
This creates 10 threads with equal priority and tests predictibility
of picking all threads in round robin fashion. Test fails when any
thread consumes more time than time slice allocated to it or threads
are not scheduled in round robin fashion.
Jira: ZEP-2371
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
The API name space for Bluetooth is bt_* and BT_* so it makes sense to
align the Kconfig name space with this. The additional benefit is that
this also makes the names shorter. It is also in line with what Linux
uses for Bluetooth Kconfig entries.
Some Bluetooth-related Networking Kconfig defines are renamed as well
in order to be consistent, such as NET_L2_BLUETOOTH.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
- replaced a test point with ztest API
- separated the main file into two:
- main.c, which has ztest entry
- xip.c, which has the original routine
JIRA: ZEP-2382
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- added a ztest test point
- separated the main file into two files:
- main.c, which has ztest entry
- multilib.c, which has the original routine
JIRA: ZEP-2382
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- file already had ztest functions
- separated the main file into two:
- main.c, which has the ztest entry
- libraries.c, which has the original routines
JIRA: ZEP-2382
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- file does not use ztest asserts
- separated the main file into two files:
- main.c, which has ztest entry
- arm_runtime_nmi.c, which has the original routine
JIRA: ZEP-2382
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
- file already had ztest functions
- separated the main file into two:
- main.c, which has the ztest entry
- arm_irq_vector_table.c, which has the original routines
JIRA: ZEP-2382
Signed-off-by: Niranjhana N <niranjhana.n@intel.com>
As luck would have it, the TSS for the main IA task has
all the information we need, populate an exception stack
frame with it.
The double-fault handler just stashes data and makes the main
hardware thread runnable again, and processing of the
exception continues from there.
We check the first byte before the faulting ESP value to see
if the stack pointer had run up to a non-present page, a sign
that this is a stack overflow and not a double fault for
some other reason.
Stack overflows in kernel mode are now recoverable for non-
essential threads, with the caveat that we hope we weren't in
a critical section updating kernel data structures when it
happened.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Historically, stacks were just character buffers and could be treated
as such if the user wanted to look inside the stack data, and also
declared as an array of the desired stack size.
This is no longer the case. Certain architectures will create a memory
region much larger to account for MPU/MMU guard pages. Unfortunately,
the kernel interfaces treat both the declared stack, and the valid
stack buffer within it as the same char * data type, even though these
absolutely cannot be used interchangeably.
We introduce an opaque k_thread_stack_t which gets instantiated by
K_THREAD_STACK_DECLARE(), this is no longer treated by the compiler
as a character pointer, even though it really is.
To access the real stack buffer within, the result of
K_THREAD_STACK_BUFFER() can be used, which will return a char * type.
This should catch a bunch of programming mistakes at build time:
- Declaring a character array outside of K_THREAD_STACK_DECLARE() and
passing it to K_THREAD_CREATE
- Directly examining the stack created by K_THREAD_STACK_DECLARE()
which is not actually the memory desired and may trigger a CPU
exception
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Change the common "init with 0" + "give" idiom to "init with 1". This
won't change the behavior or performance, but should decrease the size
ever so slightly.
This change has been performed mechanically with the following
Coccinelle script:
@@
expression SEM;
expression LIMIT;
expression TIMEOUT;
@@
- k_sem_init(SEM, 0, LIMIT);
- k_sem_give(SEM);
+ k_sem_init(SEM, 1, LIMIT);
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Show that this mechanism can detect stack overflows with the
guard page. We only do it once since are are in an alternate
IA HW task after it happens.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
As there is no suffix to represent a literal as unsigned short
it is typecasted. It is fix for Jira ZEP-2156
Signed-off-by: Savinay Dharmappa <savinay.dharmappa@intel.com>
The IA32 MMU has no concept of a "no execute" flag, this is
unfortunately only implemented in x86_64.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Upcoming memory protection features will be placing some additional
constraints on kernel objects:
- They need to reside in memory owned by the kernel and not the
application
- Certain kernel object validation schemes will require some run-time
initialization of all kernel objects before they can be used.
Per Ben these initializer macros were never intended to be public. It is
not forbidden to use them, but doing so requires care: the memory being
initialized must reside in kernel space, and extra runtime
initialization steps may need to be peformed before they are fully
usable as kernel objects. In particular, kernel subsystems or drivers
whose objects are already in kernel memory may still need to use these
macros if they define kernel objects as members of a larger data
structure.
It is intended that application developers instead use the
K_<object>_DEFINE macros, which will automatically put the object in the
right memory and add them to a section which can be iterated over at
boot to complete initiailization.
There was no K_WORK_DEFINE() macro for creating struct k_work objects,
this is now added.
k_poll_event and k_poll_signal are intended to be instatiated from
application memory and have not been changed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Build issues caused by commit fe882f407d
which missed camel case conversion of _TimestampOpen, _TimestampRead,
and _TimestampClose.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Test whichever had Camel case defined for functions and variables have
been replaced.
Following warnings have been fixed in test cases as well.
- line over 80 characters
- Macros with flow control statements should be avoided
- Macros with complex values should be enclosed in parentheses
- break quoted strings at a space character
- do not add new typedefs
- Comparisons should place the constant on the right
side of the test
- suspect code indent for conditional statements
- Missing a blank line after declarations
- macros should not use a trailing semicolon
- Macros with multiple statements should be
enclosed in a do - while loop
- do not use C99 // comments
JIRA: ZEP-2249
Signed-off-by: Punit Vara <punit.vara@intel.com>
Where possible, replace the use of filter with newly added keywords.
This will speed things up and in some cases add more coverage due to bad
filters.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
commit d859295be9 ("tests: protection: convert to testcase.yaml")
removed testcase.ini but did not add an equivalent testcase.yaml.
Add it.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add a self-protection test suite with a set of tests
to check whether one can overwrite read-only data
and text, and whether one can execute from data,
stack, or heap buffers. These tests are modeled after
a subset of the lkdtm tests in the Linux kernel.
These tests have twice caught bugs in the Zephyr NXP MPU
driver, once during initial testing/review of the code
(in its earliest forms on gerrit, reported to the original
author there) and most recently the regression introduced
by commit bacbea6e21 ("arm: nxp: mpu: Rework handling
of region descriptor 0"), which was fixed by
commit a8aa9d4f3dbbe8 ("arm: nxp: mpu: Fix region descriptor
0 attributes") after being reported.
This is intended to be a testsuite of self-protection features
rather than just a test of MPU functionality. It is envisioned
that these tests will be expanded to cover a wider range of
protection features beyond just memory protection, and the
current tests are independent of any particular enforcement
mechanism (e.g. MPU, MMU, or other).
The tests are intended to be cross-platform, and have been
built and run on both x86- and ARM-based boards. The tests
currently fail on x86-based boards, but this is an accurate
reflection of current protections and should change as MMU
support arrives.
The tests leverage the ztest framework, making them suitable
for incorporation into automated regression testing for Zephyr.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This will prepare test cases and samples with metadata and information
that will be consumed by the sanitycheck script which will be changed to
parse YAML files instead of ini.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This is unmaintained and currently has no known users. It was
added to support a Wind River project. If in the future we need it
again, we should re-introduce it with an exception-based mechanism
for catching out-of-bounds memory queries from the debugger.
The mem_safe subsystem is also removed, it is only used by the
GDB server. If its functionality is needed in the future, it
shoudl be replaced with an exception-based mechanism.
The _image_{ram, rom, text}_{start, end} linker variables have
been left in place, they will be re-purposed and expanded to
support memory protection.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
On some devices, when k_cpu_idle() was called we were getting
interrupts that were not the timer interrupt. On bbc_micro
a power clock control driver interrupt was happening instead
and k_cpu_idle() was returning without the system tick advancing,
failing the test.
The clock control interrupts seem to only happen early in device
boot; moving the idle test much later lets the test pass on this
board (and likely all other NRF5 based boards).
Issue: ZEP-2257
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- _SysFatalErrorHandler is supposed to be user-overridable.
The test case now installs its own handler to show that this
has happened properly.
- Use TC_PRINT() TC_ERROR() macros
- Since we have out own _SysFatalErrorHandler, show that
k_panic() works
- Show that _SysFatalErrorHandler gets invoked with the expected
reason code for some of the scenarios.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The hard-coded value of 10ms doesn't take the system configured
amount of ticks per second, nor does it account for an unlucky
tick advance which causes the test to fail very intermittently
in QEMU.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
