The code has been using non DT_ prefixed defines for DT generated
defines. Switch to use DT_ prefixed ones as we want to deprecated
the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The code has been using non DT_ prefixed defines for DT generated
defines. Switch to use DT_ prefixed ones as we want to deprecated
the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The board pinmux code has been using non DT_ prefixed defines for DT
generated defines. Switch to use DT_ prefixed ones as we want to
deprecated the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The eth mcux driver has been using non DT_ prefixed defines for DT
generated defines. Switch to use DT_ prefixed ones as we want to
deprecated the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The soc nxp_imx RDC code has been using non DT_ prefixed defines for DT
generated defines. Switch to use DT_ prefixed ones as we want to
deprecated the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The i2c_imx driver has been using non DT_ prefixed defines for DT
generated defines. Switch to use DT_ prefixed ones as we want to
deprecated the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The gpio mcux driver has been using non DT_ prefixed defines for DT
generated defines. Switch to use DT_ prefixed ones as we want to
deprecated the non DT_ prefixed defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
At boot, user threads were being granted access to the entire
app shared memory section. This is incorrect; user threads should
have no access until they are added to a memory domain, which
may contain partitions defined within it.
Change from MMU_ENTRY_USER (which grants permission at boot)
to MMU_ENTRY_RUNTIME_USER (which indicates that the pages may
be granted to user mode at runtime, but not at boot).
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This patch fixes an issue with an uninitialized variable in the x509
mbedtls feature. I sent a related patch to the mbedtls project so
that this can be fixed in the future.
https://github.com/ARMmbed/mbedtls/pull/2392
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This application provides a full stack implementation for
communicating with the Google IOT Cloud. It leverages the
a JWT library to create JSON tokens which are then signed using
a RSA or ECDSA private key. The signed token is used to
authenticate with the Google IOT cloud servers. Once that is
accomplished, the application can subscribe, or publish data at
will.
Included in the application is a python script that can be used to
create RSA/ECDSA certificates and keys. The user will load the
certificate for the appropriate device on the Google IOT Cloud. The
private key is created by the script and stored in a C structure format
that is then consumed by the application. It is important to note that
any keys generated from the scripts SHOULD NOT BE STORED publicly.
Please refer to the README for more information.
Signed-off-by: David Brown <david.brown@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This patch adds a JSON web token library that adds the capability
to sign JSON tokens. This was located in subsys due to the dependency
on MBEDTLS, which resides in /ext.
Signed-off-by: David Brown <david.brown@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Add support to STM LIS2DW12 3-axis accelerometer driver.
The driver support I2C and SPI bus communication and both
polling and drdy trigger mode.
Co-authored-by: Mario Tesi <mario.tesi@st.com>
Signed-off-by: Armando Visconti <armando.visconti@st.com>
We've removed all references to base_label in dts bindings and are
removing the functionality. We should depend on DT_ prefixed defines
going forward.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We aren't using the defines generated by base_label for this device and
we should use DT_ prefixed ones if/when we do.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Select CPU_HAS_FPU_DOUBLE_PRECISION in SAM E70 and NXP I.MX RT
series of MCUs to signify double-precision floating-point unit.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
SoC family STM32F769XI supports both double and single precision
floating-point unit. This commit enables double-precision by
default in this SoC.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit introduces a Kconfig option for ARM SoCs, to signify
that the SoC implements a double-precision floating point unit.
The option is utilized in cmake/fpu-for-gcc-m-cpu to select the
appropriate GCC compile option flag for FPU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This change removes special handling for shell root commands.
Currently there is one loop in execute function that is used
to search commands on each level.
Fixed a bug where command buffer has been processed twice
when it was not needed (wildcards not found).
This change will allow to simplify "select" command
introduction.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
Document the `west build` command in the section corresponding to the
west commands that deal with the CMake cache, which is now named
"Building, flashing and debugging" for consistency.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The values for the registers like GDV, SDV and Boarder Waveform
depend on the panel and display controller. Add DT properties
and obtain such values from DT.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Shell will store only pointer to the prompt string instead of
copying it to the RAM buffer. It will save RAM memory and
it will simplify implementation of a new feature: "select"
command. When a command will be selected than shell will
display command syntax as a prompt.
Removed obsolete ASSERT check in a static function.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
This is hitting a stack overflow (probably the same reason xtensa is
also excluded -- both are stack-hungry platforms), but with CMSIS
there is a fixed cap of 512 bytes that can't be extended. So
whitelist this sample.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This API doesn't use the normal thread priority comparison itself, so
doesn't get the magic that thread_base.prio provides. If called when
another thread should be run, this would preempt the current thread
always, even if the scheduler lock was taken.
That was benign until recent spinlockifiation exposed it: a mutex in
the philosophers test run in preempt_only mode would swap away while
holding a spinlock (which used to work with irq locks) and fail later
with a "recursive" spinlock assert.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The new spinlock validation features combined with spinlockification
have increased stack usage a bit in CONFIG_ASSERT builds, but this is
a good feature we want to keep. This test was bumping into limits, so
increase the size from 512 to 640 bytes.
Unfortunately, this is also a huge test that creates a LOT of those
stacks across different test cases, so that minor bump blows us past
the 64k SRAM limit on a bunch of boards. So unify all those stacks
that are only ever used in one case at a time so the memory can be
shared. Now there's one fixed stack, named "tstack", and one array
"tstacks". Much smaller.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This port is a little different. Most subsystem synchronization uses
simple critical sections that can be replaced with global or
per-object spinlocks. But the userspace code was heavily exploiting
the fact that irq_lock was recursive and could be taken at any time.
So outer functions were doing locking and then calling into inner
helpers that would take their own lock (because they were called from
other contexts that did not lock).
Rather than try to rework this right now, this just creates a set of
spinlocks corresponding to the recursive states in which they are
taken, to preserve the existing semantics exactly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Simple global lock around the timer API. Actually a lot of this usage
was using needless vestigial locking around existing scheduler and
timeout APIs that are now internally synchronized.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
One spinlock per pipe object. Also removed some vestigial locking
around _ready_thread(). That call is internally synchronized now.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The k_sleep() locking was actually to protect the _current state from
preemption before the context switch, so document that and replace
with a spinlock. Should probably unify this with the rather cleaner
logic in pend_curr(), but right now "sleeping" and "pended" are
needlessly distinct states.
And we can remove the locking entirely from k_wakeup(). There's no
reason for any of that to need to be synchronized. Even if we're
racing with other thread modifiations, the state on exit will be a
runnable thread without a timeout, or whatever timeout/pend state the
other side was requesting (i.e. it's a bug, but not one solved by
synhronization).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use a subsystem lock, not a per-object lock. Really we want to lock
at mutex granularity where possible, but (1) that has non-trivial
memory overhead vs. e.g. directly spinning on the mutex state and (2)
the locking in a few places was originally designed to protect access
to the mutex *owner* priority, which is not 1:1 with a single mutex.
Basically the priority-inheriting mutex code will need some rework
before it works as a fine-grained locking abstraction in SMP.
Note that this fixes an invisible bug: with the older code,
k_mutex_unlock() would actually call irq_unlock() twice along the path
where there was a new owner, which is benign on existing architectures
(so long as the key argument is unchanged) but was never guaranteed to
work. With a spinlock, unlocking an unlocked/unowned lock is a
detectable assertion condition.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Straightforward port. Each struct k_queue object gets a spinlock to
control obvious data ownership.
Note that this port actually discovered a preexisting bug: the -ENOMEM
case in queue_insert() was failing to release the lock. But because
the tests that hit that path didn't rely on other threads being
scheduled, they ran to successful completion even with interrupts
disabled. The spinlock API detects that as a recursive lock when
asserts are enabled.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The two APIs protected by this lock are themselves internally
synchronized. Replace the irq_lock with a spinlock anyway, because
what I think it's doing is trying to prevent a race where something
else like an ISR or something it wakes up mucks with the thread before
this completes. Seems fragile on SMP as it stands, but this preserves
behavior on uniprocessor architectures.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Straightforward spinlock around the global thread state. Two changes
to the locking strategy were needed:
1. There was a needless recursive lock taken in schedule_new_thread().
This is only ever invoked in circumstances where the lock was already
held, or where there is no need for internal synchronization.
2. The recursive irq_lock() around the loop that spawns the initial
static threads (which happens at the start of main thread execution)
was removed. Most of the job (i.e. making sure the threads don't run
before the loop is finished) was already duplicated by the sched_lock
it was already taking, and the attempt to promise that all the
timeouts happen on the same tick is already true by construction at
system startup on uniprocessor systems, and not possible to guarantee
at all under SMP (where other CPUs can take that timer interrupt). We
don't document or test for this feature, so don't try to be fancy.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Really the locking in this file is vestigial. It only exists because
the scheduler's _unpend_all() call to wake up everyone waiting on a
wait_q is unsynchronized, because it was written to assume
irq_lock-style-locking. It would be cleaner to put that locking into
the wait_q itself and/or use the scheduler's subsystem lock. But it's
not clear there's any performance benefit, so let's stick with the
more easily verifiable change first.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Poll gets a single subsystem lock for now. The existing locking in
Ben's code is subtle, being used both for latency control and for
critical section protection. So getting each k_poll_event to use a
separate lock will require care and a little logic change. Do the
simple version for now, which still works to decouple it from the
global lock.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These functions, for good design reason, take a locking key to
atomically release along with the context swtich. But there's still a
common pattern in code to do a switch unconditionally by passing
irq_lock() directly. On SMP that's a little hurtful as it spams the
global lock. Provide an _unlocked() variant for
_Swap/_reschedule/_pend_curr for simplicity and efficiency.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Switch semaphores to use a subsystem spinlock instead of the system
irqlock.
Note that this is only "half way there". Semaphores will no longer
contend with other irqlock users on SMP systems, but all semaphores
are still sharing the same lock. Really we want semaphores to be
independently synchronized, but adding 4 bytes to every one (there are
a LOT of these things) for a separate spinlock is too much to pay.
Rather, a proper SMP-aware implementation would spin on the count
variable directly. But let's not rock that boat quite yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Just like with _Swap(), we need two variants of these utilities which
can atomically release a lock and context switch. The naming shifts
(for byte count reasons) to _reschedule/_pend_curr, and both have an
_irqlock variant which takes the traditional locking.
Just refactoring. No logic changes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Spinlocks are written above the arch-provided _arch_irq_un/lock()
calls. But those aren't stubbed by the mocking layer, and as it's not
an "arch" I don't see an obvious place to put them. Handle them in
spinlock.h.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
