proprietary firmware

Tore Dalaker tore at dalaker.com
Fri Feb 8 09:10:15 CET 2008



Med vennlig hilsen / Kind regards
Tore Dalaker
Rosenkrantzvegen 19
N-4353 Klepp Stasjon
+4798024965

On Fri, 8 Feb 2008, Wolfgang Spraul wrote:

> Dear Community,
>
> Some of our chips or chipsets contain proprietary firmware in flash memory. 
> For example, in GTA02 these include the Wi-Fi, GPS, and GSM chipsets.
> Ideally, we would have liked to use chipsets for which even the firmware code 
> would be free, but they don't exist right now.
> So we accepted proprietary firmware, as long as it was in flash or ROM.
>
> Then we ran into problems when bugs were found in the firmware, and we wanted 
> to update handsets out in the field.
> The vendors would give us firmware updates and reflashing tools, but they 
> wouldn't let us redistribute those tools to our users. We asked for special 
> licenses to allow us to distribute those flashing tools to our users, and got 
> them in some cases, after months of licensing negotiations.
> 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. The tools do this because vendors are worried that 
> people would disassemble, patch, and reassemble the firmware, triggering 
> regulatory reclassification of their chipsets (software controlled radio).
> 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. One reason for this is that RAM needs less power and is cheaper. 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.
>
> This got quite frustrating, until we met Richard Stallman last weekend. And 
> he cleared it up for us rather quickly :-)
>
> 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. This way we completely avoid the issue of 
> distributing proprietary firmware updates and binary firmware updaters with 
> restrictive licensing that load only cryptographically signed firmware.
>
> We liked his advice. It speeds up our decision making and allows us to focus 
> on what we do best: Developing Free Software that is available in full source 
> code, running on the main CPU, that we and anyone else can modify and 
> optimize. 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.

Maybe you could do something like a  ssh in to the phone and update it 
remotely? This would be a lot easyer than returning devices both for users 
and openmoko..

> 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.
>
> We hope this helps clarify OpenMoko's current position on proprietary 
> firmware: Ignore them while they stay inside of a chip or chipset, and refuse 
> to touch them. Focus on what Free Software can do.
> Feedback and comments are always very welcome.
> Best Regards,
> Wolfgang
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>




More information about the community mailing list