SOCFPGA_SYSMGR_REG_BASE base address now read from Device tree
This commit changes the way the SOCFPGA_SYSMGR_REG_BASE base address is
determined. Previously, the address was hard-coded in the system_manager
source file. This commit changes the code to read the address from the
Device tree. This makes the code more flexible and allows the base
address to be different for different boards.
Signed-off-by: Navinkumar Balabakthan <navinkumar.balabakthan@intel.com>
With the introduction of the SAI and EDMA drivers, there's
no longer a need to map the MMIOs using the mmu_regions.c
method since this is taken care of by the drivers via
device_map(). As such, remove entries for EDMA and SAI from
mmu_regions.c.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add support of voltage control to Renesas PFC driver. Voltage register
mappings have been added to r8a77951 and r8a77961 SoCs.
Allow 'power-source' property for 'renesas,rcar-pfc' node. This property
will be used for configuring IO voltage on appropriate pin. For now it
is possible to have only two voltages: 1.8 and 3.3.
Note: it is possible to change voltage only for SD/MMC pins on r8a77951
and r8a77961 SoCs.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Add RGPIO gpio driver. This driver is used for i.MX93 and i.MX8ULP.
GPIO pinctrl, read/write and interrupt is supported. Runtime mmio
configuration is enabled, so no need for region definition in
mimx9/mmu_region.c
Signed-off-by: Chekhov Ma <chekhov.ma@nxp.com>
Adopt the "MMU_REGION_DT_FLAT_ENTRY" macro to automatically generate
elements in "mmu_regions" according to devicetree "compatible" and
"status".
Signed-off-by: Chekhov Ma <chekhov.ma@nxp.com>
Adopt the "MMU_REGION_DT_FLAT_ENTRY" macro to automatically generate
elements in "mmu_regions" according to devicetree "compatible" and
"status".
Signed-off-by: Chekhov Ma <chekhov.ma@nxp.com>
Renesas R-Car Gen4 is different from Gen3 regarding pinmux.
While Gen3 had only one base address to manage all pins,
Gen4 has one set of pinmux registers per GPIO banks.
We could expose one pinmux register per GPIO controllers,
but that would break potential compatibility with Linux
Device tree.
Instead create a reg_base array to parse all reg base from
device tree and identify proper base address based on the pin
definition.
This imply to add a pfc_base parameter to most of the pfc_rcar
function.
Signed-off-by: Julien Massot <julien.massot@iot.bzh>
Signed-off-by: Pierre Marzin <pierre.marzin@iot.bzh>
Signed-off-by: Aymeric Aillet <aymeric.aillet@iot.bzh>
i.MX93 share similiar register layout with i.MX RT11xx. Change ccm driver
to align with i.MX RT11xx, and make it easier to enable other drivers.
Signed-off-by: Chekhov Ma <chekhov.ma@nxp.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>
This commit updates all arm64 SoCs to set SOC_LINKER_SCRIPT CMake
variable to point to active linker script directly.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
These headers are using things like `uint32_t` & devicetree
macros, so they should include the `devicetree.h` & `types.h`.
Otherwise they depend on the parent file to have those headers
included before they are included.
Signed-off-by: Yong Cong Sin <ycsin@meta.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>
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>
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>
The current mechanism of the MPU region switching configures and
reprograms the regions (including inserting, splitting the dynamic
region, and flushing the regions to the registers) every time during the
context switch. This, not only causes a large usage of the kernel stack
but also a lower performance.
To improve it, move the configuration operations ahead to make sure the
context swtich only flushes the current thread regions to the registers
and does not configure the regions anymore. To achieve this, configure
the regions during any operations related to partitions (partition
add/remove, and domain add/remove thread), flush the sys_dyn_regions if
the current thread is the privileged thread, and flush the thread's own
regions if it's a user thread.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Some configurations have the system timer driver hardwired in.
Let's make them compatible with CONFIG_SYS_CLOCK_EXISTS=n.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The Keystone 3 (K3) family encompasses a wider variety of SoC's.
This aligns the soc/arm64 naming with the soc/arm directory.
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Add Pin Function Controller tables of registers and their bits
for ARM64 Renesas R-Car family. With this changes we can use
Renesas PFC driver for configuring bias and driving capabilities.
Add only needed driver strength and bias pins to PFC,
e.g. SDx and UART TX/RX pins.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Add support of r8a77961 SoC to gen3 series.
Create a dtsi file with a common part for both r8a77951 and r8a77961.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Add Pin Function Controller tables of registers and their bits
for ARM64 Renesas R-Car family. With this changes we can use
Renesas PFC driver for configuring bias and driving capabilities.
Note: some of files copy-pasted from Renesas Arm 32
SoC directory and this commit is a temporary
solution, we need to rework it in order to use
the same source files for both architectures.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
The Zephyr linker scripts have inconsistent ordering of various chunks of
data which lands in RAM at runtime. This leads to the value of _end not
being consistently defined as the maximum address of static variables used
in the application.
Create a helper linker fragment, zephyr/linker/ram-end.ld, which can be
included after the last possible definition of RAM data, that consistently
sets _image_ram_end, _end and z_mapped_end.
Signed-off-by: Keith Packard <keithp@keithp.com>
This prevents configuration errors if a board is configured when
the SoC indicates segger RTT support but the segger module is
not available.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This commit creates identity mappings for all memory regions required
by SOF. This is needed because drivers using these memory regions have
not yet been ported to Zephyr.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Since SOF uses some extra sections we need to add them to the linker
script. The used linker script is simply a copy of arm64 linker script
with SOF regions included. This is because conditionally adding sections
to the main arm64 linker script is not really desirable.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The purpose of the GIC ITS is to translate message-passing interrupts into
LPIs. The LPI range starts at value 8192, which means the current default
value (200) is too low. Therefore, bump the highest IRQ number when ITS
is enabled.
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
Co-authored-by: Henri Xavier <datacomos@huawei.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>
Some platforms need to define multiple memory regions with
various attribute. This patch adds dts defined regions in the mpu
configuration. The memory attribute can be set in the device tree.
Signed-off-by: Yanqin Wei <Yanqin.Wei@arm.com>
