sanitycheck is opening an insane number of file descriptors
simultaneously as it opens up communication pipes with
every test that supports emulation, on every emulated
board target.
Increase the resource limit on open files until this code
can be properly refactored.
Workaround for: #17239
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Add support to STM LSM6DSO 6-axis IMU sensor driver.
This driver supports communication with device though both
I2C and SPI bus and both polling and drdy trigger mode.
This driver supports also the sensorhub mode with the possibility
to connect a maximum of two external devices, typically a
magnetometer and an environmental sensor, currently selected among
following devices: lis2mdl magnetometer, lps22hh or lps22hb
pressure and temperature sensors, HTS221 humidity sensor.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Add support to STM LPS22HH pressure and temperature sensor.
The driver support I2C and SPI bus communication and both
polling and drdy trigger mode.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
OpenThread did not verify if the interface provided in the net_mgmt
handler is actually an OpenThread interface. In result, when multiple
network interfaces were used, different interfaces were processed by the
OpenThread handler, ending up in a crash.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This was dumping coverage before the test code even ran.
Ideally, this gets re-written to use ztest, but meanwhile
place a dummy main thread which sleeps forever, and dump
coverage once the test succeeds.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These empty functions needed to be declared static inline
or we get build errors if the header is included by more
than one C file.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Make sure the IPv4 and IPv6 socket addresses are initialized before
copying them. This avoids uninitialized memory access.
Coverity-CID: 199436
Fixes#17202
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The network interface events should be in L2 layer so there
is no one that would emit L1 events so no need for it.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The zephyr_stdint.h file enforces Zephyr specific policies on the
compilation environment. Let's give compilers a chance to provide
definitions of their own via TOOLCHAIN_C_FLAGS prior the inclusion
of zephyr_stdint.h.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Commit f57ba2d30c ("cmake: toolchain_cc_imacros: don't use space
separated arguments") moved toolchain_cc_imacros() to using the long
argument format in order to avoid spaces that CMake uses to delimitate
and deduplicate arguments.
It seems that xcc doesn't support the --imacros=foo form. However
it does support the short "combined" -imacrosfoo form (without space).
So let's use that instead and document the caviat.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
If user has set CONFIG_NET_CONTEXT_TIMESTAMP then enable
network packet throughput collection for UDP packets.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This can be used to activate the network packet statistics
collection. Note that we do not have resources to calculate
each network packet transit times but we collect average times
instead.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Finalize the CONFIG_NET_CONTEXT_TIMESTAMP support that was started
earlier but never properly finished. We collect network statistics for
TX packet network stack throughput time from when the net_context_send
is called and when the net_pkt was sent out successfully by the network
device driver.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Adds coverage for the uncovered json_calc_encoded_len()
and covers a bunch more error cases.
This gets us up to 90.1% line coverage and 100% function
coverage.
Fixes: #16944
Partial fix for: #16011
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- The --gcov-tool argument now has a reasonable default
if the Zephyr SDK is in use.
- --coverage-platform, if unspecified, defaults to what
was passed to --platform
- --coverage implies --enable-slow, so that tests with
the 'slow' tag are built and run.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The current CMSIS v2 implementation is clearly assuming that timeout
arguments being passed to e.g. osDelay() are in units of Zephyr ticks,
not milliseconds as specified by ARM or (inconsistently) assumed by
our test code.
Most tests work with the ~100 Hz default tick rate, but they tend to
fail on precision issues at higher tick rates. Force the CMSIS v2
applications to be 1000 Hz for now as a workaround, and detect the
mismatch as a build failure.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume that k_busy_wait() and CMSIS
osKernelSysTick() (which is just k_cycle_get_32()) were perfectly
synchronized. On nRF, they aren't (one is the 32 kHz RTC timer, the
other is a calibrated spin loop using the CPU frequency).
When ticks were being reported at 100 Hz granularity, there wasn't
enough precision to detect the mismatch. Now there is. Rework the
test to require that the clocks match to within 1%.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test seems a little confused. It does a POSIX usleep() for 90ms,
then checks the time taken, and verifies that it was no less
than... 91ms!
On existing platforms, tick alignment makes sure that we always take a
little longer, so this passes. But on high tick rate configurations we
get it exactly right. And fail.
Adjust the calibration to allow (exactly) 90ms sleeps. Also fixed a
comment that described the wrong units.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to properly align its millisecond-measured wait
time and assumed that there would be no other overhead. In fact on
fast tick rate systems (or even ones where the alignment computation
doesn't provide the needed padding as "slop") that's not quite enough
time to complete the full test. There are cycles between the sleep
calls that need to be accounted for, and aren't.
Just give it one extra work item of time before failing. We aren't
testing work queue timing precision here, just evaluation semantics.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
"50" ticks is fine with 100 Hz timer precision but way too short to
survive the conversion to milliseconds on fast, non-decimal tick
rates. Make it half a second, which was the original intent.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test was written to assume ~100 Hz ticks in ways that are
difficult to fix. It wants to sleep for periods on the order of the
TICKLESS_IDLE_THRESH kconfig, which is extremely small on high tick
rate systems and (on nRF in particular) does not have a cleanly
divisible representation in milliseconds.
Fixing precision issues by cranking the idle threshold up on a
per-system basis seems like an abuse, as that is what we want to be
testing in the first place. Just let the test run at the tick rate it
has always expected.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The logic about minimal sleep sizes due to "tick" aliasing was
correct, but drivers also have similar behavior with "cycle" aliasing
too. When cycles are 3-4 orders of magnitude faster than ticks, it's
undetectable noise. But now on nRF they're exactly the same and we
need to correct for that, essentially doubling the number of ticks a
usleep() might wait for.
The logic here was simply too strict, basically. Fast tick rates
can't guarantee what the test promised.
Note that this relaxes the test bounds on the other side of the
equation too: it's no longer an error to usleep() for only one tick
(i.e. an improved sleep/timeout implementation no longer gets detected
as a test failure).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The scheduler API has always allowed setting a zero slice size as a
way to disable timeslicing. But the workaround introduced for
CONFIG_SWAP_NONATOMIC forgot that convention, and was calling
reset_time_slice() with that zero value (i.e. requesting an immediate
interrupt) in circumstances where z_swap() had been interrupted
nonatomically.
In practice, this never happened. And if it did, it was a single
spurious no-op interrupt that no one cared about. Until it did,
anyway...
Now that ticks on nRF devices are at full 32 kHz speed, we can get
into a situation where the rapidly triggering timeslice interrupts are
interrupting z_swap() calls, and the process feeds back on itself and
becomes self-sustaining.
Put that test into the time slice code itself to prevent this kind of
mistake in the future.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The default tick rate is now 10 kHz, but that driver was demanding
that it be exactly 1 kHz instead of at least that rate. I checked the
source, and the driver isn't actually extracting "ticks" from the
kernel illegally, it just needs fine-grained timers that work with the
existing millisecond API. Let it build, this is fine.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The sleep test was checking that the sleep took no longer than "2
ticks" longer than requested. But "2 ticks" for fast tick rate
configurations can be "zero ms", and for aliasing reasons it's always
possible to delay for 1 unit more than requested (becuase you can
cross a millisecond/tick/whatever boundary in your own code on either
side of the sleep). So that "slop" value needs to be no less than
1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The test for the k_uptime_delta utilities was calling it in a loop and
waiting for the uptime to advance. But the code was specifically
wanting it to advance 5ms or more at one go, which clearly isn't going
to work for a tick rate above 200 Hz.
The weird thing is that the test knew this and even commented about
the limitation. Which seems silly: it's perfectly fine for the clock
to advance just a single millisecond. That's correct behavior too.
Let's test for that, and it will work everywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When ticks are sub-millisecond, the math produces minimum and maximum
values for the slice duration test that are equal. But because of
aliasing across tick boundaries, it's always possible (for any time
period, nothing specific to time slicing here) to measure one tick
more than an intended duration. So make sure there's always at least
a range of 1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
As with the STM32 boards, these had an existing default for tick rate
that is now lower than the 10 kHz default. They're SysTick devices
that can handle the higher rate just fine. Use that.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The nRF timer runs at only 32 kHz, so there's little reason to try to
divide it to get a synthesized tick rate. Just use the raw clock as
the tick rate, which provides maximal precision and very
singnificantly simplifies the generated code for the ISR.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The ARC timer is a MHz-scale cycle counter and works very well with
the new 10 kHz default tick rate. Remove the settings for ARC
hardware.
Note that the nsim board definitions are left at 100 Hz. That is a
software emulation environment that (like qemu) exposes the host clock
as "real" time and thus is subject to clock jitter due to host
scheduling.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These all have what appears to be a promiscuously cut-and-pasted
declaration for a 1000 Hz tick rate. They are all SysTick boards and
will work very well with the new 10 kHz default, so use that instead.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When tickless is available, all existing devices can handle much
higher timing precision than 10ms. A 10kHz default seems acceptable
without introducing too much range limitation (rollover for a signed
time delta will happen at 2.5 days). Leave the 100 Hz default in
place for ticked configurations, as those are going to be special
purpose usages where the user probably actually cares about interrupt
rate.
Note that the defaulting logic interacts with an obscure trick:
setting the tick rate to zero would indicate "no clock exists" to the
configuration (some platforms use this to drop code from the build).
But now that becomes a kconfig cycle, so to break it we expose
CONFIG_SYS_CLOCK_EXISTS as an app-defined tunable and not a derived
value from the tick rate. Only one test actually did this.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Tick rate is becoming a platform tunable in the tickless world. Some
apps were setting it due to requirements of drivers or subsystems (or
sometimes for reasons that don't make much sense), but the dependency
goes the other way around now: board/soc/arch level code is
responsible for setting tick rates that work with their devices.
A few tests still use hard-configured tick rates, as they have
baked-in assumptions (like e.g. "a tick will be longer than a
millisecond") that need to be addressed first.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This code was clearly written to assume that the timeout argument to
k_mem_pool_alloc() was in ticks and not ms. Adjust to what appears to
have been the intent. It was working as intended (i.e waiting one or
1/10th of a second) only on systems where the default tick rate was
100 Hz.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When the tick rate was less than MIN_DELAY, bumping a "too soon"
expiration by just one tick may not be enough and we could
theoretically miss the counter.
Instead, eliminate the MIN_DELAY computation and write to the spec:
NRF guarantees that the RTC will generate an interrupt for a
comparator value two cycles in the future. And further, we can test
at the set point to see if we "just missed" the interrupt (i.e. zero
cycles delay) and flag a synchronous interrupt. So we only need to
miss a requested interrupt now for the special case of exactly one
cycle in the future, and then we're only late by one cycle. That's
optimal.
Also fixes an off-by-one in the next cycle computation. By API
convention, an ticks argument of one or less means "at the next tick"
and not "right now". So we need to add one to the target cycle to
avoid incorrectly triggering a synchronous interrupt. This was a
non-issue when a tick is longer than a hardware cycle but is needed
now.
Also handles the edge case with zero latency interrupts (which are
unmaskable) which might mess up timing. This was always a problem,
but we're more sensitive now and it's comparatively more likely to
occur.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We have a number of timing sensitive tests which run
correctly on a much more frequent basis if the system
is not so heavily loaded. Instead of squeezing a few
more crumbs of performance by doubling the CPU count,
just use the number of CPUs reported by the system.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
* if thread switchs in interrupt, the target sp must be in
thread's kernel stack, no need to do hardware sp switch
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
If maxsize is smaller than _MPOOL_MINBLK, then Z_MPOOL_LVLS() will be 0.
That means the loop in z_sys_mem_pool_base_init() that initializes the
block free list for the nonexistent level 0 will corrupt whatever memory
at the location the zero-sized struct sys_mem_pool_lvl array was
located. And the corruption happens to be done with a perfectly legit
memory pool block address which makes for really nasty bugs to solve.
This is more likely on 64-bit systems due to _MPOOL_MINBLK being twice
the size of 32-bit systems.
Let's prevent that with a build-time assertion on maxsize when defining
a memory pool, and adjust the affected test accordingly.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The "bits" field in struct sys_mem_pool_lvl is unioned with a pointer.
That leaves more space for inline free bits on 64-bit targets.
Let's declare it as an array and adjust its size based on the pointer
size. On 32-bit targets the generated code remains identical.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Minimum alignment and rounding must be done on a word boundary. Let's
replace _ALIGN4() with WB_UP() which is equivalent on 32-bit targets,
and 64-bit aware.
Also enforce a minimal alignment on the memory pool. This is making
a difference mostly on64-bit targets where the widely used 4-byte
alignment is not sufficient.
The _ALIGN4() macro has no users left so it is removed.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
