[FAQ] Linux: How to check what binary is running on the DM R5F

SPL boot: Inspect the DM R5F binary that is built into tispl.bin

Find the binary that is used

Refer to  [FAQ] SPL Boot: How to find the DM R5F binary that is built into tispl.bin  to find the binary that is getting loaded. Then come back to this FAQ.

Inspect the binary file

AM62x, AM62Dx, AM62Px, AM67, AM67A

Is the binary named "ipc_echo_testb_mcu1_0_release_strip.xer5f"? This prebuilt file comes from the ti-linux-firmware repository (AM67 & AM67A use the j722s binary). This is the ipc_rpmsg_echo_linux project.

AM62Ax

Depending on where the file came from, a prebuilt binary named "ipc_echo_testb_mcu1_0_release_strip.xer5f" could be the ipc_rpmsg_echo_linux project, or it could be the VPAC/ISP binary.

Check the size of the binary. ipc_rpmsg_echo_linux will be ~160-200 kBytes, while the VPAC/ISP binary will be ~600 kBytes.

SBL boot: Find the DM R5F binary that is loaded by the SBL

Refer to  [FAQ] SBL boot: How to find the DM R5F firmware that is loaded by SBL  

During Linux runtime: Test if the ipc_rpmsg_echo_linux firmware is running on the DM R5F

Check the firmware's trace logs. This can also be used to check which SDK version was used to generate the firmware

Some DM R5F firmware projects send print outputs to a trace log. If Linux successfully attaches to the DM R5F, then Linux can read the trace log. The ipc_rpmsg_echo_linux project sends outputs to a trace log.

Here is an example of how to check the trace logs:

// test is on AM62x Linux SDK 10.1
root@am62xx-evm:~# uname -a
Linux am62xx-evm 6.6.58-rt45-ti-rt-01780-gc79d7ef3a56f-dirty #1 SMP PREEMPT_RT Wed Nov 27 14:15:26 UTC 2024 aarch64 GNU/Linux

// let's check which remoteprocX instance is associated with the DM R5F
// note that remoteprocX <--> core association is NOT fixed. It can be different on different boots
root@am62xx-evm:~# head /sys/class/remoteproc/remoteproc*/name
..
==> /sys/class/remoteproc/remoteproc1/name <==
78000000.r5f
...

// Is the DM R5F firmware also from SDK 10.1?
// let's check the trace log for remoteproc1

// note the "Sciserver Version" that tells us which SDK version was used to build the project
// [IPC RPMSG ECHO] prints tell us that this is the ipc_rpmsg_echo_linux project
// and we see the same version number listed in the IPC RPMSG ECHO output
// these version numbers are generated at compile time, using files like this:
// https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/generate_ipc_fw_ver.sh
root@am62xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc1/trace0
[r5f0-0]     0.000892s : Sciclient direct init..... SUCCESS
[r5f0-0]     0.002004s : Sciserver Testapp Built On: Nov 14 2024 14:00:38
[r5f0-0]     0.006603s : Sciserver Version: v2024.11.0.0-REL.MCUSDK.K3.10.01.00.10+
[r5f0-0]     0.012100s : RM_PM_HAL Version: v10.01.08
[r5f0-0]     0.014851s : Starting Sciserver..... PASSED
[r5f0-0]     0.017786s : [IPC RPMSG ECHO] Version: REL.MCUSDK.K3.10.01.00.10+ (Nov 14 2024 14:02:25):
[r5f0-0]    16.156413s : [IPC RPMSG ECHO] Message exchange started with RTOS cores !!!
[r5f0-0]    16.162285s : [IPC RPMSG ECHO] Remote Core waiting for messages at end point 13 ... !!!
[r5f0-0]    16.170094s : [IPC RPMSG ECHO] Remote Core waiting for messages at end point 14 ... !!!
[r5f0-0]    21.920903s : [IPC RPMSG ECHO] All echoed messages received by main core from 1 remote cores !!!
[r5f0-0]    21.928608s : [IPC RPMSG ECHO] Messages sent to each core = 100000
[r5f0-0]    21.933649s : [IPC RPMSG ECHO] Number of remote cores = 1
[r5f0-0]    21.937865s : [IPC RPMSG ECHO] Total execution time = 5758661 usecs
[r5f0-0]    21.942910s : [IPC RPMSG ECHO] One way message latency = 28793 nsec

Try the rpmsg_char_simple userspace application

If Linux is attaching to the DM R5F and establishing RPMsg communication with the DM R5F, then the rpmsg_char_simple userspace application can be used to test whether the ipc_rpmsg_echo_linux project is running on the DM R5F.

CASE 1: rpmsg_char_simple successfully communicates with DM R5F. The ipc_rpmsg_echo_linux project is running on the DM R5F.

CASE 2: rpmsg_char_simple is unable to communicate with DM R5F. This could be because a different project is running on the DM R5F, but it could also be caused by other factors described in section "What are typical scenarios where RPMsg IPC communication is not initialized between the DM R5F and Linux?".

Verify remoteproc & RPMsg connection

Refer to  [FAQ] How to check if Linux can communicate with a non-Linux core through RPMsg . Then come back to this FAQ.

Run the rpmsg_char_simple userspace application

If rpmsg_char_simple is not included in the filesystem, it can be downloaded here:

rpmsg_char_simple

Different outputs that you might see are included below.

EXAMPLE 1: Successful communication, IPC example is running on the DM R5F

root@am62xx-evm:~# ./rpmsg_char_simple -r 15 -n 1
Created endpt device rpmsg-char-15-1317, fd = 4 port = 1025
Exchanging 1 messages with rpmsg device rpmsg-char-15-1317 on rproc id 15 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 100510
hello there 0!

Communicated 1 messages successfully on rpmsg-char-15-1317

TEST STATUS: PASSED

EXAMPLE 2: AM62Ax only, VPAC/ISP firmware running on DM R5F

The AM62Ax VPAC/ISP firmware does use RPMsg to communicate, so we can see that a single RPMsg endpoint is created at 0xd:

// I will cut out print statements that are unrelated to DM R5F
root@am62axx-evm:~# dmesg | grep -e r5 -e remoteproc -e rproc -e rpmsg -e virtio
...
[    7.443969] platform 78000000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1)
[    7.485132] platform 78000000.r5f: configured R5F for IPC-only mode
[    7.491773] platform 78000000.r5f: assigned reserved memory node r5f-dma-memory@9c800000
[    7.580786] remoteproc remoteproc2: 78000000.r5f is available
[    7.606619] remoteproc remoteproc2: attaching to 78000000.r5f
[    7.693146] rproc-virtio rproc-virtio.9.auto: assigned reserved memory node r5f-dma-memory@9c800000

// The DM R5F firmware defines a single RPMsg endpoint at 0xd
// so Linux can communicate with the DM R5F over RPMsg by talking to that endpoint
[    7.724386] virtio_rpmsg_bus virtio2: creating channel rpmsg_chrdev addr 0xd
[    7.727945] virtio_rpmsg_bus virtio2: rpmsg host is online
[    7.739639] rproc-virtio rproc-virtio.9.auto: registered virtio2 (type 7)

// Linux successfully attaches to the DM R5F
[    7.746700] remoteproc remoteproc2: remote processor 78000000.r5f is now attached

That means we can successfully send an RPMsg message to the DM R5F. However, since the DM R5F is not running the ipc_rpmsg_echo_linux firmware, it will not echo the same message back to Linux.

// let's check to see what RPMsg endpoint is used by default
root@am62axx-evm:~# rpmsg_char_simple -help
rpmsg_char_simple: invalid option -- 'h'
Usage: rpmsg_char_simple [-r <rproc_id>] [-n <num_msgs>] [-d           <rpmsg_dev_name] [-p <remote_endpt] [-l <local_endpt]
                Defaults: rproc_id: 0 num_msgs: 100 rpmsg_dev_name: NULL remote_endpt: 14

// since remote endpoint 0xe (14) is used by default, we have to manually pass in 0xd (13)

root@am62axx-evm:~# ./rpmsg_char_simple -r 15 -n 1 -p 13
Created endpt device rpmsg-char-15-9222, fd = 4 port = 1025
Exchanging 1 messages with rpmsg device rpmsg-char-15-9222 on rproc id 15 ...

Sending message #0: hello there 0!

// rpmsg_char_simple hangs here, waiting for the message to be echoed back
// since the message is not echoed back, the test fails
// we know for sure that ipc_rpmsg_echo_linux is not running on the DM R5F
// it may take additional tests to verify exactly what firmware IS running on the DM R5F

EXAMPLE 3: No communication, and IPC example is NOT running on the DM R5F

For example 3, I loaded a different, custom firmware into the DM R5F, which did not use RPMsg. The boot log looked like this:

[ 7.572006] platform 78000000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1)
[ 7.587962] platform 78000000.r5f: configured R5F for IPC-only mode
[ 7.598472] platform 78000000.r5f: assigned reserved memory node r5f-dma-memory@9c800000
[ 7.642301] remoteproc remoteproc1: 78000000.r5f is available
[ 7.656028] remoteproc remoteproc1: attaching to 78000000.r5f
[ 7.667068] remoteproc remoteproc1: remote processor 78000000.r5f is now attached

// note that the RPMsg VIRTIO infrastructure was not successfully set up

Since the DM R5F did not provide any RPMsg endpoints, the VIRTIO infrastructure did not finish getting set up. Linux cannot communicate with the DM R5F using RPMsg IPC.

root@am62pxx-evm:~# ./rpmsg_char_simple -r 15 -n 1
_rpmsg_char_find_rproc: 78000000.r5f does not have any virtio devices!
Can't create an endpoint device: No such file or directory
TEST STATUS: FAILED