Running conversation over on the gl-inet forums with @jeff
Based on the following commit... ar150 is flipping interfaces compared to ar71xx machine file
This can cause a bit of a problem as ar150 comes up with 192.168.1.1/24, and if the host is also 192.168.0,1/24, we're causing an arp conflict.
commit 8dde11d521
Author: Chuanhong Guo <redacted>
AuthorDate: Fri May 10 23:28:47 2019 +0800
Commit: Petr Štetiar <redacted>
CommitDate: Wed Jun 5 10:12:31 2019 +0200
ath79: dts: drop "simple-mfd" for gmacs in SoC dtsi
With a proper probe deferring for ag71xx we don't need to explicitly
probe mdio1 before gmac0.
Drop all "simple-mfd" in SoC dtsi so that gmac orders can be the same
as ar71xx.
This makes eth0/eth1 order the same as those in ar71xx, which means
we don't need a migration script for this anymore and we can merge
incorrectly split gmac/mdio driver back together.
Signed-off-by: Chuanhong Guo <redacted>
this commit flipped ar150 from WAN to LAN across eth0 and eth1 for this target, and may involve other ath79 targets as well.
with ar150 - WAN gets mapped GE1-MDIO, and GE1 MAC, and LAN gets mapped to the GE0 MAC, which is inverse to what is expected.
Device Tree is always fun, and I'd be up for the challenge, but day job keeps me very busy...
At least as I understand it (I don't have an AR150 in hand), due to the architecture of the chip, "eth0" and "eth1" vs. "LAN" and "WAN" are not transparently interchangeable.
In this specific case, using the MII interface is "physically" tied to the WAN-labeled port. The GMII interface is tied to the LAN port. This makes sense as, for example, two LAN clients each might be pumping close to 100 Mbps through wireless, requiring more than the 100 Mbps that the MII interface can provide.
I resolved a similar issue with the GL-AR300M-Lite earlier in commit eba0db95b5
I can drop ship an AR150 if you're willing to dive into this issue. AR150 and AR300M-16 are fairly similar.
I think most of the AR150 items - gpio, leds, port mapping - likely the device tree settings - I can probably sort things out locally, but with other projects (day-job), they have priority...
AR150 generally runs well enough at the moment on Master.
go figure. that thing cannot serve 100mbps to a single wlan client, how the hell could it aggregate 200Mbps to 2 clients? it would melt down, got on fire and exploded.
even if there was a chance for such performance there is nowhere to route data at those speeds except to the CPU which again is useless
Yeah, but they make for very good IOT device routers, and with 64/16, more than capable...
Anyways - with ath79, the port mapping is flipped....
eth0 eth1
ar71xx WAN LAN
ath79 LAN WAN
ar71xx maps the ports correctly, GE0 goes to PHY4 (10/100), and GE1 goes to MAC0 on the switch - so yep, it's probably a bug...
It's not a major one, and it would take me a bit of time to update device tree to fix it, but it's not blocking my efforts, and day-job is keeping me very busy, we're in a middle of a sprint...
