• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 3089 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.

ARM to PRU memory sharing using remoteproc

bwilcutt
Intellectual 310 points

I've seen a lot of examples on how ARM can access PRU memory and vice versa.  However, it is very confusing.  Even here there are answers to this very question that don't seem to help with my issue which is...

1. Using pruss_remoteproc -- no pru_drv uio driver.

2. Need to share a memory structure between ARM and PRU1, currently located on PRU1 but can be either place.

3. ARM side interface code is a custom UIO driver.

Is it as simple as finding and accessing the PRU base memory pointer?  Should I use PRU memory or ARM memory to store the shared structure?  No kernel space programming is involved and I don't want to use the pru_drv uio driver because, as I've been told, it is going away and being replaced by the pruss_remoteproc.

Is there any examples?  The labs all seem to use the pru_drv uio driver which isn't an option for me.

Thanks,

B

  • 0
    TI__Mastermind 25866 points

    Just got this working recently though someone who understands this better might be able to clarify my comments to your comments below.

    >>1. Using pruss_remoteproc -- no pru_drv uio driver.

    Yup. I was also moving from uio driver (on AM335x Linux SDK6.0)  And from what I understand if you fully install all modules (make ARCH=arm INSTALL_MOD_PATH=/media/rootfs modules_install), the PRU code gets loaded at boot.  Since we were debugging, we manually copied the built modules to the filesystem and manually did the insmod.

    >>2. Need to share a memory structure between ARM and PRU1, currently located on PRU1 but can be either place.

    Not sure what you mean by "currently".  From what I understand this is all configurable.

    >>Is it as simple as finding and accessing the PRU base memory pointer? 

    Not sure if you need to. All the driver code source is available in the kernel at  /drivers/remoteproc . Why not just use the parts you need?

    >>Should I use PRU memory or ARM memory to store the shared structure? 

    From what I understand, this is automatically being done.

    >>No kernel space programming is involved and I don't want to use the pru_drv uio driver because, as I've been told, it is going away and being replaced by the >>pruss_remoteproc. Is there any examples?  The labs all seem to use the pru_drv uio driver which isn't an option for me.

    Agreed but where do you see pru_drv uio driver being used?

    On my filestem I put the 3 modules (from http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Part_2:_User_Space_Communication ) in /lib/modules/3.14.43-g875c69b/kernel/drivers/remoteproc/pruss_remoteproc.ko

    BTW I started with Lab 6 since I had a BB with PRU Cape.  But realized you can run the above Lab 4 Part 2 on ANY AM335x target since you are just sending strings back and forth with the .echo "Hello" and cat commands.

    Also please note (that I found out later) that there are multiple versions of the PRUSW Package available that are supported on different versions of Processor SDK Version (I was using PRUSW Package 3.0 on Processor SDK Linux 01.00.00.03):

    http://processors.wiki.ti.com/index.php/Processor_SDK_PRU-ICSS_Add_On_Package

    Hope this helps!

  • 0 in reply to Joe G.
    TI__Mastermind 25866 points
    >>But realized you can run the above Lab 4 Part 2
    Sorry meant Lab 5 Part 2.
  • 0 in reply to Joe G.
    Intellectual 310 points

    Joe,

    Thank you for your response!

    I think you misunderstood.  I have two apps-- one on the ARM, one on the PRU.  They talk to each other through a "shared" structure (struct mystruct {... }.)   What I am trying to do is determine which app should instantiate the structure (ARM or PRU) and once instantiated, how do I get the other side (ARM or PRU) to talk to it?     It appears passing a pointer around that points to mystruct isn't going to cut the mustard and there doesn't seem to be any real definitive "shared memory" examples out there. 

    It's been years since I've done any Linux programming, I live primarily in the VxWorks world for embedding programming (ohhhhh so much easier than Linux).  So, I'm inexperienced with some of the newer Linux "virtual addressing" concepts.

    "Also please note (that I found out later) that there are multiple versions of the PRUSW Package available that are supported on different versions of Processor SDK Version (I was using PRUSW Package 3.0 on Processor SDK Linux 01.00.00.03):"

    Which drives me nuts... as for pru drv... it doesn't exist.  I've terminated that code from my system, formatted the sectors it was in, scratched the disk with a pin just to be sure-- and I am ONLY dealing with pruss_remoteproc.  I had to choose sides and take a stand; Orc or Human.

  • 0 in reply to bwilcutt
    Intellectual 310 points
    Btw, Joe, sharing the data structure between the two apps (PRU and ARM) is only for configuration purposes. Neither side will access the structure except in initiation stages-- but normal run-time, they won't. So, in this instance the structure isn't a "message" that is going back and forth that often.
  • 0 in reply to Joe G.
    Intellectual 310 points

    Update:  I've spent about a week trying to get the rpmsg driver to create an entry into the /dev directory such as "/dev/rpmsg_pru31".

     

    No luck.

    So I'm back trying to see if I can get the pruss_remoteproc driver to reserve DDR for the PRU.  If I can get that to work, I can just use direct addressing [of course, the Linux side has to do a mmem_map op).

    Problem is I'm doing a system that hasn't been done before and there's not a lot available out their for guidance.


    I'll update this thread if/when I get a solution.

    Thanks,

    B

  • 0 in reply to bwilcutt
    TI__Mastermind 25866 points

    >>Update:  I've spent about a week trying to get the rpmsg driver to create an entry into the /dev directory such as "/dev/rpmsg_pru31".

    Are you doing this in Linux?

    If so there is an updated "Quick Start" Wiki: http://processors.wiki.ti.com/index.php/RPMsg_Quick_Start_Guide 

    >>I live primarily in the VxWorks world for embedding programming

    If on this platform, I not very familiar with RTOS beyond TI RTOS/DSPBIOS (or understand how you can get a Linux file structure in a RTOS).

    But the host side remoteproc source code is available in the Linux kernel that you could look at for reference: https://github.com/torvalds/linux/tree/master/drivers/remoteproc