proprietary firmware

Lally Singh lally.singh at
Sat Feb 9 17:23:59 CET 2008

On Feb 8, 2008 3:51 PM, enaut <enaut.w at> wrote:
>  Christopher Earl schrieb:
>  I think he had the right intentions about this idea, however it would
> require vast CPU resources or a coprocessor dedicated to firware/driver
> layer managment. This is unlikley to happen, However trying to unlock the
> virtual lips of companies would be a huge step forward. Not to play devils
> advocate but if the firmware was loaded into RAM at boot a simple RAM dump
> would allow reverse engineering of the data, and thus the device,So im OK
> with that.
>  Andy Powell <andy at> 02/08/08 10:08 AM >>>
>  On Friday 08 February 2008 08:46, Lally Singh wrote:
>  On Feb 7, 2008 8:32 PM, Wolfgang Spraul <wolfgang at> wrote:
>  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.
>  While I see the benefits here, it seems that we're sacrificing CPU
> time, power usage, and lowered utilization of other devices on the
> phone to get over a license issue -- a technical resolution to a legal
> problem.
>  I have to agree here. This is a low powered (CPU) device that contains
> chips
> designed to perform specific tasks. Why on earth would anyone think that
> making the cpu handle those tasks be a good idea?
> Apple can manage to allow their users to update the baseband on the iPhone
> so
> why can't FIC on the neo?
> Seriously, I want a phone that works properly more than I want one that dies
> during a call because the cpu is maxed out doing stuff that the chips in the
> same device should be doing..
> Rome wasn't built in a day and you're not going to change manufacturers
> overnight either. In the meantime we have to be flexible. Mr Stallman
> appears
> to live in a land where every device has infinite resources - some would say
> it's called 'LaLa'
> Andy
>  I like the idea of having total control over my electronic devices -
> especially if they are able to collect everything about my life like a
> mobile phone. Thats why I'm currently living without any mobil.
>  If I am able to look into what runs on my device, I can trust that stuff.
> so I'm one of those guys saying doing everything open source is way better
> than gaining a little cpu-speed. and by the way I don't think that the
> cpu-speed is too limited on that device. usually cpus don't have to do
> anything. and a driver doesnt need too much. This smal gap could be closed
> esysly by optimizing things for the hardware.
>  regards enaut

'a little cpu-speed' is an assumption.  The more open these chips are,
the more software's running on the CPU, the more CPU speed they'll

400MHz is really, *really* easy to use up.  Considering how much stuff
the other ICs do by themselves, we can heavily load the CPU pretty
easily.  Also, we can lose phone reliability, as the scheduling of
periodic tasks could be delayed by other things (do we even have a
hard real-time scheduler here?).  IMHO it's a giant waste of CPU &
battery power -- the other chips will still be running, but now we're
using the CPU more.

For what?  I don't think the GSM chip does anything terribly
interesting.  Wifi's not much better, and the GPS is probably the
simplest.  I'm sure others want to find that out themselves through
their own hacking.  But I don't want to fill up my CPU with garbage
the other dedicated chips should be doing.  If openmoko decides to go
through with this firmware opening, please give us a way to use the
regular firmware, too.

I have plans for that CPU.

H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

More information about the community mailing list