Does openwrt support Qualcomm IPQ8072/IPQ8074's driver?
At this moment, no.
Kernel 4.14 (released november 2017), which is currently the newest version supported by OpenWrt, only contains basic clock and pinctrl support for ipq8074, but lacks most of the essential peripherials (IP cores), which have only been merged mainline around the middle of this year (up to May). Furthermore it's unclear if those drivers are sufficient to run the SOC without additional external patches at this moment (kernel 4.19, which -as an LTS kernel- will become the next kernel version adopted by OpenWrt). Regarding the wireless side of it, there doesn't seem to be any activity regarding the necessary drivers or firmware blobs.
Both, well at the very least the former (basic SOC support, to the extent of booting the device from its main storage and wired networking support), are the bare minimum for OpenWrt support - ideally without non-mainline patches. If that won't be fully available in the mainline kernel (which is relatively likely), someone needs to provide the necessary patches for OpenWrt (pull requests). Given that actual devices aren't even readily available on the free market so far, existing OpenWrt developers likely won't even have access to the corresponding hardware at this moment.
Depending on how the general availability (and pricing) of the actual hardware, the required SOC support and wireless drivers unfolds, I wouldn't expect OpenWrt support for this platform within the next ~year (pure speculative guesswork), unless an interested party goes the extra mile and helps a lot with its porting (collecting patches, providing pull requests) and maintenance. In the end it all depends on enough motivated (wo)manpower working on it (and you might be part of it), with access to the necessary hardware, code and data sheets concentrating their efforts and contributing the necessary changes.
As usual in opensource, that might happen "quickly", take a long time - or it might never happen at all; there are no schedules.
2 Likes
By the way, if that sounds overly pessimistic - it's not meant to be, every other target has been there in the past, just that the enduser tends not to see the blood, sweat and tears that went into it, once their device is supported.
SOC vendors can help there tremenduosly, ideally by pushing as much of the required drivers into the mainline kernel as possible - but also more direct patch submissions for OpenWrt are usually welcome.
1 Like
There has been work on the wireless side in ath10k but still not merged
Hi shl,
Thank you. I do understand what you mean.
In that regard, mvebu (Marvell) does have "better" (more mature) and mainline support.
What you mean about that ath10k is still not merged?
Do you mean that latest ath10k driver not merged into the linux kernel so far?
If it is, is there a scheduled plan to merge it based on what you have known?
Btw, do you know if the present wireless function in ath10k could support both of IPQ8072 & IPQ8074 and if it could support 802.11ax standard draft 1.0, draft 2.0 or draft 3.0 version?
I mean no code to support IPQ807X or any other QCA ax WiSoC has not been merged into ath10k driver.
There has been some talk but so far no code, I dont think that they are even mass shipping IPQ807X
1 Like
It's clear now, thanks.
Could you please give some more information about Marvell's dot11ax wifi chips and Marvell's technical support?
No 11ax support at all atm as far as "open source"/mainline goes, that includes any 11ax chipset to my knowledge
1 Like
OK... it's a bit disappointed.. Anyway, thank you.
You're just (quite) a bit too early, considering that devices haven't even reached the market yet.
Yes, it's a bit too early.
Hi @diizzy
I remember you said "In that regard, mvebu (Marvell) does have "better" (more mature) and mainline support." few days ago, so what does it mean? Is that Marvell supports more better about WIFI than Qualcomm or Broadcom in the opensource community?
This really depends on how you look at it...
What diizzy probably refers to is how close to mainline SOC support is handled by both companies, in other words how many custom patches (and how invasive they are) are needed to support the device in question - the answer to this question would be:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ipq806x/patches-4.14;hb=HEAD
vs
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/mvebu/patches-4.14;hb=HEAD
However you do have to keep in mind that this only covers support for the currently existing (802.11ac) SOCs (ipq806x vs armada 385), as there is no support at all for either Marvell's, nor QCA's upcoming 802.11ax based chipsets at the moment. In other words, at this moment this only allows an educated guess based on past behaviour to estimate how this might play out for future SOCs - but things like this can change quickly.
Another topic diizzy probably refers to is the performance tweaking of the wired ethernet support in regards to its mainline status, here Marvell wins hands down. Mvebu Armada 385 based SOCs can do routing at 1 GBit/s linespeed and beyond in OpenWrt today, while QCA ipq8065 tops out around 350-400 MBit/s - to get more than that would require using non-mainline offloading patches to enable and use the SOC's internal NSS/ NPU cores, source for this is available, but if this can be sorted for OpenWrt is an open question (but not impossible).
For the wlan side of things the situation is kind of reversed, but not clear cut either. In terms of mainline support, only QCA has made it into the mainline kernel with ath10k - Marvell tried to push mwlwifi a while ago, but quickly lost steam when their first approaches weren't in a mergeable state straight away (the driver is maintained out-of-tree at the moment). In terms of driver maturity, ath10k probably still has the upper hand over mwlwifi, both have their own kind of quirks, but both should be good enough for most users; in general the newer revisions (QCA9984 or 88W8964) seem to be better than their predecessors. Regarding the opensource point of view, both drivers are a very similar; FOSS/ GPL2 compatible kernel modules - but all the juicy bits are hidden away in redistributable, but closed source and non-free, firmware blobs that do most of the connection handling (and are unfixable by third parties). I don't think either party would be a clear winner in terms of responding to bug reports either, although ath10k-ct is a bit more approachable via Candelatech.
But again, all of the above is based exclusively on past- and current support for the existing 802.11ac SOCs (ipq8065 vs armada 385), you can only make an educated guess on how this might play out for upcoming 802.11ax based SOCs. And no, there are no predictions possible whatsoever who will win getting functional SOC and device support into OpenWrt first (or at all!) for these upcoming chipsets at this moment.
The only thing that's easier to predict, based on historical and contemporary evidence, would be that Broadcom probably won't be a contender for OpenWrt, even if they might have won the race to market. (And no, this might not be totally fair either, as SOC and ethernet support for Broadcom usually is quite good, in mainline, but wlan is a big question - if their 802.11ax wlan chipsets are softmac based there'd be virtually no hope for getting them supported - if they're fullmac based, this might get covered by brcmfmac one day).
1 Like
Thank slh you, briefly and to the point!
What can you say about Marvell Armada 385 88F6820 @1.8GHz vs Intel Celeron 1007U @1.50GHz?
Thanks in advance.
This is a much more difficult question, considering CPU architectures differ massively and the vastly different feature sets (number of ethernet ports, onboard managed switch, onboard wlan cards). The clock rate itself isn't really a useful metric for declaring how fast a CPU is in terms of instructions per cycle, unless you are comparing CPUs from the same family and generation (and all bets are off comparing different architectures).
The mvebu platform is very much optimized for fast networking throughput, but the cortex A9 derived CPU (taking the Linksys WRT3200ACM as an example) isn't quite as fast (for CPU intensive tasks) as the KRAIT300 (roughly cortex A15 equivalent) ipq8065 QCA SOCs; modern (non-Atom) x86_64 chipsets will still beat either - depending on the use case(!). These mvebu devices also have hardware cryptoengines, which aren't enabled by default and might not be particularly faster than doing it in software either, but they can offload the encryption processing from the main CPU - on the other hand mvebu is a little entropy starved (mwlwifi doesn't use the wlan cards for entropy).
In general, the Intel Celeron 1007U is ivy-bridge based (and not Atom based), so should be quite performant (I do own an ivy-bridge based pentium G2030 myself, which clocks at 3 GHz) - I would expect it to cope with 1 GBit/s routing throughput, so being on par with most mvebu devices (those limited to 1 GBit/s ports) for the simple tasks of NAT+routing. When it comes to additional services, the Celeron 1007U (no AES-NI hardware acceleration, but I would still expect it to compete well doing AES128 compared to the 88F6820) probably wins as well, but this would deserve dedicated testing. Obviously the 1007u will have an advantage in regards to its RAM size (allowing more concurrent services, beyond "routing tasks"), including hardware virtualization support (VT-x) or SATA (number of ports and performance). A bit of a question might be the mainboard chipset in terms of its number of PCIe lanes. When it comes to wlan support or number of ethernet ports, pretty much all dedicated routers win easily - this is a weak point for x86, especially small form factor x86 (it's very hard to find smaller-than-µATX boards with the option for at least two 1 GBit/s ethernet ports and two (mini-)PCIe sockets for wlan cards), unless you use an external managed switch and an external AP for the wlan.
For most home setups (especially those with less than 1 GBit/s WAN throughput) using a dedicated router platform like mvebu might still be "good enough" - and much more convenient in terms of its wlan and switch capabilities. For more professional environments (offices with a dozen of users, multiple concurrent VPN sessions, etc.) this might shift towards x86_64 quickly. But this really depends a lot on the use case and the environment (e.g., if you need multiple APs and already own a managed switch anyways, a wired-only router like x86 isn't a disadvantage anymore).
Unfortunately there simply are no easy answer.
1 Like
There is QOTOM-Q510G6 with AES-NI, 6 * 1 GBit/s LANs Intel I211-AT = $206 with 4G RAM & 16G SSD
I followed Linksys WRT3200ACM on ebay tonight, and 2 pieces sold for $116. New, respectively, more expensive.
In short the x86 platform will be faster (by quite a bit) however if the software you're is optimized there may not be much of a difference or at least to a point when it doesn't better. If you want x86-ish performance in general need you to look at the quad 64-bit ARM SoCs.
1 Like