Now that all logging methods use printk as a backend the respective
Kconfig options should declare the right dependencies.
Change-Id: I65c759db0ec7ba6333b76d8d20aea0e374fd4947
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Moved all libc Kconfigs to where the code is and remove the default
Kconfig for selecting the minimal libc. Minimal libc is now the default
if nothing else is configured in.
Removed the options for extended libc, this obviously was restricting
features in the minimal libc without a good reason, most of the
functions are available directly when using newlib, so there is no
reason why we need to restrict those in minimal libc.
Jira: ZEP-1440
Change-Id: If0a3adf4314e2ebdf0e139dee3eb4f47ce07aa89
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
For very constrained systems, like bootloaders.
Only the main thread is available, so a main() function must be
provided. Kernel objects where pending is in play will not behave as
expected, since the main thread cannot pend, it being the only thread in
the system. Usage of objects should be limited to using K_NO_WAIT as the
timeout parameter, effectively polling on the object.
Change-Id: Iae0261daa98bff388dc482797cde69f94e2e95cc
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
- does not pull in printk(), for potential footprint gain
- does not pull in k_thread_abort(), for single-threaded systems
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Change-Id: Ibc6a198b81a6cd73117d1e85aa05b92a4501a34d
A thread cannot have a coop priority in this case. It turns out a
priority is not needed when a thread is not inserted in the ready queue,
which is the case with the dummy thread.
The comment was also out-of-date, since it referred to a nanokernel
concept.
Change-Id: Id117501164bd72383d53f3df13030cf95dadc38b
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Some kernel operations, like scheduler locking can be optmized out,
since coop threads lock the scheduler by their very nature. Also, the
interrupt exit path for all architecture does not have to do any
rescheduling, again by the nature of non-preemptible threads.
Change-Id: I270e926df3ce46e11d77270330f2f4b463971763
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
nano_cpu_idle/nano_cpu_atomic_idle were not ported to the unified
kernel, and only the old APIs were available. There was no real impact
since, in the unified kernel, only the idle thread should really be
doing power management. However, with a single-threaded kernel, these
functions can be useful again.
The kernel internals now make use of these APIs instead of the legacy
ones.
Change-Id: Ie8a6396ba378d3ddda27b8dd32fa4711bf53eb36
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The numbers of timeouts that expire on a given tick is arbitrary. When
handling them, interrupts were locked, which prevented higher-priority
interrupts from preempting the system clock timer handler.
Instead of looping on the list of timeouts, which needs interrupts being
locked since it can be manipulated at interrupt level, timeouts are
dequeued one by one, unlocking interrupts between each, and put on a
local 'expired' queue that is drained subsequently, with interrupts
unlocked. This scheme uses the fact that no timeout can be prepended
onto the timeout queue while expired timeouts are getting removed from
it, since adding a timeout of 0 is prohibited.
Timer handlers now run with interrupts unlocked: the previous behaviour
added potentially horrible non-determinism to the handling of timeouts.
Change-Id: I709085134029ea2ad73e167dc915b956114e14c2
Signed-off-by: Benjamin Walsh <walsh.benj@gmail.com>
The format string passed to printk is trusted, and this is just sample
code anyway.
Change-Id: I267e1e3a9b6720c4216624bf0c2590ce42c6c681
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Not a functional bug per-se since they resolve to the same thing, but a
conceptual error nonetheless.
Change-Id: Ia11f6bd272cabe8da21d59e3378b8348f034e814
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
These tick computation can take a significant amount of time, and there
is no reason to do them with interrupts locked.
Change-Id: I2d8803ec6025b827e9450fa493084bbf8be98bad
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Use _INACTIVE instead of hardcoding -1.
_EXPIRED is defined as -2 and will be used for an improvement so that
interrupts are not locked for a non-deterministic amount of time while
handling expired timeouts.
_abort_timeout/_abort_thread_timeout return _INACTIVE instead of -1 if
the timeout has already been disabled.
Change-Id: If99226ff316a62c27b2a2e4e874388c3c44a8aeb
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The way the ready thread cache was implemented caused it to not always
be "hot", i.e. there could be some misses, which happened when the
cached thread was taken out of the ready queue. When that happened, it
was not replaced immediately, since doing so could mean that the
replacement might not run because the flow could be interrupted and
another thread could take its place. This was the more conservative
approach that insured that moving a thread to the cache would never be
wasted.
However, this caused two problems:
1. The cache could not be refilled until another thread context-switched
in, since there was no thread in the cache to compare priorities
against.
2. Interrupt exit code would always have to call into C to find what
thread to run when the current thread was not coop and did not have the
scheduler locked. Furthermore, it was possible for this code path to
encounter a cold cache and then it had to find out what thread to run
the long way.
To fix this, filling the cache is now more aggressive, i.e. the next
thread to put in the cache is found even in the case the current cached
thread is context-switched out. This ensures the interrupt exit code is
much faster on the slow path. In addition, since finding the next thread
to run is now always "get it from the cache", which is a simple fetch
from memory (_kernel.ready_q.cache), there is no need to call the more
complex C code.
On the ARM FRDM K64F board, this improvement is seen:
Before:
1- Measure time to switch from ISR back to interrupted task
switching time is 215 tcs = 1791 nsec
2- Measure time from ISR to executing a different task (rescheduled)
switch time is 315 tcs = 2625 nsec
After:
1- Measure time to switch from ISR back to interrupted task
switching time is 130 tcs = 1083 nsec
2- Measure time from ISR to executing a different task (rescheduled)
switch time is 225 tcs = 1875 nsec
These are the most dramatic improvements, but most of the numbers
generated by the latency_measure test are improved.
Fixes ZEP-1401.
Change-Id: I2eaac147048b1ec71a93bd0a285e743a39533973
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The Cortex-M3/4 kernel was reserving priorities 0 and 1 for itself, but
was not registering any exception on priority 0. Only reserve priority 0
and use it for SVC and fault exceptions instead of priority 1.
Change-Id: Iff2405e27fd4bed4e49ab90ec2ae984f2c0a83a6
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
There are now three flags that decide how many priorities are reserved
by the kernel, each one requiring one priority level: Zero Latency
Interrupts, BASEPRI locking (for SVC usage) and faults that are not at
priority -1, so that taking them in an ISR actually triggers the fault
synchronously.
Change-Id: I7f4d760c9110051aeb82dcfd8cd68026a9b74b54
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Cortex-M0/M0+ do not have other faults than the hard fault at priority
-1, so they do not need to reserve a priority to allow exceptions to
trigger during handling of ISRs.
Change-Id: I479e439f7bcac70b4b2b787bcd744a4c65437e80
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
This allows using it in _EXC_PRIO() instead of hardcoding 2 and 3.
Change-Id: I3549be54602643e06823ba63beb6a6992f39f776
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Use it to flag which CPUs can do zero latency interrupts, which depend
on being able to lock up to a specific interrupt priority.
Change-Id: I09f71366ea1d05486e38c513a09abc270884879f
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Fixes this:
error: ‘zero_addr’ defined but not used [-Werror=unused-const-variable=]
...
Change-Id: I5b0baf597e62f3206e15638a63e129503b76b048
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is a left-over that should have been renamed to the new
net_buf_alloc_debug function name.
Change-Id: Iefcbd2eefab5614b1b80214cb0927f3db77d592e
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When going into DEEP_SLEEP mode, the ARC core now saves
its context. This includes:
- All core registers
- Stack pointer
- Program counter (restored by jumping to the restore code)
The arc reset code now checks if the GPS0 bit 2 is set.
This is similar to the behavior of the x86 core done by
the QMSI bootloader which is setting GPS0 bit 1 in order
to call the restore path instead of cold boot path.
The sample has been adapted in order to support the ARC.
Jira: ZEP-1222
Change-Id: I375f03b16b8a5fd1f07ead55cf7e4947d6290c9f
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
When going into DEEP_SLEEP state, the ARC timer
needs to be restored.
This implements the function to restore the timer
after sleep.
As the time spent during sleep is not currently known,
the timer is expired to reschedule the application task.
Jira: ZEP-1224
Change-Id: I22a30d0fd79f177cf166b9a29dc78d68f7d7fbad
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
In order to resume the ARC from deep sleep,
the interrupts need to be restored.
The FIRQ stack needs to be saved and restored
when performing sleep operations.
During early initialization, the sp in the 2nd register bank
is made to refer to _firq_stack.
This allows for the FIRQ handler to use its own stack.
Fast Interrupts cannot be used after sleep if this information
is not restored.
This patch adds the suspend and resume functions.
Jira: ZEP-1223
Change-Id: Ic81980f05aee6c1f7b8c46c743f2648c65b29486
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
Move interrupt initialization for the ARC to its own
device. The init function for the arc will be only
doing platform specific operations
Jira: ZEP-1288
Change-Id: Icb04c3622890021c65cd24cecf6cafee6c37caf9
Signed-off-by: Julien Delayen <julien.delayen@intel.com>
Following commit fc21a76db6
Some more fixes are needed.
Change-Id: I19c2c979d44be5edfd76041d3cf4507860795c78
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Using a LIFO instead of a FIFO has the potential benefit that more
recently in-use buffers may be "cache-hot" and therefore accessed
faster than least recently used (which is what we get with a FIFO).
Change-Id: I59bb083ca2e00d0d404406540f7db216742a27cf
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Since the user data size is now stored in the pool there's very little
value in storing it as well per-buffer.
Change-Id: I17a99123b232423c52a2179b4eccd813728d51b1
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In order to keep the initialization process light-weight, remove
net_buf_pool_init() and instead perform the initialization of the pool
and buffers in a "lazy" manner. This means storing more information
in the pool, and removing any 'const' members from net_buf. Since
there are no more const members in net_buf the buffer array can be
declared with __noinit, which further reduces initialization overhead.
Change-Id: Ia126af101c2727c130651b697dcba99d159a1c76
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This is only for use with custom destroy callbacks, so that the
application gets isolated away from the details of how exactly the
buffers are managed. This opens up the possibility of switching away
from k_fifo to potentially better solutions, such as k_lifo.
Change-Id: I0d8322fdec3500d8ae060ae471b9448aeaa4572a
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
That bug never got caught because the buffer in unit test is always
clean and fully initialized to 0, and that part of the code being
tested is never used in real as the ACK reply is directly made by the
chip.
Change-Id: I88c4dd3767b4addf2250165b94f49fae29d322ea
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
If receiving a malformed MQTT packet with less than 5 bytes it's
possible to get a read one byte behind buf.
Change-Id: I34425add57c937c8fd9df5bf7b72af092d6f5f32
Signed-off-by: Stig Bjørlykke <stig@bjorlykke.org>
Ethernet build-all test was not being filtered base on RAM size so
build step LINK was failing with "region `RAM' overflowed by 192
bytes" error when running daily sanitycheck.
Added filter so this test is not attempted for boards with smaller
RAM such as quark_d2000_crb, which was causing daily build failure
Change-Id: I4ed3bef4f1c78e83890331db34fb1f2b2b066414
Signed-off-by: Genaro Saucedo Tejada <genaro.saucedo.tejada@intel.com>
This reverts commit 7a74fb0454.
This commit breaks the sample. The sample code has a bug which will be
addressed in a separate patch.
Change-Id: Ic44faeafced4415765fded04e2493e306fc35331
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The CONFIG_TEST_RANDOM_GENERATOR parameter is not intended for
production use. Switch to CONFIG_RANDOM_GENERATOR.
Change-Id: Id6ce986259270455223ce6a42d19a3d9c9b1e642
Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com>
Restructure the RANDOM Kconfig to match the structure used in other
drivers with a single top level menu. Move the true random number
generators to appear first in the menu, with pseudo generators at the
bottom. Do not present pseudo generators if a true random generator
is presented.
This change implies that tests, samples and applications that require
the random driver interface must now select CONFIG_RANDOM_GENERATOR.
In order for tests and samples to build (and run) on platforms that
have no random driver it remains necessary to select
the CONFIG_TEST_RANDOM_GENERATOR.
Note that CONFIG_TEST_RANDOM_GENERATOR retains its original purpose of
enabling a random driver that delivers non random numbers for the
purpose of testing only.
Change-Id: I2e28e44b4adf800e64a885aefe36a52da8aa455a
Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com>
Remove CONFIG_TEST_RANDOM_GENERATOR from each test and sample where it
is not required.
Change-Id: I949f8e93c2cb1881622a5e48efeb87c43122a170
Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com>
Update drivers to return INT_PLUS_MICRO values instead of doubles.
This hides the fact that the drivers use floating point operations and
doesn't force the application to use them as well.
Change-Id: I14c6faecb35331c2fdbdab41bc624d751de984b8
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
Use integers for sensor value calculations in which doubles are not
required.
Change-Id: I8662023ca596cb232e31849b0b77ae2bf0372cf0
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
Remove SENSOR_VALUE_TYPE_INT as it is the same as
SENSOR_VALUE_TYPE_INT_PLUS_MICRO with val2 set to 0.
Change-Id: If5a9c579b7267701c27f40fd887acae47d64edc5
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
Remove SENSOR_VALUE_TYPE_Q16_16 as it is not used by any driver. Future
drivers can use any of the remaining value types.
Change-Id: I984143cc65d6a6fd0477f310ac17c62498cc05b8
Signed-off-by: Bogdan Davidoaia <bogdan.m.davidoaia@intel.com>
Until now it has been necessary to separately define a k_fifo and
an array of buffers when creating net_buf pools. This has been a bit
of an inconvenience as well as blurred the line of what exactly
constitutes the "pool".
This patch removes the NET_BUF_POOL() macro and replaces it with a
NET_BUF_POOL_DEFINE() macro that internally expands into the buffer
array and new net_buf_pool struct with a given name:
NET_BUF_POOL_DEFINE(pool_name, ...);
Having a dedicated context struct for the pool has the added benefit
that we can start moving there net_buf members that have the same
value for all buffers from the same pool. The first such member that
gets moved is the destroy callback, thus shrinking net_buf by four
bytes. Another potential candidate is the user_data_size, however
right not that's left out since it would just leave 2 bytes of padding
in net_buf (i.e. not influence its size). Another common value is
buf->size, however that one is also used by net_buf_simple and can
therefore not be moved.
This patch also splits getting buffers from a FIFO and allocating a
new buffer from a pool into two separate APIs: net_buf_get and
net_buf_alloc, thus simplifying the APIs and their usage. There is no
separate 'reserve_head' parameter anymore when allocating, rather the
user is expected to call net_buf_reserve() afterwards if something
else than 0 headroom is desired.
Change-Id: Id91b1e5c2be2deb1274dde47f5edebfe29af383a
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This issue was reported by Coverity
Coverity-CID: 157621
Change-Id: I7f84c0868467ab55e033aecac037967da001a6db
Signed-off-by: Sergio Rodriguez <sergio.sf.rodriguez@intel.com>
