[Teknoman117]

For something considered modern, pretty much next to impossible.

All of the modern CPUs require blobs to function, whether it's microcode, embedded firmware, binary driver blobs, or otherwise.

I don't believe there is a wireless card (wifi, Bluetooth, etc.) on the market that doesn't use binary, closed source firmware. In fact, it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.

Heck, even the SDR community is having to be really careful about not drawing the ire of the FCC. That's why so few of them tend to advertise transmit capabilities.

The main ARM cores have been generally blob-less, but that's only the cores. Various SOCs require blobs to initialize. Their GPUs are all proprietary blobs up and down the stack.

So you basically would have to make your own GPU, your own radios, etc. and integrate them into your own SOC - and get the regulatory bodies to certify them for sale in their various countries. You then have to fight the entrenched companies in court over IP for years. The GPU portion will be especially tricky. The moment you try, lawyers from Nvidia, AMD, Imagination Technologies, Apple, etc. will be all over you. The radios will have Qualcomm, Broadcom, and Intel all over you.

So technical, legal, and regulatory hurdles - which is why I say next to impossible, especially on the FSF's budget.

- a jaded hobbyist

[pabs3]

There are some old WiFi devices with libre firmware, but they only support old WiFi standards.

https://github.com/qca/open-ath9k-htc-firmware https://github.com/chunkeey/carl9170fw http://netweb.ing.unibs.it/~openfwwf/

Some also call into the initial version of their code that is in the ROM, and don't have enough RAM to update all of the ROM to the current code. Things like the Osmocom Baseband code also do this.

https://www.osmocom.org/projects/baseband/

[serendipitous]

> That's why so few of them tend to advertise transmit capabilities.

Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.

[oshiar53-0]

> it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.

1. You can use signed firmwares to make it both compliant and upgradable.

2. You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part. Alternatively, you can implement the restriction at the hardware level if feasible (effectively making it fixed function).

3. Finally, you can sell the parts individually to serve a separate market segment.

[mlyle]

> You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part.

Unfortunately this isn't quite enough for compliance, because of stuff like DFS channels/radar detection.

> Alternatively, you can implement the restriction at the hardware level if feasible

Not super feasible, and --- inability to update/fix bugs isn't a feature.

[Teknoman117]

> You can use signed firmwares to make it both compliant and upgradable.

The FSF would not be okay with this though, as it would be a GPLv3 violation to prevent users from replacing the firmware with a modified version.