2.6. Booting Remote Cores

This section discusses booting remote cores from Linux. Linux can boot remote cores during Linux boot, or during Linux runtime. Reference section dev_remote_core for information about booting remote cores from CCS.

2.6.1. Booting Remote Cores During Linux Boot

In normal operation, the boot loader (U-Boot) boots and loads Linux onto the A53 cores of the AM62x. If the remote cores are enabled in the Linux devicetree, then Linux will use the RemoteProc driver to boot the remote cores during Linux kernel boot time. Reference section Linux Boot Flow for more information about the Linux boot flow.

The Linux devicetree tells the RemoteProc driver which firmware files to load into the remote cores. By default, RemoteProc looks for these files:

Core Name	RemoteProc Name	Description	Firmware File Name
M4F	5000000.m4f	M4F core	am62-mcu-m4f0_0-fw

The above files are generally soft linked to the intended firmware on a root file system. For example:

root@am62xx-evm:/opt/ltp# ls -l /lib/firmware
...
lrwxrwxrwx 1 root root      72 May 21  2022 am62-mcu-m4f0_0-fw -> /lib/firmware/pdk-ipc/ipc_echo_baremetal_test_mcu2_0_release_strip.xer5f

2.6.2. Booting Remote Cores from the Linux Console or User Space

To reload a remote core with new executables, please follow the below steps.

First, identify the remotproc node associated with the remote core:

# head /sys/class/remoteproc/remoteproc*/name

Then, use the sysfs interface to stop the remote core. For example, to stop the core at remoteproc1:

# echo stop > /sys/class/remoteproc/remoteproc1/state

If needed, update the symbolic link in the /lib/firmware/ folder to point to a new firmware:

# ln -sf /full/path/to/firmware_name symbolic_link_name

Finally, use the sysfs interface to start the remote core:

# echo start > /sys/class/remoteproc/remoteproc1/state

Note

The RemoteProc driver does not support a graceful shutdown of R5 and M4 cores in the current Linux Processor SDK. For now, it is recommended to reboot the board to load new binaries into an R5F or M4F core.

The full process on AM62x looks like this:

root@am62xx-evm:~# head /sys/class/remoteproc/remoteproc*/name
==> /sys/class/remoteproc/remoteproc0/name <==
5000000.m4fss

==> /sys/class/remoteproc/remoteproc1/name <==
30074000.pru

==> /sys/class/remoteproc/remoteproc2/name <==
30078000.pru

Let’s use the sysfs interface to load an IPC example onto the M4F core:

root@am62xx-evm:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[  440.832317] remoteproc remoteproc0: stopped remote processor 5000000.m4fss

root@am62xx-evm:~# cd /lib/firmware

root@am62xx-evm:/lib/firmware# ln -sf /lib/firmware/pdk-ipc/ipc_echo_baremetal_test_mcu2_0_release_strip.xer5f am62-mcu-m4f0_0-fw

Since graceful shutdown of remote cores is not currently supported, reboot the board in order to load new binaries onto the remote core. Once graceful shutdown is supported, the sysfs interface can be used to re-start the remote core instead of rebooting the entire board:

root@am62xx-evm:~# echo start > /sys/class/remoteproc/remoteproc0/state
[  450.930070] remoteproc remoteproc0: powering up 5000000.m4fss
[  450.936112] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 78960
[  450.960447]  remoteproc0#vdev0buffer: assigned reserved memory node m4f-dma-memory@9cb00000
[  450.969408] virtio_rpmsg_bus virtio0: rpmsg host is online
[  450.975089] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[  450.975850]  remoteproc0#vdev0buffer: registered virtio0 (type 7)
[  450.982840] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[  450.988824] remoteproc remoteproc0: remote processor 5000000.m4fss is now up