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…
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?
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.
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.
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.
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.
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.
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
