cpu-speed limitations

[Joachim Steiger]

Rod Whitby wrote:
> Hmm - there's a current issue regarding the GTA01 GPS gllin driver and 
> kernel /sys filesystem paths, so the response of Openmoko to that 
> "previous generation" issue is probably a good indicator of the sort of 
> attention that GTA02 Glamo will get once GTA03 is released.

we don't have all the sources to gllin.
also patching the binary is forbidden by the eula we got the binary
under. to be fair, we were happy to have a redistribution-allowance at
all after all that hassle there.

and guess what we learned... binary code which you can't compile
yourself fresh when you need it is unusable, undebuggable,
unmaintainable and thus a real pain in the ass and something which does
for sure not help solving problems, but make new ones.

the facts are that we do not have the complete source of gllin, and no
working eabi binary. thats the whole reason why we have that ugly
eabi-oabi wrapper. its not nice, but its better than nothing at all.

about symlinks.. i couldn't completely follow you... if you think its
something we could change without tampering with the binary of gllin
itself by hex-editor: please file it as a 'enhancement'-ticket.

> I'm hoping that the response is a positive one from Openmoko.

you decide. we try our best, even when we sometimes only learn something
and do not win what we wished for.

in this case this was a lesson teaching: 'keep you app cpu completely
binary-only-parts free or perish'

> Publishing the schematics will be a great first step, but there is still 
> the "previous generation" support for the proprietary NDA stuff that 
> needs to be factored into Openmoko's staffing plans (since the community 
> can't do it).

depends.. you can ask direct questions. ;) means if you want to know
something which you cannot see from exiting code and you know its there:
ask. we can still read the docs and explain out interpretation in a few
lines of chat ;)

usually in all drivers one writes he usually starts by copying the
register mapping from the datasheet and adding comments. thats often a
much better documentation than a pdf which says different things,
depending into which chapter one peeks ;)
drivers which don't crash tend to be closer to real hw than pdfs.

i think there are already enough things one could do with the available
informations.. e.g. complete some nice setup for hw-accelerated mp4
video playback on the glamo (i could imagine a nice gstreamer plugin
instead of a badly hacked up mplayer there)

see
http://unadventure.wordpress.com/2008/06/08/accelerating-in-my-pocket/
for that.

also i remember some locking issues between kerneldriver and xglamo
which could need a helping hand.. i think dodji, andy or holger would be
the guys to ask whats the details there.
afaik thats one of the locks up sometimes reasons.

happy hacking.


kind regards


-- 

Joachim Steiger
Openmoko Central Services