AM625: PRU HW UART driver

Hello Tony,

This example is for the PRU cores to control the hardware UART instance within the PRU subsystem.

If the customer wanted to enable Linux to control the PRU UART instance, that would require separate code. i.e., porting the code from AM335x that was added in SDK 7.3:
https://software-dl.ti.com/processor-sdk-linux/esd/docs/07_03_00_005/devices/AM335X/linux/Release_Specific_Release_Notes.html 
https://software-dl.ti.com/processor-sdk-linux/esd/docs/07_03_00_005/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pruss-uart.html 

QUESTION #2. Can PRU HW UART be controlled by A53 in Linux directly? One customer wants to use PRU-eth and PRU HW UART together (5 Ethernet and 10 UART on AM64x), I think currently firmware can't support together.

Yes, the PRU HW UART can be controlled by the Linux A53 cores directly. In fact, we have a customer who is programming Linux <--> PRU core <--> PRU UART, but only for their very specific usecase. For most customers, I would suggest that if Linux is sending and receiving UART packets, you want Linux to control the hardware UART instance directly (i.e., Linux <---> PRU UART).

For future readers, AM62x has PRUSS, while AM64x has PRU_ICSSG - for details on the differences, refer to https://www.ti.com/lit/sprac90

PRU Ethernet is only supported on the AM64x, not the AM62x.

Technically, the Linux driver for PRU UART should not do anything to the rest of the PRU subsystem other than make sure that it is clocked (i.e., the Linux PRU UART driver will not try to load firmware into any of the PRU cores, it will not read or write to the PRU IMEM or DMEM, etc).

As far as I am aware, if Linux A53 is using the PRU's internal bus to access the PRU UART, it should NOT impact the PRU cores' abilities to access memory or other parts of the PRU subsystem. That is based on https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096933/faq-pru-how-do-i-calculate-read-and-write-latencies 

There are no buffers between the PRU core and memory internal to the PRU subsystem. Thus, if another core is using an endpoint connected to the ICSS CBASS bus, the PRU core has to wait for the endpoint to become available before it can perform a write.

The internal CBASS interconnect is "fully switched". That means that multiple cores can use the CBASS simultaneously, as long as the cores are accessing different endpoints. e.g., PRU0 can access DRAM at the same time that PRU1 is accessing the PRU's hardware UART.

If needed, I can double-check with the hardware designer on whether Linux <--> PRU UART and PRU Ethernet should be possible within the same subsystem.

We have not yet ported the Linux PRU UART driver from AM335x to AM62x, but there is a requirement to add that feature at some point. I am not currently aware of any requirements to add the driver for AM64x.

Regards,

Nick

Hi, Nick,

Very clear, I got my answer. 

some more detail questions, you can look into when have time. 

Nick Saulnier said:

For most customers, I would suggest that if Linux is sending and receiving UART packets, you want Linux to control the hardware UART instance directly (i.e., Linux <---> PRU UART).

#1. Can use DMA in this use case on AM64/AM62x? there is event route PRU HW UART to GICSS

#2. Can route/mapping PRU interrupt to GICSS without PRU firmware running? just configure the PRU host interrupt mapping register in PRU-ICSS?  If there is other firmware like PRU ethernet running on the PRU-ICSS, is it still workable? 

Device Drivers  --->
      IRQ chip support  --->
              <M>   TI PRU-ICSS Interrupt Controller

Hello Tony,

Will take a couple days for me to followup on this, still trying to catch up from travel. Feel free to ping the thread if I haven't replied by Friday.

Regards,

Nick

Tony 

Nick is ooo till July 15th. This will need to wait till he returns. As of now there is no support for this in the SDK, so any guidance will be best effort basis and we will need to follow up with proper request into the SDK to add support for this - best case would be end of the year SDk10.1 time frame. 

Hello Tony,

I am back and slowly working through all the threads, apologies for the delay. Is this something you still need us to look into?

Regards,

Nick