Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem
On Mon, Jun 12, 2017 at 11:13:00PM +0200, Karsten Merker wrote:
> On Mon, Jun 12, 2017 at 10:01:09PM +0200, Jean-Louis MOUNIER wrote:
>
> > dmesg
> > [ 0.000000] Booting Linux on physical CPU 0x0
> > [ 0.000000] Linux version 4.9.0-3-armmp (debian-kernel@lists.debian.org)
> > (gcc
> > c version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-1
> > (2017-06-04)
> > [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7),
> > cr=10c5387d
> > [ 0.000000] CPU: div instructions available: patching division code
> > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> > instructio
> > on cache
> > [ 0.000000] OF: fdt:Machine model: Olimex A20-Olinuxino Micro
[...]
> > [ 3.794273] sun7i-dwmac 1c50000.ethernet: no regulator found
> > [ 3.800957] sun7i-dwmac 1c50000.ethernet: no reset control found
> > [ 3.807117] Ring mode enabled
> > [ 3.810262] DMA HW capability register supported
> > [ 3.814879] Normal descriptors
> > [ 3.830912] libphy: stmmac: probed
> > [ 3.834483] eth%d: PHY ID 0007c0f1 at 1 IRQ POLL (stmmac-0:01) active
[...]
> The phylib output points at a Microchip LAN8710A ethernet PHY
> while older revisions of the A20-Olinuxino MICRO used a Realtek
> RTL8201CP instead. As far as I can tell from a quick glance at
> the PHY driver sources in the Linux kernel, there doesn't seem to
> be a PHY-specific driver for the LAN8710A. The microchip PHY
> driver seems to support only the LAN88XX series (PHY ID
> 0007c130), but not the LAN87XX series.
>
> AFAICS u-boot 2016.11 (the version used by Debian) also doesn't
> have a PHY-specific driver for the Microchip LAN8710A.
Hello,
I have done some further digging and have to correct/amend my
previous findings. In fact both the kernel and u-boot have a
driver for this PHY. It looks like the Microchip LAN8710A hasn't
originally been a Microchip design but instead stems from SMSC
and has been re-branded as a Microchip product later on after
Microchip has acquired SMSC. Therefore this PHY isn't handled by
the microchip PHY driver but by the smsc PHY driver. The driver
masks out the lower nibble of the PHY ID and matches only on the
upper bits, which explains why grepping the sources for the
(full) PHY ID hasn't turned up any results.
This rules out lack of a driver as the source of your problem.
The smsc PHY driver is included in the debian-installer builds,
so in theory, everything should work. Just to make sure that we
don't chase an obscure hardware issue here: could you try the
board with a different ethernet cable and on a different switch?
As things are working with the android-derived 3.4 kernel, a
hardware issue is very unlikely, but it would be good if you
could check it nonetheless as we have had the the (indeed rare)
case that an actual hardware issue with a PHY (clock pulse
instability) has respectively hasn't shown up depending both on
the switch involved and on the exact PHY configuration, which
is driver-dependant.
Another interesting test would be whether the network works in
u-boot. Could you stop the boot process in u-boot (just press
return a few times during u-boot initialization) and run the
"dhcp" command at the u-boot prompt to see whether getting a DHCP
lease works in u-boot?
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: