OpenWrt One / project update

Thu Apr 11 07:52:17 PDT 2024

> Bjørn Mork wrote: "And I consider immutable source-less compiled binary blobs the absolute worst kind of all binary blobs.
> They are impossible to debug and fix, and have exactly no theoretical chance of ever been replaced by an open source alternative, even in the wettest libre software dreams."

Why I consider BootROM - if present - as a lesser evil: said BootROM
is always much smaller and does much less stuff than the higher level
binary blobs, and also it is better having "just a BootROM" than
"BootROM + said binary blobs" (because of course you can't expect
"blobbed" WiFi chips to be better in this regard).

> Paul D wrote: "This seems part of a much larger debate: finding a company who would produce a spec compliant SoC which does or does not contain IP, and gives it away freely"

This is another approach, which may be better in the long term.
However, what I am suggesting (and have proposed a long time ago while
seeing the 1st "OpenWRT One" message) - is much more simple:

" Dear colleagues, so here is a list of 30 WiFi chips of X generation
and might be a good candidate for our new routers.
Let's take a quick look at each chip to determine its
"liberation-potential" and choose a chip which appears to be easier to
liberate.
Oh, there is a very detailed public datasheet available for Y chip,
and Z researcher has shared his analysis of its existant binary blob?
That's cool, let's choose Y chip for our new router - even if it is
slightly worse / slightly more expensive than a S chip without such
benefits."

> ... "Things like RPi and its analogues seem evidence that people want to hack and tinker."

To be honest the success of RPi is kinda undeserved, seeing RPi is
closely affiliated with Broadcom which is one of the most hostile
companies towards the opensource (on the same level as NVidia). Also,
it disappointed me so much that Pine64 chose Broadcom as a WiFi chip
for their Pinephone Pro, that I chose a regular Pinephone despite its
clearly worse performance (because there has been at least some
reverse work done for its Realtek chip - sadly it doesnt use AR9462
chip like Purism Librem phone)

> Daniel Golle wrote:

Thank you Daniel for a very detailed reply

> We are well aware of that and of course would appreciate any efforts
> towards a blob-less system. The advantage of the chosen MT7981+MT7976
> chip combination is that it is generally well-understood and people
> of our community have been working with the vendor (MediaTek) to write
> a high-quality WiFi driver for it. It this moment, this is definitely
> as good as it gets, the situation for all other modern WiFi chips is a
> lot worse. For this SoC we are going to have open source datasheets
> which cover most parts. We already got an Open Source implementation
> of the ARM TrustedFirmware-A as well as U-Boot (see DDR4-exception
> below, however).

This sounds quite inspiring. Do you think there is a possibility of
opensource source replacement for the existent Mediatek blobs, i.e.
are there any firmware signatures that might be blocking us from even
trying to develop them?

> You won't find *any* device using DDR3 or more recent and faster DRAM chips which do not need to run proprietary code to carry out the initial calibration of the DRAM controller

The things are better than may seem, here are a few examples of such
devices - DDR3 and DDR4 (don't know about DDR5 but hopefully it isn't
more locked-down in these regards) :
1) my coreboot-supported AMD hardware (without a PSP backdoor) - G505S
laptop, A88XM-E desktop and AM1I-A mini-desktop (+ KGPE-D16 server
which I don't have yet)
- has a 100% opensource AGESA library which covers a lot of low-level
things, including the completely blobless source code for multi-stage
training of DDR3 controller.
Together with my pen friend Mike Banon we have even debugged this code
and modded it i.e. to be able to use 1866MHz CL9 RAM on A88XM-E
without it downclocking to 1333 MHz
(were a few unsolved issues inside that AGESA library and when AMD
paused cooperation with coreboot community - we stopped getting any
updates which might have fixed them).
2) Talos II workstation by Raptor Engineering uses DDR4 memory and
does it bloblessly, as you could see by its RYF (respects your
freedom) certification by Free Software Foundation.

All this shows to me that the source code for DDR3 / DDR4 init does
not necessarily has to be blobbed, it may be just a desire of
particular chip vendors to put everything into a binary blob

> What we do have are blobs which are part of linux-firmware and published under a license which allows their free distribution, and those blobs are uploaded to the WiFi chip itself, and they typically contain bytecode which is run on the various built-in processors of those WiFi chips.

Thank you for clarification

> They key factors which would allow reverse engineering here are:
> - known architecture and available free toolchain
> - the small the blob the easier

> In case of the WiFi part of the MT7981 the total size of all blobs is
> around 2.4 MiB. They seem to bytecode for different microcontroller
> architectures, and this is a dual-band Wi-Fi 6 solution.
> The blobs of a comperable Qualcomm/Atheros Wi-Fi 6 solution are about
> 3.7 MiB, that's more than 1.5x the size.

Is it possible to somehow cut out the bytecode for unused
architectures (i.e. for the different chips other than used by this
router), in order to further reduce the size? 2.4 MB seems a bit large
to be reverseable (at least for a single person), but if its something
like 256 KB in reality then might be doable

> Imho much more important is the (publicly documented) interface to
> the firmware once running: In case of MediaTek the functionality
> covered by the firmware is quite minimal, while for literally all
> other vendors the firmware is excessive and takes care of practically
> all aspects of running an access point.

Thank you, if this is true then I apologize for doubting the wisdom of
OpenWRT developers in choosing the platform for OpenWrt One. I just
remembered the old stories of Mediatek GPL abuse and various blob
issues, but hopefully the things are better nowadays and these
Mediatek chips indeed have the potential of running on 100%
opensource. If I were getting a OpenWrt One router, I could have
donated like 2x of its price towards the goal of its software
liberation (if there would be any crowdfunding). Also, being able to
run on 100% opensource will surely attract a lot of FSF-minded buyers

On Thu, Apr 11, 2024 at 1:20 PM Daniel Golle <daniel at makrotopia.org> wrote:
>
> Hi Ivan,
>
> On Thu, Apr 11, 2024 at 10:15:58AM +0000, Ivan Ivanov wrote:
> > > there are no Wifi-5+ chips on the market that can run without blobs
> >
> > This is true, but at the same time - undoubtedly - some chips are more
> > likely to be liberated from blobs than the others. Some WiFi chip may
> > have been partially researched (i.e. someone tried to reverse-engineer
> > its binary blob) or at least a detailed-enough public PDF datasheet is
> > available so that its clear how the hardware operates, while some
> > other WiFi chip may lack these advantages and even use a firmware
> > signature that prevents the binary blob replacement by the opensource
> > alternative.
> >
> > What I am afraid of, and what forces me to write e-mails like this
> > once-in-a-while - is a POSSIBILITY that OpenWrt One project has not
> > taken this "liberation-potential" into consideration while choosing a
> > chip for a new router - and as result, it may turn out after that
> > OpenWrt One project becomes popular and the people would like it to
> > become blobless (i.e. by some crowdfunding initiative), but then find
> > out it impossible to liberate because of some technical limitation
> > like that firmware signature.
>
> We are well aware of that and of course would appreciate any efforts
> towards a blob-less system. The advantage of the chosen MT7981+MT7976
> chip combination is that it is generally well-understood and people
> of our community have been working with the vendor (MediaTek) to write
> a high-quality WiFi driver for it. It this moment, this is definitely
> as good as it gets, the situation for all other modern WiFi chips is a
> lot worse. For this SoC we are going to have open source datasheets
> which cover most parts. We already got an Open Source implementation
> of the ARM TrustedFirmware-A as well as U-Boot (see DDR4-exception
> below, however).
>
> >
> > > Could you please list the wifi chips you know of which ether have
> > > a) completely open source firmware, or
> > > b) no firmware at all (neither loaded in ram, nor in internal flash)?
> >
> > The best WiFi hardware capable of working on 100% opensource, I am
> > aware of and using at the moment, is based on the chips of Atheros
> > ath9k / ath9k_htc families:
> > 1) Netgear WNDR3800 router, SoC : Atheros AR7161 rev 2, yes it is
> > 802.11n but it supports 5 GHz, and my ISP is slower than 300 Mbps in
> > any case
> > (bought it locally but you may visit this page for a more complete
> > description - shop [dot] vikings [dot]
> > net/product/wndr3800-wlan-router/ )
> > This router runs on LibreCMC (fork of OpenWRT to designate the routers
> > which could work on 100% opensource) and its U-Boot is blobless too
> > AFAIK
>
> And here comes the next serious limitation:
> You won't find *any* device using DDR3 or more recent and faster DRAM
> chips which do not need to run proprietary code to carry out the
> initial calibration of the DRAM controller. The DRAM consortium
> enforce this with their patents and licensing strategies down to the
> SoC companies. Literally *all* of them ever since DDR3 require such
> blobs which have increased size with every generation of DRAM.
>
> In case of MediaTek those blobs are neither obfuscated nor not signed,
> they are merely compiled objects with a symbol table (which is probably
> the most relaxed interpretation of those DRAM consortium rules, but
> who knows, even the rules themselves are not public).
>
> > 2) AR9462 MiniPCIe WiFi module, also 802.11n with 5 GHz support, for
> > G505S laptop with a coreboot opensource BIOS
> > (btw this G505S is the most powerful coreboot-supported laptop without
> > Intel ME/AMD PSP backdoors, has a quadcore AMD and up to 16/32GB RAM)
>
> AR9462 can't be bought new any more at this point in time.
> I remember that TP-LINK had licenced some older QCA silicon and was
> still building batches of it for a while, but even this is now more
> than 5 years ago and I believe they have stopped doing that.
>
> > 3)  There are also ath9k-based USB adapters which work on 100%
> > opensource, but those with 5 GHz support are rare (haven't been able
> > to find in the wild)
>
> Also those you can't order or buy new anywhere at this point.
>
> >
> > However, of course it does not mean that there is nothing newer than
> > this "ath9k" that could theoretically work on 100% opensource without
> > any blobs in userspace.
>
> Sorry, but none of those blobs run in userspace. Userspace is 100%
> built from Free Open Source Software for practically all
> OpenWrt-supported devices.
>
> What we do have are blobs which are part of linux-firmware and published
> under a license which allows their free distribution, and those blobs
> are uploaded to the WiFi chip itself, and they typically contain bytecode
> which is run on the various built-in processors of those WiFi chips.
>
> As you correctly stated, there isn't any post-WiFi-4 chip which does not
> require such firmware blobs.
>
>
> > A couple of years ago I've seen someone trying to reverse-engineer a
> > newer chip's blob (think it was 802.11ac ), but a Google does not want
> > me to find this page atm :P
>
> They key factors which would allow reverse engineering here are:
>  - known architecture and available free toolchain
>  - the small the blob the easier
>
> In case of the WiFi part of the MT7981 the total size of all blobs is
> around 2.4 MiB. They seem to bytecode for different microcontroller
> architectures, and this is a dual-band Wi-Fi 6 solution.
>
> The blobs of a comperable Qualcomm/Atheros Wi-Fi 6 solution are about
> 3.7 MiB, that's more than 1.5x the size.
>
> Imho much more important is the (publicly documented) interface to
> the firmware once running: In case of MediaTek the functionality
> covered by the firmware is quite minimal, while for literally all
> other vendors the firmware is excessive and takes care of practically
> all aspects of running an access point.
>
> While it may not be completely up-to-date any more, I still recommend
> to watch this talk given by Felix Fietkau in 2015:
>
> https://www.youtube.com/watch?v=hiUosbhR0Wo
>
>
> >
> > > And don't forget about the "bootROM", stored in silicon
> >
> > BootROM is considered by Free Software Foundation as a part of
> > hardware, + it is not as bad as those bloated&buggy binary blobs
> > running at your OpenWRT space
>
> There aren't any blobs running on the CPU inside OpenWrt, neither
> in kernel nor in userland. This is a misunderstanding.
>
>
> >
> > On Thu, Apr 11, 2024 at 9:51 AM Piotr Dymacz <pepe2k at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On 11.04.2024 10:52, Bjørn Mork wrote:
> > > > Ivan Ivanov <qmastery16 at gmail.com> writes:
> > > >
> > > >>> SOC: MediaTek MT7981B , Wi-Fi: MediaTek MT7976C
> > > >>
> > > >> Are these Mediateks capable of working without any binary blobs, at
> > > >> least in theory?
> > > >
> > > > A simple question back to you: Could you please list the wifi chips you
> > > > know of which ether have
> > > > a) completely open source firmware, or
> > > > b) no firmware at all (neither loaded in ram, nor in internal flash)?
> > >
> > > [...]
> > >
> > > And don't forget about the "bootROM", stored in silicon, taking care of
> > > (among other things) booting the SoC from different media.
> > >
> > > --
> > > Cheers,
> > > Piotr
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel