proprietary firmware

Steven Kurylo sk at
Fri Feb 8 22:16:32 CET 2008

Great stuff, this is why I'll by a neo and tell everyone I know the
same. Free the phone!

On 2/7/08, Wolfgang Spraul <wolfgang at> 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.
> 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

Steven Kurylo

More information about the community mailing list