proprietary firmware

[Mike Montour]

Wolfgang Spraul wrote:

> Next we discovered that those reflashing tools had further issues: for 
> example, they would only allow loading cryptographically signed firmware 
> into the chipset flash memory.

I don't see why the cryptographic-signing requirement is a problem. Sure 
it would be nice if every peripheral was fully open-source and hackable, 
but that's just not realistic. If you're loading a proprietary blob 
anyway, who cares whether or not it has cryptographic authentication?

> Furthermore, we see that for upcoming chipsets, vendors are switching 
> from storing the firmware in flash memory to loading the firmware into 
> RAM at run time.

IMHO that's a good thing as long as they allow reasonable redistribution 
of those firmware blobs (i.e. so that OM can include them in rootfs 
images).

>  In this case the firmware, whether original or updated, has to 
> be loaded each time the device boots, requiring that the binary-only, 
> restrictively licensed firmware updater be included in the OpenMoko 
> distribution.

If the device is designed to load its firmware on every boot, then 
there's no reason that it should require a binary-only tool. It should 
just be part of that driver's API.

I have a MythTV box with a Hauppauge PVR-350 MPEG encoder/decoder card. 
It has proprietary firmware that's loaded on boot, but no proprietary 
tools are required. I just have to put the binary blobs into 
/lib/firmware/ and Linux does the rest. See the "ivtv-firmware.c" file 
in the kernel for details of how it's done.

> He suggested we treat any chipset with proprietary firmware as a 
> black-box, a circuit. He suggested we ignore the firmware inside. If the 
> firmware is buggy and the vendor needs the ability to update the 
> firmware, we instead ask the vendor to reduce the firmware to the bare 
> minimum, so that it can be very simple and bug free, and move the rest 
> of the logic into the GPL'ed driver running on the main CPU.

Did he have any real-world examples of vendors who have been willing to 
implement such a request? It seems like it would be a large change on 
the vendor's side and would require a lot of additional development and 
QA resources. It might even require the hardware itself to be designed 
specifically for that that usage model, e.g. the Hammerhead GPS used in 
GTA01.

Also, as others have commented, the main CPU is a finite resource. It's 
not surprising that this is not a concern for the GNU project (their 
flagship text editor was known as "Eight Megs And Constantly Swapping" 
back in the days when that was a lot of memory) but it is a concern for 
users/developers like me.

> There are downsides: We will no longer offer 
> reflashing tools to update proprietary firmware, under any license. For 
> critical firmware bugs, we will accept returns, or in some cases fix the 
> bug in-house.

I purchased one of the original GTA01s with a "-Moko1" GSM firmware. At 
some point I want to have this updated to a more recent and less buggy 
version, but I am not willing to mail the phone back to another country 
to get it re-flashed (unless OM will cover the shipping + customs costs 
both ways). I might be willing to take the phone in to a local 
authorized service center, but I would prefer to do the update myself 
(even if it required a proprietary tool).

> We will push vendors to simplify the functionality of their proprietary 
> firmware, so we can implement more of this on the main CPU as Free 
> Software. Maybe some vendors will even open up firmware for Free 
> Software development, that would be the ideal outcome we are working 
> towards.

I think that's OK to push as a long-term vision, but in the short term I 
think that the best approach is cryptographically-signed blobs that the 
GPL driver loads into RAM through a set of API functions. That gives us 
the ease of updates (just copy new blobs into the firmware directory) 
and gives the vendors regulatory compliance (since only signed blobs 
will be accepted). It also encourages the model of having a GPL'd Linux 
driver talk to their device through a documented API, and may help to 
convince them to move more of the functionality onto the "GPL" side in 
the future.