AM3356: PRU-ICSS

Nick,

Thanks for the reply.

I just now realize that the PRU is a small CPU  with only 8KB of instruction &  data RAM. So my understanding is that up to 8 Kbytes of code can be loaded to PRU and this means that I should carefully consider what can be populated in those 8 Kbytes of instruction code. 

We consider 3 alternatives:

1. To use the PRU as a dedicated CPU which periodically sends/receives Ethernet packets from/to the shared memory. In this design the ARM main core will read/write the shared memory for data.

2. The main ARM core periodically sends/receives Ethernet packets through the PRU Ethernet port 

3. The main ARM core periodically sends/receives Ethernet packets through the CPSW Ethernet port

Question:  Is there any advantage of option 1 over option 2 & 3  (in CPU load time of the ARM core) ?  Is option 2 heavier in ARM core load than option 1? Is option 3  heavier in ARM core load than option 2 or 1? 

Option 1 looks more deterministic in sending/receiving data (Ethernet packets) from/to the  shared memory in PRU, however  for the main ARM core it also depends on the rate the shared memory is read/updated. 

Option 3 looks better, because we do not have to make any change in software and hardware.

Please your opinion.

Hello Martin,

Option 1: This is not a usecase TI supports. The PRU core handles getting signals into and out of the chip, and then a different core handles the networking stack. On AM335x that different core is the ARM core, while on later devices like AM64x the networking stack can be handled by the Linux A53 cores or the RTOS R5F cores.

For a general purpose Ethernet usecase, I am not aware of specific benefits to using PRU Ethernet instead of CPSW Ethernet. The primary benefit would be if your usecase needs 3-4 Ethernet ports instead of 1-2 Ethernet ports.

If you are not using the PRU-ICSS, you may consider using a different AM335x part number, like AM3354, where the Linux core can run at up to 1000MHz. That could get you slightly more performance out of the ARM core.

On the other hand, if your Linux core is spending a bunch of cycles doing non-networking tasks like monitoring an external voltage value, that is the kind of task that you could offload to the PRU subsystem. Let me know if you have additional questions about PRU.

Regards,

Nick

I double-checked with the engineer who supports CPSW Ethernet, and he confirmed that he would expect CPSW Ethernet to have the same or less ARM processing required to do Ethernet than PRU Ethernet. That combined with CPSW Ethernet supported on all AM335x Linux SDK releases would lead me to suggest using CPSW Ethernet for your usecase.

Regards,

Nick

Hello Nick,

Thanks again for  your answer.

I am not familiar with the code  & architecture of the Ethernet subsystem in the PRU and how it interconnects with the AM335x main core.

I assume that the Ethernet driver on the AM3356 core somehow transfers/receives the Ethernet data packets to/from the PRU. I assume that the PRU implements the MAC layer and controls the MII lines which are connected to a PHY. Am I correct?

The guys from my team insist to clarify the following option:

Is it is feasible (possible) to  change the Ethernet driver within the PRU in a way that it will aggregate several incoming Ethernet or UDP packets to a one packet and forward the single aggregated packet to the AM335x ARM core. The idea is to reduce the time of serving multiple packets to one incoming packet . I am not sure if I have the ability to control within the PRU the Ethernet data traffic which goes through the PRU to the AM335x main core Ethernet driver. 

Please advise on this issue.

Hello Martin,

It has been a while since I dug into exactly where the division of labor occurs between the Linux Ethernet driver and the PRU firmware, but your assumption is generally correct. For more information, refer to the SDK docs, starting at section "How It Works"

https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/08_02_00_24/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU-ICSS_Ethernet.html

Another thing you'll note is that the AM335x's PRU-ICSS version of PRU Ethernet uses a shared memory strategy to pass frames between Linux and the PRU, instead of using DMA. That is another point in favor of CPSW, as I believe that uses DMA for data transfer.

What about aggregating Ethernet packets?

From a "modify how the Ethernet driver / PRU firmware works" standpoint:
I would NOT suggest trying to modify the Linux driver / PRU firmware interface. Technically I can point you to the PRU firmware source code, but it is very complex, undocumented assembly code. The interface also changed from SDK 7.3 --> SDK 8.2.

I would expect that the Linux ethernet driver has an option to aggregate packets instead of interrupting the ARM core every single time a TX packet is received. I would look into that option with CPSW before trying anything with PRU Ethernet.

I'm reassigning your thread to the CPSW guy if you have followup questions about that subject.

Regards,

Nick

Actually, I'll hold onto the thread for a bit longer.

Please start by taking a look at 
https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_01_00_001/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW.html

section "Interrupt Pacing"

Regards,

Nick

No problem Martin!

One additional note on interrupt pacing - I would expect that to help with RX Ethernet packets (though I'm not sure how much it would improve things since I have not tested myself). That would not lower processor load for TX Ethernet packets generated by the ARM core though.

Regards,

Nick