I've got an old EnGenius ESR600 which stopped working on the stock firmware (freezes when it enables the 5GHz radio), so I'm porting OpenWRT to it to see if I can make it useful again. The system consists of:
J2 on the face of the board is a header-less serial port, which I have populated. It's CMOS 3.3V levels, and operates by default at 115200 baud, 8N1.
Although the U-Boot operations documented are only 2 (tftp and flash system code), 3 (boot from flash), and 9 (tftp and flash bootloader code!) it will also accept 1 (tftp to RAM and boot), 4 (enter U-boot CLI).
I have built an OpenWRT initram image that will boot, but I am having trouble with the device tree spec for the Atheros AR8327 setup.
The existing MT7620A based systems with an AR8327 (LR-25G001, TEW-692GR, and WLR-6000) aren't really illuminating!
The initial hint I started from was the U-Boot banner which announces "ASIC 7620_MP (Port5<->GigaSW)", so since that's a well-known way of configuring the system I assume the AR8327 is on port 5 of the SoC's own switch, and is controlled on the MDIO bus.
My first attempts have managed to bring up the internal switch, and one attempt managed to bring up both the internal MT7620 switch and the AR8327, but none of the LAN/WAN ports were active-- "swconfig...show" did not show any ports with link activity indication that changed when plugging/unplugging the ethernet cable, although the device on the other end notes the link active.
Thanks -- yeah, still got the stock firmware in flash (and have the uImage). I do have a shell on it but most of the debug tools are stripped from the image, even to the point they stripped the kernel logging so no boot msgs or dmesg capability.
I had previously taken the stock .DLF file apart and added an "/sbin/cli" script to the squashfs and rebuilt the image so that I could log in (admin) before I found a reference to using "lin17" to get a shell bypassing the missing /sbin/cli. My /sbin/cli script renames /sbin/ifconfig and then execs a shell because if I let it get as far as turning the radio on it's game over -- I guess I should set it up to just ignore the one interface that kills it and I may be able to recreate and install some tools to help dig into it.
I'll have another look at the LR25-G001 and see if it makes more sense now that I have a better understanding of some of the other parts of the system. I'll also go and re-read the DTS for Dummies guide and the drivers for the chips.
The ESR600 is working better now, but not perfectly. I've got the AR8327 switch showing up (though as "switch0 - mdio-bus"), but as with the LR25G001 it has the problem of only the WAN port and two of the four LAN ports working - the working ports are PHYs 0, 1 and 4(wan).
The 2.4GHz radio works, but the 5GHz radio takes down the system when enabled under BOTH the stock and the OpenWRT firmware. I'm guessing probably a hardware problem.
If anyone has ideas about why the AR8327 is behaving like this I'm open to suggestions -- I have already confirmed that the basic "initvals" match the stock firmware configured values. There are a number of magic values in the ar8327.c that I don't have documentation for -- the only data sheet for the chip that I can find appears to document rev2, and this is a rev4 chip, and according to the ar8327.c code there was at least one new register added.
Any guesses on why this is happening? All the PHYs are on the AR8327 switch, but the probing is selecting the 8216/8236/8316 driver for 3 of them (which work) and the Generic PHY driver for 2 of them -- which don't work.
That's a boolean property, so the "= <1>" is not required. But thanks for the suggestion anyway. I dug in to the code a bit more and thought I'd found it in the probe routine where it disallows anything but addresses 0, 3, and 4 -- which matches this observed behavior... so I tried removing that check, and it does indeed point all the PHYs to the AR driver instead of the generic one... but has no actual effect on whether the ports work or not. I think that because the switch looks like a PHY, and then the AR8327 driver code handles its own PHY probing, we end up with the higher level code probing the switch multiple times, which then probes its own PHYs multiple times. Seems like an architectural problem in the driver tree. It works equally as poorly if you only declare a single ethernet-phy on the MDIO bus -- the switch code itself still finds its own PHYs. But, regardless, it doesn't explain the non-functional PHYs yet.
Following up on my own post -- I've decided there is probably preexisting issue in the ar8327 driver that I'm not prepared to track down at this time. Everything else is working, so i've submitted a pull request for the commit with a new device tree and supporting files.