• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 600 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.

AM623: How to add PRU remoteproc at device enum on RPMsg char library?

Rafael Volkmer
Intellectual 380 points
Part Number: AM623

Hello, could you help me with how to access the shared memory (IPC) of the PRU's RPMsg from the MPU? Here, in the RPMsg char library (print below, with the git link), there is this enum to deal with remoteproc, however, there is no support for the PRU. How could I add it here? Is there a default value that can handle it? Would I have to change the logic for PRU addressing? Would I have to access it as a pointer to the protocol's shared memory area?

Can be found at: rproc_id.h « include - rpmsg/ti-rpmsg-char - Unnamed repository; edit this file 'description' to name the repository.

If I need to access with a pointer to the address. In this case, the addressing is 30, isn't it (in this case, the port)? How could I directly reference this address? I'm used to dealing with pointers to hexa content, like, for example ( * (volatile uint32_t*) 0x000123 ). How would I refer to this port 30? I say this since, from what I understand, the PRU's RPMsg communication channel is not started when the board boots, and I have to create it directly within /dev/ to access it. Git and print repository link below:

Can be found at: main.c « PRU_RPMsg_Echo_Interrupt0 « am62x « examples - pru-software-support-package/pru-software-support-package - The PRU Software Support Package (ti.com)

This also opens up another question for me: could I change the channel port to, for example, 15? Or is 30 the default allocated memory from the shared memory devkit and I just create a way to access it?

  • 0
    TI__Guru** 101700 points

    Hello Rafael,

    Apologies for the delayed response - I'm in crunch time for the next 2 weeks, so I've got limited time to work on the forums. If I haven't replied within a couple of business days, feel free to ping the thread to get my attention again. I should be able to be more responsive in June.

    If by "shared memory" you mean "RPMsg message packets", then that is supported with RPMsg IPC (remember, RPMsg always sends 496 bytes of data with every message. So it's fine for sending smaller quantities of data, but if you're trying to transmit kilobytes or megabytes of data, it might be better to do a custom shared memory region and just use RPMsg to notify).

    With RPMsg, the channel name is defined in the Linux driver as "rpmsg-pru".
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_pru.c?h=ti-linux-6.1.y-cicd

    However, as far as I am aware, there is no reason you can't just change the channel port, as long as it doesn't conflict with RPMsg endpoints defined for your other remote cores (M4F & DM R5F). I think we just randomly decided to use endpoint numbers 30 and 31 for the PRU_RPMsg_Echo_Interrupt0 & 1 examples.

    By the way, did you ever try the Linux driver? Did it work, or not really?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 380 points

    Hi Nick! So, about the drivers, I believe you meant in respect to the PRU UART, right?

    We did do some things in this regard, including studying possibilities with serdev (since we are using this in the MPU's serial ADC). It worked, but we saw that we would need more development time to implement it, not because it wasn't more practical, as it certainly is, but because we had already worked a lot on bare metal. I managed to finalize a HAL for the PRU's UART that works perfectly, thanks to the help on the forums and, as this demand is mine and I'm much more used to baremetal than operating on OS, it's a safer environment for me. If you want, I can send you some of the results we had with the UART drivers.

    Regarding the question I asked before, the first part was not clear to me, which is how I could deal with the PRU channel through the enum and what aspects of that routine within the function that receives the elements of that enum as parameters. Could you clarify more for me, if possible?

  • +1 in reply to Rafael Volkmer
    TI__Guru** 101700 points

    Hello Rafael,

    Understood. If it feels like PRU development is a better fit for your development environment, feel free to keep working on that solution!

    Right now, the only PRU Linux-side example involves reading to and writing from the character interface.

    I suspect that we might be able to add PRU cores to the ti-rpmsg-char userspace example as well, but it would take a bit of work. I will not have bandwidth to look into it myself for the next 2 weeks, but if you wanted to try to get it working, this is what I think you would need to do:

    1) Add a new entry for PRU cores https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/tree/include/rproc_id.h

    2) Add the PRU core definitions here: https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/tree/src/soc.c
    y    ou should be able to check the boot logs to see what the name of the PRU cores is, it would be in the form of base_address.pru (probably)

    3) The rpmsg_pru driver is different from the rpmsg_char driver that is currently used by the ti-rpmsg-char project:
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_pru.c?h=ti-linux-6.1.y-cicd
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_char.c?h=ti-linux-6.1.y-cicd

    At this point, I haven't looked into exactly what the differences are, or how easy it would be to get the userspace code to use the rpmsg_pru driver instead of the rpmsg_char driver.

    Regards,

    Nick