Nobody likes binary blobs. When those blobs come in the form of firmware
for peripheral devices, though, it is probably fair to say that most of us
are able to live with their existence. Yes, it would be nicer to have the
source and to be able to create modified firmware loads, but, as long as
the firmware itself is distributable, Linux users usually do not worry
about it. That is not true of all users, though, as can be seen from an
effort underway in the GTA04 project.
GTA04 bills itself as the
next-generation OpenMoko phone. The end product is intended to be a board
that can fit inside an existing OpenMoko handset case but which provides a
number of features the OpenMoko phone never had: 3G/HSPA connectivity, USB
2.0 on-the-go support, BlueTooth, an FM transceiver, various sensors
(barometer, gyroscope, ...), and the obligatory flashlight device. Also
provided will be a Debian port to make the whole thing work. The hardware
design is reasonably far along, with boards from an
early adopter program about to make their way to developers. There is,
though, one nagging problem that the project would still like to solve.
The GTA04 uses a Marvell 8686 "Libertas" chip for its WiFi connectivity;
that is the same chip used in the first generation OLPC XO laptop. That
chip requires a significant firmware blob to be loaded before it can
function. One of the earliest bugs filed at OLPC called for
the replacement of this blob with free software, but nobody stepped up and
got the job done. So, five years later, the GTA04 project, whose goal is
the creation of a 100% free handset, is stuck shipping that same firmware
Some projects would shrug their collective shoulders, treat the blob as
part of the hardware, and move on to the long list of other problems in
need of solution. Others might bite the bullet, get hardware documentation
from somewhere, and write a replacement blob. Yet others might decide that
Marvell's hardware is incompatible with their goals and find a different
WiFi chip for their board. GTA04, though, has done none of the above.
What the GTA04 developers would like to do is documented on this
The task is to develop a prototype of a microcontroller that sends
an immutable firmware program through an SDIO interface into a
Marvell 8686 based WLAN chip independently from the main CPU. The
goal is to isolate the non-free firmware binary from the main CPU
so that it becomes effectively circuitry.
The architecture we want to use this with is a TI OMAP3 with a
level shifter and a Wi2Wi W2CBW003 chip connected to it.
Our idea is to use a MSP430F5528IYFF controller that sits between
the OMAP3 and the level shifter so that either of the MCUs can
control the SDIO interface and right after reset, the firmware is
injected from the MSP430 into the Wi2Wi chip.
In other words, the project proposes to add another microcontroller to its
board for the sole purpose of shoving the firmware blob into the Marvell
WiFi controller. By so doing, they turn the blob into "effectively
circuitry" and, seemingly, no longer feel quite so dirty about it. The
Free Software Foundation agrees with
this goal, having apparently set it as a condition for their endorsement of
The current thinking is that by removing the ability for this
software to be upgraded, we can effectively treat the wireless
networking hardware as a circuit, and importantly, not a malicious
circuit that can be upgraded.
One might object that, if the firmware blob contains malicious code, that
code will still exist even if it does not pass through the CPU as data
first. The GTA04 is meant to be a free device; the operating software
will be under the user's control. So one would expect that the firmware
blob will not be spontaneously replaced by something nastier. If the
firmware blob were somehow able to maliciously "upgrade" itself
against the will of the Linux system running the phone, it would be able to
do any of a number of other unpleasant things regardless of which processor
loads it into the WiFi controller. Meanwhile, if Marvell comes out with a
new blob offering better performance or fixing bugs, users will no longer
have the option of installing it on their phones.
It is, in other words, hard to see the benefits that
are being bought through this exercise.
In fact, it would seem that the GTA04 project is wanting to saddle itself
with a more complex design, higher hardware costs, less flexibility in the
future and increased power
usage to create a system that runs the exact same binary blob on the same
controller. That's a high price to pay for the comfort that comes from
having swept the blob under the rug where it can't be seen. This whole
thing might be humorous if it weren't for the little fact that it would
really be nice to see this project succeed; more freedom in this area is
sorely needed. What they are trying to do is challenging enough without
the addition of artificial obstacles. It will be a sad day if the pursuit
of a truly free handset is impeded by an exercise in papering over an
inconvenient binary blob.
(Thanks to Paul Wise for the heads-up).
to post comments)