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

AM6442: How is PRU Ethernet initialized?

Jared Weyer
Prodigy 196 points

Other Parts Discussed in Thread: SYSCONFIG

For future readers, this is a continuation of the discussion at  AM6442: Single port network topology DT setup  

Hey Nick,

Thank you, this is helpful!

I know you are reassigning for help with the fiber question; however, I have one more question that I think you could answer for me:

3) It is my understanding that the ti-prueth driver configures the pinmux and that remoteproc uploads the ethernet firmware. I am assuming that sysconfig is used to build the ethernet firmware that is loaded onto the PRUs. If this is the case, how does the pinmuxing defined in sysconfig not conflict/overwrite the pinmux setup by ti-prueth?

Thanks again,

Jared

  • 0
    Prodigy 196 points

    Hello,

    Any update on this?

    Thanks,

    Jared

  • 0 in reply to Jared Weyer
    TI__Guru 51011 points
    Jared Weyer said:
    I am assuming that sysconfig is used to build the ethernet firmware that is loaded onto the PRU

    sysconfig is javascript based tool which helps with resource management like pinmux, memory and MPU configuration etc. PRU firmware excepts Linux or RTOS application to setup pinmux. So basically, only relies on PRU-CGT IDE, configuration, compiler or debugger | TI.com

  • +1 in reply to PratheeshGangadhar
    TI__Guru** 110030 points

    Giving additional information on top of Pratheesh's comments:

    PRU cores are capable of reading & writing to the processor's pinmux registers. So the PRU cores could potentially do their own pinmux settings, but that does not mean that is what is actually done for a specific usecase.

    As Pratheesh said, the PRU Ethernet firmware acts like an Ethernet peripheral for whatever software instance is interacting with it. A "normal" hardware peripheral wouldn't set it's own pinmuxing, and so we designed the PRU Ethernet firmware to act the same way. Thus, it is the responsibility of Linux to configure pinmuxing for the PRU subsystem for PRU Ethernet.

    If you take another look at the Linux devicetree nodes for PRU Ethernet, you'll see pinmux settings linked there. The Linux kernel applies the pinmux settings during boot time.

    Wait... how do I prevent conflicts between Linux and MCU+ SDK pinmux settings? 

    Linux typically does the pinmuxing for the peripherals that Linux controls, while an MCU+ core does the pinmuxing for the peripherals that MCU+ core controls. So how do you make sure that those pinmux settings do not conflict?

    dev.ti.com sysconfig allows you to generate pinmux settings for your processor, and then you can divide up those pinmux settings between the processor cores.

    FYI: Multicore academy might be helpful for your team

    If you are also doing MCU+ development on the R5F cores, I would strongly suggest taking a look at the AM64x Multicore academy. If you have questions about the academy feel free to create e2e posts. I am the Multicore academy author, so you'll come back to me.

    Based on this question, you may be interested in learning how to avoid peripheral conflicts between Linux & MCU+ cores:
    AM64x multicore academy > Peripherals
    https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AaRdsK4zRjlChfPY2v0AhQ__AM64-ACADEMY__WI1KRXP__LATEST

    many customers like to get their hands dirty by starting with the "Application Development on Remote Cores" section, and then jumping to the different topic sections for more information as needed: https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AfSHr0vWbFdGCnmoPeMXzg__AM64-ACADEMY__WI1KRXP__LATEST

    Regards,

    Nick