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>
The mm_reg_t type used to represent a MMIO address (e.g. in the
sys_write*() APIs) was defined to a uint32_t, which is obviously wrong
on 64 bit systems where devices can be mapped anywhere.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The default page table (the architecturally required one used for
entrance to long mode, before the OS page tables get assembled) was
mapping the first 4G of memory.
Extend this to 512G by fully populating the second level page table.
We have devices now (up_squared) which have real RAM mapped above 4G.
There's really no good reason not to do this, the page is present
always anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When checking the absolute value of cycles set to the comparator
use the MAX_CYCLES instead of MAX_TICKS.
The commit changes function names and comments to make it clear
where ticks (system ticks) and where RTC cycles are used.
Fixes#26701
Signed-off-by: Pawel Dunaj <pawel.dunaj@nordicsemi.no>
Several peripherals are non-functional in the ENG_A revision
of nRF5340 (Application MCU) so we delete the corresponding
DTS nodes in the device description.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When building for nRF5340 Application MCU we need to properly
select which are the default GPIO port/pins for UARTE on the
Network MCU (so we allocate them to Network MCU). These depend
on the actual version of the board we are using (PDK or DK) so
this commit implements the corresponding conditional logic.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
When building for nRF5340 PDK board, enable Kconfig option
for Erratum 19. Do not enable when building on nRF5340 DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We rename the nRF5340 board directory to
nrf5340dk_nrf5340 since this will be now
containing board definitions for both the
nRF5340 PDK and DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Refactor the common Kconfig and build files of nRF5340
board definition to enable building for either nRF5340
PDK or DK.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We do not need to have the nrf5340pdk_ prefix in the
partition configuration and sram planning files for
nrf5340 platforms because these files may be common
for any nrf5340 board variant. Also, we do not need
it in the common .dts header for the Application MCU.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Rename the nRF5340 QKAA variant .dtsi headers (Application
MCU) by adding an Engineering A (Eng A) suffix. This is done
to indicate that the headers should be explicitly used when
building for a board that contains the Engineeering A nrf5340
SoC variant.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We need to use CPUAPP and CPUNET instead of CPU0 and CPU1
terminology, because those terms are the ones used
throughout the DeviceTree definitions for nRF5340 SoC.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Move the definition of the number of MPU regions
(num-mpu-regions) in a SoC variant-specific header
instead of the common .dtsi for nRF5340 Application
MCU. This allows us to define different SoC variants
with different number of MPU regions available.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit renames the nrf5340_cpuapp_common.dtsi header
to nrf5340_cpuapp_peripherals.dtsi. This name is more
appropriate, as the header contains DT definitions for
peripherals, accessible from either Secure or Non-secure
execution environment (i.e. not accessible exclusively
by Secure or Non-Secure).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
We do not need to list the SoC compatibles in the
PDK node definition, this was accidentally left out.
Removing it in this commit.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Reverse the order of these checks because invalid PDU type will
never be expected. If PDU type is invalid we should respond with
error 0x0002 - Invalid format.
Signed-off-by: Michał Narajowski <michal.narajowski@codecoup.pl>
Since Python 2 is already EOL, Linux distributions are starting
to drop support for Python 2. For example, on Ubuntu 20.04,
"python" is no longer available. This breaks the bootstrap
and autogen.sh as they are both default to executing "python".
Fix this by setting the PYTHON environment variable before
building so both scripts will use python3 instead.
Also update git checkout to grab the official 2.04 release.
Fixes#25398
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Security documentation contains a code guideline section that is more
about security principles than code guidelines itself. Just removing
the mention do code guideline to avoid possible confusions with
upcoming project code guideline based on MISRA-C.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Configuration file was left unchanged after development
of USB Audio class. Deleted configs should never be present.
Signed-off-by: Emil Obalski <emil.obalski@nordicsemi.no>
Recent changes to struct _timeout changed the declaration order to
avoid alignment padding. While this has no effect to C99 code C++
requires that designated initializes appear in declaration order.
Update the initializer macro so it can be used in C++ code.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Deal with qemu crashes and do not register pass status as the default.
In case we do not have a status, report unknown.
This now captures different states from qemu that were not captured
before.
Fixes#26679
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
With native_posix, a flash.bin file is created when running the tests.
If the tests are re-run, they fail since the flash is no-longer erased.
Before running the tests, erase the flash so that the 'read' test can
work regardless of the previous state.
Fixes: 25171
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple test for this command to check that the output is as
expected.
This requires a larger output buffer in shell_dummy, so update that
too.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is annoying to read just a single word at a time. Update this
command to print any amount of data. This uses byte format at present.
We could perhaps support something like:
flash read.8
flash read.16
flash read.32
to chose the size.
Example output (with line breaks to keep within git-style limit):
$ flash read FLASH_CTRL 0 20
00000000: 20 25 00 20 1d 26 00 08 69 68 00 08 45 26 00 08
| %. .&.. ih..E&..|
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|........ ........|
Signed-off-by: Simon Glass <sjg@chromium.org>
