Kconfig options with a HEAP_MEM_POOL_ADD_SIZE_ prefix should be used to
set the minimum required system heap size. This helps prevent
applications from creating a non-working image by trying to set a too
small value.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There are duplicated names specified in per-board YAML files.
This change will allow distinguishing boards in software that
presents the pretty names and not the raw names of boards.
Signed-off-by: Wojciech Sipak <wsipak@antmicro.com>
Read real frequncy from ARM Arch Timer instead of using define
'CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC' which can be incorrect for
some run cases. If we run xenvm under qemu we get one frequency, but
we can run this build as a DomU for Xen under different real platforms
and thus with differenty arch timer frequencies. So, we need to read
frequency from the timer registers.
Signed-off-by: Mykola Kvach <xakep.amatop@gmail.com>
This is support for AArch64 development board.
The board uses 4-core Cortex-A55, which are based on
the ARMv8.2 architecture.
In addition,we support smp support and
it can use 4-cores to run basic samples.
Signed-off-by: Charlie Xiong <1981639884@qq.com>
The BCM2711 SoC exposes 58 GPIOs. The first 28 (bank 0) are accessible
to users via the 40-pin header, while the others (bank 1) are used for
controlling on-board peripherals.
This also update doc of `rpi_4b` board.
Signed-off-by: Chen Xingyu <hi@xingrz.me>
* defconfig is located under `boards/arm64/` instead of `boards/arm/`
* 64-bit mode (`arm_64bit=1`) is required to boot
Signed-off-by: Chen Xingyu <hi@xingrz.me>
Updates Ethernet PHY devicetree bindings to be more consistent with
Linux by using the standard `reg` property for the PHY address instead
of a custom `address` property. As a result, MDIO controller bindings
now require standard `#address-cells` and `#size-cells` properties.
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
Some Ethernet PHYs used the devicetree node name `phy`, while others
used `ethernet-phy`. Be consistent and use `ethernet-phy` throughout.
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
This is coming from devicetree and corrosponds to what we have in the
dts/bindings/vendor-prefixes.txt file.
This will allow for static filtering, especially with twister, i.e. no
need to build anything to know the vendor of a board
All of the vendor data was extracted automatically from the devicetree,
so some platforms might not have the right vendor or no vendor at all
right now, we need to fix some of the DTS information or do this
manually to get this 100% correct. But we are close.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
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>
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>
- Updated basic samples READMEs to use the new zephyr:code-sample::
directive. Dropped "-sample" suffix that's not required anymore now
that samples have their own namespace.
- Updated all references to the samples to use the :zephyr:code-sample:
role. Checked and updated the wording of said references to account
for the fact that samples should not have "... sample" in their name
anymore.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Let FVP_BaseR_AEMv8R simulate the operation of cache-related.
This will slow the speed of FVP_BaseR_AEMv8R but it can obtain realistic
simulation results as much as possible. So the timeout_multiplier needs
to be increased.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
This platform should not be set as a default platform. It does not run
in CI, i.e. not a simulator/emulator.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
PCI devices are have some differences to regular nodes:
* node name specifies device/function e.g. "pcie@1,0"
* register address has a different meaning
* zero-sized register is allowed
This improves alignment with Linux DT for PCI devices
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Enable qemu_cortex_a53 networking using the Intel e1000 Ethernet driver.
This board only supports a single UART, so subsystems like logging and
shell would need to be disabled to use SLIP, therefore QEMU Ethernet is
used as the default instead.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Now that all in-tree phys are declared under their mdio bus, drop the
`mdio` property and use DT_INST_BUS to find the bus.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Rework the devicetree definition for smsc91x to put the mdio and
ethernet device at the same level, and make the phy a child of the mdio
node.
This allows matching up the device initialization sequence with the
devicetree hierarchy.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This is the initial Zephyr support for Intel SoC FPGA Agilex5 support.
Agilex5 has dual-core 64-bit ARM Cortex*-A55 and dual-core 64bit
ARM Cortex*-A76.
The Zephyr will need to be loaded by Intel Arm Trusted Firmware (ATF).
Agilex5 Zephyr boot flow:
FSBL:ATF BL2(EL3) -> ATF BL31(EL3) -> OS:Zephyr(EL1)
Intel ATF can be loaded from:
https://github.com/altera-opensource/arm-trusted-firmware.git
Signed-off-by: Teik Heng Chong <teik.heng.chong@intel.com>
Signed-off-by: Girisha Dengi <girisha.dengi@intel.com>
This moves CONFIG_MAX_THREAD_BYTES from the board's defconfig
file into the Kconfig file. This is to get rid of the cmake
warning about CONFIG_MAX_THREAD_BYTES being assigned value
but got the value ''. This is due to CONFIG_USERSPACE being
disabled, where some tests explicitly do so. This is simply
done to avoid confusion when running those tests manually.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The latest Yocto release, PD23.1.0, has the CACHE_CMD included.
Therefore, the default image can be used to boot Zephyr.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
This commit adds some additional information about the SOF variant
of the mimx93_evk board. It mostly goes into how SOF with Zephyr
is going to work using this board and some basic Jailhouse-related
concepts.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
This commit introduces a new variant of the mimx93_evk_a55 board
used to run the SOF module.
This is required because we don't want to pollute the imx93_a55
generic board with SOF-specific nodes such as the memory nodes.
Also, the SOF-specific drivers should not be activated in the
generic board.
SOF with Jailhouse also requires some specific configurations
such as the 40-bit PAs and VAs and the static data cache line
size so this is another reason for which this new
board had to be created.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
There are some wrong interrupt-cells values of the uart nodes in this
board. The order of the arm,gic interrupt-cells should be type, irq,
flags and priority.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
A recent change introduced the possibility to declare MPU memory
regions using the device tree and the framework described in
zephyr/linker/devicetree_regions.h.
So remove the device region declared in mpu_regions[] and the used
defines for the addresses, rename REGION_DEVICE_ATTR to REGION_IO_ATTR
in arm_mpu.h to be compatible with the framework and add a device tree
node to fvp_baser_aemv8r.dts to describe the device memory region.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
This demonstates how to use the TI K3 pincrtl driver.
Previously UART0 only worked becuase U-Boot leaves it configured
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Johan Hedberg