This is all inspired by GL-iNet's GL-SF1200 Home AC Router. It's powered by a SF19A2890 Dual-core MIPS CPU clocked at 800MHz.
Perhaps the root of the issue is a lack of understanding around how GL-iNet develops its router firmware from what is effectively a fork(?) of OpenWrt (https://github.com/gl-inet/openwrt) and eventually routers are supported by the official OpenWrt releases.
It is unclear to me who is involved/responsible for getting routers like the GL-SF1200 supported by the official OpenWrt releases. What does GL-iNet need to do/provide? What does the chip manufacturer (SiFlower, in this case) need to provide? What does the OpenWrt community need to provide?
It's basically simple, someone who has the device sitting on their desk and cares about getting OpenWrt working, needs to actually do the work and provide a tested patch series/ pull request. In some cases this someone might be a GL-Inet employee (which, in general, is a rare occurance), in other cases it's a motivated/ experienced user. How difficult this is going to be, varies massively between targets (and devices) - how much of the necessary SOC support and drivers is mainline, how good (and complete-) are the drivers.
Looking at this specific case, quite a bit more work than usual is needed as the used SoC SiFlower SF19A2890 isn't supported by OpenWrt at all yet. While drivers for basic features are probably available in source in the Linux 4.14 source tree, all more advanced features are binary-only and will work only with that specific outdated Linux 4.14 kernel. See all the binaries in the sf_* folders in:
Now given that you find the complete kernel sources (ie. including the sourcecode for drivers of ethernet, switch, wifi, etc.), that probably still wouldn't help too much as it's Linux 4.14. And because these drivers are most likely not built using the kernel subsystems (ie. mac80211 for the softmac-wifi cores, dsa for the switch, ...) but rather giant monolithic beasts impossible to ever run on any other kernel than that vendor one and also not trivial to "port" (rather: rewrite based on knowledge gained from...) to recent kernels.
I really appreciate you taking the time to dive into the specifics here. It definitely seems like no trivial task. I wonder how Gl-iNet is going to handle this particular router given they have a very strong track record of getting their routers OpenWrt support. Though given the information here, I have my doubts as to whether this router will ever see official OpenWrt release support...
I had made this post with the thought that I may be able to use this router as an opportunity to contribute to the OpenWrt community as I recently acquired this particular model. However, this seems very far from good-first-issue territory, to say the least. I'll find some other things that are a bit less intimidating
Regardless, could you clarify/check-my-understanding on a couple things for me?
What are some examples of the "advanced features" that would be binary-only in this instance?
Would it be correct to say that the best path forward to support is for SiFlower to 1.) put in the work to update the binaries to work with the latest-ish kernel, 2.) rewrite the drivers to use kernel subsystems, and 3.) release the complete kernel sources.
If this doesn't happen, is the best hope at support a limited feature set that forgoes the advanced, binary-only features?
I take it that from a community/project perspective where developer time is incredibly precious, the herculean-sounding effort it would take to properly support such a device without any major support from the SoC manufacturer is hardly worth the benefit, right? Put another way, I imagine it's more beneficial to support devices where it isn't such an uphill climb?
How does one even acquire the necessary experience to rewrite drivers in the manner necessary to provide support?
Probably not, indeed - and it's unlikely that they'd even try.
The best course of action is to submit SOC support and drivers to the mainline kernel, early and completely. In these cases OpenWrt support is 'easy', wait for the next mainline LTS kernel containing this support (or do targeted backports), then start working on OpenWrt integration (it's rarely this simple).
But the bare minimum would be providing full source under GPLv2 compatible licensing, to allow others doing the work necessary (a target/ device would have to be very attractive in terms of performance/ features/ pricing to convince others to spend the effort needed, but it may happen nevertheless (e.g. rtl838x recently)); the main requirements are clear and compatible licensing and full source.
sf_eswitch
driver for an external (as in: chip next to the SoC) Gigabit switch
sf_gmac
Ethernet driver
sf_hnat
Hardware NAT flow-offloading
sf_netlink
middleware to speak with Linux Kernel interfaces
sf_smac
wifi driver
sf_switch
driver for the in-SoC Fast Ethernet switch
So without all that you basically have a nice CPU with a serial port and maybe bit-banged SPI for flash access. That's much better than nothing and a good base when starting developing the missing drivers.
2 and 3 are correct.
1 doesn't work.
(there are other options, such as a more clean dual-licenced middle-ware design like madwifi back then, but lets not go there)
Of course. You got to start from somewhere. In the moment you can build a recent kernel from source and it somehow boots that's a very good point for others to join-in.
It's not so easy to judge at this point because you may well find out that major parts of the proprietary components are not too different from existing ones and might be supported using existing drivers (e.g. stmmac Ethernet). WiFi is a huge amount of work even with the support of the vendor, and it multiplies if things have to be done using reverse-engineering techniques, of course. But it's not impossible.
Well, unlike the proprietary mess out there, we got quite a bunch of well written and well documented drivers based on Linux subsystems. Understanding and working on improving these drivers (take any of the existing ethernet, dsa and mac80211 drivers which come with Linux as an example) helps to learn what is needed for such a driver to work, how to structure it and so on.
I would first check if what ever they are claiming there is really true.
Is the device running a recent Kernel?
Do they provide sourcecode for all parts of it?
Previously it more looked like they just glued a very outdated kernel with many parts not available in source code into an outdated private fork of OpenWrt...
They got something running there which they may call "OpenWRT" which is actually a fork of a very outdated version of OpenWrt with many proprietary (as in: binary-only) components.
If they are marketing this as being OpenWrt, then this is a clear violation of our trademark policy.
They may of course say "it runs our proprietary OS which is based on OpenWrt" -- just like Raspbian is based on Debian.
So that's a trademark violation (and wrong camel-casing of OpenWrt, but that's covered by the trademark anyway afaik) @aparcar@hauke@blogic maybe we should have SFC send them a friendly letter?
Or is someone of that company hanging out here and can change that on their site to avoid misleading users?
So, if its supported by this site, its supported "the true way"?
Since I have not found any differentiation between the GL-iNet way and the official way.
Outside of this thread, that is. I think that could be communicated differently.
