State of bluetooth & wifi drivers in linux-libre

[Denis 'GNUtoo' Carikli]

On Sun, 20 Oct 2024 02:28:22 +0000
Divya <divya at subvertising.org> wrote:
> What exactly includes non-free firmware? I linked the firmware for
> the chip that is licensed under GPLv2. I am aware that linux-libre is
> completely free software. But the chip in question has its firmware
> publicly available as free software. Unless I'm missing something,
> where is the non-free firmware?

Assuming upstream Linux has a driver for these, there is a way to get
this fixed relatively easily compared to other nonfree firmwares, and
have the firmware get included in FSDG distributions.

The job to do to make that happen is to take the firmware binary which
is in 8051 assembler and produce source code from that.

The good news is that the firmware is really small and that it's not
very hard to do compared to reverse engineering other WiFi firmwares.

The bad news is that last time I looked automated tools like retdec
didn't support this CPU architecture so it might require a bit of time.

But given the size it's probably coded in assembly directly, so maybe
that makes it easier, especially if you can at the end produce the same
binary (see below why).

So the first thing to do is to try to find a way to understand which
parts of the firmware is code and which part is not. Maybe writing code
to follow all instructions with radare2 or similar software could do
that somehow. We have the address at which code starts to execute
already.

Once this is done the next step could be to somehow get this source
code to build and get the same binary than the one you extracted from
the driver. This is important as it could make most distributions
accept the source code without having to do a lot of source code
reviews.

Also if I remember well there are several sections inside the firmware
binary as there are gaps that can seen with hexdump -C. Maybe some
zones are data or maybe there is a simplistic bootloader and then code.

After that, it could be a good idea to comment a bit the source
code and to use some meaningful names. The driver has some information
on the communication between the driver and the firmware.

So it might be possible to name the registers / memory address used to
do this communication and they are probably easy to find as the
constant used by the driver are also easily found inside the 8051 code,
but I've not been able to confirm that as I didn't try to modify the
firmware to do experiments with it. If I remember well there is some
comments or variable / functions names about a mailbox
communication interface in the driver somewhere.

See https://libreplanet.org/wiki/Group:Hardware/Components/WiFi/Realtek for
more details, especially this link:
https://libreplanet.org/wiki/Group:Hardware/research/e-readers/Kobo/Aura_H2O_Edition_2#WiFi_firmware

Also a difficulty here would be to understand where to stop, for
instance it's unclear if a partially commented source code would be OK
or not, but maybe other people can comment on that. If it's easy enough
to comment all the source code, doing that might avoid complex
discussions and save a lot of time.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20241113/d7be88d9/attachment.sig>