Once again, GL-iNET is misusing the OpenWrt trademark . This device is not supported (yet) in vanilla OpenWrt, but only in their private fork. That means that you cannot just install package from OpenWrt's download server and you depend on updated firmware from the vendor. See https://github.com/gl-inet/gl-infra-builder
Once support for MT7981 SoC will hit OpenWrt and mainline Linux (probably only next year), then it is very likely that GL-iNET devices with that chip will be among the first being supported.
Misleading information about software compatibility will not do them a favor, that's for sure. And just calling it "OS based on OpenWrt" or anything like that would make it more clear and won't hurt anyone.
However, it's important to also mention that they are doing a pretty good job publishing sourcecode for use with their hardware, especially when you compare them to the rest of the industry...
I doubt that. Think of the many posts over the years from people who complained here in the threads - when they found out their devices wasn't [yet] supported; but magically it "already has OpenWrt installed". Some even insist we support hardware problems too!
(I know there was at least one such post in the last 24 hours.)
The OEM got their already - we (the community) get the headaches.
Seems to be selling routers.
I'm curious - is there a instruction page that
Is there an instruction on that?
Because I think you're noting No.3 but...it seems totally to match No. 1 ("communicate compatibility with your product truthfully").
I thought that was how OpenWrt started in the first place...
(I say that sarcastically about the original code that started open source routing software - my point was that they do offer the very code...are there code blobs missing that would be used to instantly port the device into OpenWrt?)
It's a bit different from the original WRT54G case: Linksys only supplied the most necessary source code without history or even ability to actually build a firmware binary. And they did that only after loosing in court.
GL-iNET generally supplies complete sources even before a product becomes publicly available, the sources include version history (git), build instructions and it's easy to compile a firmware binary with that.
So that's much better and way more than what would be the legal requirement for GPL.
You can build a firmware from source for this device -- but with an outdated kernel and bloated drivers which come from MediaTek SDK. While in most parts the MT7981 SoCs are very similar to MT7986, some parts do differ such as clocks and pinctrl. I've tried using the clock and pinctrl driver from MediaTek's SDK with OpenWrt -- unfortunately Linux freezes on boot.
So what would be needed is a major clean up or even re-write of those clock drivers and a bit of cleanup for the pinctrl driver, all that will most likely happen within the next 3-4 months.
Supply patches to upstream Linux kernel to add hardware support. Once hardware is supported in Linux kernel, we can add (ie. backport) support to OpenWrt.
Then it's easy, all they have to do is submit board support code (ie. device tree and board-specific user-space scripts).
Chip designers supply downstream board manufacturers with a software development kit. Usually this contains a (terribly outdated) Linux kernel and a minimal Linux user-space distribution, often times based on OpenWrt. Usually this is developed behind closed doors by the chip designer and it wouldn't even make much sense for them to send any of it upstream at the point the chip designer is working on it, as the chip is not yet mass-produced and no devices for testing/validation are available in the market.
@nbd clarified that fq_codel + AQL + ATF is all handled on top of the mt79, but that the RU scheduling within a txop for multiple stations requires AQL.
I should be happy, right? fq_codel + atf is good!
But: for the record, I HATE AQL. It's not a needed feature, it is a badly managed hack of an extra buffer that can add 10s of ms excess latency to an otherwise great wifi chip. Far better would be device firmware that exposed per-stations queues and can be gang scheduled by the firmware providing what stations can be talked to at the same time.
I am hugely disappointed that AQL is still needed by successor chipsets and wifi7 device driver designs, after 10 years of me describing how to do it better.
I made the mistake of buying xiaomi ax3200 and it doesn't support wifi 6 for 2.4GHz. It was on sale and I made a mistake in hurry. My question is why doesn't it support AX standard for 2.4GHz?
due to still ongoing chip shortage several router manufacturers have combined the older mt7621 with an AX 5GHz wifi chip.
That results in non-AX on 2.4 and overall less CPU computing power. A very shallow concept with major drawbacks, but it gives you the „AX“ label on marketing slides.
I recently acquired a ZBT Z800AX which is based on the Qualcomm IPQ8072 SOC, arm cortex a53s. It was listed as running OpenWRT and so I naively assumed that meant it was a supported device. It does run OpenWRT, but an apparently heavily modified custom version of chaos calmer 15.05.1.
I'm having problems getting a modem configured on it and I believe I'd benefit from a more recent release. It's fairly recent hardware and from a non-major manufacturer so not surprisingly I don't see it listed as supported and may not ever but I'm curious if a build for another device with the same hardware might work? Any ideas would be appreciated.
No, you will have to port OpenWrt support for your device yourself; the ipq807x target support is still under development/ pending (see the Xiaomi ax3600 thread for details).
If you need a solution now, get a different device, otherwise be prepared to spend significant time and efforts on doing the necessary development (and hope that ZBT didn't shut the door too closely via secure boot).