Mainline OpenWRT on GL-X1200 Amarok

ChrisW · November 7, 2019, 12:13pm

Hi, hope this is the right place to make contact; if not, please feel free to send me elsewhere to the correct contact point.

I’m interested in your GL-X1200 router, but am looking to run mainline OpenWRT on it, building my own heavily stripped down image. (I’m not a fan of web interfaces or unused code on networking hardware.)

I’m fine with tracking git master branch if support hasn’t yet hit a release, but can’t see any device tree under

git.openwrt.org Git - openwrt/openwrt.git/tree - target/linux/ath79/dts/

and I can see the commit adding ath79 support for the GL-X750, but no corresponding commit for the GL-X1200:

git.openwrt.org Git - openwrt/openwrt.git/commit

Does it just run the same image as a GL-X750, or has there been a problem with upstreaming support for this router?

jeffsf · November 7, 2019, 5:20pm

Welcome Chris!

GL.iNet provides source for their firmware at GitHub - gl-inet/openwrt: This repository is fork from openwrt official repo, we will update the latest tag and release GL.iNet firmware based on it.. I believe you should be able to build a v18 image from that, configured as you desire. 19.07.0-rc1 was just tagged, so I expect that GL.iNet will update their firmware once 19.07 is a “release” and the dust has settled.

Most likely the reason that it hasn’t been “upstreamed” is a combination of the deprecation of the ar71xx target, no SPI-NAND support on ath79 (yet¹), and nobody with a GL-X1200 in hand to do the port to ath79 and test it.

¹ Long story, but it looks like this will finally be merged to master (not 19.07) in the next few days

github.com/openwrt/openwrt

ath79: Enable target for SPI-NAND; Support NAND for GL-AR300M and GL-AR750S

openwrt:master ← jeffsf:ath79-nand-pr

opened 07:29PM - 30 Jun 19 UTC

jeffsf

+363 -118

# Overview This series of commits prepares for use of SPI-NAND from the upstr…eam Linux MTD framework for the ath79 target. It addresses upgrade issues associated with tar-style files and metadata, allowing "force-less" upgrade paths from ar71xx to ath79 builds, including from previous NOR builds to ath79 builds that support NAND. Addresses comments in previous PRs around SPI-NAND support, including https://github.com/openwrt/openwrt/pull/615 https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401 in the manner requested by @mkresin > Please re-spin [PR 1428] as soon as we have kernel 4.19 support. SPI-NAND support in this PR utilizes the upstream Linux framework, as requested. The GL.iNet GL-AR300M and GL-AR750S devices are then supported using NAND with this framework. The commits have been resequenced here from the order in which they were developed to provide clearer patches, rather than the original "find a problem and fix it" order. As a result, the reasoning behind some of the preliminary set of commits may not be completely clear until the devices are added in subsequent commits. Original development done on `master` prior to the 19.07 branch and the change to Linux 4.19 for the ath79 target. This series should be able to be backported to v19 by adding `KERNEL_PATCHVER:=4.19` to `target/linux/ath79/nand/target.mk` Boot logs and/or upgrade logs of any configuration or transition available on request. # Roadmap of Commits These logical "chunks" of commits are denoted in [my GitHub repo](https://github.com/jeffsf/openwrt) as tags. The links within each chunk's description below will show the commits and changes associated with each chunk. The tags will be updated should this PR be rebased or changed prior to merge, keeping the tag-based links usable. In addition to the supplied links, the tags are available in clones of my repo for local examination and exploration of the commits in this PR, without the need to apply remote patches to a local repo. ``` pr2184-00-merge_base pr2184-04-Prepare_ath79-nand_target pr2184-05-Enable_robust_upgrades pr2184-06-GL-AR300M_NAND_support pr2184-07-Add_GL-AR300M16 pr2184-08-GL-AR750S_NAND_support ``` Accepted from Patchwork: * <strike>pr2184-01-Add_I2C_support</strike> * <strike>pr2184-02-uboot-envtools_support_for_GL-AR300M-Lite</strike> Superseded by commit 5b6a809092 and related: * <strike>pr2184-03-Refactor_of_common_functions</strike> ## Prepare ath79-nand Target <strike>* ath79: Remove legacy GL.iNet GL-AR300M NAND target Removal for reimplementation [confirmed with original author](http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017190.html).</strike> Retained and _replaced_ on suggestion of @adrianschmutzler * ath79: Prepare NAND subtarget for upstream support of SPI NAND Use of subtarget-specific `nand/base-files/` makes this a lot cleaner and doesn't impact the generic or tiny targets. Examination of the tiny target (and the one-board nature of `base-files/lib/functions/k2t.sh`) suggest that a few kB might be saved for the tiny target by similarly splitting out its own files from those for the generic target. This refactoring of the generic and tiny sub-targets was not performed. _(See further https://patchwork.ozlabs.org/patch/1181653/ by @adrianschmutzler for the ath79 target and https://github.com/openwrt/openwrt/pull/2513 for the ramips target.)_ https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-00-merge_base...jeffsf:pr2184-04-Prepare_ath79-nand_target _Also available as https://patchwork.ozlabs.org/patch/1186259/_ ## Enable Robust Upgrades * build: sysupgrade-tar alt-board= for legacy upgrades Existing sysupgrade tooling on the ar71xx platform isn't able to upgrade to ath79 NAND images, even with the use of SUPPORTED_DEVICES. * sysupgrade: NAND: Prefer CONTROL for board, improve robustness Rather than taking the first directory found in the tar as that from which the assets are obtained, trust the contents of the CONTROL file found. Though the CONTROL file could be fed to sh, parse it somewhat robustly to allow for a transition to JSON or other formats in the future. grep -m 1 -o -E "\bBOARD=[^[:space:]'\"]+" Exploration of legacy flashing revealed some "interesting" behavior of the NAND upgrade process off the "happy path". The most egregious were addressed. Unmodified, `nand_do_upgrade_success()` continues to perform a reboot rather than returning. This continues to prevent boards from checking that the flash was successful prior to changing the next-boot partition. Do to the invasiveness of changing this, it was not refactored at this time. Future refactor of this should also consider using the existing `$CONF_TAR` rather than the hard-coded `local conf_tar="/tmp/sysupgrade.tgz"` Error-checking was examined, but between the above concerns and the challenges on getting return codes from pipelined commands under `sh` (neither `pipefail` nor `PIPESTATUS` are available) it was not further pursued. Initial thoughts were that non-zero error codes might be split into those that were still bootable ("warnings") and those that were not bootable ("errors"), perhaps as positive and negative for ease of consistent implementation. https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-04-Prepare_ath79-nand_target...jeffsf:pr2184-05-Enable_robust_upgrades _Also available as https://patchwork.ozlabs.org/project/openwrt/list/?series=138554_ ## GL-AR300M NAND Support With the previous support in place, the boards can be added. Features such as access to NAND storage while booted under NOR (intentionally, or as a result of boot-count based fail over) and flashing either NOR-based or NAND-based firmware are provided. Legacy NOR boards may be transitioned to full support of NAND without serial, U-Boot access, or use of "force" in sysupgrade. For example Legacy NOR ==> glinet,gl-ar300m-nor ==> glinet,gl-ar300m-nand Direct transition to glinet,gl-ar300m-nand from a NOR kernel is not possible and is prevented by checks already in place within sysupgrade. For example: ``` LEDE_RELEASE="OpenWrt 18.06.2 r7676-cddd7b4c77" "model": { "id": "gl-ar300m", "name": "GL.iNet GL-AR300M" }, root@OpenWrt:/# sysupgrade /tmp/OpenWrt-2019-06-29_0807-0700-ath79-nand-glinet_g l-ar300m-nand-squashfs-sysupgrade.bin Invalid image type. Image check 'platform_check_image' failed. ``` https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-05-Enable_robust_upgrades...jeffsf:pr2184-06-GL-AR300M_NAND_support ## Add GL-AR300M16 As the glinet,gl-ar300m-nor board was moved to the NAND target in the previous commits, there is not a "generic" build suitable for the dual-port, NAND-less GL-AR300M16, or for users of the GL-AR300M that do not need access to the NAND (which adds ~320 kB at this time). This commit clearly disambiguates the "generic" (NOR-only) build and its primary, intended device from the NAND-aware build. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-06-GL-AR300M\_NAND\_support...jeffsf:pr2184-07-Add\_GL-AR300M16](https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-06-GL-AR300M_NAND_support...jeffsf:pr2184-07-Add_GL-AR300M16) ## GL-AR750S NAND Support Two variants are provided, one with root file system on NOR flash, the other with it on NAND flash. Consistent with the OEM firmware at this time, the kernel always resides on NOR flash. As noted in the commit message, the "glinet,gl-ar750s-nand" board name is reserved for a potential, future build that boots its kernel from NAND flash. It is likely that change to the U-Boot would be required to boot off NAND, either from the manufacturer or a third party. The current U-Boot provides for updating itself through an HTTP interface, without serial connectivity being required. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add\_GL-AR300M16...pr2184-08-GL-AR750S\_NAND\_support](https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add_GL-AR300M16...pr2184-08-GL-AR750S_NAND_support)

sfx2000 · November 8, 2019, 5:38am

It’s a bit early for Amarok, looking in from the outside - cloning gl-inet’s repo is a good place to start.

git clone https://github.com/gl-inet/openwrt.git

And there you’ll find the target… that should get you sorted

amarok-openwrt-glinet-fork

FWIW - as @jeffsf mentions - over on ath79 on master, there are issues with flash on split NOR-NAND targets, and it seems that Amarok might fall into that bucket, similar to GL-AR300M and GL-AR750S on the ath79 branch

ChrisW · November 9, 2019, 5:59pm

Thanks for the replies. Yes, I’d spotted gl-inet’s repo, but as you say, they’ve based their patches against a release branch and an obsolete system target, rather than master and ath79. There’s also a bunch of other patches applied there as well as the extra profile for GL-X1200.

I’m probably over-paranoid about non-mainline forks from working with kernels on embedded ARM boards, where manufacturers throw prehistoric “BSP” kernels over the wall to rot, never rebasing them. (Their patches are often of such embarrassingly poor quality that they’d never make it into the mainline kernel: sometimes they can’t even write a device tree for their own hardware correctly!)

gl-inet do give the appearance of being much higher quality than that.

I’m reluctant to commercially deploy anything that isn’t properly upstream, but if I get some free time, I’ll buy a test router and have a dig at the relevant diffs as they’re quite possibly trivial to port forward on top of openwrt master with your pending NAND+NOR flash patches.

With any luck, gl-inet will beat me to it…

sfx2000 · November 9, 2019, 11:32pm

Even on master, ar7xxx/ar9xxx is not obsolete, not just yet - much of this is around the migration to ath79 with device tree, and then there is the NOR/NAND split issues for devices that support NOR/NAND

Onboarding a new target into Mainline - yes, going with ath79 would be a long term solution, but as mentioned earlier, would take a contributor time to bring it on board, and this is a fairly new device, probably not in the hands on one with the skills, and more importantly, upstream commit access into master.

If you look at Master now - you’ll find quite a few GL-Inet targets already in and supported.