• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 207 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM6548: Need help accessing mailbox modules from PRUs and RTUs

Michael Deleo
Prodigy 21 points
Part Number: AM6548

We're migrating PRU code from the AM335x processor to the AM6548 and noticed that the Mailbox 0 constant table entry (22) was removed in the AM6548 so it is no longer available in the PRU/RTU local memory space.

We are looking for a simple, thread-safe means of passing data between the ARM A53 cores and the ICSSG PRU/RTU cores.

Internet searches have revealed only examples for the AM335 (BeagleBone black).

Thanks in advance!

Mike

  • +1
    Prodigy 21 points

    Not sure if it's good form to answer your own question but I found a solution that appears to work.  There is likely some inefficiency in reaching outside of the local PRU address space but that could be optimized with an ARM-generated interrupt when a message is posted to the mailbox.

    // AM65x TRM Section 7.1.5
    typedef struct {
        union {
            volatile uint32_t msg_status_reg;
            volatile struct {
                uint32_t num_messages : 3;  // 0-2
                uint32_t reserved : 29;     // 31-3
            } msg_status_reg_bit;
        };
    } mailbox_msg_status_t;
    typedef struct {
        volatile uint32_t message_reg;
    } mailbox_message_t;
    #define MAILBOX0_REG_BASE       (0x31f80000)
    #define MAILBOX_MSG_STATUS      (0xc0)
    #define MAILBOX_MESSAGE         (0x40)
    volatile register uint32_t __R30;
    volatile mailbox_msg_status_t *mailbox0_msg_status = (mailbox_msg_status_t *)(MAILBOX0_REG_BASE + MAILBOX_MSG_STATUS);
    volatile mailbox_message_t *mailbox0_message = (mailbox_message_t *)(MAILBOX0_REG_BASE + MAILBOX_MESSAGE);
    void main()
    {
        volatile uint32_t r30Val = 0;
        volatile uint32_t on = 0;  
        while (1) {

            __R30 = r30Val;

            if (on) {
                r30Val |= (1 << 8);
            } else {
                r30Val &= ~(1 << 8);
            }
            on = !on;
            if (mailbox0_msg_status->msg_status_reg_bit.num_messages > 0) {
                if (mailbox0_message->message_reg == 7890)
                    r30Val |= (1 << 10);
            }

            __delay_cycles(100000);  

        }
  • +1 in reply to Michael Deleo
    TI__Guru* 76435 points

    Hello Michael,

    It is absolutely good form to reply back with a solution if you find one, thank you for doing that!

    Out of curiosity, what OS is running on the A53 cores?

    There are multiple ways to message between cores. Note that there are not any mailbox outputs going to the PRU_ICSSG (I think, late at night right now so feel free to correct if I got that wrong), so the A53 would probably want to use interrupts to notify the PRU cores.

    From a Linux standpoint, in Linux 5.10 and later, we would typically expect to use interrupts to message from the PRU to Linux. The PRU's INTC configuration would be split in half: interrupts going to Linux would be defined in the Linux device tree node of the driver receiving the PRU interrupts, and interrupts going to the PRU cores would be defined in the PRU firmware. More information at https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am65x/PRU_RPMsg_Echo_Interrupt0/intc_map_0.h 

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 21 points

    Nick,

    We're running VxWorks 7 on the A53 cores.

    Thanks for the clarification and link.


    Mike

  • 0 in reply to Michael Deleo
    TI__Guru* 76435 points

    Hello Mike,

    Got it. I won't be able to help much from a VxWorks standpoint, but if you have any followup questions about the PRU, feel free to reply here, or create a new thread if it is a new question.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru* 76435 points

    ah, one more note:

    This is probably more information than you need. But if PRU read/write latencies outside of the PRU_ICSSG are a concern, here is an FAQ I wrote that goes super in depth: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096933/faq-pru-how-do-i-calculate-read-and-write-latencies

    Regards,

    Nick