mx28 u-boot eth1 problem

[Chiz]

I've built a custom iMX28 module board, and want to use u-boot to test all the interfaces. I was able to get everything working with the exception of ETH1 (FEC1 port).

Whenever I ping from the FEC1 port, I don't get a response, and the ETH1 Receive Buffer Descriptor notes a RX CRC error.

I've assigned an ip address to the board, mac adresses to each FEC port. ETH0 works fine, but ETH1 doesn't.

I tried the same u-boot image on the EVK, and both FEC ports work fine. I've poured over the schematics and artwork for my board and I can't seem to find anything wrong.

So I loaded a Linux image on my board. With Linux, I can get both FEC ports working on my board. However, when I use u-boot, FEC1 does not work.

Does anyone have an idea what might be going on, or any suggestions on where to look.

I think the issue has to do with u-boot, and I'm not sure if there are register settings that have to do with timing and synchronization, which are not set up properly. Might explain why I see an Rx CRC error on the Receive buffer Descriptor.

Any help is welcome.

Thanks.

[MarekVasut · Accepted solution]

Try upstream U-Boot 2013.01 , it supports both FECes on mx28. It might also be a PHY issue, check that.

[Bogumil]

I've found similar problem on custom hardware and embedded code. I think that's because ethernet FEC drivers are different in U-boot and linux (see below). In my understanding, U-boot driver correctly drops frames marked with CRC error status flag, but Linux driver just increase error counter and process it, as for good CRC frames. That's why I think it could be a iMX28 FEC1 processor bug (marking all frames as bad CRC).

U-boot driver (/drivers/net/fec_mxc.c, function fec_recv:

if ((bd_status & FEC_RBD_LAST) && !(bd_status & FEC_RBD_ERR) && ((readw(&rbd->data_length) - 4) > 14)){

     // -> frame processing

}

Linux driver (/drivers/net/fec.c, function fec_enet_rx):

if (status & BD_ENET_RX_CR) /* CRC Error */

     dev->stats.rx_crc_errors++;

// -> frame processing

[MarekVasut]

I suspect there might be yet another issue with the FEC. How do you use GPIO 3_27 ? Do you use it as GPIO or as FEC_RXER or not at all? It seems this pin might be "leaking" if it's in GPIO input mode and it's incrementing the error counter ...

[Bogumil]

Thank's for tip. I've checked it and it's GPIO input (a button in my board), stable high in normal operation. Nothing changed when I pressed and hold the button (GPIO low). I'm also using LAN8720A (same on EVK).

Chiz Chikwendu, do You also use 2 PHY, FEC0 connected to PHY address 0, FEC1 connected to PHY address 1?

BTW, We've just made simple test with opposite PHYs addresses (FEC0 with PHY address 1, FEC1 with PHY address 0) and nothing changed, still CRC error in FEC1. It seems it's not an issue with LAN8720 RXER output/address.

[Bogumil]

We've changed GPIO 3_37 from input to output (still as GPIO) and we don't receive CRC error status. For me, that confirms a processor bug. Thank's a lot Marek.

[Radist]

Today we find out exactly the same issue with eth1 at imx28 running Windows Embedded CE 6.0

Looks like it is bug inside IC, because GPIO 3_37 configured like GPIO, but works like ETH1_RX_ER.

I have reported that to freescale and we are waiting for the answer. Does somebody reported this bug to freescale before?

[michaelkrummsdo]

I have the same issue on our custom board even with mainline U-Boot 2013.04.

Do you have an answer from freescale yet? Is this issue chip internal?

[Bogumil]

I didn't informed freescale. But all my tests described above confirms that's processor internal bug (leaking GPIO input into ETH_RX_ER).

[Chiz]

In my application, I use GPIO 3_27 as GPIO input. I couldn't use it now for FEC_RXER. GPIO 3_27 is not connected to the PHY. It is configured as a GPIO input. If it causes RXER on the iMX28 MAC, then I would consider that this is a chip issue.

However, I do not think that GPIO 3_27 (FEC_RXER) is responsible. I have configured the iMX28 to perform a loop back test on FEC1. The FEC1 interface does not send data out to the PHY, it just loops it back to itself. If the FEC_RXER pin was causing error (due to GPIO 3_27), then I would see it with the loop back test. But the loop back test was successful. So I know the issue is occuring on the MAC/PHY interface.

The PHY on my board is the LAN8720A. The RXER pin on the PHY is actually dual function. It is used to set the PHY address on power up. Then it is left to function as RXER after power up.

I do wonder if the pull up resistor on this pin is too strong and causes a leakage on the RXER input. Perhaps I can change the pull up resistor, and use a weaker pull up.