Like I said above, if there is a downloadable firmware image available from the OpenWrt buildbots in the release downloads.
Preferably the current releases:
There is a huge difference between a hacked-up and partially proprietary OS somehow based on OpenWrt on one hand and on the other having all the drivers needed and a recent Linux kernel built from source, having documented the code and it being accepted by the community after review.
The former is impossible to maintain in the long-run, meaning you will have to live with bugs and vulnerabilities because you can't do anything about it (as not all components are available in source-code form -- and even if we had those sources, I bet the code quality is so low that it would still need a huge amount of work to get it cleaned up and built on top of an up-to-date Linux Kernel).
We may need to put more effort into enforcing that, but it's actually quite clearly stated in our Trademark Policy:
You can use OpenWrt trademarks to make true factual statements about OpenWrt or communicate compatibility with your product truthfully.
So using the name OpenWrt claiming that our firmware is supporting a specific device is only legal if that's actually true. Meaning that the device is supported by the sourcecode on git.openwrt.org and binaries provided at downloads.openwrt.org. If you don't find it there, it's not supported. To make it easier, you can use the OpenWrt Firmware Selector to quickly search among the supported devices.
Going back to your original question: Up to now GL-iNet always chose chips which were already well-supported by OpenWrt for their router products (e.g. QCA or MediaTek). SiFlower SoC is not supported at all yet, neither by OpenWrt nor upstream by the Linux Kernel. So it takes more than just copying over a device-tree file and adding a few lines of shell-code to setup things in userspace...
Has anyone conntacted Gl-INet yet for this breach of contract?
And here I was thinking they were the best vendor to go with since they appeared to have wide support (and they are the main results on amazon for openwrt), but if they aren't upstreaming, that's not very helpful. Is there a list of vendors that actually work with and upstream to OpenWRT, instead of just living downstream or having their devices reversed? If I'm going to spend money on a new device I'd like to reward companies who do things the right way.
Yes, I realized it was better served in a separate thread after I posted on this one. Sorry for the noise.
Hi,
I don't know if anyone is still asking but i bought one sft1200 to figure out what's inside.
You can in the constructor interface install lucy
Then it appear you can acces to a pretty fully openwrt.
I personnaly found all of my needed packages.
They seems to have their own repos, when i update the packages list i get these adresses:
https://fw.gl-inet.com/releases/v18.06.5/packages-3.6/siflower/packages/Packages.gz
https://fw.gl-inet.com/releases/v18.06.5/kmod-3.8/siflower/sf19a28_nand/Packages.gz
The constructor web interface seem to be just a porly functionnal wrapper for openwrt.
In my case (with using mwan3) tweaking with the gli interface broke conf and add interfaces without asking for.
In my opinion if you don't use the custom webui,
you're fine with the"propietary" packages,
fine too maybe never get uptates
It can be a pretty decent alternative to the gl-mt1300 for its price
I've been struggling with one of those to make it work as expected.
TL;DR
EDIT:
An update about this.
The GL-SFT1200 (Opal) product page still claims it runs OpenWrt, which as described before it's not really OpenWrt but "a fork" this vendor is handling internally. Maybe somebody from the developer team would want to discuss that misleading claim with them.
For other models, I've read that after several users got in contact with them, they agreed to develop that hybrid firmware support for that equipment, and in some cases they even have released the "clean" images, which looks more like the real OpenWrt.
Note: The clean firmware has only LuCI, no GL.iNet web Admin Panel.
For this SiFlower-based that's not the case, the only available firmware is the vendor's one, which its stable 3.215 version is apparently "Based on openwrt 19.07.8" system and "OpenWrt 19.07.10 CVE" security patches (which casing aside I think is more like the proper wording they should be using elsewhere).
I have been using devices from GL-Inet for many years and have had experience with a wide variety of devices from this company. (ar-150, ar-300, ar-750, sft1200-opal and others).
Basically, I was always very satisfied with their devices. I came across GL-Inet while looking for routers that can be operated with OpenWRT. Before I had made a few bad purchases, e.g. TP Link routers that were announced as revision XX and were then delivered as revision XY, which was not compatible with OpenWRT and could not be flashed.
In principle, it has been the case for years that the router call ends up in a self-built GL-INET interface. The front end comes from the GL-Inet repository and consists of a number of packages that can be de/installed with opgk. For a number of devices, e.g. the ar-750 series, pure OpenWRT versions can also be downloaded and installed from their website. They then have luci installed and you end up directly in OpenWRT when you call up the device.
Personally, I didn't think that their own interface was that bad at all. GL-INET concentrated on the really important things in router operation. And tried to make it as easy as possible for less ambitious users to put an OpenWRT-based router into operation.
They even have more complicated things like an OpenVPN server displayed in their interface. Simple OpenVPN connection scenarios can be mapped with a few mouse clicks. In the newer versions they have this built in for wireguard as well.
Completely sufficient for simple scenarios, but as soon as you need something else, e.g. a network network coupling, their solution cannot be used. They use completely non-transparent solutions for these things and generate, for example, firewall rules and binaries calls on the fly and completely ignore the way these things are solved in OpenWRT. That's why I've only ever used the luci interface and implemented things conform to OpenWRT.
The informations presented here in this thread were absolutely not clear to me and I believed until yesterday that these are devices that follow the ideas of the OpenWRT community.
But I was surprised that, after updating to the latest version of the software on my SFT1200 (which is a good, reliable router with a verg good price-performance ratio), OpenWrt 18.06 r0-d5ed025 is still shown as the base system, although GL-INET itself specifies OpenWRT 19 as the base in their release notes.
However, after reading this thread here, I now understand this and see that https://github.com/gl-inet/openwrt/tree/openwrt-18.06-siflower is just a branch of her own fork in which they integrated the siflower SDK. But probably not even manage to do that for OpenWRT 19.
This is of course an extreme disappointment. And unfortunately I fell for the grandiose statements on their website. Awkward!
greetz
Klaus
I had 2 of their products, MT300N v1 & MT1300, the first one only being used as travel router in old days so I wasn't too care about the GL-INET UI (stock UI). However when I got the MT1300 I really found that the stock UI and functionalities are having some issues. It allows me to install the luci UI when I need extra features, but what's the point there? I have to switch UI very often, and I couldn't change any WiFi setting from luci because it will mess up with original configuration. So when vanilla OpenWrt 22.03 is out (the 21.02 still somehow bad because I need to SSH to configure but at least usable) I find that finally I can make good use of it.
Will I continue to buy GL's products? It really depends on the chipset they picked, the SiFlower definitely won't be my choice, while their MT2500/MT3000 using Mediatek chipset I might go for it since it has higher chance to get vanilla OpenWrt on it.
That's why I never look into their products after the MT1300, I don't think there would be chance to get official OpenWrt support (I hope the upcoming MT2500/MT3000 does becaue they use Mediatek)
MT2500 and MT3000 will definitely get vanilla OpenWrt on them. I'm working on this. gl.inet has provided hardware and all necessary documentation (schematics, ...) to do this. Would of course be nicer if they'd even do that themselves, but that's too much to ask, I guess. It's quite different case from the SiFlower SoC where there isn't even any sourcecode for most drivers. For MT7981 everything relevant is available in sourcecode, just needed some work to go to upstream Linux and will land in OpenWrt very soon.
@daniel it seems that Siflower has a presence online, maybe someone can try a contact with them and ask for an access to the source code for their 2 CPU's. Just have to convince them that it would be an advantage for the company have their 2 CPU's supported by vanilla OpenWRT... 
https://www.siflower.com.cn/en/products/detail/7
The problem here is most likely that also SiFlower is not the owner and designer or most parts of this SoC: They probably licensed major parts of it from other companies, and that probably prohibits them from publishing driver sources... The best chance we have is to request sourcecode from the entity which is legally obliged to give it to, ie. the entity which sold the device to you, as only with them you have relationship in the sense of the law and GPL license.
@daniel it seems that they have a site (chinese) dedicated for developers, but I think it is all based on the SiFlower SDK (I do not have the skills to check this)...
https://developers.siflower.cn/
I also found a patch file for one of the SiFlower SoC's (for the older OpenWRT 15.05.1). I think I have seen there some drivers source code...
https://github.com/siflower-company/sf16a18-sdk-4.2.10/tree/master/chaos_calmer_15_05_1/target/linux/siflower/patches
This patch indeed contains sourcecode for some (but by far not all) drivers of another, very outdated, MIPS-based SiFlower SoC. The Wi-Fi parts and everything related to the Ethernet switch are missing, however. I also doubt that e.g. the Ethernet part of this old MIPS-based SoC (which is all a patch-work of different supposedly licensed IP blocks, the drivers have copyrights of ST-Micro, Samsung, Broadcom, Synopsys/DesignWare, ...) will even be similar at all to what they use in their more recent ARM-based SoCs, let alone all the missing parts...
@daniel the SiFlower SF16A1890 is still advertised on their website, so I think they still sell it, like they do with the newer SF19A2890. If we check the specs, the wireless speed and CPU clock is better on the newer... maybe they share some code... they probably would not develop everything from ground up again...
The two SoCs are very different, and in major parts not designed by SiFlower, but made of licensed IP blocks. The little parts they did themselves (pinctrl, clks, ...) could be reused, but even that would be surprising given the very different CPU cores (ARM vs. MIPS) they used.
You are over-estimating those Chinese manufacturers, most of them only with hardware + driver combinations able to support maybe 1-2 yrs update. I worked in consumer electronics industry quite a number of years ago, those Chinese manufacturers might introduce their chipset to have let say 10 special features, and you are interested to use 5 of them, then they started to work on a package with very ugly source or just a binary blob for your 5 requested features, a feature that no one asked for would never work, and the so-called 10 features only existed in their demo prototype.
This also explains why those Rockchip RK3399/3588 are so powerful (You can see NanoPi R4S/R6S) but we are so difficult to use 100% of their advertised features, the RK3399 has been released > 6yrs and their advertised video encoder functionality is still.....not usable (luckily most of other features were worked out). Their lower end RK3288 was having great support not because they did it well, it was because Google picked this chip to use in their Chromebook platform and Google helped them doing all developments as well as upstream to linux kernel source tree.
So you want them to share some code? Yes it might be possible but this will be mostly broken thing if no customers ever asked for it (no one pay for update version and why would they spend the effort? they would just move on to another newer product)