[OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity

Jeff Kletsky lede at allycomm.com
Fri Sep 27 12:33:21 EDT 2019


NB: What is described here may also impact other single-port, ath79 devices

    There are over 40 such devices that appear to use "eth0" as their only
    Ethernet port in target/linux/ath79/base-files/etc/board.d/02_network


TL;DR

  * Single-port ath79 devices may be unreachable on first boot

  * Attempts at disabling the "unused" GMAC1 as a solution were unsuccessful
    * If there is a way to disable GMAC1, it seems a preferred solution

  * This patch, or its replacement, should be applied to `master`
    as well as `openwrt-19.07` as both contain the interface reversal



commit 8dde11d521, ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi
reversed the assignment of eth0 and eth1 on many ath79 devices.

In the case of the single-port GL-AR300M-Lite, this resulted in an
inability to connect to the device after a clean flash[1] or after
regeneration of /etc/config/network.

This patch manages the change by modifying 02_network to use the
now-labeled eth1 for the "LAN" interface on configuration of
/etc/config network

As I understand the QCA9531, it has two GMACs:

* GMAC0
  * Base address of 0x19000000
  * Can be connected to FE PHY 0 or FE PHY 5 of the 5-port, integral switch
    (or, if in SW_ONLY_MODE is set, is not connected)
  * Is referenced as `eth0: eth at 19000000` in ath79.dtsi

* GMAC1
  * Base address of 0x1a000000
  * Is connected "directly" to the integral switch
  * Is referenced as `eth1: eth at 1a000000` in ath79.dtsi

Prior to commit 8dde11d521, the kernel designation of the interfaces
was consistent with the naming in the DTSI:

  /sys/devices/platform/ahb/19000000.eth/net/eth0
  /sys/devices/platform/ahb/1a000000.eth/net/eth1

Builds prior to this commit were tested at the time to provide
first-boot connectivity and that has been subsequently confirmed.

After commit 8dde11d521, the kernel names are reversed (as suggested
by the commit message):

  /sys/devices/platform/ahb/19000000.eth/net/eth1
  /sys/devices/platform/ahb/1a000000.eth/net/eth0

The SoC's GMAC1 is now associated with the kernel's "eth0".

In the case of the GL-AR300M-Lite, testing of "official" snapshots as
well as local `master` builds indicated that the populated port was that
which the kernel now identified with "eth1" -- GMAC0

This is consistent with observations that "old" firmware for the
device connected through "eth0" and "new" firmware, through "eth1".

As suggested by Alberto Bursi in the linked thread, one approach to
resolution would be to disable the "unused" interface, GMAC1. This
would have the additional advantage of removing the unconnected
interface from the kernel and end-user visibility. By disabling GMAC1,
it was expected that GMAC0 would be identified by the kernel as "eth0"
as the sole Ethernet interface visible.

&eth1 {
       status = "disabled";
};

This, unfortunately, resulted in the Ethernet driver unable to connect
to the assigned phy 4, with no Ethernet interface created and

kern.info kernel: [    0.495579] libphy: Fixed MDIO Bus: probed
kern.err kernel: [    0.846986] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
kern.err kernel: [    1.216982] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
kern.err kernel: [    1.556969] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
kern.err kernel: [    4.681196] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
kern.err kernel: [    5.057462] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.

appearing in the logs. Thinking that it was related to switch initialization

&mdio1 {
       status = "okay";
};

was tested, and found to have the same, unsucessful result.

If there are suggestions as to how to disable the "unused" GMAC, yet
preserve the ability to access the phy, I would evaulate them.

Jeff




[1] https://forum.openwrt.org/t/how-do-i-flash-gl-ar300-lite/44802




_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list