Part Number: PROCESSOR-SDK-J784S4
Hi
The following patch in the Linux kernel makes it impossible for us to load a R5 firmware to one of the main domain second cores:
commit d8a0df33f167321a2991825b40e46169da0f642b
Author: Apurva Nandan <a-nandan@ti.com>
Date: Wed Dec 13 09:06:29 2023 +0530
remoteproc: k3-r5: Wait for core0 power-up before powering up core1
PSC controller has a limitation that it can only power-up the second core
when the first core is in ON state. Power-state for core0 should be equal
to or higher than core1, else the kernel is seen hanging during rproc
loading.
Make the powering up of cores sequential, by waiting for the current core
to power-up before proceeding to the next core, with a timeout of 2sec.
Add a wait queue event in k3_r5_cluster_rproc_init call, that will wait
for the current core to be released from reset before proceeding with the
next core.
Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Our use case is to load most of the firmware via the remoteproc interfaces from userspace. This is unfortunately not possible any more if core 0 is not loaded during boot time by the kernel.
Our simple workaround is the following adjustment:
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 6cdd431e31de..f66301525ccd 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -1445,10 +1445,9 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
core->released_from_reset,
msecs_to_jiffies(2000));
if (ret <= 0) {
- dev_err(dev,
+ dev_notice(dev,
"Timed out waiting for %s core to power up!\n",
rproc->name);
- return ret;
}
}
Is this something which you would recommend?
Could you please fix this for the next SDK release?
Regards
Daniel
