Building support for EnGenius ESR600

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:

  • MediaTek MT7620A w/ 64MB RAM (Nanya MT5TU32)
  • Flash: MXIC MX25L12845EMI-10G (16 MB)
  • 2.4GHz WiFi (RT3091 as part of SoC)
  • 5GHz WiFi Ralink RT5592N
  • Gigabit switch: AR8327-BL1A
  • 4 LAN ports, 1 WAN port
  • LEDs: wifi 5G, wifi 2.4G, power, WAN, WPS 5G, WPS 2.4G
  • Buttons: Reset, WPS
  • Bootloader: U-Boot 2013/05/21 10:15:14

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-- "" 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.

Does anyone have any other helpful suggestions?

I'd throw the stock back on it and poke the daylights out of it. You can also tear apart oem firmwares to extract some useful information.....

Are you able to get a shell on stock?


Other than that, maybe throw your sample dts up on pastebin or something so someone might see something obvious..... regulator enable maybe? clocks?

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.

1 Like

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.

/sys/bus/mdio_bus/drivers/Atheros AR8216!AR8236!AR8316:
--w-------    1 root     root          4096 May  5 10:35 bind
lrwxrwxrwx    1 root     root             0 May  5 10:35 mdio-bus:00 -> ../../../../devices/platform/10100000.ethernet/mdio_bus/mdio-bus/mdio-bus:00
lrwxrwxrwx    1 root     root             0 May  5 10:35 mdio-bus:03 -> ../../../../devices/platform/10100000.ethernet/mdio_bus/mdio-bus/mdio-bus:03
lrwxrwxrwx    1 root     root             0 May  5 10:35 mdio-bus:04 -> ../../../../devices/platform/10100000.ethernet/mdio_bus/mdio-bus/mdio-bus:04
--w-------    1 root     root          4096 May  5 10:35 uevent
--w-------    1 root     root          4096 May  5 10:35 unbind

/sys/bus/mdio_bus/drivers/Generic PHY:
--w-------    1 root     root          4096 May  5 10:35 bind
lrwxrwxrwx    1 root     root             0 May  5 10:35 mdio-bus:01 -> ../../../../devices/platform/10100000.ethernet/mdio_bus/mdio-bus/mdio-bus:01
lrwxrwxrwx    1 root     root             0 May  5 10:35 mdio-bus:02 -> ../../../../devices/platform/10100000.ethernet/mdio_bus/mdio-bus/mdio-bus:02
--w-------    1 root     root          4096 May  5 10:35 uevent
--w-------    1 root     root          4096 May  5 10:35 unbind

The ESR600.dts looks like this for the the Ethernet:

&ethernet {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&rgmii1_pins &mdio_pins>;
        mtd-mac-address = <&factory 0x4>;
        port@5 {
                status = "okay";
                phy-mode = "rgmii";
                mediatek,fixed-link = <1000 1 1 1>;
        mdio-bus {
                status = "okay";

                ethernet-phy@0 {        /* AR8327 switch */
                        reg = <0>;
                        phy-mode = "rgmii";
                        label = "lan4";
                        qca,ar8327-initvals = < /* Replicated from stock firmware U-Boot */
                                0x10 0x40000000 /* POWER ON STRAPPING */
                                0x04 0x07600000 /* PORT0 PAD MODE CTRL */
                                0x7c 0x00001476 /* PORT0 STATUS */
                                0x08 0x00000000 /* PORT5 PAD MODE CTRL */
                                0x0c 0x00000000 /* PORT6 PAD MODE CTRL */
                                0x94 0x0000007e /* PORT6 STATUS */
                                0x80 0x00000200 /* PORTS 1 - 5 STATUS */
                                0x84 0x00000200
                                0x88 0x00000200
                                0x8c 0x00000200
                                0x90 0x00000200
                ethernet-phy@1 {
                        reg = <1>;
                        phy-mode = "rgmii";
                        label = "lan3";
                ethernet-phy@2 {
                        reg = <2>;
                        phy-mode = "rgmii";
                        label = "lan2";
                ethernet-phy@3 {
                        reg = <3>;
                        phy-mode = "rgmii";
                        label = "lan1";
                ethernet-phy@4 {
                        reg = <4>;
                        phy-mode = "rgmii";
                        label = "wan";

well.... this line seems incomplete;

mediatek,mdio-mode; > mediatek,mdio-mode = <1>;

i'd try pasting out that whole section from similar devices you can find.... less is more....

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.

1 Like

It’s a Boolean property, so the = <1> is unnecessary. But thanks for the suggestion anyway.

1 Like

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.

I'm waiting for the review process to grind slowly along. If the merge of my code happens I'll look deeper into the problem.