proprietary firmware

Jeremiah Flerchinger jeremiah.flerchinger at gmail.com
Sat Feb 9 22:11:20 CET 2008


I see the concern of using up all the CPU time and wasting power.  It 
would be great if we could have binary patches as downloads with 
software & an architecture that could update all the firmware. 

It would be even better if we had enough information about the chips in 
concern that we could upload our own software into the flash memory or 
RAM of different chips to run our own firmware.

Software drivers on the main processor could be used in either case to 
test & apply temporary patches or provide specialty extensions.  More 
information about hardware & an API to access the hardware would be 
needed either way.

My opinion is a (binary/encrypted) software mechanism should be provided 
to update firmware with binary/encrypted data from the vendor, but try 
to get APIs with the firmware to get access to lower level functionality 
and provide the option of doing as much or as little on chip as 
desired.  Individuals could flesh out modules in software & they could 
eventually create fully open & functional drivers & firmware.  Users 
could be given a default configuration and allowed to choose an 
alternate configuration or additional software modules/patches.

Maybe, in the future, hardware manufacturers would agree to set aside or 
disclose some address locations/registers on the hardware that point to 
certain functions & allow values to be written there that point to 
custom routines.  Maybe they could even allocate some address space in 
the hardware for custom routines to be loaded in addition to a method of 
interacting with the CPU & main memory (possibly with these chips 
executing code on main RAM as instructed by CPU).

On another note, access to low level GPS functions could be fairly 
interesting.  Imagine gathering data from a local weather station and 
using it to better calculate atmospheric effects and improve accuracy.

> 'a little cpu-speed' is an assumption.  The more the more software's running on the CPU, the more CPU speed they'll take.
>
> 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.
>   




More information about the community mailing list