| Age | Commit message (Collapse) | Author |
|---|
|
Fix typo in Kconfig symbol help text, change incorrect A52 to correct R52.
No functional change.
Signed-off-by: Marek Vasut <[email protected]>
Acked-by: Peng Fan <[email protected]>
|
|
Prepare v2026.04-rc4
|
|
After years of developing the ADI ADSP platform, Timesys was purchased
by another company and is no longer contracted to maintain the platform.
Signed-off-by: Philip Molloy <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <[email protected]> #TI boards
Acked-by: Yao Zi <[email protected]> #TH1520
Signed-off-by: Peng Fan <[email protected]>
|
|
i.MX95 uses System Manager(sm) API to start/stop logical machine or cpu.
There are two modes:
M7 in a dedicated logical machine, use LMM API
M7 and A55 in same logical machine, use CPU API
Extend the driver to using LMM and CPU protocol to manage the M7 core:
- Detect using LMM or CPU API in probe using API scmi_imx_lmm_info().
- Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID
is fixed as 1 in SM firmware if M7 is in a separate LM),
if Linux LM ID is not same as M7 LM ID(linux and M7 in same LM), use
LMM protocol to start/stop. Whether using CPU or LMM protocol to
start/stop, the M7 status detection could use CPU protocol to detect
started or not. So in imx_rproc_is_running, use scmi_imx_cpu_started to
check the status of M7.
- For above case (2), Use scmi_imx_lmm_power_boot to detect whether
the M7 LM is under control of A55 LM.
- For above case , after using SCMI_IMX_LMM_POWER_ON to check
permission, scmi_imx_lmm_shutdown API should be called to shutdown
the M7 LM.
- Add a new ops imx_rproc_ops_sm.
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a new flag ATT_ECC which indicates the memory region needs ECC
initialization. If the flag is set, clearing the whole memory region to
initialize ECC. If ECC is not initialized, remote core will crash if
directly access the area.
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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/[email protected]
Signed-off-by: Anshul Dalal <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
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 <[email protected]>
|
|
Greg Malysa <[email protected]> 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/[email protected]
|
|
This adds the ability to load ldr-formatted files to the SHARC
coprocessors using the rproc interface. Only a minimal subset
of rproc functionality is supported: loading and starting
the remote core.
Secure boot and signed ldr verification are not available
at this time through the U-Boot interface.
Co-developed-by: Greg Malysa <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Co-developed-by: Ian Roberts <[email protected]>
Signed-off-by: Ian Roberts <[email protected]>
Co-developed-by: Piotr Wojtaszczyk <[email protected]>
Signed-off-by: Piotr Wojtaszczyk <[email protected]>
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Oliver Gaskell <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
|
|
Memory region used by remote cores was set to non-cached region but
commit 7c9c6e192580 ("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 <[email protected]>
Signed-off-by: Beleswar Padhi <[email protected]>
|
|
Judith Mendez <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Judith Mendez <[email protected]>
Reviewed-by: Daniel Schultz <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
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 <[email protected]>
[Ryan: Fix implicitly include warning]
Signed-off-by: Ryan Eatmon <[email protected]>
[Judith: Cleanup driver, fix warnings, remove lreset logic]
Signed-off-by: Judith Mendez <[email protected]>
Tested-by: Daniel Schultz <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Fixes: 3286d223fd7 ("sandbox: implement invalidate_icache_all()")
Acked-by: Heinrich Schuchardt <[email protected]>
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 <[email protected]>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
Signed-off-by: Simon Glass <[email protected]>
|
|
and device's parent name
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 <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Udit Kumar <[email protected]> says:
Some use case needs rproc firmware to be loaded at u-boot stage,
using following commands at u-boot shell, firmware could be loaded
=> setenv dorprocboot 1
=> run boot_rprocs
For Secure devices, secure version of rproc firmware should be loaded,
which is appended by sec keyword[0].
but currently non-secure firmware is loaded even for secure devices.
So adding support for loading secure firmware on Secured devices.
[0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7
Bootlogs:
GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-gp_device line 65 onwards
HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-hs-device line 60 onwards
|
|
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 <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]> # Intel Edison
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Prepare v2024.07-rc3
|
|
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 c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Hari Nagalla <[email protected]> says:
This series adds relevant ip data in remoteproc driver for AM62a devices.
Logs: https://paste.sr.ht/~hnagalla/5e20838705c1d688bca81886dad56451b56d3913
|
|
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 <[email protected]>
Reviewed-by: Devarsh Thakkar <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Devarsh Thakkar <[email protected]>
|
|
MD Danish Anwar <[email protected]> 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 <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
|
|
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ravi Gunasekaran <[email protected]>
Reviewed-by: Roger Quadros <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Manorit Chawdhry <[email protected]>
Signed-off-by: Apurva Nandan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Manorit Chawdhry <[email protected]>
Signed-off-by: Apurva Nandan <[email protected]>
|
|
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 <[email protected]>
|
|
Replace instances of http://www.ti.com with https://www.ti.com
Signed-off-by: Nishanth Menon <[email protected]>
|
