AM5K2E02: Rx Flow configuration with no firmware

Hi

We have compared the registers as suggested & there is no problem within the GbE switch itself.  We have used the port statistics registers to confirm that that packets are being received on this port.  During testing (working and non-working port (3) ) we have configured a single port only.

The Thread Mapper is set to its default (0) value in both tests.  We think that this is correct for routing data from Host 0 on the GbE to the Global PktDMA.  We do not think thread priorities are required in this simple test.

The queue numbers and flow ids are allocated in exactly the same way for both the working port and the non-working port.  We have looked queue peek registers on the working and non working port (3).  On the working port we can see the byte/packet counts increasing and the allocated Rx buffer in memory contains the packet data.  We do not see this in the non working build. 

For some reason the information in the Host Descriptor does not seem to be acted on.

If we rebuild with the TI firmware enabled & the Thread Mapper configured and no changes to the flow/rx channel configuration, all ports work.

No RTOS is being used

Hi

The firmware is for the PAs in the NETCP & the Accumulators in the QMSS.  (bin files).  I have four test builds:

#1 Firmware enabled using Port 1 (Tx/Rx both okay)

#2 Firmware enabled using Port 3 (Tx/Rx both okay)

#3 No firmware using Port 1  (Tx/Rx both okay)

#4 No firmware using Port 3  (Tx okay, Rx does not work)

The builds transmit and receive simple UDP packets.  Packet reception is triggered by a simple interval timer and the use of Qmss_getQueueEntryCount().  The difference between build #3 & #4 is minimal - just the port number we poll & the IP address in the packets changed.  We do not change the rx flow or channel configuration in any of the builds (#1, #2,#3, #4). We do change the queue used.

Build #4 - the Qmss_getQueueEntryCount() does not change from 0

We have used the JTAG to analyse the registers and cannot see any differences that would affect the Rx functionality. We have also compared the register configurations against the TI Uboot build which we have working on both Ports 1 & 2.  The are some limitations to this method; some registers are write-only and the read of these locations simply returns 0. To work round this, we have added some global variables to the code to store the values that we write to these registers.  These can be inspected via the JTAG debugger (Lauterbach).

When we use builds that load firmware, we see that the Thread Mapper registers have 0x02 for each thread indicating that data is routed from GbE Host 0 to Ingress-0.  This is expected.  When we do not use firmware, the value is set to 0 indicating that data is routed straight to the Global PktDMA.  (Setting it to any other value does work when tested on build #3) This follows section 3.1 of SPRUHZ0 (Aug14).  Do you know if there is a later release of this document ? (The code in Pa_create indicates 16 registers to cover all threads - section 3.1 looks incomplete).

• Do you think that the thread mapper should have a value other than 0?
• Should we be setting the src tag & dest tag in the Host Packet Descriptor when we configure the Rx Flow or should we let the back end application (GbE) add this? We have assume that he back end does this - we do not set this field in builds that use firmware (#1 & #2).
• Should it be possible to use any General Purpose Queue for packet reception (Rx Q) and as a free descriptor queue (FDQ)?  I have assumed that because we are not using the accumulation firmware, that queues which perform accumulation should be avoided. 

Progress has been made on this matter.

Cppi_RxFlowCfg is the key to this problem.  We found that the flowIdNum has a close relationship to the Ethernet port number.  Setting flowIdNum  = CPPI_PARAM_NOT_SPECIFIED with firmware removed causes Rx not to work. Cppi_configureRxFlow will allocate its own flowIdNum causing the failure.  To make the system work without firmware the flowid must use value of 0-7 for Eth Port 1, 8-15 for Eth Port 2, 16-23 forEth Port3.  This is not clear in SPRUG9RH that this needs to be done.  However, we have assumed that not many applications avoid the use of the firmware.

============================

The following has been extracted from the documentation for any other developers planning to venture down a no firmware route

It is important to note that there is not a correspondence between RX channel and RX flow, but rather between RX packet and RX flow. For example, one peripheral may create a single RX flow for all packets across all channels, and another may create several flows for the packets on each channel.

SPRUG9RH p25:

In nonloopback cases, the RX flow is specified in the packet info structure of the Streaming I/F. In the event no RX flow is specified, the RX DMA will use RX flow N for RX channel N

When packet reception begins on a given channel, the port will begin by fetching the first descriptor (or for host packets, descriptor + buffer) from the queue manager using a free descriptor queue that was programmed into the RX flow being used by the packet

SPRUG9RH p135

1. Streaming I/F Overrides:

(a) flow_index. A value of 0xFFFF (or a value >= the number of RX Flows) will cause the RX DMA to use the channel (thread) number for flow_index. So, an RX Flow is always used, even if not directly specified.

SPRUG9RH p137

How should RX flows and channels be used?

The first step is to recognize that the RX DMA is driven from the RX streaming I/F. Each transaction for a

packet is received from the streaming I/F, and contains a channel number. This number will not change for the entire packet’s reception (and once a packet starts on a channel, that channel is dedicated to that packet until it completes). The channel number is determined by the programming of the peripheral (because it is the peripheral that drives the RX streaming I/F).

p138:

So, it is not a matter of the peripheral finding an enabled channel, but rather the peripheral using a specific channel whether or not it is enabled (and if not enabled, no data will pass through).

The matter is closed, however it would be useful if you confirm the relationship between the flows and the Ethernet ports.  Could you clarify which document states this?  If you can to this please reply with your findings and then set the thread to Resolved..