Add is_running callback to query the R5F core halt status via the
TI-SCI processor control API. This allows the remoteproc framework
to determine whether the R5F core is currently runnin.
The core is considered running when the PROC_BOOT_CTRL_FLAG_R5_CORE_HALT
bit is not set in the control flags.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
Reviewed-by: Andrew Davis <afd@ti.com>
After ti_secure_image_post_process() authenticates the image, it may
relocate it to a different memory location and update image_addr to
point to the verified image.
However, rproc_elf_load_image() and rproc_elf_get_boot_addr() were
still using the original "addr" parameter, potentially operating on
the unverified or stale image location instead of the authenticated
image.
Use image_addr (cast to ulong to match function signatures) after
authentication to ensure all operations work with the verified image.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
passing 'size' (ulong) to ti_secure_image_post_process() caused
a type mismatch compiler error.
On platforms where ulong and size_t differ in size, directly
casting could lead to out-of-bounds memory access. Fix by
introducing a size_t temporary variable, passing it to the
function, and writing back the potentially modified value for
use in subsequent calls.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
Acked-by: Andrew Davis <afd@ti.com>
Introduce remote processor configuration for the i.MX93 Cortex-M33 core.
This patch adds:
- Address translation table (ATT) for i.MX93, including TCM
(secure and non-secure) and DDR regions.
- A new device configuration structure `imx_rproc_cfg_imx93` using SMC
method and ARM SMC ops.
- Device tree match entry for "fsl,imx93-cm33"
This enables remoteproc framework to properly initialize and manage the
Cortex-M33 core on i.MX93 platforms.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
i.MX8MQ/M use MMIO based method to directly configure SRC registers
to start/stop M4.
Add mmio ops to start/stop/is_running.
Add i.MX8MQ cfg data, i.MX8MN reuses i.MX8MQ data.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Support i.MX8MP/N with start/stop/device_to_virt/is_running/load
implemented. The device static configuration is mostly reused from
Linux Kernel with adapation to U-Boot dm_rproc_ops.
The booting method:
- load mmc 2:2 0x90000000 /lib/firmware/imx8mp_m7_DDR_rpmsg_lite_str_echo_
rtos.elf
- rproc load 0 0x90000000 ${filesize}
- rproc start 0
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Some areas needs to be initialized by using memcpy_toio and memset_io.
Following Linux Kernel commit: 40df0a91b2a5 ("remoteproc: add is_iomem to
da_to_va"), add this to U-Boot.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The existing compatible name for U-Boot's k3 system controller driver
i.e "ti,am625-system-controller" has been added to linux[1] device-tree.
This compatible in kernel is meant for configuring the Control Module
registers (CTRL_MMR0).
However in U-Boot, the matching driver was being used to load the system
firmware on the secure M-cores by the R5 SPL and therefore must be
updated to a different compatible to avoid conflicts.
Therefore, this patch renames all references of the compatible to
"ti,am654-tisci-rproc-r5". The "-r5" is appended so as to avoid any
future conflicts since r5 specific compatibles should only be useful for
U-Boot.
[1]: 5959618631fe ("dt-bindings: mfd: ti,j721e-system-controller: Add compatible string for AM654")
https://lore.kernel.org/r/20250421214620.3770172-2-afd@ti.com
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Add early boot support for AM64 single cpu mode configuration.
In single CPU mode the 2nd core of the R5F cluster can't be used or
unavailable.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
In k3_r5f_split_reset and k3_r5f_unprepare ret may not have been
assigned to before the code reaches the return ret at the function exit.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
In the struct ti_sci_proc the fields proc_id and host_id are declared as
u8 so cannot be set to nor compared with a macro defined with a value
using 16 bits. Change the macro to only use 8 bits to make the code work
as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
The TI IPU remoteproc driver cannot build without access to some
platform specific header files. Express that requirements in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Acquire processor control before doing core reset operations in probe
routine. Release the control afterwards, so that it can be acquired
during core loading operations.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Greg Malysa <malysagreg@gmail.com> says:
This series adds all of the supported peripheral drivers for the sc5xx
series of SoCs from Analog Devices and other drivers that are used by
the evaluation kits, such as a GPIO expander used by the EZLITE carrier
boards. This series passes gitlab CI tests.
Link: https://lore.kernel.org/r/20250226173150.13198-1-malysagreg@gmail.com
Memory region used by remote cores was set to non-cached region but
commit 7c9c6e1925 ("arm: mach-k3: Merge initial memory maps") makes
all memory region as cached, unified across K3 devices.
This causes inconsistency while booting remote cores on devices, due to
cache incoherency between remote core and boot code.
So to make this operation coherent, cache the address and len while
loading ELF program headers to memory and flush that region in the next
cycle of load.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Judith Mendez <jm@ti.com> says:
Some K3 devices like am62x and am64x have a M4 processor in the MCU
voltage domain. This patch series introduces remoteproc M4 driver which
will be used to load firmware into and start the M4 remote core.
This series also adds support for R5F cores on am64x SoCs in patch 2 and
sets up environment to load FW in remote cores in patch 3,4,5.
This patch series also enables remoteproc drivers by default as per what
remoteproc sybsystem is supported per SoC, thus all remoteproc options
are now deleted in configs/* since they are no longer required.
This patch series was tested on am64x EVM, am62x SK, am62ax SK,
am62px SK boards.
Any additional tested by's are welcome since I was not able to
test any additional boards.
Tested by running the following commands in u-boot prompt:
=> setenv dorprocboot 1
=> run boot_rprocs
Link: https://lore.kernel.org/r/20250210202944.1071931-1-jm@ti.com
If SYS_K3_SPL_ATF is enabled, for K3 ARCH enable the
remoteproc ARM64 driver by default so that it does not
have to be defined in each board defconfig file.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
AM64x SoCs have two R5F clusters in the main power domain.
Extend support for R5F remote proc driver on AM64x with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
voltage domain.
Add a remote proc driver to support this subsystem to be able to load
and boot the M4 core.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[Ryan: Fix implicitly include warning]
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
[Judith: Cleanup driver, fix warnings, remove lreset logic]
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
Explicitly flush icache on the CR52 core before jumping to the next
stage software to make sure it does not contain any invalid content.
Explicitly flash and invalidate dcache on the CA76 core both over the
trampoline buffer and over the CR52 firmware, and then trigger full
system synchronization, to make sure the data surely land in DRAM,
from where the CR52 can surely pick them up.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add R-Car Gen4 APMU controller remoteproc driver capable of starting
the Cortex-R52 cores in Renesas R8A779G0 V4H/V4M SoC. The APMU IP is
in fact a power management unit capable of additional operations, but
those are not used by U-Boot so far.
This requires slight adjustment to the SPL entry point code, as that
is being executed on the Cortex-R52 #0 and the Cortex-R52 #0 enters an
endless loop once it starts the rest of the SPL on Cortex-A76 core.
The endless loop now checks for content of APMU CRBARP registers and
tests whether valid VLD_BARP and BAREN_VALID bits are set, if so, the
Cortex-R52 core exits the endless loop and jumps to address started
in CRBARP[31:18] register in ARM mode, which is a trampoline code to
jump to the final entry point.
The trampoline code is in place to avoid limitation of CRBARP[31:18]
address field, which limits the core start address to memory addresses
aligned to 0x40000 or 256 kiB . The trampoline is placed at 0x40000
aligned address and jumps to the final entry point, which can be at
an address with arbitrary alignment at instruction granularity.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The cache-flush function is incorrect which causes a crash in the
remoteproc tests with arm64.
Fix both problems by using map_sysmem() to convert an address to a
pointer and map_to_sysmem() to convert a pointer to an address.
Also update the image-loader's cache-flushing logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 3286d223fd ("sandbox: implement invalidate_icache_all()")
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Changes in v6:
- Re-introduce
Changes in v2:
- Drop message about EFI_LOADER
arch/sandbox/cpu/cache.c | 8 +++++++-
drivers/remoteproc/rproc-elf-loader.c | 18 +++++++++++-------
lib/efi_loader/efi_image_loader.c | 3 ++-
3 files changed, 20 insertions(+), 9 deletions(-)
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
uc_pdata->name is populated from device tree property "remoteproc-name".
For those devcices that don't set "remoteproc-name", uc_pdata->name
falls back to dev->name.
If two devices have same name, this will result into uc_pdata->name not
being unique and rproc_init() will fail.
Fix this by using combination of dev->name and dev->parent->name instead
of using just the dev->name to populate uc_pdata->name.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Andrew Davis <afd@ti.com>
Remoteproc firmware images aren't authenticated in the current boot flow.
Authenticates remoteproc firmware images to complete the root of trust
in secure booting.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
AM62A has a R5F core in MCU voltage domain.
Extend support for R5F remote proc driver on AM62A with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
AM62A SoC has a single C71x DSP subsystem with analytics engine in
main voltage domain. Extend support to AM62A with compatible strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
MD Danish Anwar <danishanwar@ti.com> says:
This series adds AM64x related compatibles to PRUSS and PRU_RPROC drivers.
This series is a prerequisite for ICSSG Ethernet driver.
Once Support for AM64x is added to PRUSS and PRU_RPROC driver, I'll send
another series to enable ICSSG Ethernet driver for AM64x as well.
Add support for AM64x PRU cores by adding compatibles for AM64x.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Add APIs to set a firmware_name to a rproc and boot the rproc with the
same firmware.
Clients can call rproc_set_firmware() API to set firmware_name for a rproc
whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
a buffer by calling request_firmware_into_buf(). rproc_boot() will then
load the firmware file to the remote processor and start the remote
processor.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Acked-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain,
and there are no C66x DSP subsystems on these SoCs. The C71x DSP subsystem
is a slighly updated version of the C71x DSP subsystem on J721e. The
C71x DSPs are 64 bit machine with fixed and floating point DSP
operations.
Extend support to the C71x DSPs with J721S2 compatible strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
The K3 J721S2 SoCs have three dual-core R5F subsystems, one in MCU
voltage domain and the other two in MAIN voltage domain. These R5F
clusters are similar to the R5F clusters in J7200 SoCs.
Compatible Info is updated to support J721S2 SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
DSP core is going into abnormal state when load callback is called
after starting of DSP core.
Reload of firmware needs core to be stopped first, followed by
load.
So avoid loading of firmware, when core is started.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
We know that "pa" is non-NULL so it's nicer to just return zero instead
of return !pa. This has no effect on runtime behavior.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Configuring master firewalls require the power of the cluster to be
enabled before configuring them, change the load of rproc to configure
the gtc clocks and start the cluster along with configuring the boot
vector.
The start of rproc will only start the core.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The driver enables IPU support. Basically enables the clocks,
timers, watchdog timers and bare minimal MMU and supports
loading the firmware from mmc.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[Amjad: fix compile warnings]
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Add remoteproc resource handling helpers. These functions
are primarily to parse the resource table and to handle
different types of resources. Carveout, devmem, trace &
vring resources are handled.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[Amjad: fix redefinition of "struct resource_table" and compile warnings ]
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
