There's no need to use APPLICATION level. In case of the IPM console
test, priorities have been adjusted to make sure sender/receiver are
initialized in the correct order.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
There's no need to use APPLICATION level. Also create a custom init
level that runs late in the process (depends e.g. on SPI which runs at
high priority level, 70).
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Convert the driver to a dt-based device. Also update Kconfig so that it
depends on the right compatible being enabled, initialize in POST_KERNEL
(APPLICATION should not be used for devices) and remove one redundant
include.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
The device model was not used for anything useful, only to call some
init code. Change to SYS_INIT instead.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Rework the can_dlc_to_bytes table lookup code in a way that allow the
compiler to guess the resulting output and somehow fix the build
warning:
zephyr/drivers/can/can_nxp_s32_canxl.c:757:9: warning:
'__builtin___memcpy_chk' forming offset [16, 71] is out of the bounds
[0, 16] of object 'frame' with type 'struct can_frame' [-Warray-bounds]
757 | memcpy(frame->data, msg_data.data, can_dlc_to_bytes(frame->dlc));
where the compiler detects that frame->data is 8 bytes long but
can_dlc_to_bytes could return more than that.
Can be reproduced with:
west build -p -b s32z270dc2_rtu1_r52 \
-T samples/net/sockets/can/sample.net.sockets.can.one_socket
Suggested-by: Martin Jäger <martin@libre.solar>
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This reverts commit 3127d7b54c which
was forgotten when switching back to breathe from docleaf and causing
unecessary "here's a warning about something that's not actually
a warning" :)
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Include the nrf peripheral kconfig definitions for all simulated
nrf boards, not just for the nrf52_bsim.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Doxygen gets confused by the macro expansion in
include/zephyr/xen/public/domctl.h as that is only defined if
CONFIG_ARM64=y, add a no-op expansion of that macro when building the
documention so it has something to work on.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
ESP32C3 LuatOS core is a dev board with esp32-c3.
It has similar functions to esp32c3 devkitm, but smaller in size.
Signed-off-by: YuLong Yao <feilongphone@gmail.com>
Instead of detecting that we are in a native/POSIX arch based
board by checking for each board specifically,
let checks for the architecture.
In that way other boards (like the upcoming nrf53_bsim ones)
will also work.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Introduce a helper function zephyr_nanopb_sources to generate
source files and add these to a target.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
This is the final step in making the `zephyr,memory-attr` property
actually useful.
The problem with the current implementation is that `zephyr,memory-attr`
is an enum type, this is making very difficult to use that to actually
describe the memory capabilities. The solution proposed in this PR is to
use the `zephyr,memory-attr` property as an OR-ed bitmask of memory
attributes.
With the change proposed in this PR it is possible in the DeviceTree to
mark the memory regions with a bitmask of attributes by using the
`zephyr,memory-attr` property. This property and the related memory
region can then be retrieved at run-time by leveraging a provided helper
library or the usual DT helpers.
The set of general attributes that can be specified in the property are
defined and explained in
`include/zephyr/dt-bindings/memory-attr/memory-attr.h` (the list can be
extended when needed).
For example, to mark a memory region in the DeviceTree as volatile,
non-cacheable, out-of-order:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_VOLATILE |
DT_MEM_NON_CACHEABLE |
DT_MEM_OOO )>;
};
The `zephyr,memory-attr` property can also be used to set
architecture-specific custom attributes that can be interpreted at run
time. This is leveraged, among other things, to create MPU regions out
of DeviceTree defined memory regions on ARM, for example:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-region = "NOCACHE_REGION";
zephyr,memory-attr = <( DT_ARM_MPU(ATTR_MPU_RAM_NOCACHE) )>;
};
See `include/zephyr/dt-bindings/memory-attr/memory-attr-mpu.h` to see
how an architecture can define its own special memory attributes (in
this case ARM MPU).
The property can also be used to set custom software-specific
attributes. For example we can think of marking a memory region as
available to be used for memory allocation (not yet implemented):
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_NON_CACHEABLE |
DT_MEM_SW_ALLOCATABLE )>;
};
Or maybe we can leverage the property to specify some alignment
requirements for the region:
mem: memory@10000000 {
compatible = "mmio-sram";
reg = <0x10000000 0x1000>;
zephyr,memory-attr = <( DT_MEM_CACHEABLE |
DT_MEM_SW_ALIGN(32) )>;
};
The conventional and recommended way to deal and manage with memory
regions marked with attributes is by using the provided `mem-attr`
helper library by enabling `CONFIG_MEM_ATTR` (or by using the usual DT
helpers).
When this option is enabled the list of memory regions and their
attributes are compiled in a user-accessible array and a set of
functions is made available that can be used to query, probe and act on
regions and attributes, see `include/zephyr/mem_mgmt/mem_attr.h`
Note that the `zephyr,memory-attr` property is only a descriptive
property of the capabilities of the associated memory region, but it
does not result in any actual setting for the memory to be set. The
user, code or subsystem willing to use this information to do some work
(for example creating an MPU region out of the property) must use either
the provided `mem-attr` library or the usual DeviceTree helpers to
perform the required work / setting.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Renesas rcar_h3ulcb_ca57 and rcar_salvator_xs_m3 boards support recently
was added to Zephyr mainline. Add Xen control domain guest support for
them via xen_dom0 snippet extention.
Note: please pay attetion to overlay nodes and comments in case of any
issues on your setup.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Zephyr snippets allow to apply pre-defined build configuration and
extentions to your build0. It is made by applying generic snippet
conf/device-tree changes and may be extended with platform-specific
files.
It looks like great approach for convertion Zephyr OS build to Xen
control domain on different boards, as it requires Kconfig changes
and board device tree changes (configuration for memory node, hypervisor
console, grant table region etc).
Please note, that Xen hypervisor passes all selected parameters via
domain device-tree, but Zephyr does not use it in runtime. So, user
should keep values in board overlays in sync with real Xen values.
Add example and docs for converting qemu_cortex_a53 board to Xen
Domain-0 guest. This approach might be used for other boards, where
Zephyr Dom0 is needed.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Add wrapper functions for Xen memory managment hypercall. They can be
used for unprivilaged Zephyr guest initialization and for domain
management, when Zephyr is used as Xen Domain 0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds possibility to call hypervisor HVM parameter functions
for specified domain (instead of only DOMID_SELF). It is needed for
configuring domains, that were created from Zephyr control domain.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Add Xen domctl API implementation for Zephyr as control domain.
Previously Zephyr OS was used as unprivileged Xen domain (Domain-U),
but it also can be used as lightweight Xen control domain (Domain-0).
To implement such fuctionality additional Xen interfaces are needed.
One of them is Xen domain controls (domctls) - it allows to create,
configure and manage Xen domains.
Also, used it as a possibility to update files copyright and licenses
identifiers in touched files.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Xen public headers are added to Zephyr kernel partially, so we need
to update them for new features implementation.
Further implementation of Xen domains configuration and memory
management requires dedicated Xen public headers inside Zephyr kernel.
It will be used for add Zephyr OS Xen Domain-0 funtionalities.
Update existent and add new required public headers from Xen 4.17.0
release.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
This commit adds interface for evtchn allocation that can be used by
privilaged domain. Domain 0 can specify both dom and remote_dom
parameters for hypercall, where in others domains dom should be always
DOMID_SELF. It is needed for creating pre-defined channels during
domain setup in Zephyr Dom0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
