the RT685 contains an additional flexcomm peripheral, that supports
only I2C. This commit adds this peripheral to the device tree,
and enables pins and clocks for flexcomm15.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
There is currently no information available about the XIP
addresses for the nRF52840 and nRF5340.
Add this via a new 'reg' block in the relevant QSPI nodes, along with
names for the register blocks so they are easier to retrieve.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Recently we started to use Parasoft Codescan Static Analysis tool
to fix MISRA violations and align code to follow our Coding Guidelines.
I started fixing violations, and adding suppression tages to fix
false-positive findings. Developers started to ask me, what I'm doing
here and where is the documentation page about that.
Add a new section describing violations fixing process using Parasoft
tool.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
Catch up on the CAN driver API argument naming changes:
- Unify naming of callback function pointers as "callback".
- Unify naming of user-specified callback function arguments as
"user_data".
- Instances and pointers to struct zcan_frame are named "frame",
not "msg", to avoid confusion with the CAN message queue support.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Improve the CAN driver API documentation:
- Reorder API declarations and organize them into logical groups.
- Add doxygen strings where missing.
- Improve and unify wording of existing doxygen strings.
- Unify naming of callback function pointers as "callback".
- Unify naming of user-specified callback function arguments as
"user_data".
- Instances and pointers to struct zcan_frame are named "frame",
not "msg", to avoid confusion with the CAN message queue support.
- Check for __DOXYGEN__ to include documentation for optional APIs in
the documentation.
- Use "@cond INTERNAL_HIDDEN" to hide internal API details such as padding.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Reflect the removal of BOARD.dts.pre.tmp in favor of zephyr.dts.pre in
SVG diagrams. Clean up adjacent text.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This causes any devicetree error messages to refer to the source files
which contain the errors instead of intermediate <BOARD>.dts.pre.tmp
files in the build directory.
Do this using a new python-devicetree feature which can correctly
handle cpp's generated line marker directives.
To use this feature, rework the way that the C preprocessor is run on
devicetree inputs so that line marker directives are preserved by
removing the -P option.
This is a backwards incompatible change to the way the generated files
in the build directory used to work, as not all tools can consume line
markers. In particular, dtc can't handle these lines. We therefore
pass dtc zephyr.dts instead (the final parsed devicetree output from
python-devicetree).
Since <BOARD>.dts.pre.tmp is a publicly documented file, this is
changing existing behavior, so use a new file name for the
intermediate files to make it more obvious that something changed. In
particular, use zephyr.dts.pre instead of <BOARD>.dts.pre.tmp.
(The $BOARD.dts.pre.tmp name is a little cumbersome anyway.)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Curently, any and all devicetree syntax errors are being handled by
dtc, because it runs before gen_defines.py. This means that any
improvements we make to devicetree error handling and reporting in
dtlib or edtlib will never be noticed by users that have dtc
installed.
(This also has the unfortunate effect of hiding dtlib error reporting
from me, since my systems all have dtc installed.)
Move dtc to after gen_defines.py, so that initial error handling and
warnings all come from python. If DTC has some additional warnings or
errors to report, let them come last. They will still halt the build
if anything is wrong.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Don't let a malformed devicetree escape as a DTError. Wrap it in an
EDTError instead, so callers can just rely on the edtlib APIs as is
generally expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
A GCC linemarker of the form:
# 1 "filename" 2 3 4
or so is not currently being handled, because the current regular
expression assumes the "flags" values (the numbers after "filename")
are limited to a single value. Tweak the regular expression to allow
for up to 4 flags, which is what GCC documents it may emit:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/cpp/Preprocessor-Output.html
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit updates list of supported Xen VM fetures after
implementation of Xen Enlighten, event channels and interrupt-driven
UART API for Xen hypervisor console driver.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds Xen consoleio serial driver. It is needed to receive
kernel messages from Zephyr in case it runs as Xen privileged domain
(Dom0). There is no console ring buffer for such domain, so regular
uart_hvc_xen driver can not be used (privileged domain input/output
are possible only through consoleio interface).
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds support of interrupt-driven API for UART-like Xen PV
console driver. It is implemented via Xen event channels. It allows to
send and receive data by chunks (not single symbols) and without
polling.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds support of Xen Enlighten page and initial support for
Xen event channels. It is needed for future Xen PV drivers
implementation.
Now enlighten page is mapped to the prepared memory area on
PRE_KERNEL_1 stage. In case of success event channel logic gets
inited and can be used ASAP after Zephyr start. Current implementation
allows to use only pre-defined event channels (PV console/XenBus) and
works only in single CPU mode (without VCPUOP_register_vcpu_info).
Event channel allocation will be implemented in future versions.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
There is some legacy code that tries to mask IDC interrupts when
starting up cores. This is there because the IDC interrupt is both
the system IPI when Zephyr is running (and can thus be signaled
asynchronously to the code calling arch_start_cpu()) and the messaging
protocol to the boot ROM on the other CPU. So the idea is that we
mask interrupts after startup so nothing is confused.
But that's needless in the current architecture. We maintain a
synchronized cpus_active[] record that will show true/active for any
CPU between the end of its SMP startup sequence and the beginning of
the shutdown process in soc_halt_cpu(), and false at all other times.
An IPI will never be sent to a CPU that is running in the boot ROM,
because such a CPU will be flagged as inactive. Likewise a ROM
startup IDC will never be sent to a CPU running Zephyr code for the
converse reason. Remove all that code.
Unfortunately SOF itself still needs an interrupt unmask step at CPU
startup, because it's still doing its own masking (probably according
to the same algorithm that we imported). Leave that in place as a
minimal workaround until we get that fixed upstream.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Investigation by Kai Vehmanen has shown that there is a very short
delay needed before starting the secondary core on cAVS 1.5 hardware.
What we finally realized is happening is that on these devices,
secondary core power is managed by the host. The cavs-fw.py test
integration powers the second core on at system startup and lets
Zephyr start it later, but SOF will power it up and send an IPC to the
firmware immediately.
There is a period after power-up but before the ROM is available
(unclear whether this is a race vs. hardware, the ROM firmware, or the
kernel driver, or potentially some combination); interrupts latched
earlier than that seem to be cleared by CPU initialization.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These registers were defined in the new interface, but still being
used with bare bits (and in one spot a legacy field access macro).
Clean things up and use macros pervasively. To be fair: in this
particular case the field names aren't particularly descriptive...
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The usage of this interface is correct, but the docs in the header
spoonerized the source and destination of masking in the INTCTL
registers. Oops.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Put the initial stack in (slow) IMR memory instead of HP-SRAM. Very
little happens on this stack anyway before Zephyr switches off to the
interrupt stack and/or main thread. And this will allow us to start
running stackful C code much earlier in the boot process.
This puts the stack into the region of memory immediately below the
IMR image (because that edge of the image is easier to detect in
code). On all current platforms, that's offset quite a bit into IMR
space and leaves plenty of room. But we should have some kind
architectural way to reserve this space...
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The memory layout for the boot loader was needlessly complicated, with
separate fixed regions defined at fixed addresses, all in a file that
needs to be contiguous and DMA'd from the host in a single block. The
end result was a lot of magic numbers and wasted space.
Clean things up so that it links in a single region expressed (for the
benefit of rimage, I think) as a single program header in the ELF
file.
This is in preparation for further changes to unify the bootloader
stage with the main Zephyr image in a single link.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This board, whose hardware is just a cAVS 1.8 device without an x86
host CPU, started life (as all the cAVS devices did) as a
cut-and-pasted copy of the same basic code.
Because of hardware and schedule limitations, it didn't get the same
unification treatment that all the other platforms did. But it turns
out that in SMP configurations (which... it's not clear if we actually
test on hardware?) it wants to use the cavs_timer driver, which now
uses the new SOC API and not the old one. Which s1000 doesn't expose.
So... I guess we have to continue to cut and paste until we can find
time to unify this. Add a copy of the new shim/IDC headers to this
SOC and expose them via devivcetree.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Zephyr will try to run the `zephyr.elf` file by default. This is
problematic for any `..._ns` target, as they all need to boot through
[mcuboot and] TF-M. They simply hardfault without the rest of their
system image.
This corrects the `west build -t run ...` for the `mps3_an547_ns`
board, as it now has special treatment.
Signed-off-by: Jimmy Brisson <jimmy.brisson@linaro.org>
In #40140, all on-chip gpios where made to use `CONFIG_GPIO_INIT_PRIORITY`.
The lmp90xxx and sx1509b are off-chip gpios. This commit reverts those
changes for these two devices.
Signed-off-by: Ryan McClelland <ryanmcclelland@fb.com>
This commit reworks the CMOS test to a generic seconds
counter test.
And it adds a test case for the iMX RT1064 SNVS RTC.
Tested with mimxrt1064_evk
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Adds a driver using the SNVS high power and optionally low power
RTC instances. A device specific function `mcux_snvs_rtc_set` is
provided to update the current counter value.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Update the SPI context during all transceive functions. This fixes a
deadlock where SPI transactions failed to give back the semaphore.
Verified on NPCX9 based Chromebook.
Signed-off-by: Keith Short <keithshort@google.com>
Update the configuration file to use BT_FILTER_ACCEPT_LIST
instead of the deprecated BT_WHITELIST.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The internal functions of this driver needed either `device *`
or `st7789v_data *` as argument. Standardize to
using `device *`.
Signed-off-by: Casper Meijn <casper@meijn.net>
Remove mention to DT_DRV_COMPAT in brief since DT_FOREACH_STATUS_OKAY
is not relying on it and is taking "compat" as argument.
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
RT11xx USDHC lacks some watermarking features that RT10xx SOCs include.
Place #ifdef guards around these features.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
RT11xx SOC definitions did not enable USDHC controller. Select Kconfig
symbols required to enable it.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
GPIO10 was missing from RT11xx DTS, and is required to manage SD card
power. Enable this GPIO.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
