hi, i intend to flash a clean openwrt on AR750S. but i’m completely confused after reading NOR/NAND/UBOOT stories all along. so far i have openwrt experience only with TP-link Archer C7 v4 which does not have these fancy hardware features just a sole NOR flash afaik.
also openwrt providing bin files while GL-inet download offers img FW files.
my question how i can clean up the router and how and where to flash the openwrt itself.
If/once accepted, the following PR will provide native NAND support with “vanilla” OpenWrt.
The juggling with U-Boot that you probably have read about is due to the lack of support for SPI-NAND flash in “vanilla” OpenWrt prior to the adoption of Linux 4.19 and the upstream SPI-NAND framework. These patches also provide a NAND-aware kernel and the sysupgrade hooks as an option for both the GL-AR300M and the GL-AR750S which allow “cross-flashing” of NAND <=> NOR, which was not available on the ar71xx platform.
Edit:
If you’re in a rush for the NOR-based version, the OpenWrt sysupgrade.bin would need to be flashed through U-Boot if you are running NAND-based firmware at this time. Older GL-AR750S boot loaders had challenges with non-Windows computers. If you run into one of these, a Windows machine is needed to update the U-Boot.
thanx jeffsf, i guess exactly these 2 readings you linked pushed the hot iron into my brain.
if i got it good NOR vs NAND flashes are like 2 boot drive 1 being e.g. a CD-RW and the other is a USB stick (sorry for the dumb parallelism). And U-boot is the U/EFI/bios bootloader.
And upon your hard work succeeds some next stable version of openwrt will understand both drive to run from them, while the bootloader will understand that there is a bunch of different drives so which one wanna use to install the OS on it or which installed OS i wanna start up?
Embedded devices aren’t quite like desktops. What to boot and what file system to use depend on the boot loader and the kernel. U-Boot isn’t quite as “smart” as EFI. It’s more, “What’s the boot counter? Ok, 0? Set it to 1, load the kernel from this address into memory here, and jump execution to its entry point” than anything really sophisticated.
On the GL-AR300M, right now, its U-Boot supports either booting from a NOR-resident or a NAND-resident kernel, depending on a “boot counter” in its preserved environment. More than 3? Boots from NOR, otherwise from NAND. This device supports “dual firmware” where there are two kernels.
The Gl-AR750S, right now, its U-Boot only supports a NOR-resident kernel. So it doesn’t have complete dual firmware. When the kernel loads, it is “pre-programmed” for its root file system on NOR, or on NAND.
Maybe one day I’ll get current U-Boot source and the time to poke at it for the GL-AR750 to provide dual-firmware operation.
ohh, if i see it right its like AR750S presently will boot the kernel always from NOR and the kernel will understand and use the NAND flash as extroot (like a plugged in usb stick on Archer C7 with extroot setup)?
No, a little different than that.
Early on in the kernel boot process (very, very early, actually), it looks at the kernel command line and any overrides built into the kernel. Based on that, it tries to mount root. Typically, for an OpenWrt system, it mounts root first as the ROM, then the “overlay” file system on top of it. The overlay is like tracing paper; if there is a file with the name you’re looking for, you see that, If not, you see what is in the ROM beneath.
“extroot” is really something else, another step beyond that. Once the ROM is mounted as root, with the overlay from the flash, a second overlay is mounted, often from a USB stick.
The AR750S will boot a kernel from NOR flash, then either
- Mount ROM and overlay from NOR
- Mount ROM and overlay from NAND
The way the kernel can “tell” which to mount is based on the flash layout compiled into the kernel. Here’s the flash-detect and how the kernel decided to interpret it (there’s no GPT, MBR, or the like on the flash, just what is in the kernel)
[ 0.409401] m25p80 spi0.0: w25q128 (16384 Kbytes)
[ 0.414306] 6 fixed-partitions partitions found on MTD device spi0.0
[ 0.420889] Creating 6 MTD partitions on "spi0.0":
[ 0.425852] 0x000000000000-0x000000040000 : "u-boot"
[ 0.431736] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.437900] 0x000000050000-0x000000060000 : "art"
[ 0.443510] 0x000000060000-0x000001000000 : "nor_firmware"
[ 0.449948] 0x000000060000-0x000000260000 : "kernel"
[ 0.455733] 0x000000260000-0x000001000000 : "nor_reserved"
[ 0.466244] spi-nand spi0.1: GigaDevice SPI NAND was found.
[ 0.472058] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[ 0.480690] 1 fixed-partitions partitions found on MTD device spi0.1
[ 0.487253] Creating 1 MTD partitions on "spi0.1":
[ 0.492240] 0x000000000000-0x000008000000 : "ubi"
“ubi” has special meaning to the OpenWrt kernel, so that is what was selected (on NAND). Had the NOR section been called “firmware”, it would have been selected instead (assuming the other wasn’t named “ubi”).
You can see how the names are defined in the kernel definition for NOR root file system (there’s a lot of magic – but at least here you can see the nodes for the different partitions being named or removed, as appropriate)
/delete-node/ &nor_kernel;
/delete-node/ &nor_reserved;
&nor_firmware {
compatible = "denx,uimage";
label = "firmware";
};
whereas for the NAND root file system
&nor_kernel {
label = "kernel";
};
&nand_ubi {
label = "ubi";
};
I start to feel obsolete, so i have to keep learning more.
Sometimes i’m wondering what went wrong with the “computational” electronics in the 21st century. In the mid 80s i had a zx-spectrum with a zilog-80 processor 16kB ROM and 48kB RAM and a 5.25 floppy drive was an unbelievable achievement in storage compared to compact cassette tapes. And we developed a CAD software on it with “finite element” calculation/sim to design full-blown road/railway bridges. Fine honed assembler code. And it worked and the bridges still standing. There one could focus on solving computation tasks.
Here and now like an IKEA furniture home assembling when you get the wrong instruction-drawings and the wrong screw-pack with the wood.
So i truly appreciate the job you do to blow a more friendly “ghost in to the shell”.
cheers, lev
Thanks for doing this. I have a copy of the openwrt repo with this pull request applied here: GitHub - IETF-Hackathon/openwrt: This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins or for reporting issues. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git. All issues should be reported at: https://bugs.openwrt.org
I’m going to be using this at the IETF hackathon in Montreal in a little over a week. However, I have not been able to get the sysupgrade that I built to install on a version of the system built with the old patches you provided for openwrt 18.06 to make NAND work. Is there something different about this? Is there a way to flash this not from sysupgrade? Or is it possible that I accidentally built the NOR version, even though I’ve applied this pull request?
If you applied the ath79, NAND patch series to OpenWrt master, or cloned my repo and checked out the branch, you should be able to build ath79 > NAND > GL-AR750S NOR/NAND (NOR kernel, NAND file system). Perhaps you built an ar71xx image? (Looking at your repo, it’s probably the next paragraph.)
The other thing is that the running kernel needs to “talk NAND” to flash NAND. If you’re running an ar71xx NOR build, you can either flash using U-Boot, or sysupgrade with the ath79 NOR version, then sysupgrade with the NOR/NAND version.
1 Like
Thanks, that was it. The current install is an old NAND build, so hopefully it will work to flash the new version. Is there a reason why the AR-750S appears under both architectures?
1 Like
ar71xx is in “no commit” status. It will shortly be removed from master entirely.
Edit:
Apologies for the terse answer, I was down to 2% on my phone.
Upgrade should go smoothly for you. I checked all the devices from OpenWrt, GL.iNet NOR, and GL.iNet NAND so it shouldn’t require “force”.
I’m curious what you’re hackathon is all about. If you’ve got some time, would you drop me a line here, over at the OpenWrt boards, or to the email on the commits?
bahh, yesterday i received those ar750s routers, them sooo tiny. Regarding mesh setup, would it help with overall mesh throughput, if i install a usb wifi stick on each of them (i have a fistful rtlxxxx noname sticks)?
What is on my mind, to have the mesh running on the built in 2.4gHz radio, and each node to provide independently set channel 2.4gHz AP for clients via usb stick wifi.
Would it worth thinking about it?
Not the most robust devices, but perhaps worth a try.
meanwhile i found the “village telco” community had the same in their mind, attaching usb cabled adapters with ext-directional antennas to node routers. and playing with whois the mesh whois the local ap.
@jeffsf : Thanks for all your work on the NAND side of the gl-inet devices.
Lately I have been trying to convert my AR300M from stock firmware to clean openwrt NAND firmware. So far, I was not successful.
I have been using this NOR firmware to convert the NOR part of my device to clean openwrt. This worked. Now, when I try to convert also the NAND part using any of the firmware from this link, I always get the following error message from sysupgrade:
root@OpenWrt:/tmp# sysupgrade -n openwrt-ath79-nand-glinet_gl-ar300m-nand-squashfs-sysupgrade.bin
Image metadata not found
Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
Image check failed.
root@OpenWrt:/tmp# sysupgrade -n openwrt-ath79-nand-glinet_gl-ar300m-nand-squashfs-factory.ubi
Image metadata not found
Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
Image check failed.
Do you have any clue, what could be the problem?
Thanks for your help!
BR, Dennis
There is no support for SPI-NAND on ath79 in any of the upstream OpenWrt branches or snapshots.
That AR300M “NAND” image has been non-functional as long as I’ve been aware of it (there is no driver for SPI NAND in the OpenWrt tree for the ath79 target) and OpenWrt has on multiple occasions ignored or refused to accept patches to even remove the broken code.
I’ve jumped through the hoops of getting the needed SPI-NAND drivers accepted by mainstream Linux, resolved all the upgrade and cross-grade issues months ago, yet the code still rots without meaningful review. PR linked in post 2 of this thread is still open, has been recently rebased on master, and continues to build valid images for
- GL-AR300M-Lite
- GL-AR300M16
- GL-AR300M NOR boot, NAND-aware
- GL-AR300M NAND boot
- GL-AR750S NOR root, NAND-aware
- GL-AR750S NAND root
The general upgrade path is OpenWrt or GL.iNet firmware to NOR-based, NAND-aware version, to NAND-based version. Direct flashing of a NAND-based image through U-Boot is also possible.
Thanks for your prompt response. It is really a pity that your PR does not get more attention from upstream OpenWrt. I will clone your repo then and try to build the images myself.