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@19000000` in ath79.dtsi * GMAC1 * Base address of 0x1a000000 * Is connected "directly" to the integral switch * Is referenced as `eth1: eth@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. ð1 { 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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel