libethdrivers: Nitrogen6_SoloX imx6 driver seems to have mdio register access issue #115
Comments
|
This might be what is sampled on the MDIO bus due to the way it works. So the PHY you are trying top talk is mute. Can you narrow down when this happens? There are two ethernet ports on this board, but both PHYs are on the MDIO bus of ETH0 and thus the accesses need to be sync'ed properly and the PHYs must never end up using the same IDs. |
|
It usually happens when trying to autonegotiate the link. Usually with the second phy. The issue happens regardless if the two ethernet driver instances are in the same component or a separate component. In both cases there is synchronization between them so the second one isn't started until the first one successfully starts. The second device does need to use the MDIO interface from the first. Both successfully initialize about 1 in 3 or 4 attempts. I've added a log of all of the mdio_read results for when it fails on the second device. I modified the auto negotiation code to declare a failure once it sees more than 5 0xffff results in a row otherwise it interprets 0xffff as an actual value and declares successful negotiation at which point no packets will be received or transmitted. It's also possible to observe that several of the mdio_read results while waiting for autonegotiation contain errors. : |
|
Changing the udelay inside |
|
Fixing the delays and make them use a timer seem a good improvement. We have some issues with these boards also, where some board appeared much more stable than others. A colleague of mine is doing some testing currently, I'll make him get in touch with you. |
|
Hi @kent-mcleod, I would appreciate it, if you could send me your fix as an patch. |
|
I was able to reproduce the error on multiple of our units. |
|
Hi @FelixSchladt, This was my patch: It was first to detect the failure, and then to increase the udelay. The implementation of udelay that I changed to uses a custom timer interface that returns a monotonic timestamp in ns. And spins until the delay period has passed. |
|
Hi @kent-mcleod, thanks for providing the patch. I tested it on our boards and its definitely an improvement but sadly its only a ~80% success rate. Further I did some benchmarking on the default udelay implementation and it seems to be surprisingly accurate: I did this on a couple of our boards, and the times stay consistent. Considering that the timeserver likely introduced some overhead too, i would say, that a different udelay implementation is not necessarily required. |
|
If you keep increasing the udelay does your success rate go up? |
|
Yes this helps, I tried 20ms, 50ms and 100ms. |
|
It's helpful to know that you are experiencing the issue too. Do you have a way to run Linux on the board and check whether both cards work there? I'll try and do the same with my board too. |
|
Yes I did that already and both ethernet ports work flawlessly with linux. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've found when trying to test imx6 ethernet driver on the Nitrogen6_SoloX platform that quite often, the mdio_read implementation (https://github.com/seL4/util_libs/blob/master/libethdrivers/src/plat/imx6/enet.c#L397) will start returning all ones (0xffff) until the hardware is reset. Has anyone else experienced this or know what could cause this?
The text was updated successfully, but these errors were encountered: