LEDE point of view on proprietary drivers

Please look in
package/kernel/mt76
and
kmod_mt76*
of current LEDE
for mt76x2(e) this uses already mac80211

mt76 is one of the drivers getting a lot of attention from the bufferbloat and make-wifi-fast projects, so if you have hardware that supports it, it should be a very good choice to use.

I understand I should use the MT76 driver(s) for both my MT7628A and MT7621A devices. (MT7612E for 5 Ghz n/ac). However we are still seeing a lot of bugs/kernel panics on these drivers, so at the moment it is not stable enough as "production" router.

I am following the driver (issues) on github and if I can help the project, I am more than willing to test the driver on my device(s).

I skimmed through some of the issues ..
There are only a few real errors.
You must compare this with the stock/vanilla driver from Realtek

If "only a few errors" generate kernel panics and reboots...

It seems that the 7602 is getting stable. The 7612 is not rebooting, still throws kernel errors/warnings. The 7603 is still unstable. Looks like some issues are there long time, so it seems to me that these "few errors" are not that easy to iron out.

Again: nothing against all of the people trying hard to make the MT76 work, but for myself (possible a lot of "normal" users) I prefer a stable proprietary driver over crashes. Hence the question, could we provide compiled (as in: without source due legal reasons), with a stable release. With stable release, to avoid kernel variations.

as someone who has been using Linux a long time (0.99 kernel), I've been burned
so many times by proprietary drivers that can't be updated to new kernel
versions, that I sure hope that LEDE doesn't fall into that trap.

I don't object to binary blobs that are firmware to be executed on the various
chips, but anything that prevents kernel updates always comes back to bite
you.

David Lang

1 Like

For my POV there is no stable version at all !
You have some point in time with a version you can call stable, because only bug fixes are added to userspace.But if you add code to the kernel you get a new minor version, thus you need a new proprietary driver binding to this kernel.
So no luck here.
Read on lwn, how Sony handles kernel development
https://lwn.net/Articles/647524/
they are ~1800 patches ahead, which is crazy.

Someone from a big AV company has said
The easiest way (and sometime to only) to update your phone, is to buy a new one.

In a sense I agree with the statement: to improve buy a new one. However: from a simple consumer point of view: I just bought a new one. A router in this case. This router happens to have a MT762x SOC. It might not be enterprise grade, but it has a dual core processor, 16MB flash, 512MB ddr2 RAM, gigabit Ethernet, dual band B/AC wifi, a USB port and a mini PCIe connector to add (as option) a WWAN Card (LTE maybe). As a consumer I want this new device more or less at the latest standard. Nothing bleeding edge, but a stable device that I might use and possibly update over the next few years.

Unboxing this device, the vendor put a 3.x kernel and proprietary drivers. Why, cause the latest will upset consumers. So if we can give consumers the choice by offering a kernel 4.4 / 9 device with the choice to use a proprietary driver or an open source version I think the user base will grow.

After all, it's this what we are doing with the Broadcom drivers? Include a binary-only version to have more devices run LEDE? Because the Open source version is still lacking features consumer expect to be standard in this time and age?

If the answer is: we want the (almost) latest kernel, latest version of any package, then I think we should define our target audience. Cause let's be honest. In that environment you don't really want all kinds of newbies bricking their devices.

But...that should be a different topic. I guess I got my answer. If I manage to get the drivers property ported to our current kernel, I will keep it in the "community build" area.

[quote="drbrains, post:17, topic:3820, full:true"]
This router happens to have a MT762x SOC. It might not be enterprise grade, but it has a dual core processor, 16MB flash, 512MB ddr2 RAM, gigabit Ethernet, dual band B/AC wifi, a USB port and a mini PCIe connector to add (as option) a WWAN Card (LTE maybe).

After all, it's this what we are doing with the Broadcom drivers?[/quote]
So you have a Mediatek SoC with a Broadcom Wifi card ??

This is whats confuses me in the first place.
Broadcom is known to be (very ?) bad in GPL code for their devices.

They are project like DD-WRT, I think, they have signed a NDA to get the sources from Broadcom and can create drivers with updated kernel.
But LEDE wont go this track, maybe some people have signed a NDA to work on a GPL driver.
Also Qualcoms ath10 driver is a result of some NDA assignment

I have 2 devices I'm playing with at the moment. One based on a MT7628A, with MT7603 on the SOC and a MT7612e for 5Ghz AC.
An other with a MT7621A. This has a separate MT7603 on the PCIe bus and the same MT7612e.

The comparison with Broadcom is purely for the proprietary part. The binary blob is included in LEDE, but not for and Mediatek/Ralink.

In another thread, someone is already advising against getting a Mediatek based router, because of unstable wifi. So unless we get the MT76 working properly, any OpenWRT, LEDE or similar will be atheros only. Which is why I'm trying to get the driver from the MTK SDK to work on a Kernel 4.4.

If this is from LEDE, this is normal.
LEDE builds all drivers for all devices, regardless if this usable on $platform

Again I don't think vendor drivers are best (for all ?)
If the driver is ready to ship, they do.

Sometimes vendors do rework their driver, but sometimes don't.
For my drivers I'm working on (some USB 802.11ac dongles)

Yes, I noticed on some Realtek based (non open source:wink:). And without cfg80211/nl80211 support ??

I'm reworking initially the MT76x2e driver and it should have cfg80211 support. Problem is, it's using kernel 3.8 references to the 80211 headers. And they used an older (more forgiving) version of GCC. Using gcc 6.3 and kernel 4.4.61 at the moment. (Snapshot is already at 4.4.69 I know). I got it finally to build/compile. It's still complaining about missing files at runtime, even I put those files where the driver expects them. Need to look at it a bit closer, the CC 15.05 version that was supplied by the vendor doesn't seem to need them. So I need to figure out to build for efuse, flash or eeprom.

Anway, I'll keep it a community build project, once it works. I'm referencing the sources from Padavan next to the MTK Openwrt SDK files. For some reason, Padavan still is using a version 3.x kernel.

Do you have an ETA when the first builds will arrive? :slight_smile: If there is any beta testing that needs to be done, I would like to volunteer.

I don't have and ETA yet. It seems I'm patching the patches to the point that I'm rewriting half the code. One has to ask at which time does it become "mine" and no longer some else's patched :wink:

As soon I as have good results on my own device, I will let you know.

3 Likes

How is the patching? I have a similar router ZBT WG3526 16MB. I am experiencing unstable WIFI on MT7603E with latest LEDE/OpenWRT snapshot, worse with LEDE stable release 17.01.4
Btw, where can I get LEDE firmware with patched proprietary driver, can you share with me? Any suggesting, how to get stable WIFI on ZBT WG3526, Thanks!

I did manage to patch the MTK sources. But the MT76 driver development continued in the meantime so I choose to use them instead.

Another user here published the compiled MTK binaries here: MT76 precompiled drivers (mediatek wifi is useless in MT7628)

Since he only shares the binary there is less problems with the closed nature of the drivers.

as long as you ignore the potential GPL violation of the kernel

Thanks! I am going to try that. Well I hope the development of open source MT76 driver will deliver good result. It is getting better, it can be usable if there is only few WIFI connection very close to the router with low traffic. Good luck, I will try the next stable release,

Is this true? LEDE documentation says that "LEDE / OpenWrt use only FOSS drivers. Fully open-source support for Broadcom wifi chips is very limited"

I’m sure. See: https://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm47xx

The Broadcom-wl part is proprietary with some wrapper. Even the open source drivers are not that good. DD-WRT has some deal with Broadcom and a NDA for their drivers. For this reason I recommend their fork for the Broadcom based routers. I had the Kong builds running on the Netgear R7000 and R6150. Together with Entware it comes very close to the OpenWRT solution.

1 Like