This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA829V: IPC echo test. No output in dmesg.

Part Number: DRA829V

Hello experts!

I'm setting up a build system for colleagues to work on the r5f cores on this SoC. I have a custom
board that is built upon SDK 8.6. I have downloaded the latest RTOS PDK version 09_01_00_06.

Building the echo tests goes fine, and I get a lot of echo binaries in the binary build folder:

bomellberg@bosse-buildcom:~/se3linux/ti-processor-sdk-rtos-j721e-evm-09_01_00_06/pdk_jacinto_09_01_00_22/packages/ti$ find . -name "ipc_echo_*xer5f"
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu3_0_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu1_1_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu2_1_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu2_0_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu1_1_release.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu1_0_release.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu2_0_release.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu3_0_release.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu3_1_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu1_0_release_strip.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu3_1_release.xer5f
./binary/ipc_echo_test_freertos/bin/j721e_evm/ipc_echo_test_freertos_mcu2_1_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu3_0_release_strip.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu1_0_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu3_1_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu2_1_release_strip.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu1_1_release_strip.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu1_1_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu3_0_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu2_1_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu1_0_release_strip.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu3_1_release_strip.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu2_0_release.xer5f
./binary/ipc_echo_baremetal_test/bin/j721e_evm/ipc_echo_baremetal_test_mcu2_0_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu1_1_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu1_0_release.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu2_0_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu2_1_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu1_0_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu3_1_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu3_1_release.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu2_1_release.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu3_0_release.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu3_0_release_strip.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu1_1_release.xer5f
./binary/ipc_echo_testb_freertos/bin/j721e_evm/ipc_echo_testb_freertos_mcu2_0_release.xer5f

I have tried adding both the barebone and the freertos variants. They are added fine and can be started:

root@AS-3-P-BEEFF1:/lib/firmware# ll
total 252
drwxr-xr-x 5 root root 1024 Jan 23 15:38 .
drwxr-xr-x 8 root root 3072 Mar 9 2018 ..
drwxr-xr-x 2 root root 1024 Mar 9 2018 cadence
lrwxrwxrwx 1 root root 57 Jan 23 15:33 j7-main-r5f0_0-fw -> ti-ipc/ipc_echo_testb_freertos_mcu2_0_release_strip.xer5f
lrwxrwxrwx 1 root root 57 Jan 23 15:38 j7-main-r5f0_1-fw -> ti-ipc/ipc_echo_testb_freertos_mcu2_1_release_strip.xer5f
-rw-r--r-- 1 root root 247469 Mar 9 2018 pvdec_full_bin.fw
-rw-r--r-- 1 root root 4728 Mar 9 2018 regulatory.db
-rw-r--r-- 1 root root 1182 Mar 9 2018 regulatory.db.p7s
drwxr-xr-x 3 root root 1024 Mar 9 2018 ti-eth
drwxr-xr-x 2 root root 1024 Jan 23 15:31 ti-ipc

[ 43.857589] remoteproc remoteproc0: powering up 5c00000.r5f
[ 43.858760] remoteproc remoteproc0: Booting fw image j7-main-r5f0_0-fw, size 88408
[ 43.860138] rproc-virtio rproc-virtio.1.auto: assigned reserved memory node r5f-dma-memory@a2000000
[ 43.860215] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[ 43.860219] remoteproc remoteproc0: remote processor 5c00000.r5f is now up
[ 273.384556] remoteproc remoteproc1: powering up 5d00000.r5f
[ 273.389843] remoteproc remoteproc1: Booting fw image j7-main-r5f0_1-fw, size 88408
[ 273.391152] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node r5f-dma-memory@a3000000
[ 273.391226] rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
[ 273.391230] remoteproc remoteproc1: remote processor 5d00000.r5f is now up

root@AS-3-P-BEEFF1:/lib/firmware# cat /sys/class/remoteproc/remoteproc*/state
running
running
offline
offline

But, neither of the versions actually echo anything when I modprobe the client from Linux:

root@AS-3-P-BEEFF1:/lib/firmware# modprobe rpmsg_client_sample count=5
root@AS-3-P-BEEFF1:/lib/firmware# dmesg|tail
[ 273.384556] remoteproc remoteproc1: powering up 5d00000.r5f
[ 273.389843] remoteproc remoteproc1: Booting fw image j7-main-r5f0_1-fw, size 88408
[ 273.391152] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node r5f-dma-memory@a3000000
[ 273.391226] rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
[ 273.391230] remoteproc remoteproc1: remote processor 5d00000.r5f is now up

There is no output in the dmesg.

Regards,

/Bo

  • Hello,

    I have a custom
    board that is built upon SDK 8.6. I have downloaded the latest RTOS PDK version 09_01_00_06.

    Does this mean your SD card was prepared from SDK 8.6 and you only copied latest ipc echo test images of 9.1 ? if so it won't work the SD card should also be prepared using SDK 9.1 setup script.

    lrwxrwxrwx 1 root root 57 Jan 23 15:33 j7-main-r5f0_0-fw -> ti-ipc/ipc_echo_testb_freertos_mcu2_0_release_strip.xer5f
    lrwxrwxrwx 1 root root 57 Jan 23 15:38 j7-main-r5f0_1-fw -> ti-ipc/ipc_echo_testb_freertos_mcu2_1_release_strip.xer5f

    Please use ipc_echo_test_freertos_mcu***_release.xer5f images to link.

    As part of SDK 9.1 by default vision apps binaries are being added as default firmwares .Ensure that vision apps dtbo is not included in uEnv.txt as we have different reserved regions in vision apps and regular ipc echo tests.

    Regards

    Tarun Mukesh

  • Hi Tarun Mukesh,

    I don't know if it is relevant to talk about SDK versions as we are on a custom board without SD slot. We build our U-boot and Linux from the yocto-ti repository, with ti-linux-kernel and ti-u-boot updated to very late versions.

    Linux version 6.1.69, U-Boot version 2023.04

    I tried the file you suggested:

    root@AS-3-P-BEEFF1:/lib/firmware# ls j7-main-r5f0_0-fw -al
    lrwxrwxrwx 1 root root 43 Jan 24 09:18 j7-main-r5f0_0-fw -> ipc_echo_test_freertos_mcu2_0_release.xer5f

    But running modprobe rpmsg_client_sample count=5 is still silent.

    I don't have any vision apps dtbo or any other dtbo. uEnv.txt is not used on our platform.

    How can I be sure that my Linux app (rpmsg_client_sample) is a compatible version with the above xer5f-file?

    Regards,

    /Bo

  • Hi Bo,

    Please share your complete kernel log, and a listing of the firmwares you are using (ls -l /lib/firmware).

    regards

    Suman

  • Hi Suman and Tarun Makesh,

    I'm happy to report that I got it working. I didn't realize that the rpmsg_client_sample.ko actually needed
    som more modules to work. Once I moved all the modules over to the target board, everything worked
    nicely.

    For future reference, these are the modules that I think are needed:

    Module Size Used by

    rpmsg_client_sample 16384 0
    rpmsg_ctrl 16384 0
    rpmsg_char 16384 1 rpmsg_ctrl
    virtio_rpmsg_bus 20480 0
    rpmsg_ns 16384 1 virtio_rpmsg_bus

    Best regards,

    /Bo

  • Hi Bo,

    Yes, all of those modules are required. Glad that you were able to figure it out.

    Normally, when you build the kernel, one would have used modules_install to install all the modules onto the file-system.

    The TI SDK deliberately blacklists the rpmsg_client_sample (otherwise you see 100 messages being exchanged during kernel boot with every remoteproc) to not let is autoload, and a modprobe rpmsg_client_sample is enough to load and have it exchange all the messages.

    regards

    Suman