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

[Karsten Merker <merker@debian.org>]

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.