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.
_______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
