proprietary firmware

[Alexandre Ghisoli]

Hi Wolfgang, 

Thanks for sharing this with the community.

Le vendredi 08 février 2008 à 09:32 +0800, Wolfgang Spraul a écrit :

> 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).

Madwifi [1] has the same issue with regulatory. Because countries
doesn't not allow same frequencies ranges and power output, manufacturer
are forced (by laws) to limit hardware possibilities in each countries
to pass regulatory tests.

In that way, they are very careful to whom they open the firmware
updates. Usually, the company that what to use their hardware should
sign a very strict contrat where they endorse most of the
responsibility.

Now, in OpenSource world, this is not possible to endorse that
responsibility and let the user change almost all the "locked"
parameters in such way that the device doesn't pass anymore regulatory
tests.

> 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.

This is probably the only way to get out of the current issues.

> 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.

I can understand the community and OpenMoko point of view here, but what
about functionality, speed and power consumption issue ?

If you take a look on the recent video acceleration issue with HTC
devices [2], there is a clear relation between performances and the
firmware (hardware ?) driver.

The same issue apply to the current GSM firmware.

OpenMoko devices will probably loose a lot of their functionality
because of moving everything in CPU area.

What are the possibilities ? I dont know, but forcing vendors to let
OpenMoko updates their phones are not a viable option, unless you can
let some trusted resellers around the world to make it for free.

Making a dual licensed phone ? One closed with everything in firmware
(so, easy to use, fast and low consumption, maybe re branded ?) and a
true OpenSource phone that will probably not compete (in term of speed
and power consumption) with the 1st one ?


[1] http://madwifi.org/
[2] http://htcclassaction.org/whattodo.php

-- 
        Alexandre