The phrase "object must have _k_object_init() on it at some point"
visibly misses "called".
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Fixing a few minor typo fixes in kernel/mem_domain.c
and the respective documentation section.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Extended ring buffer to allow storing raw bytes in it. API has been
extended keeping 'data item' mode untouched.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Deprecate API prefixed with sys_ring_buf_ and rename it
to ring_buf_item_ since this API is not a typical ring buffer
but ring buffer of data items (metadata + 32bit words).
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Make the multi-level interrupts diagram more clear by saying:
- the "-" means an interrupt slot
- all interrupt slots are numbered from 0 starting from right most
- alphabets denote devices
- add an example chain for device D
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
Summary: revised attempt at addressing issue 6290. The
following provides an alternative to using
CONFIG_APPLICATION_MEMORY by compartmentalizing data into
Memory Domains. Dependent on MPU limitations, supports
compartmentalized Memory Domains for 1...N logical
applications. This is considered an initial attempt at
designing flexible compartmentalized Memory Domains for
multiple logical applications and, with the provided python
script and edited CMakeLists.txt, provides support for power
of 2 aligned MPU architectures.
Overview: The current patch uses qualifiers to group data into
subsections. The qualifier usage allows for dynamic subsection
creation and affords the developer a large amount of flexibility
in the grouping, naming, and size of the resulting partitions and
domains that are built on these subsections. By additional macro
calls, functions are created that help calculate the size,
address, and permissions for the subsections and enable the
developer to control application data in specified partitions and
memory domains.
Background: Initial attempts focused on creating a single
section in the linker script that then contained internally
grouped variables/data to allow MPU/MMU alignment and protection.
This did not provide additional functionality beyond
CONFIG_APPLICATION_MEMORY as we were unable to reliably group
data or determine their grouping via exported linker symbols.
Thus, the resulting decision was made to dynamically create
subsections using the current qualifier method. An attempt to
group the data by object file was tested, but found that this
broke applications such as ztest where two object files are
created: ztest and main. This also creates an issue of grouping
the two object files together in the same memory domain while
also allowing for compartmenting other data among threads.
Because it is not possible to know a) the name of the partition
and thus the symbol in the linker, b) the size of all the data
in the subsection, nor c) the overall number of partitions
created by the developer, it was not feasible to align the
subsections at compile time without using dynamically generated
linker script for MPU architectures requiring power of 2
alignment.
In order to provide support for MPU architectures that require a
power of 2 alignment, a python script is run at build prior to
when linker_priv_stacks.cmd is generated. This script scans the
built object files for all possible partitions and the names given
to them. It then generates a linker file (app_smem.ld) that is
included in the main linker.ld file. This app_smem.ld allows the
compiler and linker to then create each subsection and align to
the next power of 2.
Usage:
- Requires: app_memory/app_memdomain.h .
- _app_dmem(id) marks a variable to be placed into a data
section for memory partition id.
- _app_bmem(id) marks a variable to be placed into a bss
section for memory partition id.
- These are seen in the linker.map as "data_smem_id" and
"data_smem_idb".
- To create a k_mem_partition, call the macro
app_mem_partition(part0) where "part0" is the name then used to
refer to that partition. This macro only creates a function and
necessary data structures for the later "initialization".
- To create a memory domain for the partition, the macro
app_mem_domain(dom0) is called where "dom0" is the name then
used for the memory domain.
- To initialize the partition (effectively adding the partition
to a linked list), init_part_part0() is called. This is followed
by init_app_memory(), which walks all partitions in the linked
list and calculates the sizes for each partition.
- Once the partition is initialized, the domain can be
initialized with init_domain_dom0(part0) which initializes the
domain with partition part0.
- After the domain has been initialized, the current thread
can be added using add_thread_dom0(k_current_get()).
- The code used in ztests ans kernel/init has been added under
a conditional #ifdef to isolate the code from other tests.
The userspace test CMakeLists.txt file has commands to insert
the CONFIG_APP_SHARED_MEM definition into the required build
targets.
Example:
/* create partition at top of file outside functions */
app_mem_partition(part0);
/* create domain */
app_mem_domain(dom0);
_app_dmem(dom0) int var1;
_app_bmem(dom0) static volatile int var2;
int main()
{
init_part_part0();
init_app_memory();
init_domain_dom0(part0);
add_thread_dom0(k_current_get());
...
}
- If multiple partitions are being created, a variadic
preprocessor macro can be used as provided in
app_macro_support.h:
FOR_EACH(app_mem_partition, part0, part1, part2);
or, for multiple domains, similarly:
FOR_EACH(app_mem_domain, dom0, dom1);
Similarly, the init_part_* can also be used in the macro:
FOR_EACH(init_part, part0, part1, part2);
Testing:
- This has been successfully tested on qemu_x86 and the
ARM frdm_k64f board. It compiles and builds power of 2
aligned subsections for the linker script on the 96b_carbon
boards. These power of 2 alignments have been checked by
hand and are viewable in the zephyr.map file that is
produced during build. However, due to a shortage of
available MPU regions on the 96b_carbon board, we are unable
to test this.
- When run on the 96b_carbon board, the test suite will
enter execution, but each individaul test will fail due to
an MPU FAULT. This is expected as the required number of
MPU regions exceeds the number allowed due to the static
allocation. As the MPU driver does not detect this issue,
the fault occurs because the data being accessed has been
placed outside the active MPU region.
- This now compiles successfully for the ARC boards
em_starterkit_em7d and em_starterkit_em7d_v22. However,
as we lack ARC hardware to run this build on, we are unable
to test this build.
Current known issues:
1) While the script and edited CMakeLists.txt creates the
ability to align to the next power of 2, this does not
address the shortage of available MPU regions on certain
devices (e.g. 96b_carbon). In testing the APB and PPB
regions were commented out.
2) checkpatch.pl lists several issues regarding the
following:
a) Complex macros. The FOR_EACH macros as defined in
app_macro_support.h are listed as complex macros needing
parentheses. Adding parentheses breaks their
functionality, and we have otherwise been unable to
resolve the reported error.
b) __aligned() preferred. The _app_dmem_pad() and
_app_bmem_pad() macros give warnings that __aligned()
is preferred. Prior iterations had this implementation,
which resulted in errors due to "complex macros".
c) Trailing semicolon. The macro init_part(name) has
a trailing semicolon as the semicolon is needed for the
inlined macro call that is generated when this macro
expands.
Update: updated to alternative CONFIG_APPLCATION_MEMORY.
Added config option CONFIG_APP_SHARED_MEM to enable a new section
app_smem to contain the shared memory component. This commit
seperates the Kconfig definition from the definition used for the
conditional code. The change is in response to changes in the
way the build system treats definitions. The python script used
to generate a linker script for app_smem was also midified to
simplify the alignment directives. A default linker script
app_smem.ld was added to remove the conditional includes dependency
on CONFIG_APP_SHARED_MEM. By addining the default linker script
the prebuild stages link properly prior to the python script running
Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov>
Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
This patch adds a set of priorities at the (numerically) lowest end of
the range which have "meta-irq" behavior. Runnable threads at these
priorities will always be scheduled before threads at lower
priorities, EVEN IF those threads are otherwise cooperative and/or
have taken a scheduler lock.
Making such a thread runnable in any way thus has the effect of
"interrupting" the current task and running the meta-irq thread
synchronously, like an exception or system call. The intent is to use
these priorities to implement "interrupt bottom half" or "tasklet"
behavior, allowing driver subsystems to return from interrupt context
but be guaranteed that user code will not be executed (on the current
CPU) until the remaining work is finished.
As this breaks the "promise" of non-preemptibility granted by the
current API for cooperative threads, this tool probably shouldn't be
used from application code.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
User mode may now use queue objects. Instead of embedding the kernel's
linked list information directly in the data item, a container struct
is allocated from the caller's resource pool which is then added to
the queue. The new sflist type is now used to store a flag indicating
whether a data item needs to be freed when removed from the queue.
FIFO/LIFOs are derived from k_queues and have had allocator functions
added.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Similar to what has been done with pipes and message queues,
user mode can't be trusted to provide a buffer for the kernel
to use. Remove k_stack_init() as a syscall and offer
k_stack_alloc_init() which allocates a buffer from the caller's
resource pool.
Fixes#7285
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Dynamic kernel objects no longer is hard-coded to use the kernel
heap. Instead, objects will now be drawn from the calling thread's
resource pool.
Since we now have a reference counting mechanism, if an object
loses all its references and it was dynamically allocated, it will
be automatically freed.
A parallel dlist is added for efficient iteration over the set of
all dynamic objects, allowing deletion during iteration.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Some kernel APIs may need to allocate memory in order to function
correctly, especially if they are exposed to userspace where
buffers provided by user code cannot be trusted.
Instead of simply drawing from the system heap, specific pools
may instead be assigned to threads, and any requests made on
behalf of the calling thread will draw heap memory from that pool.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Forthcoming patches will dual-purpose an object's permission
bitfield as also reference tracking for kernel objects, used to
handle automatic freeing of resources.
We do not want to allow user thread A to revoke thread B's access
to some object O if B is in the middle of an API call using O.
However we do want to allow threads to revoke their own access to
an object, so introduce a new API and syscall for that.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This works like k_malloc() but allows the user to designate
a specific memory pool to use instead of the kernel heap.
Test coverage provided by existing tests for k_malloc(), which is
now derived from this API.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adding a new kernel object type or driver subsystem requires changes
in various different places. This patch makes it easier to create
those devices by generating as much as possible in compile time.
No behavior change.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Driver APIs might not implement all operations, making it possible for
a user thread to get the kernel to execute a function at 0x00000000.
Perform runtime checks in all the driver handlers, checking if they're
capable of performing the requested operation.
Fixes#6907.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The only difference between this call and k_thread_abort() (beyond
some minor performance deltas) is that "cancel" will act as a noop in
cases where the thread has begun execution and will return an error.
"Abort" always succeeds, of course. That is inherently racy when used
as a "stop the thread" API: there's no way in general (or at all in
SMP situations) to know that you're calling this function "early
enough" to catch the thread before it starts.
Effectively, all k_thread_cancel() gives you that k_thread_abort()
doesn't is an indication about whether or not a thread has started.
There are many other ways to get that information that don't require
dangerous kernel APIs.
Deprecate this function. Zephyr's own code never used it except for
its own unit test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add the missing 'max_num_pending_alerts' argument to the
K_ALERT_DEFINE used in the "Signaling an Alert" code example.
Signed-off-by: Stig Bjørlykke <stig.bjorlykke@nordicsemi.no>
This patch adds documentation on the design and implementation of stack
objects for architectures which utilize MPU backed stack and memory
protection.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Remove thread from memory domain API (k_mem_domain_remove_thread())has
only one argument which is thread ID as per the implementation whereas
documentation says there has to be two arguments, memory domain and
thread ID.Memory domain argument is not required as a thread belongs
to single memory domain at any point in time. Also memory domain
initialisation function (k_mem_domain_init()) should accept only 3
arguments i.e, memory domain name, number of parts and array of
pointers to the memory domain, instead of 4.
Signed-off-by: Spoorthi K <spoorthi.k@intel.com>
In a scenario where a platform harbours multiple interrupts to the
extent the core cannot support it, an interrupt controller is added
as an additional level of interrupt. It typically combines several
sources of interrupt into one line that is then routed to the parent
controller.
Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
The expected order for heading levels in our ReST documents is # for H1,
* for H2, = for H3, and - for H4. Some documents snuck in without
following this guideline.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
The existing docs immediately dive into the details without providing
the user with any kind of high level overview or description of the
threat model.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This commit fixes
https://github.com/zephyrproject-rtos/zephyr/issues/5008.
It does so by splitting up gen_syscalls.py into two scripts with a
json metadata file to communicate syscall metadata between them. The
parsing script parses header files from include/ and writes syscall
metadata to a file if the contents changed. The generation script
reads from the json file and generates syscall code.
The build system DAG now looks like this:
always_rebuild -> json -> syscalls -> offset.o
The script for generating json will do so only if the content changes,
this ensures that the entire DAG does not always do a full rebuild.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This gives more detail on how system calls with large argument
lists, or large return value types should be handled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This initial batch of documentation describes policies and
mechanism related to kernel objects and system calls.
Some details on porting user mode to a new arch have been
provided in the architecture porting guide.
Thread documentation updated with some user mode consideration.
This is not the final documentation, more to come in subsequent
patches.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
doc/kernel/overview/changes.rst contains information about changes from
kernel release 1.5 ("Version 1 Kernel") to the combined "Version 2
Kernel" and doc/porting/application.rst talked about how to change
applications using Version 1 interfaces to the Version 2 interface.
This information remains in the online tagged versions of the
documentation, but it's time to remove this from the current
documentation set. (Also removing example porting code.)
Fixes issue #1524
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Add the following application-facing memory domain APIs:
k_mem_domain_init() - to initialize a memory domain
k_mem_domain_destroy() - to destroy a memory domain
k_mem_domain_add_partition() - to add a partition into a domain
k_mem_domain_remove_partition() - to remove a partition from a domain
k_mem_domain_add_thread() - to add a thread into a domain
k_mem_domain_remove_thread() - to remove a thread from a domain
A memory domain would contain some number of memory partitions.
A memory partition is a memory region (might be RAM, peripheral
registers, flash...) with specific attributes (access permission,
e.g. privileged read/write, unprivileged read-only, execute never...).
Memory partitions would be defined by set of MPU regions or MMU tables
underneath.
A thread could only belong to a single memory domain any point in time
but a memory domain could contain multiple threads.
Threads in the same memory domain would have the same access permission
to the memory partitions belong to the memory domain.
The memory domain APIs are used by unprivileged threads to share data
to the threads in the same memory and protect sensitive data from
threads outside their domain. It is not only for improving the security
but also useful for debugging (unexpected access would cause exception).
Jira: ZEP-2281
Signed-off-by: Chunlin Han <chunlin.han@linaro.org>
fixed error introduced in application.rst (v1.8) along with a general
spelling check pass including consistent spelling of "runtime" and
hyphenated words with "pre-"
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
New top-level dts/ folder and description added.
Fixed error in bullet list in subsys/ description (needed
a blank like before the list.
Alphabetized folder list (subsys/ was listed after tests/)
Signed-off-by: David B. Kinder <david.b.kinder@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>
