2016-04-26 11:55 GMT+02:00 Guillermo Rodriguez Garcia <guille.rodriguez@xxxxxxxxx>: > 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: This line is actually in genphy_config_advert, sorry for the noise. Guillermo > > 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
