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>
Xen-related Kconfig options were highly dependand on BOARD/SOC xenvm.
It is not correct because Xen support may be used on any board and SoC.
So, Kconfig structure was refactored, now CONFIG_XEN is located in
arch/ directory (same as in Linux kernel) and can be selected for
any Cortex-A arm64 setup (no other platforms are currently supported).
Also remove confusion in Domain 0 naming: Domain-0, initial domain,
Dom0, privileged domain etc. Now all options related to Xen Domain 0
will be controlled by CONFIG_XEN_DOM0.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Add yaml file for 'xen,xen', because without it an appropriate
'CONFIG_DT_HAS_XEN_XEN_ENABLED' isn't generated.
It will be used for checking Xen support on current setup, instead of
checking if it is BOARD/SOC "xenvm" (which is not correct for Domain-0
configurations).
Remove xen,xen-4.15.yaml at all, because it isn't necessary to have
yaml for some specific Xen version.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Zephyr device and device.pm tests uses device tree fragments applied
to main board device trees. For xenvm they have conflicting
address/size cells definition with board DT. It leads to CI and test
issues during build (xenvm has 0x2 cells, tests have 0x1).
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Move memory mapping of Xen node to Grant Table driver system init
function. After moving mapping we don't need anymore records of
xen-xen node into 'mmu_regions' array, so they were deleted from
all SoCs: Rcar Gen3/Gen4 and XenVM.
We need at least 16M of virtual address space to map memory of Xen
node, so the virtual memory sized has been increased to 32 MB, it
should be enough for basic use-cases and mapping of 16M mem region
of Xen node.
Unfortunately, after moving we also need to increase number of XLAT
tables. The previous code was more efficient if we talking about
usage of XLAT tables, because it mapped grant tables using a higher-
order table that allows mapping blocks of 2MB. And after the changes
is maps every 4KB page, so we need more XLAT tables.
Increase number of grant frames, it is needed to sync stage 1 and stage 2
memory mappings, previously we map only one page on stage 2 and further
usage of unmap regions can cause MMU translation errors.
Perform mapping stage 1 before mapping for stage 2 (add to physmap),
because right after stage 1 we can try to access memory and if it is
unmap in stage 2, error will be received during translation.
Note: Xen Grant Table driver doesn't use Zephyr Device Model.
Authored-by: Mykola Kvach <mykola_kvach@epam.com>
Co-authored-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
After 79d0bf39b8 was merged, the inclusion
of <zephyr/acpi/acpi.h> with CONFIG_ACPI=n caused a build failure because
<acpica/source/include/acpi.h> could no longer be included due to the
inlcude path not being injected anymore.
Fix this by guarding the header inclusion when CONFIG_ACPI
is not set.
Fixes#62679.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Fix missing lazy calculation when using ticker interface
required for Central CIS create.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix initialization of CIS lazy_active event count used when
first CIS event is active. Now initialization for first and
any subsequent CISes made active.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Toolchain utilities need to be used through the <zephyr/toolchain.h>
parent header, where the right header is chosen.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
