• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 980 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM625: Issues with RPMsg control devices

Leon Rigoni
Intellectual 325 points

Part Number: AM625
Other Parts Discussed in Thread: AM6442

Dear TI,

I am trying to establish an RPMsg communication channel between Linux userspace and the M4F remote core.

The demo echo works fine, but when I use my own remote core firmware, it stops working. This is what I do:

1. I load my remote core firmware via CCS debugger
2. I run the following script:

rmmod virtio_rpmsg_bus
rmmod rpmsg_ctrl
rmmod rpmsg_char
rmmod rpmsg_ns
modprobe virtio_rpmsg_bus
modprobe rpmsg_ctrl
modprobe rpmsg_char
modprobe rpmsg_ns

which outputs

[ 9224.468197] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 9224.474779] virtio_rpmsg_bus virtio1: rpmsg host is online

3. I launch the remote core firmware via the debugger
4. I run rpmsg_char_simple on Linux

This is what I get:

root@am62xx-evm:~# ./rpmsg_char_simple -r 9 -n 3 -p 14
_rpmsg_char_find_ctrldev: could not find the matching rpmsg_ctrl device for virtio0.rpmsg_chrdev.-1.14
TEST STATUS: FAILED

My echo task on FreeRTOS calls RPMessage_waitForLinuxReady(SystemP_WAIT_FOREVER), then it creates the socket and calls RPMessage_announce(), just like in the demo project.

Can you tell me what I am missing?

Kind regards,

Leon Rigoni

  • 0
    TI__Mastermind 28150 points

    Hi,

    Thanks for your query.

    Our expert will look into this and get back to you.

    Regards

  • 0
    TI__Guru** 109580 points

    Hello Leon,

    Since you are already connected via CCS, please use the CCS debugger to check where the M4F is in its code.

    My suspicion is that since you are initializing the M4F from CCS instead of from the Linux remoteproc driver, Linux has no way of knowing that the remote core is live. So the M4F is just sitting at RPMessage_waitForLinuxReady(SystemP_WAIT_FOREVER).

    Please use Linux to initialize the remote core, as documented here:
    AM62x academy > Linux module > Evaluating Linux > Booting remote cores
    https://dev.ti.com/tirex/explore/node?node=A__AckaMLLzyxszvNaSLSFIQg__AM62-ACADEMY__uiYMDcq__LATEST

    Then you can attach the CCS debugger to the M4F after Linux has already initialized the M4F. See steps here:
    AM62x academy > Multicore Module > Application Development on Remote Cores
    https://dev.ti.com/tirex/explore/node?node=A__AVn3JGT9fqm0PbS.pegO-g__AM62-ACADEMY__uiYMDcq__LATEST 

    You should understand this whole page ^, but the specific steps I'm referring to are in section 
    "How to debug a remote core while Linux is running"

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 325 points

    Hello Nick,

    I have now changed my setup: The remote core gets booted from Linux while Linux is starting up. When I connect with CCS, my FreeRTOS is up and running.

    The error however is still there.

    From the logs I see something weird: There are two virtio channels set up:

    [ 3.488384] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
    [ 3.510692] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xe

    I wonder why this happens, because I announce only one channel with port 14 on the remote side. Where does this other channel come from? What triggers those messages in the first place? Is it the call to RPMessage_announce() on the remote core?

    I am having some trouble understanding the demo project:

    - The demo project creates two echo tasks, but I only need one (for the user space). So is it enough if I only create the task with endpoint 14?
    - What is the point of IpcNotify_registerClient()? Why do I need a callback? I was also experimenting with the AM6442, and this function wasn't used there.

    If I want to implement a simple one-shot echo slave on the remote core, the way I understand it I need to call the following functions in that order with reasonable parameters:

    RPMessage_waitForLinuxReady()
    RPMessage_CreateParams_init()
    RPMessage_construct()
    RPMessage_announce()
    RPMessage_recv()
    RPMessage_send()

    Am I missing something important here?

    I'm sorry for this bloated question, so thanks a lot in advance.

    Kind regards,

    Leon

  • +1 in reply to Leon Rigoni
    TI__Guru** 109580 points

    Hello Leon,

    Ok, there are a couple of different things to chat about here.

    VIRTIO channels

    First off, let's look at the default output on boot.

    root@am62xx-evm:~# dmesg | grep virtio
[    6.387078] rproc-virtio rproc-virtio.1.auto: assigned reserved memory node m4f-dma-memory@9cb00000
[    6.409044] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[    6.533806] virtio_rpmsg_bus virtio0: rpmsg host is online
[    6.534148] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[    6.558251] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[    6.815444] rproc-virtio rproc-virtio.3.auto: assigned reserved memory node r5f-dma-memory@9da00000
[    6.827246] virtio_rpmsg_bus virtio1: rpmsg host is online
[    6.827933] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
[    6.841104] rproc-virtio rproc-virtio.3.auto: registered virtio1 (type 7)
[    6.841349] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
root@am62xx-evm:~# dmesg | grep remoteproc
[    6.239272] k3-m4-rproc 5000000.m4fss: configured M4 for remoteproc mode
[    6.304672] remoteproc remoteproc0: 5000000.m4fss is available
[    6.328877] remoteproc remoteproc0: powering up 5000000.m4fss
[    6.334958] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 55016
[    6.416064] remoteproc remoteproc0: remote processor 5000000.m4fss is now up
[    6.745419] remoteproc remoteproc1: 78000000.r5f is available
[    6.796687] remoteproc remoteproc1: attaching to 78000000.r5f
[    6.848041] remoteproc remoteproc1: remote processor 78000000.r5f is now attached

    Why are there two different channels there? It comes from this part of the sample code at
    examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c

    /*
 * Remote core service end point
 *
 * pick any unique value on that core between 0..RPMESSAGE_MAX_LOCAL_ENDPT-1
 * the value need not be unique across cores
 *
 * The service names MUST match what linux is expecting
 */
/* This is used to run the echo test with linux kernel */
#define IPC_RPMESSAGE_SERVICE_PING        "ti.ipc4.ping-pong"
#define IPC_RPMESSAGE_ENDPT_PING          (13U)

/* This is used to run the echo test with user space kernel */
#define IPC_RPMESSAGE_SERVICE_CHRDEV      "rpmsg_chrdev"
#define IPC_RPMESSAGE_ENDPT_CHRDEV_PING   (14U)

    That is there so that the out-of-the-box example is compatible with both the ti-rpmsg-char userspace example (which uses rpmsg_chrdev, try going to the ti-rpmsg-char repo and doing grep -r 'rpmsg_chrdev), and the kernel's generic rpmsg example at samples/rpmsg/rpmsg_client_sample.c (which uses ti.ipc4.ping-pong).

    So if you aren't trying to interact with the kernel example, there is no reason to have that second channel.

    You can actually have multiple remote core endpoints all using the same channel. Check out more information here:
    AM62x academy > multicore module > How to Develop with RPMsg IPC > "How to add multiple RPMsg endpoints to a remote core running RTOS?"
    https://dev.ti.com/tirex/explore/node?node=A__AVjm7chph.4Q-bCWodAr.w__AM62-ACADEMY__uiYMDcq__LATEST 

    If you are trying to start with a Linux userspace example and you are basing it off of ti-rpmsg-char, I would try using rpmsg_chrvdev, like I do in that multiple endpoint example linked above.

    Graceful shutdown enablement 

    You asked about IpcNotify_registerClient(). THAT is what this code is for. Try searching the sample code for RP_MBOX.

    If you are comparing against AM64x, you'll see that this same code got added in starting in SDK 9.1.

    For more information about the concept of graceful shutdown, refer to 
    AM62x academy > multicore module > How to Develop with RPMsg IPC > "Graceful shutdown"
    https://dev.ti.com/tirex/explore/node?node=A__AVjm7chph.4Q-bCWodAr.w__AM62-ACADEMY__uiYMDcq__LATEST 

    For more details on the specifics of the MCU+ side code, refer to the MCU+ SDK docs
    https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/09_01_00_39/exports/docs/api_guide_am62x/GRACEFUL_REMOTECORE_SHUTDOWN.html

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 325 points

    Hello Nick,

    Thanks a lot, this helps. I got a simple message exchange to work now. Just one thing is not working as expected:

    The way I understand it, the function RPMessage_recv() should give me the core ID of the core who sent me the message (in this case it should be 2 as in CSL_CORE_ID_A53SS0_0, right?). I can then use this value to send the response back to the same core.

    However, the function gives me a core ID of 0, but I have to send the response back to core ID 2, otherwise it is not received. It works in the demo project though. I can of course just ignore the core ID returned from RPMessage_recv(), but it would be nice to know what's happening there.

    Kind regards,

    Leon

  • 0 in reply to Leon Rigoni
    TI__Guru** 109580 points

    Hello Leon,

    FYI, based on your experience I am working with the Linux dev to remove the references to ti.ipc4.ping-pong in the ti-rpmsg-char repo. Thanks for creating the thread.

    Hmm, I have not heard of an issue where someone was unable to use the remoteCoreID that was passed in by RPMessage_recv. Feel free to attach code snippets of RPMessage_send & RPMessage_recv if you want me to take a look.

    If you are going to send the first RPMsg from Linux, you should be able to just wait on the remote core side for the first message, and then save that information for useage later. If you want to send the first RPMsg from the remote core, you'd need to set a fixed endpoint on the Linux side (in the default example, the Linux endpoint number is auto-generated), and hardcode that information in the remote core firmware. I haven't had time to write documentation about how to do that yet, but I can provide some additional information about how to do that if you need.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 325 points

    Hello Nick,

    Thanks a lot for the information, Ishould be able to take it from here.

    Kind regards

    Leon