Building OpenWrt with proprietary drivers extracted from OEM firmware

According to @thedukesd, I might need to patch the drivers to work with the newer kernel version, if I brick something U-boot wouldn't work (correct me if I am wrong).

This has ath10k based wifi, which works pretty well, but does use a binary blob already. Doesn't seem worth the effort to try to extract any OEM drivers.

1 Like

@gaspare has the C6 router and he has tested the wireless capabilities:

So the binary blob isn't doing as good as the closed source driver blob :frowning:

If you use the initramfs version of the image, everything is in memory. Nothing is committed to flash. So you can test all you want, and not have a brick. Even with the sysupgrade version, the bootloader partition is read-only, so it is next to impossible to brick the bootloader. In my opinion, you would really need to put in extraordinary efforts to wipe out the U-boot bootloader, if all you are experimenting with are the WiFi drivers.

1 Like

That's not Ath10k - seems like mt76. The source you linked said v2, but seems from the other thread maybe you have a v3? Totally different router. Still not worth the effort for this driver.

2 Likes

Thats right.... C6 v3 is a Mediatek MT7621 .. C6 v2 is an Atheros.... I have a v3...
Support for v3 is still in early stages, but it works...

Original drivers are a little tricky to port to newer kernels (they were build for kernel 3.10) ... If you have the knowledge to port the driver, better help improving mt76 :slight_smile:

Oops, didn't realize the SoC was different for v3... and you are right, it looks like a totally different router. I have the v2 version with Qualcomm Atheros QCA9563... so maybe the wireless performance isn't bad with OpenWrt after all? I will have to test.

I would be interested in building OpenWRTwith the closed source drivers for Archer C7. Have you already tried this? I know that being closed source these drivers could not make into official OpenWRT builds, but I am having performance Wifi issues with Archer C7 (while stock firmware can go close to 600Mbps, OpenWRT barely reaches 400Mbps with the snapshot builds, let alone 19.07) and I would be willing to experiment an "alternative" OpenWRT build with closed source ATH10K drivers.

1 Like

Thanks for sharing the numbers, 400 Mbps doesn't sound bad for FOSS firmware. I might also be interested in trying the closed source drivers from atheros... if they can work with my Archer C6.

Notice that I am talking about effective Wi-fi performance only, no NAT involved. This is important to me because I have a local NAS server, and I am using OpenWRT as access point in three devices (2 Archer C7 and 1 DIR-859). I only achieved 400Mbps using a snapshot build and replacing the ath10k-ct with the standard ath10k drivers. 19.07.7 Wi-fi was limited around ~330Mbps (again, no NAT involved, only WLAN<->LAN traffic measured with IPERF3).

BTW, right now I am using a custom 21.02 "access point" build I made myself by removing dhcpd/dnsmasq, replacing the ath10k-ct by the standard ath10k drivers and replacing the standard kmod-ath10k-ct by kmod-ath10k-ct-smallbuffers (even being a "ct" kmod it works with the standard driver).

One interesting thing: using IPERF3 on an iPad, while I can get ~400Mbps downstream (802.11ac@80Mhz from the wired IPERF3 server), the rate goes up to a whooping ~550Mbps upstream (on par with the stock firmware). I don't know why there is such a difference on the iPad, with my laptop the IPERF3 downstream is more or less the same as the iPad (~400Mbps) and the upstream is only marginally better (~450Mbps).

I've ordered a new Wifi card for my laptop, I intend do to some more tests and eventually I will create a new thread with my results. I am intrigued with these results. Why ath10k drivers can receive data @550Mbps max but only transmit data @400Mbps max? I believe there is something else (which are not the drivers) which seems to be CPU-bound limiting the Wifi performance on devices with weaker CPUs (single-core @~750MHz).

2 Likes

@blinkstar88

I have closed source driver from Atheros, let me know if you need it.

I'd be very interested in this as well. I'm doing a lot of research and study on embedded driver development with the goal of being able to port firmware such as OpenWRT to other hardware that isn't officially supported by the OpenWRT team.

I'd be extremely grateful to have a copy of the Atheros source code that you possess.

1 Like

Were you able to attain the closed source code? I'm interested in obtaining a copy.

here the closed source code atheros driver

Hi @TheDcoder,
i don't know if you already read this thread.
I'm testing all version of those firmware, and i was searching how to build my own version to have better performances.
I have 3 archer c6 v2 eu version.
My best throughput has been of 220 mbit for 5 ghz...

pherhaps joining the effort with the other would lead to some great results.

1 Like

Maybe this is better?
https://source.codeaurora.org/quic/qsdk/oss/system/openwrt/feeds/qca-wifi-10.4.2/tree/net

UPD It seems that CodeAurora does not contain everything that is needed :frowning:

UPD #2 I found the source code a little fresher, but slightly: https://github.com/lvjiang/R21/blob/master/package/qca/qca-wifi/fwbin/wifi_fw_version.info

UPD #3 The most recent of the leaked ones that I found: https://github.com/eisaev/ipq807x-spf100-cs

Thanks for mentioning the thread, I should also try measuring the wireless throughput I get.

I know this reply is a tad late but thank you for providing this.

Much appreciated @eisaev

There is also something called sfe-offload which someone included in his images, but it's just a snapshot and I would love to bring it into stable releases.

My numbers were around 600 Mbit/s up and down with a 2x2 Smartphone iperf3 measurement with an Archer D7.

The name of the user is @gwlim. Unfortunately I don't get responses how to bring the sfe-offload to my devices.

Compared to software offloading I also just see 400 Mbit/s.

I hope we could manage something since more and more proprietary driver finally find their way into Linux-based systems.