Currently this is defined as a k_thread_stack_t pointer.
However this isn't correct, stacks are defined as arrays. Extern
references to k_thread_stack_t doesn't work properly as the compiler
treats it as a pointer to the stack array and not the array itself.
Declaring as an unsized array of k_thread_stack_t doesn't work
well either. The least amount of confusion is to leave out the
pointer/array status completely, use pointers for function prototypes,
and define K_THREAD_STACK_EXTERN() to properly create an extern
reference.
The definitions for all functions and struct that use
k_thread_stack_t need to be updated, but code that uses them should
be unchanged.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
All sys_slist_*() functions aren't threadsafe and calls to them
must be protected with irq_lock. This is usually done in a wider
caller context, but k_queue_poll() is called with irq_lock already
relinquished, and is thus subject to hard to detect and explain
race conditions, as e.g. was tracked in #4022.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
User threads can only create other nonessential user threads
of equal or lower priority and must have access to the entire
stack area.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to track permission on stack memory regions like we do
with other kernel objects. We want stacks to live in a memory
area that is outside the scope of memory domain permission
management. We need to be able track what stacks are in use,
and what stacks may be used by user threads trying to call
k_thread_create().
Some special handling is needed because thread stacks appear as
variously-sized arrays of struct _k_thread_stack_element which is
just a char. We need the entire array to be considered an object,
but also properly handle arrays of stacks.
Validation of stacks also requires that the bounds of the stack
are not exceeded. Various approaches were considered. Storing
the size in some header region of the stack itself would not allow
the stack to live in 'noinit'. Having a stack object be a data
structure that points to the stack buffer would confound our
current APIs for declaring stacks as arrays or struct members.
In the end, the struct _k_object was extended to store this size.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We also need macros to assert that an object must be in an
uninitialized state. This will be used for validating thread
and stack objects to k_thread_create(), which must not be already
in use.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is too powerful for user mode, the other access APIs
require explicit permissions on the threads that are being
granted access.
The API is no longer exposed as a system call and hence will
only be usable by supervisor threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's currently too easy to run out of thread IDs as they
are never re-used on thread exit.
Now the kernel maintains a bitfield of in-use thread IDs,
updated on thread creation and termination. When a thread
exits, the permission bitfield for all kernel objects is
updated to revoke access for that retired thread ID, so that
a new thread re-using that ID will not gain access to objects
that it should not have.
Because of these runtime updates, setting the permission
bitmap for an object to all ones for a "public" object doesn't
work properly any more; a flag is now set for this instead.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We got rid of letting uninitialized objects being a free-for-all
and permission to do stuff on an object is now done explicitly.
If a user thread is initializing an object, they will already have
permission on it.
If a supervisor thread is initializing an object, that supervisor
thread may or may not want that object added to its set of object
permissions for purposes of permission inheritance or dropping to
user mode.
Resetting all permissions on initialization makes objects much
harder to share and re-use; for example other threads will lose
access if some thread re-inits a shared semaphore.
For all these reasons, just keep the permissions as they are when
an object is initialized.
We will need some policy for permission reset when objects are
requested and released from pools, but the pool implementation
should take care of that.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This will allow these thread objects to be re-used.
_mark_thread_as_dead() removed, it was only being called in one
place.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
API to assist with re-using objects, such as terminated threads or
kernel objects returned to a pool.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Use some preprocessor trickery to automatically deduce the amount of
arguments for the various _SYSCALL_HANDLERn() macros. Makes the grunt
work of converting a bunch of kernel APIs to system calls slightly
easier.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Does the opposite of k_object_access_grant(); the provided thread will
lose access to that kernel object.
If invoked from userspace the caller must hace sufficient access
to that object and permission on the thread being revoked access.
Fix documentation for k_object_access_grant() API to reflect that
permission on the thread parameter is needed as well.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
By default, threads are created only having access to their own thread
object and nothing else. This new flag to k_thread_create() gives the
thread access to all objects that the parent had at the time it was
created, with the exception of the parent thread itself.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
User threads aren't trusted and shouldn't be able to alter the
scheduling assumptions of the system by making thread priorities more
favorable.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We now have macros which should significantly reduce the amount of
boilerplate involved with defining system call handlers.
- Macros which define the proper prototype based on number of arguments
- "SIMPLE" variants which create handlers that don't need anything
other than object verification
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- Dumping error messages split from _k_object_validate(), to avoid spam
in test cases that are expected to have failure result.
- _k_object_find() prototype moved to syscall_handler.h
- Clean up k_object_access() implementation to avoid double object
lookup and use single validation function
- Added comments, minor whitespace changes
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Computing the total size of the array need to handle the case where
the product overflow a 32-bit unsigned integer.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Use new _SYSCALL_OBJ/_SYSCALL_OBJ_INIT macros.
Use new _SYSCALL_MEMORY_READ/_SYSCALL_MEMORY_WRITE macros.
Some non-obvious checks changed to use _SYSCALL_VERIFY_MSG.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Instead of boolean arguments to indicate memory read/write
permissions, or init/non-init APIs, new macros are introduced
which bake the semantics directly into the name of the macro.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Expecting stringified expressions to be completely comprehensible to end
users is wishful thinking; we really need to express what a failed
system call verification step means in human terms in most cases.
Memory buffer and kernel object checks now are implemented in terms of
_SYSCALL_VERIFY_MSG.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This API only gets used inside system call handlers and a specific test
case dedicated to it. Move definition to the private kernel header along
with the rest of the defines for system call handlers.
A non-userspace inline variant of this function is unnecessary and has
been deleted.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The old policy was that objects that are not marked as initialized may
be claimed by any thread, user or kernel.
This has some undesirable implications:
- Kernel objects that were initailized at build time via some
_<object name>_INITIALIZER macro, not intended for userspace to ever
use, could be 'stolen' if their memory addresses were figured out and
_k_object_init() was never called on them.
- In general, a malicious thread could initialize all unclaimed objects
it could find, resulting in denial of service for the threads that
these objects were intended for.
Now, performing any operation in user mode on a kernel object,
initialized or not, required that the calling user thread have
permission on it. Such permission would have to be explicitly granted or
inherited from a supervisor thread, as with this change only supervisor
thread will be able to claim uninitialized objects in this way.
If an uninitialized kernel object has permissions granted to multiple
threads, whatever thread actually initializes the object will reset all
permission bits to zero and grant only the calling thread access to that
object.
In other words, granting access to an uninitialized object to several
threads means that "whichever of these threads (or any kernel thread)
who actually initializes this object will obtain exclusive access to
that object, which it then may grant to other threads as it sees fit."
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We now show the caller's thread ID and dump out the permissions array
for the object that failed the check.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This API has a return value which was not being propagated back to the
caller if invoked as a system call.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These are removed as the APIs that use them are not suitable for
exporting to userspace.
- Kernel workqueues run in supervisor mode, so it would not be
appropriate to allow user threads to submit work to them. A future
enhancement may extend or introduce parallel API where the workqueue
threads may run in user mode (or leave as an exercise to the user).
- Kernel slabs store private bookkeeping data inside the
user-accessible slab buffers themselves. Alternate APIs are planned
here for managing slabs of kernel objects, implemented within the
runtime library and not the kernel.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
k_pipe_block_put() will be done in another patch, we need to design
handling for the k_mem_block object.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These modify kernel object metadata and are intended to be callable from
user threads, need a privilege elevation for these to work.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We want applications to be able to enable and disable userspace without
changing any code. k_thread_user_mode_enter() now just jumps into the
entry point if CONFIG_USERSPACE is disabled.
Signed-off-by: Andrew Boie <andrew.p.boie@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>
Everything get passed to handlers as u32_t, make it simpler to check
something that is known to be a pointer, like we already do with
_SYSCALL_IS_OBJ().
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Device drivers need to be treated like other kernel objects, with
thread-level permissions and validation of struct device pointers passed
in from userspace when making API calls.
However it's not sufficient to identify an object as a driver, we need
to know what subsystem it belongs to (if any) so that userspace cannot,
for example, make Ethernet driver API calls using a UART driver object.
Upon encountering a variable representing a device struct, we look at
the value of its driver_api member. If that corresponds to an instance
of a driver API struct belonging to a known subsystem, the proper
K_OBJ_DRIVER_* enumeration type will be associated with this device in
the generated gperf table.
If there is no API struct or it doesn't correspond to a known subsystem,
the device is omitted from the table; it's presumably used internally
by the kernel or is a singleton with specific APIs for it that do not
take a struct device parameter.
The list of kobjects and subsystems in the script is simplified since
the enumeration type name is strongly derived from the name of the data
structure.
A device object is marked as initialized after its init function has
been run at boot.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
To define a system call, it's now sufficient to simply tag the inline
prototype with "__syscall" or "__syscall_inline" and include a special
generated header at the end of the header file.
The system call dispatch table and enumeration of system call IDs is now
automatically generated.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- syscall.h now contains those APIs needed to support invoking calls
from user code. Some stuff moved out of main kernel.h.
- syscall_handler.h now contains directives useful for implementing
system call handler functions. This header is not pulled in by
kernel.h and is intended to be used by C files implementing kernel
system calls and driver subsystem APIs.
- syscall_list.h now contains the #defines for system call IDs. This
list is expected to grow quite large so it is put in its own header.
This is now an enumerated type instead of defines to make things
easier as we introduce system calls over the new few months. In the
fullness of time when we desire to have a fixed userspace/kernel ABI,
this can always be converted to defines.
Some new code added:
- _SYSCALL_MEMORY() macro added to check memory regions passed up from
userspace in handler functions
- _syscall_invoke{7...10}() inline functions declare for invoking system
calls with more than 6 arguments. 10 was chosen as the limit as that
corresponds to the largest arg list we currently have
which is for k_thread_create()
Other changes
- auto-generated K_SYSCALL_DECLARE* macros documented
- _k_syscall_table in userspace.c is not a placeholder. There's no
strong need to generate it and doing so would require the introduction
of a third build phase.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
A quick look at "man syscall" shows that in Linux, all architectures
support at least 6 argument system calls, with a few supporting 7. We
can at least do 6 in Zephyr.
x86 port modified to use EBP register to carry the 6th system call
argument.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
* Instead of a common system call entry function, we instead create a
table mapping system call ids to handler skeleton functions which are
invoked directly by the architecture code which receives the system
call.
* system call handler prototype specified. All but the most trivial
system calls will implement one of these. They validate all the
arguments, including verifying kernel/device object pointers, ensuring
that the calling thread has appropriate access to any memory buffers
passed in, and performing other parameter checks that the base system
call implementation does not check, or only checks with __ASSERT().
It's only possible to install a system call implementation directly
inside this table if the implementation has a return value and requires
no validation of any of its arguments.
A sample handler implementation for k_mutex_unlock() might look like:
u32_t _syscall_k_mutex_unlock(u32_t mutex_arg, u32_t arg2, u32_t arg3,
u32_t arg4, u32_t arg5, void *ssf)
{
struct k_mutex *mutex = (struct k_mutex *)mutex_arg;
_SYSCALL_ARG1;
_SYSCALL_IS_OBJ(mutex, K_OBJ_MUTEX, 0, ssf);
_SYSCALL_VERIFY(mutex->lock_count > 0, ssf);
_SYSCALL_VERIFY(mutex->owner == _current, ssf);
k_mutex_unlock(mutex);
return 0;
}
* the x86 port modified to work with the system call table instead of
calling a common handler function. fixed an issue where registers being
changed could confuse the compiler has been fixed; all registers, even
ones used for parameters, must be preserved across the system call.
* a new arch API for producing a kernel oops when validating system call
arguments added. The debug information reported will be from the system
call site and not inside the handler function.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Based on work by Chunlin Han <chunlin.han@linaro.org>.
This defines the interfaces that architectures will need to implement in
order to support memory domains in either MMU or MPU hardware.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Now creating a thread will assign it a unique, monotonically increasing
id which is used to reference the permission bitfield in the kernel
object metadata.
Stub functions in userspace.c now implemented.
_new_thread is now wrapped in a common function with pre- and post-
architecture thread initialization tasks.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We already check the stack sentinel for outgoing thread when we _Swap,
just leverage that.
The thread state check in _check_stack_sentinel now only exits if the
current thread is a dummy thread.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Thread may be in user mode when it returns and can't look at
_current. Use k_current_get() which will be a system call.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This will be used by system call handlers to ensure that any memory
regions passed in from userspace are actually accessible by the calling
thread.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
In various places, a private _thread_entry_t, or the full prototype
were being used. Be consistent and use the same typedef everywhere.
Signen-off-by: Andrew Boie <andrew.p.boie@intel.com>
Previously, this was only done if an essential thread self-exited,
and was a runtime check that generated a kernel panic.
Now if any thread has k_thread_abort() called on it, and that thread
is essential to the system operation, this check is made. It is now
an assertion.
_NANO_ERR_INVALID_TASK_EXIT checks and printouts removed since this
is now an assertion.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's now possible to instantiate a thread object, but delay its
execution indefinitely. This was already supported with K_THREAD_DEFINE.
A new API, k_thread_start(), now exists to start threads that are in
this state.
The intended use-case is to initialize a thread with K_USER, then grant
it various access permissions, and only then start it.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Garbage values here could wreak havoc on the initial switch to main
depending on how arch-specific _Swap() manages memory permissions when
switching threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
All system calls made from userspace which involve pointers to kernel
objects (including device drivers) will need to have those pointers
validated; userspace should never be able to crash the kernel by passing
it garbage.
The actual validation with _k_object_validate() will be in the system
call receiver code, which doesn't exist yet.
- CONFIG_USERSPACE introduced. We are somewhat far away from having an
end-to-end implementation, but at least need a Kconfig symbol to
guard the incoming code with. Formal documentation doesn't exist yet
either, but will appear later down the road once the implementation is
mostly finalized.
- In the memory region for RAM, the data section has been moved last,
past bss and noinit. This ensures that inserting generated tables
with addresses of kernel objects does not change the addresses of
those objects (which would make the table invalid)
- The DWARF debug information in the generated ELF binary is parsed to
fetch the locations of all kernel objects and pass this to gperf to
create a perfect hash table of their memory addresses.
- The generated gperf code doesn't know that we are exclusively working
with memory addresses and uses memory inefficently. A post-processing
script process_gperf.py adjusts the generated code before it is
compiled to work with pointer values directly and not strings
containing them.
- _k_object_init() calls inserted into the init functions for the set of
kernel object types we are going to support so far
Issue: ZEP-2187
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/1280, but
also many other failures, where output was garbled due to this. Other
similarly affected issues are missing first benchmark (context) in
latency benchmark and some net tests.
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
k_timer_start(timer, duration, period) is API used to
start a timer. Currently duration parameters accepts
only positive number.
But a user may require to do some periodic activity
ASAP and start timer with 0 value. So this patch
allows 0 as minimum value of duration.
In this patch, when duration value is set as 0 then
timer expiration handler is called instead of submiting
this into timeout queue.
Jira: ZEP-2497
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
The API/Variable names in timing_info looks very speicific to
platform (like systick etc), whereas these variabled are used
across platforms (nrf/arm/quark).
So this patch :-
1. changing API/Variable names to generic one.
2. Creating some of Macros whose implimentation is platform
depenent.
Jira: ZEP-2314
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
SYS_DLIST_FOR_EACH_CONTAINER is preferable over using
SYS_DLIST_FOR_EACH_NODE as that avoid casting directly which assumes the
node field is always at the beginning.
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>
The boot banner is being printed after static threads have started, for
example this is visible with tests using ztest.
This puts the banner message before starting any threads.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Partial implementation of the IEEE 1003.1 pthread API, including
mutexes and condition variables in their default behaviors, and
pthread barrier objects. The rwlock and spinlocks abstractions are
not supported in this commit (both only make sense in the presence of
multiple SMP processors).
Note that this is the IPC mechanisms only. The thread creation API
itself is unsupported: Zephyr threads work differently from pthreads
and don't port cleanly in all cases. Likewise the "_INITIALIZER"
macros from pthreads don't work cleanly here, and _DECLARE macros have
been provided to statically initialize pthread primitives in a manner
more native to Zephyr
Signed-off-by: Andy Ross <andrew.j.ross@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>
Save some memory for small memory systems when running ztests. We have
our own stack in ztest so we should be able to get away reducing down
the main stack.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* 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>
If there are multiple preemptive threads with same priority, and any
one thread preempts before its time slice expires (due to yields/
semaphore take/queue etc), then next schedules thread is getting
lower time slide than expected.
This patch fixes this issue by accounting time expired when a thread
releases CPU before its time slide expires.
Jira: ZEP-2217/ZEP-2218
Signed-off-by: Youvedeep Singh <youvedeep.singh@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>
This test was just wrong. If the current thread did not race with any
others during the allocation process, then the result will be false
because it was detected so earlier in the function. If we did race,
then sure: it might be true now if someone snuck in and freed a block.
But so what? We already have the block we want to break. The
behavior in the code as written was to early-exit from the break loop,
returning a buffer that was larger than the one requested (though
otherwise benign -- we wouldn't leak, just waste memory). No idea
what I was thinking.
Thanks to Du Quanwen for the diagnosis.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Subsequent patches will set this guard page as unmapped,
triggering a page fault on access. If this is due to
stack overflow, a double fault will be triggered,
which we are now capable of handling with a switch to
a know good stack.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Adds common and Kinetis-specific adc device tree properties, and updates
all Kinetis SoC and board dts files to include adc nodes.
Jira: ZEP-1396
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Introduce a configurable boot delay option (defaulting to none) that
happens right after printing a boot delay banner, #before calling
main() in kernel/init.c:_main(), before taking timestamps for _main()
and once all the infrastructure is in place. Move also the boot banner
to happen after this delay.
The rationale for this is some boards will boot really fast and print
out some test case output in the serial port before the system that is
monitoring the serial port is able to read from the serial port.
This happens in MCUs whose serial port is embedded in a USB connection
which also is used to power the MCU board. When powering it on by
powering the USB port, there is a time it takes the host system to
detect the USB connection, enumerate the serial port, configure it and
load, start and read from the serial port. At this time, it might have
printed the output of the serial port.
While manually it is possible to press a reset button, on automation
setups this adds a lot of overhead and cabling or modifications to the
MCU that are easier (and cheaper) to overcome with this delay. Other
options (like using a separate serial line) might not be possible or
add a lot of cabling and cost, plus it'd also add extra build
configuration.
Change-Id: I2f4d1ba356de6cefa19b4ef5c9f19f87885d4dfd
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Commit 1bc2fdc70 ("dts: arm: STM32 boards use DT to configure I2C")
added a new Kconfig option, HAS_DTS_I2C, which should be set when the
target supports configuration of I2C peripherals via Device Tree.
Currently, STM32 targets select this. However, the fact that
HAS_DTS_I2C has no default is causing prompting when building Zephyr
on other targets with DTS. To avoid this and allow builds to complete
as usual, have HAS_DTS_I2C default to n.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
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>
Configure I2C using DT for the following STM32 boards:
disco_l475_iot1
nucleo_f401re
96b_carbon
olimexino_stm32
Signed-off-by: Yannis Damigos <giannis.damigos@gmail.com>
Applications will have their own BSS and data sections which
will need to be additionally copied.
This covers the common C implementation of these functions.
Arches which implement their own optimized versions will need
to be updated.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
1. Changed _tsc_read() to k_cycles_get_32(). Thus reading the
time stamp will be agnostic of the architecutre used.
2. Changed the variable names from *_tsc to *_time_stamp.
JIRA: ZEP-1426
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The existing __stack decorator is not flexible enough for upcoming
thread stack memory protection scenarios. Wrap the entire thing in
a declaration macro abstraction instead, which can be implemented
on a per-arch or per-SOC basis.
Issue: ZEP-2185
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
