Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #58033 > unrolled thread

Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Karsten Merker <merker@debian.org> - 2017-06-14 20:40 +0200
    Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Karsten Merker <merker@debian.org> - 2017-06-16 16:20 +0200
      Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Jean-Louis MOUNIER <jean-louis.mounier@laposte.net> - 2017-06-16 22:10 +0200
        Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Karsten Merker <merker@debian.org> - 2017-06-21 19:20 +0200
          Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Jean-Louis MOUNIER <jean-louis.mounier@laposte.net> - 2017-06-22 20:00 +0200
            Bug#864562: No ethernet link on Olimex A20-Olinuxino Micro Rev. J, possibly PHY driver problem Karsten Merker <merker@debian.org> - 2017-07-18 22:30 +0200

#58033 — 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.

[toc] | [next] | [standalone]

#58052

On Thu, Jun 15, 2017 at 09:07:47PM +0200, Jean-Louis MOUNIER wrote:

> I tested the link on several switches (3 at least) before opening the bug.
> So I think the problem is really located on the PHY detection and
> management.
> 
> I validated the hardware by testing with pre-installed Debian MicroSD, as
> recommended by Olimex.
> 
> Now the test you ask (on a 4th switch !):
> 
> dhcp
> 
> Speed: 100, full duplex
> 
> BOOTP broadcast 1
> 
> ...       (from 1 to 17)
> 
> then restart with "speed: 100" and so on...

So the same problem shows up in u-boot, not only in the kernel.

> Small remark : I did manage a complete installation by using a USB-Ethernet
> interface (shipped from Olimex). It ran fine with Jessie but failed with
> Stretch. My goal was (is ?) to have an A20 server that boots from its hard
> disk.
> I could not restart it ! It didn't boot from the hard disk. Perhaps it is
> necessary to boot from MicroSD then switch to hard disk. Not a hard failure
> : my first goal was to run a full install ! I will try again ASAP.

The Allwinner A20 itself cannot boot directly from a harddisk, it
always has to boot from either an MMC device (such as an SD-card
or an eMMC chip), from an SPI flash chip, from a raw NAND flash
chip or via the Allwinner-specific FEL protocol over USB. 
Therefore u-boot must always be loaded by one of these methods,
with the common case being an SD card.  Once u-boot is loaded, it
provides the option of booting the rest of the system from a
SATA harddisk, from a USB mass storage device or over the network.

The order in which u-boot tries to boot from the various devices
is set in the "boot_targets" u-boot environment variable.
You can show it at the u-boot prompt with the following command:

=> printenv boot_targets
boot_targets=fel mmc0 scsi0 usb0 pxe dhcp

If you want the change the boot order, e.g to make the harddisk
the primary boot device, you just need to modify the variable
accordingly ("scsi0" is the harddisk, even if you actually
have a SATA disk and not a SCSI disk):

=> setenv boot_targets "scsi0 mmc0 usb0 pxe dhcp"

and save the change with

=> saveenv

Regards,
Karsten

P.S.: Please send replies regarding the bug always also to the
      bug itself (i.e. to 864562@bugs.debian.org) and not only
      to the personal email address of people working on it.
-- 
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.

[toc] | [prev] | [next] | [standalone]

#58053

Hello Karsten,

thank you for all your informations about A20 specifications. I will 
test them ASAP ! I guessI will spend time on uboot...

However, I have a new information about Jessie on my A20-Olinuxino 
Micro. Yesterday night, I installed Jessie on my board using my 
USB-Ethernet interface. Two informations.

I first used a 128M micro SD, with no speed indication. The (small) size 
would have been enought for the installer but I could not boot the 
installer, probably because the card is too slow. I attempted another 
install with a Class10 8G Micro SD and then it ran fine. I don't know if 
it is really a bug.

Second and more important regarding #864562 : after reboot, the board 
network interface is still unable to connect to the switch. This means 
that the issue is probably in the kernel, even in Jessie kernel.

Hope it helps

Regards

Jean-Louis

[toc] | [prev] | [next] | [standalone]

#58109

On Fri, Jun 16, 2017 at 10:01:56PM +0200, Jean-Louis MOUNIER wrote:

> However, I have a new information about Jessie on my A20-Olinuxino
> Micro.  Yesterday night, I installed Jessie on my board using my
> USB-Ethernet interface.  Two informations.
> 
> I first used a 128M micro SD, with no speed indication. The (small)
> size would have been enought for the installer but I could not boot
> the installer, probably because the card is too slow.  I attempted
> another install with a Class10 8G Micro SD and then it ran fine.  I
> don't know if it is really a bug.

Hello,

that is a known limitation with regard to the A20.  For proper
operation in A20-based systems one has to use SDHC cards (which
in practice means cards between 4GB and 32GB).  "Classic" SD 1.x
cards (in practice those with a capacity of 2GB or less) should
be avoided.

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.

[toc] | [prev] | [next] | [standalone]

#58131

Hello Karsten,

I installed Stretch on my A20 with the USB network interface.

After a successfull minimal installation (on the Micro SD card), I 
configured eth0 and rebooted the system. The result is the same : the 
PHY is unable to get an IP address with DHCP.

The problem witch 4.9.0-3-armmp-lpae is the same as with the installer 
kernel.

Small information :

root@hendrix:~# dmesg |grep eth0
[   10.040210] sun7i-dwmac 1c50000.ethernet eth0: fail to init PTP.
[   10.045905] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   12.117354] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 
100Mbps/Full - flow control rx/tx
[   12.117405] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I think I'll have to wait for a new kernel release...

Hope it helps

Regards

Jean-Louis

[toc] | [prev] | [next] | [standalone]

#58452

On Thu, Jun 22, 2017 at 07:50:58PM +0200, Jean-Louis MOUNIER wrote:
> Hello Karsten,
> 
> I installed Stretch on my A20 with the USB network interface.
> 
> After a successfull minimal installation (on the Micro SD card), I
> configured eth0 and rebooted the system. The result is the same : the PHY is
> unable to get an IP address with DHCP.
> 
> The problem witch 4.9.0-3-armmp-lpae is the same as with the installer
> kernel.
> 
> Small information :
> 
> root@hendrix:~# dmesg |grep eth0
> [   10.040210] sun7i-dwmac 1c50000.ethernet eth0: fail to init PTP.
> [   10.045905] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   12.117354] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 100Mbps/Full
> - flow control rx/tx
> [   12.117405] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> I think I'll have to wait for a new kernel release...

Hello,

I think the reason for your problem has been found, but
unfortunately a proper solution will probably require u-boot
and/or kernel modifications.

The problem appears to be indeed related to the different
ethernet PHY in revision J of the board and the corresponding
changes in the GPIOs used to control the PHY.  Revision G of the
board has an RTL8201CP PHY and uses the SoC GPIO pin PA17 as the
(low-active) EPHY-RST# output, which is connected to the
(low-active) RESETB# input on the PHY side.  So for proper
operation with the RTL8201CP on the revision G board, PA17 must
be high (or in tri-state high-impedance mode as there is a pullup
on the PHY RESETB# input) during normal operation because
otherwise the PHY would be held in reset state and couldn't work.

On the revision J board, which uses a LAN8710A PHY, the EPHY-RST#
signal isn't provided by PA17 as on the revision G board, but
instead by PH10.  PA17 on the other hand is connected to the
LAN8710's NINT/TXER/TXD4 pin (which also has a pullup, i.e. it
is in high state unless the SoC explicitly pulls the line down). 
According to the LAN8710A datasheet, the NINT/TXER/TXD4 pin
provides different functions depending on the state of the
NINTSEL pin.  On the Rev. J board, NINTSEL is pulled low by an
external pulldown resistor, so NINT/TXER/TXD4 doesn't work in
its default interrupt mode, but instead in TXER/TXD4 mode.
If I understand the datasheet correctly (I am not really familiar
with the inner workings of the PHY), in this mode the line needs
to be pulled low for normal operation.

If this assessment is correct, we end up with two contradicting
requirements:

- on rev. G boards, PA17 must be high during normal operation
  to get a working PHY
- on rev. J boards, PA17 must be low during normal operation
  to get a working PHY

AIUI, the mainline kernel doesn't know about the difference
between revision G and revision J boards and has PA17 in high (or
tri-state high-impedance) state.  The reason why it works with
the Olimex 3.4 kernel appears to be that this 3.4 kernel has a
patched driver for the LAN8710A which modifies the state of PA17
in the PHY driver setup function.  Unfortunately this is a
non-portable hack that cannot go into mainline as is and a proper
solution will probably need some time.

Could you perhaps perform an experiment?  U-boot has a "gpio"
command that can set the state of GPIO pins on many platforms. 
Could you stop the boot process by pressing "enter" during u-boot
initialization, run the command "gpio clear PA17" at the u-boot
prompt and then try to get a DHCP lease in u-boot by running the
"dhcp" command?

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web