In case of dualcore, STM32H7, STM32W and STM32MP1,
protect concurrent register write access with HSEM.
Done for following drivers:
clock_control, counter, flash, gpio, interrupt_controller
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Sample tries to estimate maximum number of messages that can be
logged. It was using two system cycles and counting number of
messages logged in that window. It did not take into account the
fact that clock frequency may vary and logging speed also varies
(especially if LOG_IMMEDIATE is enabled). Presented results may
be faulty and misleading.
Fix is attempting to adjust window size to increase precision of
the measurement.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Add the coding guidelines agreed upon by the project TSC with a
description of the staged approach needed to implement them
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When running CMake, then Python3 will be used.
This is detected through FindPython3, with a preference for using the
python or python3 in path, if any of those matches the required Python
minimal version in Zephyr.
It is also possible for users to specify a different Python, as example
by using:
`cmake -DPYTHON_PREFER=/usr/bin/python3.x`
However, when running `west` as native command, then west will be
invoked on linux based on the python defined in:
`west` launcher, which could be: `#!/usr/bin/python3.y`
Thus there could be mismatch in Pythons used for `west` and the python
used for other scripts.
This is even worse on windows, where a user might experience:
```
>.\opt\bin\Scripts\west.exe --version
Traceback (most recent call last):
File "C:\Python37\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
...
File "C:\Python37\lib\socket.py", line 49, in <module>
import _socket
ImportError: Module use of python38.dll conflicts with this version of
Python.
```
when testing out a newer Python, but the python in path is still a 3.7.
By importing `west` into zephyr_module.py and by using, as example
`python -c "from west.util import west_topdir; print(topdir())"`
we ensure the same python is used in all python scripts.
Also it allows the user to control the python to use for west.
It also ensures that the west version being tested, is also the version
being used, where old code would test the version imported by python,
but using the west in path (which could be a different version)
If the west version installed in the current Python, and west invocation
is using a different Python interpreter, then an additional help text
is printed, to easier assist users with debugging.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The generic SPI GPIO chip select support now respects devicetree flags
for signal active level. This pass DT information to driver instance to
ensure proper behavior.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
We only have one use of _binding_compat and it doesn't need self, so
just fold it into _init_compat2binding.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We deprecated a number of aspects of the DTS binding syntax in Zephyr
2.1. Remove the support for the deprecated syntax. Remove from docs
about the deprecated syntax as well.
Removed reference in release-notes-2.1.rst to legacy_binding_syntax
since that anchor doesn't exist anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
During inspection of the workqueue tests, I find out testing gaps.
Decided to add new test cases that can improve Zephyr OS testing
quality.
Added new test cases:
1. test_work_item_supplied_with_func
In docs described that work item supplied with a handler function,
prove that it works.
2. test_process_work_items_fifo
Test that system process work items in first-in, first-out manner.
3. test_sched_delayed_work_item
Verify that delayed work item processed after specific period of time
stated by user.
4. test_workqueue_max_number
Test the limit of number of workqueues created
5. test_cancel_processed_work_item Created test to increase branch
coverage.
Modified existing test cases:
1. test_work_submit_handler updated Doxygen tag, added more detailed
description"
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
Unit tests were failing to build because random header was included by
kernel_includes.h. The problem is that rand32.h includes a generated
file that is either not generated or not included when building unit
tests. Also, it is better to limit the scope of this file to where it is
used.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Create syscalls to make possible using random APIs from user mode
threads. These APIs can have different implementations, like using
entropy driver or Xoroshiro128. Some of these implementations also have
some globals to preserve state between calls.
Make it run entire in user space would require user adding these globals
to their memeory domains and/or grant access to entropy device. Syscalls
simplify its usage.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Add github worklow for sanitycheck tests to run sanitycheck
testsuite on any changes in sanitycheck, sanitylib or
scripts/tests/sanitycheck directory.
Signed-off-by: Aastha Grover <aastha.grover@intel.com>
According to our compliance checks, we have 'useless-suppression'
and 'unused-import' on our hands:
W0611: Unused CLoader imported from yaml as Loader
W0611: Unused Loader imported from yaml
I0021: Useless suppression of 'unsubscriptable-object'
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Since the i2c init structure is moved from config_info to the stack,
this change requires 12 bytes more stack during driver initialization.
This fixes#25255
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
() This is simply to clean up the code for cycles and timing
calculations as there are quite a bit of unnecessary AND
operations.
() This also moves the cycle calculation closer to the print
statement as a few calculations were done between grabbing
counter values.
() PRINT_STATS() now takes only two parameters as the third
one was always calling CYCLES_TO_NS(2nd) anyway.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The on-board sensor has a enable pin that must be pulled
high in order to power the sensor.
Since no i2c sensor connected to ENV_I2C is supported by zephyr yet,
changed the pins of i2c1 to be connected to CCS811_I2C pins.
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
wifi-reset-gpios flags were not respected so far. This means that
setting reset as active low (which is required in most cases for ESP
modules/chips) was done inside esp driver with inverted logic. Use dts
flags instead, so "active low" property is configured the same way as
for other drivers (i.e. in device-tree instead of driver).
This change also allows to configure reset as active high, in case where
ESP's nRST signal is somehow inverted on the board (behaving as RST
signal instead).
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Add template for hardware support to properly label those requests and
distinguish them from other feature requests.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Now that kconfigfunctions.py is loading the EDT object from a pickle
file, I can't find any other reads of the environment variables it was
previously using to do that.
(The CMake variables with the same names are read in different places;
I'm specifically talking about environment variables here.)
Remove the dead stores.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This saves time and avoids the need to pass additional state around in
the environment to recreate the edt exactly.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We need to save and restore the devicetree data to generate optimized
dependency information later on in the build, in particular during the
final application link.
Make this happen by pickling the EDT object in BUILD_DIR/edt.pickle.
The existence of this file is an implementation detail, so do not add
it to the documentation.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
We have a use case for saving the EDT object to be able to open it up
again later. It would be convenient to be able to do this with the
pickle module from stdlib.
The only thing stopping us from doing that appears to be the open
reference to sys.stderr that's held the edt object even after
EDT.__init__ exits. However, there doesn't seem to be a need to keep
holding on to this object, and in fact it would be a little bit nicer
to drop the reference in case something else (even in the same Python
process that created it originally) wants the EDT object around, but
might want the warn file closed if its refcount zeroes out.
Just drop the reference at the end of __init__ and make EDT._warn()
throw an exception if it's attempted to be used after the constructor
exits.
Make pickle-ability an API guarantee so we can treat any regressions
as bugs going forward.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
I can't see a good reason to be doing this in the Node class's
unit_addr accessor. Move it up to the edtlib initialization so it only
happens once.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Use the C LibYAML parser if available, rather than the Python parser. It
is much faster.
This is a clean and rebased version of PR #20210 by
Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Co-authored-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Include the files that provide the types and macros used by the
header. Ensure that all declarations use C language linkage when
included from a file using C++.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
C99 designated array initializers are not part of the C++ language,
and are not supported in GNU G++. Replace their use with invocations
of the Zephyr listify macro utility, with ancillary helper functions.
Also fix the initialization order to match declaration order (which
C++ also requires).
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
C++ requires that designated initializers be provided in declaration
order. Fix the macros that violate this requirement.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
compatible = "arm,cortex-m33f" was already used for some time
(lpc55S6x, nrf9160...) without any related bindings.
Every works fine until you need to access one CPU node property
(eg. clock-frequency)...
Signed-off-by: Arnaud Mouiche <arnaud.mouiche@invoxia.com>
In nRF9160 and application core in nRF5340, not all interrupts with
highest numbers are implemented. Thus, limit the number of interrupts
reported to the test, so that it does not try to use some unavailable
ones.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The page table initialization needs a populated PCI MMIO
configuration, and that is lazy-evaluated. We aren't guaranteed that
a driver already hit that path, so be sure to call it explicitly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The firmware on existing devices uses HPET timer zero for its own
purposes, and leaves it alive with interrupts enabled. The Zephyr
driver now knows how to recover from this state with fuller
initialization, but that's not enough to fix the inherent race:
The timer can fire BEFORE the driver initialization happens (and does,
with certain versions of the EFI shell), thus flagging an interrupt to
what Zephyr sees as a garbage vector. The OS can't fix this on its
own, the EFI bootloader (which is running with interrupts enabled as
part of the EFI environment) has to do it. Here we can know that our
setting got there in time and didn't result in a stale interrupt flag
in the APIC waiting to blow up when interrupts get enabled.
Note: this is really just a workaround. It assumes the hardware has
an HPET with a standard address. Ideally we'd be able to build zefi
using Zephyr kconfig and devicetree values and predicate the HPET
reset on the correct configuraiton.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Right now x86_64 doesn't install handlers for vectors that aren't
populated by Zephyr code. Add a tiny spurious interrupt handler that
logs the error and triggers a fatal error, like other platforms do.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This patch is almost entirely aesthetics, designed to isolate the
variant configurations to a simple macro API (just IN/OUT), reduce
complexity derived from code pasted out of the larger ns16550 driver,
and keep the complexity out of the (very simple!) core code. Useful
when hacking on the driver in contexts where it isn't working yet.
The sole behavioral change here is that I've removed the runtime
printk hook installation in favor of defining an
arch_printk_char_out() function which overrides the weak-linked
default (that is, we don't need to install a hook, we can be the
default hook at startup).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Various cleanups to the x86 early serial driver, mostly with the goal
of simplifying its deployment during board bringup (which is really
the only reason it exists in the first place):
+ Configure it =y by default. While there are surely constrained
environments that will want to disable it, this is a TINY driver,
and it serves a very important role for niche tasks. It should be
built always to make sure it works everywhere.
+ Decouple from devicetree as much as possible. This code HAS to work
during board bringup, often with configurations cribbed from other
machines, before proper configuration gets written. Experimentally,
devicetree errors tend to be easy to make, and without a working
console impossible to diagnose. Specify the device via integer
constants in soc.h (in the case of IOPORT access, we already had
such a symbol) so that the path from what the developer intends to
what the code executes is as short and obvious as possible.
Unfortunately I'm not allowed to remove devicetree entirely here,
but at least a developer adding a new platform will be able to
override it in an obvious way instead of banging blindly on the
other side of a DTS compiler.
+ Don't try to probe the PCI device by ID to "verify". While this
sounds like a good idea, in practice it's just an extra thing to get
wrong. If we bail on our early console because someone (yes, that's
me) got the bus/device/function right but typoed the VID/DID
numbers, we're doing no one any favors.
+ Remove the word-sized-I/O feature. This is a x86 driver for a PCI
device. No known PC hardware requires that UART register access be
done in dword units (in fact doing so would be a violation of the
PCI specifciation as I understand it). It looks to have been cut
and pasted from the ns16550 driver, remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
PCI devices on 64 bit systems can be mapped anywhere, not just in the
lower 4G of memory. Remove pointer size assumptions.
Also this removes the use of a struct uart_device_config to store the
(runtime) BAR address. That struct has other stuff in it, and the
only thing we need is the single MMIO address. It's also REALLY
confusing to have two "devconf" fields in the device storing values of
the same struct type, some fields of which are used from one of them
but some from the other!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The PCI API was originally limited to 32 bit addresses. Even though
it had code to skip over the high word in 64 bit BAR entries, it
refused to use it and returned a 32 bit value. Some devices in the
wild have default mappings from the firmware for devices above 4G.
Also remove the "iobar" API. It's dead code, we don't call it and we
don't test it. IO space BAR entries are a legacy feature from way,
way back in PCI history (I genuinely have never heard of a real device
that uses them!). And there's no difference in format between one of
these and a 32 bit "memory" BAR anyway, someone who actually had this
requirement could just use the existing API without worry.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Alexandre Bourdiol