Don't know if this has been posted before, but perhaps it's relevant?
https://patchwork.ozlabs.org/patch/602067/
From the poll thread, it looks like so far we all have the "Green" RTL8211E. Wonder if the uboot could specify FORCE_MASTER when that chip is detected? Then we could do some testing.
The drawback is that it seems ports forced to MASTER will not connect with other ports that are forced as well, and you don't want this applied to chips that don't need it forced. Forcing MASTER would help those of us with one PINE in our environment, but for those going PINE to PINE, it wouldn't work. Either way, I'd commit to test any upcoming potential resolutions, even if my particular issue was solved since I only have one PINE.
UPDATE: There is also this, from http://linux-sunxi.org/Ethernet:
I know we've already done testing with TX_DELAY, but perhaps this is hitting that in a different area (GMAC delay)? I dunno. I'm not a linux expert, just trying to dig some stuff up for those who are. But they might already be aware of all this.
https://patchwork.ozlabs.org/patch/602067/
Quote:This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this define is set, RTL8211x PHYs (except for the RTL8211F) will have their 1000BASE-T master/slave autonegotiation disabled and forced to master mode.
This is helpful for PHYs like the RTL8211C which produce unstable links in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB and A20-OLinuXino-Lime2.
From the poll thread, it looks like so far we all have the "Green" RTL8211E. Wonder if the uboot could specify FORCE_MASTER when that chip is detected? Then we could do some testing.
The drawback is that it seems ports forced to MASTER will not connect with other ports that are forced as well, and you don't want this applied to chips that don't need it forced. Forcing MASTER would help those of us with one PINE in our environment, but for those going PINE to PINE, it wouldn't work. Either way, I'd commit to test any upcoming potential resolutions, even if my particular issue was solved since I only have one PINE.
UPDATE: There is also this, from http://linux-sunxi.org/Ethernet:
Quote:For reliable Gigabit networking (1000Mbit operation), several sunxi devices require an important tweak that adjusts the relative timing of the clock and data signals to the PHY, in order to compensate for differing trace lengths on the PCB (details). Among others, this includes Banana Pi/Pro, Cubietruck, Lamobo R1, pcDuino3 Nano and Orange Pi/Mini. Recent mainline U-Boot uses CONFIG_GMAC_TX_DELAY to initialize these devices accordingly. If a necessary GMAC TX delay isn't set, then GBit Ethernet operation might be unreliable or won't work at all. 10/100 Mbit/sec negotiation is unaffected, so misconfigured devices could actually work (faster) when connected to a Fast Ethernet port instead of a GBit Ethernet port.
I know we've already done testing with TX_DELAY, but perhaps this is hitting that in a different area (GMAC delay)? I dunno. I'm not a linux expert, just trying to dig some stuff up for those who are. But they might already be aware of all this.