The OpenWRT project is now two decades old. The project has come a long way since Linksys was forced to release the GNU-licensed code for the original WRT54G router from which the project takes its name. They’ve marked the occasion in an interesting manner: by proposing that the plethora of devices supported by the OS be joined by a fully upstream-supported reference hardware platform.
Spec-wise it’s what you would expect for a hackable router platform in 2024. A MediaTek chipset can be found at its centre, but the hardware is not in this case the important bit. Here will be a platform that won’t have to rely on proprietary manufacturer BLOBs, and which will thus likely continue to have up-to-date kernel support long into the future. So many enticing SBCs fall in this regard, and many retain ossified kernel versions after their manufacturers tire of them as a result.
It appears that the future of this project will be subject to an OpenWRT community vote, and we sincerely hope that it will come to fruition. Meanwhile, we couldn’t resist a peek at the status of the router that started it all, by our reckoning the original WRT54G was last supported by the OS over a decade ago.
Blimey I feel old :)
Still have the original.
Story talks about being free of software obsolescence but in routers it’ll be hardware obsolescence that dooms it.
I’d argue software will still tend to be first unless its already an OpenWRT supported model – it is going to be abandoned by the ISP/Maker and left limping along long obsolete long before the WiFi and Ethernet standards have moved on so much the hardware isn’t practical.
Won’t support the latest generations of WiFi speed etc, but even into WiFi 11 and beyond the devices will probably be able to talk to the older router just fine – so the upgrading hardware only becomes important for a relatively small group of folks that actually need the latest standard’s speed/bandwidth, better frequency hopping or whatever.
No it’s also about security.
I think I still have three. One had bad ram, and my replaced ement job didn’t work. Two have bad flash chips. But a hoarder gotta hoard … :(
Still running my original 54G and every router since has been reflashed with openwrt. It’s the bomb!
Would love to see the reference board design be a drop in replacement on the 54G. Kinda like a sleep router if you will. I’ve got a couple broken ones that can be repurposed.
I e-wasted my unused for a long time OG five years ago when I moved across country and had to get rid of a lot of old treasure
The nice thing about having a hardware reference platform is that once you have one, it won’t be the last. They’ll be able to keep tracking hardware improvements. Just as we weren’t all stuck with Raspberry Pi 1.
The challenges that the community needs to overcome here are pre-FCC-approved Wi-Fi modules that are being designed into new hardware so that there’s less cost and time bringing it to market. The firmware just totally stinks in those things, and it’s usually immutable in practice – though perhaps physically capable of a manufacturer update – once installed. And of course the other things like manufacturers who only want to support an HAL for their hardware that’s a proprietary BLOB.
It’s pretty much guaranteed that a viable and fully supported reference platform for OpenWRT will become the reference platform for a generation of commercial devices. And it’s much better to lead hardware development than follow it.
Love this! :-)
> Spec-wise it’s what you would expect for a hackable router platform in 2024. A MediaTek chipset can be found at its centre,
Oddly enough, I’ve repurposed my wife’s old 10″ Amazon Fire HD tablet (suez) to run debian. It, too, uses a mediatek chipset, the MT8173 – and this chipset suffers the precise issue mentioned in this article, as it’s still stuck on a proprietary version of a 3.18 kernel.
Most SBC manufacturers are garbage – but despite that, I certainly hope openwrt can pull it off!
In my experience, tablets and phones are much more prone to the proprietary-kernel issues than their (non-radio) hardware would suggest or require. I think it mostly has to do with the development pipeline, given the need to support often-NDA-proprietary cellular radio hardware. Since there’s already a bunch of baked-in vendor-private stuff required, it’s a slippery slope to simply include more and more stuff without backporting it to mainstream.
blobs alone aren’t really a problem; they’re often just bitstreams to turn a collection of gate logic into a functional peripheral device with documented api. as long as the same blob ships, the peripheral behaves the same (and drivers can be developed normally). FPGAs are really convenient for creating certain kinds of peripherals, and letting the host load the bitstream really simplifies the peripheral and saves the price of a microcontroller and some flash. Most blobs don’t really get updated that often, and many stay static during the whole life of the product.
Lots of work has been done to bring the MT8173 upstream, but even if this is fully completed, it won’t automatically ensure that a given tablet would work with purely upstream kernel, due to other hardware choices(peripherals, and how they were interconnected). None of this should be a problem in an intentially-designed-for-reference design.
It’s been a while since I played around in embedded designs, but over the last few years a lot more vendor effort has gone into upstreaming hardware support. Some of this was driven by Android switching to an “upstream-first” policy. However, a big portion of it comes from the fact that, especially in embedded, most (or even all) of the intended use for a given part is as a component of some product that will be running linux in some way…
An OpenWRT reference platform shouldn’t be that expensive or difficult to design, so long as there is interest, and discipline is maintained to keep the primary goals in mind.
§%/&TZUBNGJ/&%/&”)!!!
I definitely need to update my twin Zsuns!
I have a zsun to openwrt devs, but i think it was never supported because they did not liked to make an exception for turning the wifi on by default at boot time.
Shed a tear that the Intel wifi modules don’t expose an access point mode to let us roll our own.
I wonder if glinet is involved. They seem almost suitable already.
I belive it won’t be that easy for a referece design to be CE/RoHS compliant.