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