mail at mmontour.net
Mon Feb 11 08:40:01 CET 2008
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
> 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
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
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
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
More information about the community