FEC drivers 525x 5225x

[francois_boucha]

Hi,

I'm writing some basic drivers for the Ethernet controller (5282 and 52259).  there is no TCP/IP stack, just plain Ethernet.

functions:

I got a problem when I send a packet, it is transmitted but its destination address get corrupted.

Exemple: I'm sending to a device at 00:bb:bb:bb:bb:22

Problem is, receiver never get the message, and the actual destination address I see in wireshark is : bb:22:bb:bb:bb:22

As far as I can trace the packet in the debbuger, it seems ok (destination address is OK).

Any hints?

FB

[mmdonatti]

I have the same problem. Did anyone find the solution ?

[TomE]

> I have the same problem.

Could you provide examples of the address you think you're sending and what you're seeing on the wire?

Looking at the OP's original complaint, there seems to be a problem with the representation of the MAC.

I'd suggest looking at some existing FEC code to see if you've got it right in your code. The obvious candidates would be:

LWIP:

  /* set MAC hardware address */

  FEC_PALR = (u32_t)( (CONFIG_GET_PARAM(mac)[0] << 24)

                    | (CONFIG_GET_PARAM(mac)[1] << 16)

                    | (CONFIG_GET_PARAM(mac)[2] << 8 )

                    | (CONFIG_GET_PARAM(mac)[3] << 0 ) );

  FEC_PAUR = (u32_t)( (CONFIG_GET_PARAM(mac)[4] << 24)

                    | (CONFIG_GET_PARAM(mac)[5] << 16) );

Linux:

Linux/drivers/net/ethernet/freescale/fec_main.c - Linux Cross Reference - Free Electrons

writel(ndev->dev_addr[3] | (ndev->dev_addr[2] << 8) |

    (ndev->dev_addr[1] << 16) | (ndev->dev_addr[0] << 24),

fep->hwp + FEC_ADDR_LOW);

    writel((ndev->dev_addr[5] << 16) | (ndev->dev_addr[4] << 24),

fep->hwp + FEC_ADDR_HIGH);

memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);

writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);

writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);

FNET:

ethif->reg->PALR = (unsigned long)((hw_addr[0] <<24)|(hw_addr[1] <<16)|

    (hw_addr[2] <<8)|(hw_addr[3] <<0));

ethif->reg->PAUR = (unsigned long)(hw_addr[4] <<24)|(hw_addr[5] <<16);

I don't know about you, but after an initial reading I'm confused. You'll notice most of the code samples load the four "lower" bytes into PALR, but in reverse-byte order, and then follow with the next two bytes. So using the "byte index order" of the original address, they end up in the PALR and PAUR registers in the following order:

     -------------------------------------

PALR | MAC[0] | MAC[1] | MAC[2] | MAC[3] |

     -------------------------------------

PAUR | MAC[4] | MAC[5] |                 |

     -------------------------------------

That looks like the "high bytes" are in the LOW register and the "low bytes" are in the UPPER register. So is the MAX numbered in "little-endian-order" (like in an X86) or "big-endian-order" like the ColdFire chips use? And how are these registers meant to be loaded?

The MAC is a very confusing thing. If you look at the following you'll see that the "first octet" is the "sixth byte" and vice versa. Also that the representation of the bit order is variable as some devices transmit the MSBit first and others do the opposite.

http://en.wikipedia.org/wiki/MAC_address#Address_details

http://en.wikipedia.org/wiki/MAC_address#Bit-reversed_notation

Tom

[mmdonatti]

Hi Tom,

thank you for your answer. I think it isn't a MAC address representation problem. My code is based on application note AN4577 - Using the fast ethernet controller on the Qorivva MPC564xB/C.

It seems to be the same problem for some reasons :

-  there is no lwip stack.

- I send a packet, it is transmitted but some bytes get corrupted

- I can trace the packet in the debugger, it's perfect.

Sorry, I should have specified before my problem. I created a question with more details :

https://community.freescale.com/message/358230#358230

I'm not interested yet to send specific packages, I would like just to validate my ethernet driver configuration.

any clues?

About the other thread (https://community.freescale.com/message/358377?et=watches.email.thread#358377), it was an answer for Ricardo's experience #2. I had this problem Friday.

I tried to answer this thread in the morning but my post has been moderated

thanks.

Mauricio

[TomE]

> Sorry, I should have specified before my problem. I created a question with more details :

So that's three threads you're posting in. That makes it tricky to track and try and answer.

The OP in this thread had the problem "it is transmitted but its destination address get corrupted."

Your other post in the ColdFire Forum is either an answer or a problem or both. I can't tell. That one was about double transmission of buffers.

Your post in the "Other Freescale Solutions" thread is about data corruption only. I don't think your problem matches these two ones.

You're using an MPC5604, not a ColdFire. so posting here without saying that is very confusing.

The App Note qou quote is for the MPC564x? Does it apply to the MPC5604? Which MPC5604 are you using?

I'll provide some thoughts on this in the "Other" thread.

> I tried to answer this thread in the morning but my post has been moderated

Yes, they're doing that to me too. I suspect they're delaying/moderating all posts. It gets confusing when you can see your post but nobody else can for a few days.

Tom

[mmdonatti]

Hi Tom,

thank you for your answer. I think it isn't a MAC address representation problem. My code is based on application note AN4577 (Using the Fast Ethernet Controller on the Qorivva MPC564xB/C).

http://cache.freescale.com/files/32bit/doc/app_note/AN4577.pdf?fsrch=1&WT_TYPE=Application%20Notes&W...

It seems to be the same problem for some reasons :

-  there is no lwip stack.

- I send a packet, it is transmitted but some bytes get corrupted

- I can trace the packet in the debugger, it's perfect.

Sorry, I should have specified before my problem. I created a question with more details :

https://community.freescale.com/message/358230#358230

I'm not interested yet to send specific packages, I would like just to validate my ethernet driver configuration.

any clues?

thanks.

Mauricio

[mjbcswitzerland]

Hi

Are you using multiple Tx buffer descriptors? There were errata when using just one BD for transmission (maybe not in the Kinin3 ?) whereby the frame could be repeated since the transmission engine would start polling the first BD too early and so recognise its content erroneously as a second frame.

I saw this a long time ago when experimenting with single BD but it was more like repeated frames than corrupted bytes.

Otherwise this problem is new to me. I would check some standard code as reference.

Regards

Mark

www.utasker.com

[francois_boucha]

Hi Mark,

Indeed I got 2 Tx buffer to counteract the duplicate transmission. 

I'll look at some other drivers, i'm shure it's not a big thing but very annoying.

FB

[Nouchi]

Hello,

This behavior could be caused by a Tx buffer misaligned.

The circular buffer should be 128 bits aligned, ETSDR should be divisible by 16, (see MCF52259 Reference Manual, chapter 21.4.2).

I made this mistake with my own lwIP port.

Emmanuel