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

AM335x ARM to PRU interrupt mapping

Ash Charles
Prodigy 160 points


Hi.

I've been getting started using the PRU module on an AM335x-based board following the labs [1].  The labs are working for me but I'm confused by the system event used to signal from the ARM Host (the A8) to the PRU that a rpmsg is available in Lab #5.  Specifically, "#define FROM_ARM_HOST 19" (and the corresponding mapping in the resource table) suggests that the ARM host raises the PRU-ICSS System Event #19 to indicate that a message is available.  It seems like Event 19 though is only generated by the PRUSS, not the ARM host.  There would also have to be some code on the ARM side so Linux knows how to raise this system event when it has prepared an rpmsg for the PRU: something like System Event #60 (which is the mailbox interrupt in the PRU-ICSS) makes sense to me.

I must be getting something backward or missing something---any pointers much appreciated!

[1] processors.wiki.ti.com/.../PRU_Training:_Hands-on_Labs

  • 0
    TI__Guru**** 393215 points
    The PRU experts have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 160 points

    Thanks for passing this along.  Much appreciated!

  • 0 in reply to Ash Charles
    TI__Genius 10440 points

    The ARM/Linux side uses the System Event Status Indexed Set Register (SISR) in the PRUSS INTC to trigger System Event 19 in the example that you are looking into.

    Any master with access to the SISR register can trigger any of the System Events in the PRUSS INTC. However, as you pointed out with System Event 60 (mailbox event), most of the events are triggered by other blocks/peripherals in the SoC and have a specific meaning. So, we decided to use the semi-generic pr1_pru_mst_intr[n]_intr_req System Events for the ARM/Linux to 'kick' the PRU when new messages are available.

    See the device tree include file (arch/arm/boot/dts/am33xx.dtsi) to see the ARM/Linux side of the configuration where PRUSS INTC System Events 16, 17, 18, and 19 and configured to be used for 'vring' and 'kick' interrupts for the two different PRUs.

    Also check out the PRU RemoteProc driver (drivers/remoteproc/pru_rproc.c, probe and pru_rproc_kick functions) and the PRUSS INTC driver (drivers/remoteproc/pruss_intc.c pruss_intc_trigger function).

    Jason Reeder 

  • 0 in reply to Jason Reeder
    Prodigy 160 points
    Ahhhhhh...it all makes sense now. I was using a slightly different kernel tree so the patches adding pruss_intc_trigger and making the changes to the DTs weren't present. It sounds like I should work off the older, mailbox-based examples to work with my kernel. I'm using ti-cgt-pru v2.1.3: are there any changes such that I should grab an older version of this too or should downgrading my pru-software-support-package be sufficient?
  • 0 in reply to Ash Charles
    TI__Genius 10440 points
    Using the v4.0.2 tag of the pru-software-support-package should be sufficient to get back to the mailbox based PRU RPMsg examples.

    git.ti.com/.../v4.0.2