[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 https://docs.gl-inet.com/en/3/hardware/ar300m/

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.


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