TDA4VM: Remoteproc support for MCU R5Fs

Hi Vai,

Yes, your understanding is correct w.r.t 7.1+ SDK. The MCU R5F now runs a DM firmware that is integral to the functionality of the system alongwith TIFS/DMSC firmware. 

The Linux R5 SPL does not perform any reset of MCU R5F, it rather loads a new DM firmware and branches to it. The MCU R5F cluster does come up in the same default mode the device is capable of at Power-On-Reset.  

The LockStep-mode and Split-mode capability is dictated by eFuse for a given device. A LockStep-mode device is capable of supporting both through configuration, while a Split-mode device only ever supports Split-mode. On LockStep-mode devices, MCU R5F continues to stay in LockStep-mode and is running its firmware at R5 SPL, so it will always be in IPC-only mode and it is not possible to switch to remoteproc mode. On Split-mode only devices, MCU R5F Core0 will be running the DM firmware and will always be in IPC-only mode, and it should be possible to boot the Core1 at either U-Boot or in kernel.

What is your device capable of? You should be able to tell by looking at the status bit-field values retrieved from a ti_sci_proc_get_status() call. 

regards

Suman

Hi Suman,

I'm using TDA4VM - which has a configurable MCU island, so it can operate in either Lockstep or Split mode. Does this mean that despite the Uboot device config changes and boot mode = 2 (split), both core0 and core1 will start in IPC-only mode?

Or is there a way to operate core1 differently and control it with Linux kernel/remoteproc?

Also, can you send me some detailed documentation on this to better my understanding?

Thanks

Vai

Hi Suman,

Yes, I'm using SDK 7.3.

The changes I made are to R5 SPL and not Uboot. In particular, I applied the patch below and used the new tiboot3.bin. I also had a couple of device tree changes to Uboot to instantiate each MCU R5FSS core separately, but those are trivial. When I used the newly generated tispl.bin, yes I did get an error from A72 ATF. But the older version (vanilla SDK 7.3) did not complain.

diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh
index b6d055f6f5..428abb7547 100755
--- a/tools/k3_gen_x509_cert.sh
+++ b/tools/k3_gen_x509_cert.sh
@@ -204,6 +204,7 @@ if [ $BOOTCORE == 0 ]; then # BOOTCORE M3, loaded by ROM
CERTTYPE=2
elif [ $BOOTCORE == 16 ]; then # BOOTCORE R5, loaded by ROM
CERTTYPE=1
+ BOOTCORE_OPTS=2
else # Non BOOTCORE, loaded by SYSFW
BOOTCORE_OPTS_VER=$(printf "%01x" 1)
# Add input args option for SET and CLR flags.

Yep, I've read the 6.3.3 section of TRM and also looked into what each piece of boot step is doing. I might need some clarification. You're saying that R5 ROM starts MCU R5 in lockstep mode (always?) and it needs to relinquish control by SPL shutdown before it can be reconfigured to split mode. Did I understand this right? Does this mean that given SDK 7.1+ DMSC running on it, it'll never be shutdown and hence we cannot ever operate MCU R5 in split mode (because it needs to be held in reset to configure MMR CLSTR CFG)?

Is there any possible workaround to operate the MCU R5F in split mode at all?

Thanks
Vai

Hi Suman,

Thanks a lot for this detail.

Do you guys have a patch for R5 SPL that I could use to to shutdown core1? This would be really useful to us and possibly others experiencing the same bottleneck. We could use some help from TI to get this functionality.

Thanks
Vai

Hi Vai,

Nope, there is no ready-made patch available that shuts down Core1. This definitely takes a bit of effort to get this feature functional and done cleanly.

regards

Suman 

Hi Suman,

Thanks. Any idea when we can have this feature? This would really help us develop faster on MCU island.

Thanks

Vai

Hi Vai,

This is going to be a new feature request/enhancement. We need few weeks to come back with a plan. I will close this thread for now.

regards

Suman