iMX28 / FEC: ethernet link breaks on MAC reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX28 / FEC: ethernet link breaks on MAC reset

1,256 Views
wawrzeniec
Contributor I

I'm encountering issues with an iMX28 connected to a LAN8720 PHY chip on a board very similar in design to the MX28-EVK. 

The symptom of the issue is the swinging ethernet link which has been discussed in many threads already. The generally accepted solution is to reset the PHY chip after enabling the ENET clock, but this doesn't seem to work on recent linux kernels (using v2.6.35 distributed by NXP, I am able to fix the issue by bringing the PHY into reset before bringing the interface up, and holding the reset until the interface is up, but this doesn't seem possible in recent kernel probably due to modifications in the generic phy driver - using the SMSC driver doesn't work either as the PHY needs to be up for probing during fec_enet_open()).

What I've found is that the problem can be (seemingly) fixed by issuing a soft- instead of a hard-reset in fec_restart(), which is called as soon as the link is detected to be up. That is, replace at what is now line 965 of fec_main.c > fec_restart()

writel(1, fep->hwp + FEC_ECNTRL);

by

writel(0, fep->hwp + FEC_ECNTRL);

I've tried very hard to find a solution that doesn't involve changing the reset but this is so far the only fix that worked for me (and it does seem to work very reliably). 

Right now I suspect that the hard reset might disable the clock for a few cycles and that's what might be causing the link to break. In support of this, I can recreate the issue by quickly disabling and re-enabling the clock after the soft-reset

writel(0, fep->hwp + FEC_ECNTRL);
clk_disable(fep->clk_enet_out);
clk_enable(fep->clk_enet_out);

Is this the intended behavior or a known issue? Might there be a different way to get around it? 

Thanks in advance for your answers,

Laurent Badel

Labels (3)
0 Kudos
4 Replies

1,127 Views
wawrzeniec
Contributor I

I've done some recordings to check the signal lines and I found that there is a glitch in the ENET_CLK when the reset happens. ENET_CLK during link down.jpg

For three periods, the frequency of the clock is lowered by about half. This glitch is very consistent and happens each time fec_restart() is called with a hard reset (assert bit 0 of the MAC_ECR register).

This is not seen if a soft reset is used instead (clear bit 1 of MAC_ECR).

This is also not seen using Linux 2.6.35 even though it also uses a hard reset.

I could not confirm yet that is indeed the cause of the link failure, but I think this is very likely.

This might be a kernel configuration issue as it seems to happen with Linux 5.7 but not with Linux 2.6.35.

For the record I've tried enabling the CONFIG_DMA_ARM_MEM_BUFFERABLE option but this did not make any difference.

Any other ideas?

Thanks,

Laurent

0 Kudos

1,127 Views
Yuri
NXP Employee
NXP Employee

Hello,

  Have You tried the attached patch?

Regards,

Yuri.

0 Kudos

1,127 Views
wawrzeniec
Contributor I

Thank you Yuri. 

This patch seems a bit old and not very related to my problem. I've tried porting it to linux 5.7, but I didn't see any difference. 

By adding delay to before and after the MAC reset, I can see that the link breaks (both LEDs go off on the ethernet port, as if the PHY chip is being reset, though I've tried physically disconnecting the reset pin to be 100% that the reset is not asserted) exactly at the time where the MAC is reset. 

For example, if I add 2 seconds delay before the reset, I can see that the LEDs on the ethernet port keep happily blinking for those extra 2 seconds. If I add delay after the reset, the behavior is the same as without delay suggesting that the problem occurs exactly at the time of MAC reset, and is not due to the following code. 

For some reason, though, it works much better using linux 2.6.35, even though the same code is used for the MAC reset, so the problem must lie somewhere else. Also the problem occurs systematically when the PHY is in polling mode, but not when interrupts are enabled. 

Would the chip draw more current at some point during the reset? I have a 1.5A regulator which seems like it should be good enough, but I'm wondering if it's worth looking into this in more detail. 

Do you have any information on the max current draw of the iMX28? I couldn't find this info in the user manual.

Best regards,

Laurent

0 Kudos

1,127 Views
Yuri
NXP Employee
NXP Employee

wawrzeniec 

Hello,

    As for power estimations, please use the i.MX28 Power calculator.

i.MX28 Power Calculator spreadsheet 

   Also, according to app note AN4199 (Using the i.MX28 Power Management Unit and Battery Charger), section "Limitations" (for VDD5V-only applications)  :
"During the early stage of device startup, before on-chip ROM execution, the input current on
VDD5V is limited to 100 mA. The device is running on internal LinRegs on power up, and it needs to wait for the
software to setup the 4P2 rail before switching to the DC-DC converter as the power supply. The output current
from LinRegs is much lower than that of the DC-DC converter.
   It is strongly suggested to use the i.MX28 power supply to power the i.MX28 and core components like
DRAM, NAND, and eMMC only."

https://www.nxp.com/docs/en/application-note/AN4199.pdf 

Regards,

Yuri.

0 Kudos