Mostly build tests now, will be extended to verify CTF output once we
have this feature in sanitycheck.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Calling indicate or notify on a disconnected connection object would
result in the error code ENOMEM when failing to acquire buffers instead
of the expected return code ENOTCONN.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Integrated Settings module tests with the NVS backend. The batch of
tests is shared with other backends.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
Changed the name of functional tests for NVS and FCB in the test
configuration file to avoid duplication with other test suites.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
Limited the scope of helper functions that are used in the common test
source. Now it is easier to identify which functions are intended to be
used in the test suite.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
This adds a way to specify a custom SPI configuration file to be
used with the image generation tool. For example, this can be
used to reduce the SPI image size to allow faster flashing
(e.g. 512KB instead of 16MB).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add a set of build time assertions that checks if the peripheral base
addresses defined in dts nodes match the values provided by nrfx/MDK.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Add diagram showing the current system power management and the central
method of device power management.
The diagrams were made using draw.io and can be edit using draw.io.y
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
* In ARC, pop reg ==> sp=sp-4; *sp= b; The original codes have bug that
the save of ilink (st ilink [sp]) will crash the interruptted stack's
content. This commit fixes this bug and makes the codes easier to
understand
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
It seems that the ST sensor hal expects <math.h> for float_t and
double_t definitions. Now that we have those for minlibc we don't need
to require newlib.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Prompted by an upstream bug report. Nothing in Zephyr triggers this at
the moment, but might as well fix it.
Update Kconfiglib to upstream revision 7d05084b7e, to get this commit
in:
Fix handling of parentheses in macro argument values
As an oversight, there was no check for nested parentheses in macro
arguments, making the preprocessor think the call ended after
'void)' in
def_bool $(success,echo 'void foo(void) { asm inline (""); }' \
| $(CC) -x c - -c -o /dev/null)
This broke the latest linux-next kernels (with a Kconfig error),
starting with commit eb111869301e1 ("compiler-types.h: add
asm_inline definition").
I remember seeing this when going through the C code, but somehow
forgot to put it in. Fix it, and clean up _expand_macro() a bit at
the same time.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Generating generic information for 'type: phandle-array' properties in
edtlib was difficult due to defining phandle-array as just a list of
phandles and numbers. To make sense of a phandle-array property like
'pwms', you have to know that #pwm-cells is expected to appear on
each referenced controller, and that the binding for the controller has
a #cells.
Because of this, handling of various 'type: phandle-array' properties
was previously hardcoded in edtlib and exposed through properties like
Node.pwms, instead of through the generic Node.props (though with a lot
of shared code).
In practice, it turns out that all 'type: phandle-array' properties in
Zephyr work exactly the same way: They all have names that end in -s,
the 's' is removed to derive the name of related properties, and they
all look up #cells in the binding for the controller, which gives names
to the data values.
Strengthen the definition of 'type: phandle-array' to mean a property
that works exactly like the existing phandle-array properties (which
also means requiring that the name ends in -s). This removes a ton of
hardcoding from edtlib and allows new 'type: phandle-array' properties
to be added without making any code changes.
If we ever need a property type that's a list of phandles and numbers
but that doesn't follow this scheme, then we could add a separate type
for it. We should check if the standard scheme is fine first though.
The only property type for which no information is generated is now
'compound'.
There's some inconsistency in how we generate identifiers for clocks
compared to other 'type: phandle-array' properties, so keep
special-casing them for now in gen_defines.py (see the comment in
write_clocks()).
This change also enabled a bunch of other simplifications, like reusing
the ControllerAndData class for interrupts.
Piggyback generalization of *-map properties so that they work for any
phandle-array properties. It's now possible to have things like
'io-channel-map', if you need to.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
If an architecture declares support for IPI, we still want to use it
only when running in SMP mode.
(This also fixes a build failure on ARC, which declares
CONFIG_SCHED_IPI_SUPPORTED but doesn't actually implement
z_arch_sched_ipi() yet).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
At least twice (to be fair: twice among thousands of test runs), I've
seen this device return "backwards" times in SMP, where the counter
value read from one CPU is behind the saved value already seen on the
other. On hardware this should obviously never happen, HPET is a
single global device.
Add a simple workaround on QEMU targets so the math doesn't blow up.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Disabling SMP mode for certain tests was a one-release thing, done to
avoid having to triage every test independently (MANY are not
SMP-safe), and with the knowledge that it was probably hiding bugs in
the kernel.
Turn it on pervasively. Tests are treated with a combination of
flagging specific cases as "1cpu" where we have short-running tests
that can be independently run in an otherwise SMP environment, and via
setting CONFIG_MP_NUM_CPUS=1 where that's not possible (which still
runs the full SMP kernel config, but with only one CPU available).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The test suite is filled with tests that make assumptions (e.g. about
exactly when other threads will be scheduled) that don't work when
there is another CPU available to handle the load.
Add a feature to the test suite that can "hold" all but one CPU while
the test executes, leveraging the very nice setup/teardown callbacks
to do it. When there is only one CPU, this becomes a very fast noop
of course.
Note that the hold is done by disabling interrupts and spinning, so it
comes with significant CPU cost and tends to drive up the load on the
CI system (and cause other spurious failures on unrelated tests!), so
this can't be used for long-running test cases.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was testing for an undocumented and somewhat hyperspecific
behavior: when a process reaches a reschedule point and yields to a
higher priority thread, and there is another equal priority thread
active, which thread gets to run when the higher priority thread
finishes its work? The original scheduler (because it leaves the
older thread in place in the list) implements the preemption like an
interrupt and returns to the original thread, despite the fact that
this then resets is time slice quantum unfairly. In SMP mode, where
the current threads cannot live in the active list, the thread gets
added back to the end of the queue and the other thread runs. In
effect, in UP mode "yield" and "reschedule" mean very slightly
different things where in SMP they act the same.
We don't document either behavior, as it happens. Relax the test
constraints by adding a single deliberate k_yield() to unify behavior.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The timeout code has an optimization where it refuses to send a new
timeout to the driver unless it is sooner than one already scheduled.
This won't work on SMP, though, because the timeout value when
timeslicing is enabled depends on the current thread, and on SMP the
decision as to the next thread will not be made until later (when we
swap, or exit an interrupt).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that we have a working IPI framework, there's no reason for the
default spin loop for the SMP idle thread. Just use the default
platform idle and send an IPI when a new thread is readied.
Long term, this can be optimized if necessary (e.g. only send the IPI
to idling CPUs, or check priorities, etc...), but for a 2-cpu system
this is a very reasonable default.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Our thread struct gets initialized piecewise in a bunch of locations
(this is sort of a design flaw). The is_idle field, which was
introduced to identify idle threads in SMP (where there can be more
than one), was correctly set for idle threads but was being left
uninitialized elsewhere, and in a tiny handful of cases was turning up
nonzero.
The case in pipes. was particularly vexsome, as that isn't a thread at
all but one of the "dummy" threads used for timeouts (another design
flaw IMHO).
Get this right everywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
In uniprocessor mode, the kernel knows when a context switch "is
coming" because of the cache optimization and can use that to do
things like update time slice state. But on SMP the scheduler state
may be updated on the other CPU at any time, so we don't know that a
switch is going to happen until the last minute.
Expose reset_time_slice() as a public function and call it when needed
out of z_swap().
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The loop in thread abort on SMP where we wait for the results on an
IPI correctly handled the case where a thread running on another CPU
gets its interrupt and self-aborts, but it missed the case where the
other thread pends before receiving the interrupt.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There were two related bugs when in SMP mode:
1. Underneath z_reschedule(), the code was inexplicably checking the
swap_ok flag on the current CPU to see if it was OK to preempt the
current thread, but reschedule is the DEFINITION of a schedule
point and we always want to swap, even if the current thread is
non-preemptible.
2. With similar symptoms: in k_yield() a previous fix correct the
queue handling for SMP, but it missed the case where a thread of
the SAME priority as _current was on the queue and would fail to
swap. Yielding must always add the current thread to the back of
the current priority.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
z_spin_lock_valid() reads shared variable twice to do two checkings. If
this variable is modified by other CPU between two read accesses, the
checking value is inconsistent. This inconsistency causes the error
that CPU0 can pass the checking when it doesn't hold spinlock because
zeroed-out thread_cpu value is ambiguous with the CPU0 ID.
Fix the inconsistency by only reading shared variable once and using
local variable value to do two checkings.
Fixes#19299.
Signed-off-by: Jim Shu <cwshu@andestech.com>
Values used in tests/drivers/pwm/pwm_api overflows calculation inside
xec_compute_dc(). Make calculation to be done in u64_t and then
convert to int.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Add support to LIS2MDL trigger, dynamic odr configuration as well as
temperature data reading.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Configure interrupt gpio information (irq-gpios) into the
x-nucleo-iks01a3 shield overlay file.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
LIS2MDL sensor has a fixed sensitivity equal to 1500 uGauss/LSB.
So, use a constant value directly.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Port the lis2mdl sensor driver on top of the lis2mdl_StdC
HAL interface (in modules/hal/st/sensor/stmemsc/).
Signed-off-by: Armando Visconti <armando.visconti@st.com>
On most targets, application flash size for no_optimization test
configuration is slightly higher than 128 Kbytes.
Updating requirement to the next upper flash size.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
These features are available only for SPIM3 and when they are enabled
but this instance is not, the compilation fails. So they cannot be
enabled by default (as currently), but only when it is actually needed
(and possible).
Update the module revision to fix the issue in nrfx_config_nrf52840.h.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This commit introduces separate "compatible" strings for DTS nodes
representing different types of Nordic SPI peripherals. Previously
"nordic,nrf-spi" was used for both SPI and SPIM. SPIS was already
handled separately.
Quite a few files need to be touched by this commit but the changes can
be divided into groups of related or very similar ones, distinguishable
by the initial part of the path to the modified file:
* dts/bindings/spi/
new binding for "nordic,nrf-spim" is added and common fields for all
3 types of Nordic SPI peripherals are extracted to a shared file
* dts/arm/nordic/
"compatible" properties in spiX nodes are updated (when there is no
choice as only one type of SPI peripheral is available) or replaced
with a comment pointing out that the proper type of peripheral needs
to be picked at some upper layer
* drivers/spi/
spi_nrfx_spim driver is updated with the new form of macros generated
from dts
* boards/
all spiX nodes in dts files for boards equipped with an nRF chip are
updated with the proper "compatible" property, according to the type
of SPI peripheral that is currently selected for the board by the
corresponding Kconfig choice option (SPI_x_NRF_SPI*)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This commit introduces separate "compatible" strings for dts nodes
representing different types of Nordic TWI peripherals. Previously
"nordic,nrf-i2c" was used for both TWI and TWIM, and TWIS was not
supported.
Quite a few files need to be touched by this commit but the changes can
be divided into groups of related or very similar ones, distinguishable
by the initial part of the path to the modified file:
* dts/bindings/i2c/
new bindings for "nordic,nrf-twim" and "nordic,nrf-twis" are added
and the one for "nordic,nrf-i2s" is renamed to "nordic,nrf-twi",
common fields for all these bindings are extracted to a shared file
* dts/arm/nordic/
"compatible" properties in i2cX nodes are updated (when there is no
choice as only one type of TWI peripheral is available) or replaced
with a comment pointing out that the proper type of peripheral needs
to be picked at some upper layer
* drivers/i2c/
both flavors of i2c_nrfx drivers are updated with the new names of
macros generated from dts
* boards/
all i2cX nodes in dts files for boards equipped with an nRF chip are
updated with the proper "compatible" property, according to the type
of TWI peripheral that is currently selected for the board by the
corresponding Kconfig choice option (I2C_x_NRF_TWI*)
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
For CMSIS compilation, we define __PROGRAM_START
to avoid compiling the bss/data initialization
routines provided by CMSIS.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Use the new 'compatible:' and 'include:' syntaxes, and clean it up like
for other bindings.
Shorten the description, because it appears in the output as a comment
above the generated macros, and it looks neater. I asked Mateusz what
kind of device it is.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Anas Nashif