OMAP-L137/138 EMAC programming

Steve,

Can you clarify what section in the user guide says that the NEXT descriptor field links cannot be modified?  It's a long doc so there may be typos with conflicting information.  Looking at Section 2.5.2, the doc says that it is possible to modify the NEXT descriptor field, but care must be taken to avoid a race condition:

EMAC User Guide, Section 2.5.2 said:

The HDP must never be written to while a list is active. To add additional descriptors to a descriptor list already owned by the EMAC, the NULL “next” pointer of the last descriptor of the previous list is patched with a pointer to the first descriptor of the new list. The list of new descriptors to be appended to the existing list must itself be NULL terminated before the pointer patch is performed.

There is a potential race condition where the EMAC may read the “next” pointer of a descriptor as NULL the instant before an application appends additional descriptors to the list by patching the pointer. This case is handled by the software application always examining the buffer descriptor flags of all EOP packets, looking for a special flag called end of queue (EOQ)....

If you want to be extra safe about the potential race condition and you are communicating with a flow-control-enabled PHY, you could use RXnFREEBUFFER and RXnFLOWTHRESH to assert a pause request when your driver is running low on available buffers.

Once the OWNER flag for a packet has been cleared by EMAC, the CPU software can take over the associated descriptors/buffers without contention.  The EMAC hardware will not touch them again.

-Tommy

Hi Tommy,

Thanks!

Both sections 2.5.4.1 and 2.5.5.1 of SPRUFL5A mention how a descriptor next link can never be touched once in an active list - unless it is NULL. This leads me to wonder if (A) the list is always scanned from the associated RXnHDP to the next empty buffer to be filled. If this is so - you could never reuse the descriptor's next link as it is being used to *hold* the list together. Or (B) the hardware maintains some internal pointer that is kept pointing at the next descriptor after the last descriptor used i.e. the OWNER/EOP/EOQ bits.

Really there is not concise enough information in the documentation to effectively engineer a *clean* solution. Makes me question it...

I do not like (A). To avoid having an EOQ situation where software may not be able to introduce a new list to the RXnHDP before dropping a packet, you would have to continually chain off the end of an over growing list *AND* you would not be able to reuse any of the descriptors. UGLY! Perhaps you could reuse a used descriptor by making a new buffer available and then allowing the EMAC to see it via the OWNER bit. Caveats are not knowing then which is the next sequentially received buffer as well as fragmented over more than 1 descriptor issues...

(B) is better. BUT need to know it really works this way. Let me know what you can find out. Can also experiment a bit on my own --- but eventually need something I can rely on in production code!!!! Documentation should reflect (B) if it indeed works that way...

Also I cannot really hold off a sender with some form of flow control as you alluded to with the PHY in our system design. This avenue would not be a preferred solution...

Appreciate your time and effort - thanks again!

Steve Speier

Steve,

My experience with the EMAC controller points to (B).  There's a simple state machine which advances the HDP through the linked list as each descriptor is processed.  The underlying hardware has no comprehension of the length or nature of the list.

I think the documentation is just trying to make users extra cautious when updating the descriptor list.  With the Tx/Rx FIFOs, the EMAC can advance through descriptors faster than the line speed bit-rate (this would apply mostly to Tx).  Given the potential race conditions, it's safer to only modify the end NULL pointer.

-Tommy

Hi Tommy - again,

And Happy Thanksgiving coming up! If not celebrating -- it's the thought that counts and hoping you're having a good day!

(B) makes the most sense to me as well on the hardware side. It allows for reuse of the descriptors and it's not a real problem for software to maintain where the start of the empty list is.

Thanks for the help!

Steve Speier

Hi All - again,

I'm looking for help again with getting ethernet going on a LOGIC PD OMAP-L138EVM. I've followed the 1-2-3 steps outlined in SPRUFL5A. I can send a TX ethernet packet, but nothing will be received. I've got RXMBPENABLE set to allow broadcast reception. Plenty that I can see on the network, an active link, but never see any of them. Also the statistics registers see no RX activity of any kind...

Before I post code -- is there any known issue possibly left out of SPRUFL5A? I've followed all I can see being in 2.15.4 and 2.10.1. Again I can write ethernet packets with the configuration I've got...

Thanks for anyone's time!

Steve Speier

Steve,

Have you taken a look at the Logic PD BSL EMAC loopback test?  It is a working, basic reference for transmitting & receiving EMAC traffic.

-Tommy

Hi again Tommy--

Happy *December* holidays now :-)

I have been using bits and pieces from the Logic PD BSL sources. Not 100% in many case - you have to mindful they were written more in mind for use with the DSP I think...

Had not even thought of this - focused on finding more info on this complex controller! So nice idea -- will let you know -- thanks!

Steve Speier