Hi,
On 20-03-16 16:28, Michael Haas wrote:
On 03/20/2016 02:45 PM, Hans de Goede wrote:
Hi,
On 19-03-16 14:40, Michael Haas wrote:
On 03/19/2016 10:32 AM, Hans de Goede wrote:
Hi,
On 19-03-16 09:39, François-David Collin wrote:
Hi,
As I’m banging my head on this too, please allow me to provide some
details
I got two stable situations :
The Lime2 is connected directly to the Gbit interface of my laptop,
speed are OK:
Michael Haas' work to debug this by looking at the phy registers
seems to be the most promising so-far, the clk reg and axp209
registers all seem to be identical between good and bad setups.
Can you try to:
1) Stop the boot in u-boot (press a key on the serial console)
2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
to tftp
3) Do: "mii read 1 0x11" in u-boot and record the output ?
Regards,
Hans
Hi all,
i have diffed and cross-compared logs of several working and broken tftp
downloads. The most significant
difference between working and broken was registers 0xa, 0x1c and 0x2a
in the first MII page.
These registers started making sense when I looked at the datasheet for
the RTL8211CL. Previously, I was looking at the RTL8211E.
0xA was set to 7800 for working runs and 3800 for broken runs. The
difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
Resolution'. In the broken runs, the autonegotation configured the
OlinuXino to 'slave'. I have whipped up a quick patch which disable the
master/slave part of the autonegotiation and force master mode.
The patch itself is quite terrible as it's forcing the master mode bits
for every phy, not just for the RTL8211CL. It's good enough for testing,
however, and I seem to be getting consistent download speeds. There are
occasional hangs when booting the downloaded kernel, but that is
probably a different issue.
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 51b5746..484b2be 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
int genphy_config_aneg(struct phy_device *phydev)
{
int result;
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
if (AUTONEG_ENABLE != phydev->autoneg)
return genphy_setup_forced(phydev);
Please test this change and let me know. If it's successful, I will
submit a proper version.
Good catch, I wonder why we need this. I believe that the proper version
should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER
and then add a Kconfig option for this (and enable it in the lime2
defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless
someone can dig up an errata from realtek which said we should.
I was going to add that in realtek.c, not in phy.c - as soon as I figure
out which section there is applicable.
Ack, I already understood that. What I mean is that even if you limit
the fix to just apply to rtl8211cl phys, that that is still a somewhat
big hammer if the problem only happens on the lime2. Always applying
the workaround if the phy is a rtl8211cl means also applying it on
other sunxi boards and likely also on boards with a completely different
soc which also happen to use the rtl8211cl, which is why I suggest that
you wrap it in #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER and a matching
Kconfig bool, which defaults to false.
I have started a new thread
asking about that.
Ack I've seen that.
Are any other sunxi boards impacted by the same problem that you know ?
No, I don't know of any other boards, but I have not looked very hard :)
Ok, so for now lets put this fix / workaround behind a #ifdef then, and
enable it only on the lime2
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
