[Upstream] - OpenWRT master, kernel 4.14 and gl-inet firmware

Any thoughts on the upstream - and the mess that is with AR7XXX/AR9XXX - which is likely at some point to be deprecated - it kind of is now, with most updates ending over in the ATH79 branch on the OpenWRT master…

Folks are working on getting GL AR300M over to Kernel 4.14 and device tree with the ATH79 target, and AR300M seems to be the tip of the spear there…


For casual users - don’t go here - stick with the factory builds…

image/generic.mk:  DEVICE_TITLE := GL.iNet GL-AR150
image/generic.mk:  DEVICE_TITLE := GL.iNet GL-AR300M-Lite
image/generic.mk:  DEVICE_TITLE := GL.iNet GL-AR300M
image/generic.mk:  DEVICE_TITLE := GL.iNet GL-AR750S
image/generic.mk:  DEVICE_TITLE := GL.iNet GL-X750

(the -Lite is mine, and will be submitting it shortly)

Lite similar to AR300M-NOR on this target - the other NIC would just be ignored as it is with current…

NAND vs. NOR - shouldn’t be that much different that what the builds are now…

Device Tree is the big deal here - and keeping it current with uBoot…

Everything should be fine with the the 3.0 release

Need a different run-time config or the device is unreachable prior to configuration, as well as during failsafe (no populated Ethernet socket for “LAN”).

There is also only three LEDs on the -Lite, not the four in the AR300M DTS. It may be that the DTS is incorrect as it appears that GPIO 2 controls the USB power, not an LED. This is possibly a “fix” that both devices need.

Edit: Will be cleaning up the DTS for the AR300M series, in general, as there are a few “errors” in it – have functional system LED now indicating timing for and failsafe entry.

Can you, @sfx2000, or perhaps @alzhao confirm that on the AR300M that GPIO 2 controls the USB power, not an LED, as well as that is is active low?

In AR300M there is GPIO2 controls the USB power, not really an LED.

check here GL-AR300M (Shadow) - GL.iNet Docs

this is not available in AR300M-Lite, it is only available in AR300M-Nor and Nand.


Looks like it to me - gpio 2 GPIO_ACTIVE_LOW for the AR300M NAND and NOR

Rest looks ok - noticed for the NAND dts file, they (Openwrt) reference the Micron mt29f, not sure if that’s a major concern, as my particular board has a Gigadevice spinand - should be safe, but need to check…

@jeffsf - remember, playing around with OpenWRT master can get one into a bad way really fast, as changes are fast and fluid, breakage there is expected part of working on the tip of the source tree…

Thanks, will look into the different NAND chip – would you post or PM me the part number?

On the AR300M-Lite that I have, it looks like what I would guess is a SMD MOSFET has not been populated and bridged with a 0Ω jumper, so I can’t confirm that the USB power will come on for a non-Lite device. Having found several errors already in the DTS (note, for example, that the GPIO for the status LED is incorrect), I don’t completely trust that the DTS has gotten the sense of that line correct. It’s probably a non-issue as you don’t want to be PWM-ing the power to your USB port as defining it as an “LED” would permit and have already removed that designation from my DTS versions.

Thanks for the warning on working on development branches. I’ve been working with “bleeding edge” since it was Backfire.

GD5F1GQ4UCYIG - it’s very similar when looking at the data sheet for the Micron and comparing things…

It’s standard stuff - 3.0v, 120MHz clock, QIO, 2048-byte read, 128K erase, WSON8 package…

The more I dig into this board, the more I appreciate the developers, there’s a lot of smart thinking that went into it.

1 Like

Just keep a copy of your art partition backed up - that’s the factory data including RF Cal… for the AR300M-NAND it’s on /dev/mtd3

cat /dev/mtd3 > art.img # this backs it up to an image file
cat art.img > /dev/mtd3 # this restores

@jeffsf - the NAND box boots out of NOR still, that’s where uboot lives…

on the testing build - 3.012 - noticed that kernel was expecting the NOR to be a Micron 8K, but found the Winbond 16K

[    0.833518] m25p80 spi0.0: found w25q128, expected m25p80
[    0.848358] m25p80 spi0.0: w25q128 (16384 Kbytes)
[    0.853261] 4 cmdlinepart partitions found on MTD device spi0.0
[    0.859369] Creating 4 MTD partitions on "spi0.0":
[    0.891689] spi-nand: Giga SPI NAND was found.
[    0.864336] 0x000000000000-0x000000040000 : "u-boot"
[    0.870837] 0x000000040000-0x000000050000 : "u-boot-env"
[    0.877866] 0x000000050000-0x000000ff0000 : "reserved"
[    0.884717] 0x000000ff0000-0x000001000000 : "art"
[    0.896339] spi-nand: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[    0.904469] 2 cmdlinepart partitions found on MTD device spi0.1
[    0.910586] Creating 2 MTD partitions on "spi0.1":
[    0.915573] 0x000000000000-0x000000200000 : "kernel"
[    0.925630] 0x000000200000-0x000008000000 : "ubi"
[    1.381634] found bad block 7fe0000

The bad block is nothing to worry about…

Only reason why I’m on openwrt master at the moment is that I’m helping out a small group that is bringing up a rockchip board, and I need to close out my stuff there before I get deeper into this board…

Yes, completely agree – hitting a US$18 price point (GL-AR300M-Lite), delivered, for such a capable device with clean, professional packaging, top-notch firmware, support, and a warranty isn’t easy. They’ve made it easy for me to recommend their products to all the people that are whining that their ancient or cheap devices with insufficient flash and/or RAM, as well as often outdated wireless chips, can’t be supported by modern, secure firmware.

From my AR300M-Lite (likely 2018 production), ath79 target, build based my changes after on

commit 7541d30c9c2946fe112d7966f9d1e7456725c324 (master)
Author: Kevin Darbyshire-Bryant <redacted>
Date:   Mon Dec 17 16:36:44 2018 +0000

I see similar

[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] MIPS: machine is GL.iNet GL-AR300M-Lite
[    0.000000] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0
[    0.384810] m25p80 spi0.0: w25q128 (16384 Kbytes)

as well as on another vendor’s product using a QCA9558

[    0.399682] m25p80 spi0.0: w25q128 (16384 Kbytes)

(I also see the same “bad block” message on my AR750S at 7fe0000)

I might be on an older uboot…

root@GL-AR300M:~# strings /dev/mtd0 | grep -nr "U-Boot" | head -n 1
384:U-Boot 1.1.4-g36de7573 (May 26 2017 - 14:42:18)

Anyways - the bad block thing, like I mention, is just a warning, not a problem… The spi-nor - again, probably just a warning based on upstream code… would be good to have confirmation from the gl-intet folks…

The Lite has challenges - but I do think upfront that the AR-300M board with NAND has some serious traction with the maker community… and worthy of an LTS version of the board

@alzhao- nice to see pepe2k for Uboot - netconsole might be handy, but like the WebUI, could be a security risk - but no more than the WebGUI there.

No GL-AR750 Ath79 target?

Not yet – I’ve “paused” work there until Kernel 4.19 for ath79 is available with the “approved” NAND framework. (Upstream rejected the approach presently used.) I’ve got a NOR version running, but that doesn’t really provide a lot over the ar71xx target.

Edit: This looks promising

I noticed a patch in the mailing list. Looks like official support for ath79:


I’m currently building the firmware to test ath79. I’m really curious if the performance will be better!

OpenWrt ath79 has been on 4.14 with 4.19 as “testing” as noted above. After 19.07 was branched, master moved to 4.19. There is no announced LTS kernel past 4.19 at this time.

I would not expect any performance improvements with just the kernel change. There may be some minor changes in performance (in both directions) due to moving from the unsupported ar71xx platform to the ath79 platform and possibly different drivers. The main change is structural in how the kernel and drivers are managed.

The GL-AR150, GL-AR300M, GL-AR300M-Lite, GL-AR750S, and GL-X750 have all been on ath79 for some time now, though with only NOR support. On master they are on 4.19 at this time.

SPI-NAND support for the GL-AR300M and GL-AR750S is under review.

I suggest there would b little change in performance - stabilit, yes, shifting to a new target introduces unknowns…

Saw the recent checkin’s on Master for AR300M/AR300Lite for the ath79 target.

Something I’ve noticed on ath79 for ar150 is that they flipped the interface mapping - eth1 is now WAN, and eth0 is LAN - not sure why… but it can cause problems that one didn’t see on the ar7xxx, where the ar150 machine file shows eth0 as WAN

I might have to dig into this further, but my attention lays elsewhere at the moment… just curious if you see the same thing on the ar300m targets you’re working on.

For the community here - as @jeffsf mentions - no change in performance, so no big hurry to jump

Something about driver initialization, as I recall.

The flip, I believe, was undone with

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>

I resolved the first-boot issues that then arose with the GL-AR300M-Lite in commit eba0db95b5