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 Application Development on Remote Cores 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