Hello, 2016-04-21 9:32 GMT+02:00 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: > On Wed, Apr 20, 2016 at 05:58:40PM +0200, Guillermo Rodriguez Garcia wrote: >> Hello, >> >> 2016-04-19 9:11 GMT+02:00 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: >> > Hi Guillermo, >> > >> > +Cc Philipp Zabel who ported the patch to barebox >> > >> > On Mon, Apr 18, 2016 at 04:49:47PM +0200, Guillermo Rodriguez Garcia wrote: >> >> Hello all, >> >> >> >> I am playing with barebox on an Atmel SAMA5D3 Xplained board. It is >> >> now working fine for the most part, however after updating to the >> >> latest sources from git I found a problem that I had not seen before. >> >> >> >> This board has two Ethernet interfaces; eth0 uses a Micrel KSZ9031RN >> >> PHY, and eth1 uses a Micrel KSZ8081RNB PHY. >> >> >> >> It seems that after release 2016.03.0, eth0 does not work anymore with >> >> some routers. Specifically I found this problem with a Comtrend >> >> VG-8050. I have tested other routers and the problem was not present >> >> there. >> >> >> >> After some research it seems that the problem is caused by this >> >> commit: http://git.pengutronix.de/?p=barebox.git;a=commit;h=da89ee8f2e04e116410632a185024f58b8262d87 >> >> >> >> Before this commit eth0 was working fine. After this commit, the link >> >> cannot established anymore: >> >> >> >> [...] >> >> barebox:/# ping 192.168.0.128 >> >> ping failed: Network is down >> >> >> >> Before diving further into this I thought it could be a good idea to >> >> ask, in case someone can shed some light here. >> > >> > I have no idea what the issue is here. We might have to make this option >> > configurable via devicetree to give boards different options. Since the >> > patch comes from the Linux Kernel, do you have the same problems under >> > Linux? >> >> I'm trying to get the latest kernel to boot. The latest version >> supported by Atmel is 4.1, which doesn't have the patch yet. Will >> report back asap. > > Thanks. We can revert this patch since Philipp only ported it to stay in > sync with the kernel. Anyway, if it makes problems we'll probably need a > solution for the kernel aswell. More info on this after researching the issue. Looks like problem is not directly caused by the modified FLP timings, but is revealed by that change. Immediately after setting the FLP timings, the autonegotiation is restarted by calling genphy_restart_aneg(phydev). Within genphy_restart_aneg, the following line: oldadv = adv = phy_read(phydev, MII_ADVERTISE); returns 0xffff, and negotiation fails. It seems to be a timing problem. Any minimal delay _before_ that phy_read (1ms) is enough to make it work -- phy_read returns 481 instead of 0xffff, and the negotiation completes. The same delay right after phy_read does not solve the problem. This happens even if I modify ksz9031_center_flp_timing() so that it does NOT touch the FLP timings. So as I said it is not directly related to the actual FLP timing values, but rather to some timing issue related to the negotiation itself. It just happens that the center_flp_timing function does restart the autonegotiation, and thus reveals the problem. Is it OK to add this 1ms delay in genphy_restart_aneg? Best, Guillermo Rodriguez Garcia guille.rodriguez@xxxxxxxxx _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
