Methods to initialize remote cores#
There are multiple ways to initialize a remote core: during SBL boot, during U-Boot, or with the Linux remoteproc driver.
Which initialization methods are available in which boot flows?#
The Linux remoteproc driver is the “default” way to initialize a remote core, but there are additional options to initialize the remote core earlier in the booting process depending on which boot flow is used.
Initialization methods available with SPL boot flow:
U-Boot initialization
Linux remoteproc driver
Initialization methods available with SBL boot flow:
During SBL boot
U-Boot initialization
Linux remoteproc driver
For more information about the difference between SPL boot flow and SBL boot flow, refer to Boot flows: SPL vs SBL.
Where to learn more about initializing DM R5F?#
Refer to .
How does Linux interact with a remote core that was initialized before Linux boot?#
There are 2 options that TI supports:
Linux interacts with the remote core through Linux RPMsg
Linux and the remote core do not interact
Case 1: Linux interacts with the remote core through Linux RPMsg#
In this case, the remote core and the remote core’s memory should be defined in the Linux devicetree as if Linux remoteproc was initializing the remote core.
Before attempting to initialize the remote core, Linux will check to see if the remote core is already running. When Linux sees that firmware is already running on the remote core, Linux will simply “attach” to the remote core, and initialize the RPMsg communication infrastructure necessary for IPC with the remote core.
Note
On Linux kernel 6.6 and earlier, graceful shutdown of a remote core is NOT supported if the remote core was initialized by something other than the Linux RemoteProc driver. For more information about graceful shutdown, refer to Graceful shutdown.
Case 2: Linux and the remote core do not interact#
In this case, the remote core should be “disabled” in the Linux devicetree. Refer to this section for more information: Disabling remote cores in Linux.