GTA04 openness/freedom (was GTA04 Group Buy - Status)

Michael Sokolov msokolov at ivan.Harhan.ORG
Fri Dec 2 23:54:01 CET 2011

Radek Polak <psonek2 at> wrote:

> i am rather saying:
> (shortage of existing GTA02 units) -> (GTA04 is the solution)

It is *a* solution for some classes of users.  It is not *the*
solution for all use cases.

> Also pool graphics performace of GTA02 make the user experience very bad - 
> hardly acceptable for normal users and this is fixed in GTA04 and that's one 
> more reason to upgrade.

Fancy graphics is something I couldn't care less about.  I would be
quite happy with the most bare-bones UI which should be implementable
just fine on the GTA02, producing responsiveness no worse than my
ancient Mot V66.

Instead what I want is an everyday cellphone that does voice calls,
SMS and CSD, and does so using software and firmware for which I have
access to inspectable and recompilable source, be it legal or illegal.

I'm currently in the process of trying to acquire a TSM30: that may be
the right phone for me, given that my GTA02 is currently a paperweight
due to the lack of an army capable of invading Germany and prying the
Closedmoko fw semi-src from its hoarders.  I should be able to acquire
at least one TSM30, but I'm hoping to be able to find at least two:
since no TSM30 schematics are available (I don't know whether it's
because they've never been released in the first place, or if they are
available in some obscure location and those who know that location
are selfishly refusing to point me to it), I will probably have to
reconstruct them by taking an actual TSM30 PCBA and sending it to a
professional PCB/PCBA reverse engineering lab where they would remove
all components, separate and image the layers of the PCB or whatever
they do to reconstruct the netlist and the layout of inner layers.
Unfortunately that process requires destroying at least one PCBA. :-(

Of course hiring a professional PCB/PCBA reverse eng lab is devilishly
expensive, but it should still be less expensive than hiring the kind
of people who could help me recover the semi-src I'm looking for by
some brute-force means...  Not to mention the cost of restructuring my
life to avoid ever visiting any country that does extradition...

What would I do if someone was willing to release an anonymous copy of
the GTA0x (or Leonardo baseline) Calypso fw semi-src, so that instead
of expending 100% of my life-force to recover that jewel I could
actually do something productive?  Well, in that case I would start by
taking my GTA02 out of the box in which it came, and putting my own
very simple distro on the Samsung application processor.  I would then
bring up the Calypso, using the knowledge of its code to understand
the process better.  Maybe even find and fix a bug or two in that
Calypso fw in the process.

After bringing up my own distro on the GTA02 that uses built-from-src
code for both the AP and the BP, I would quite seriously consider
building my own replacement PCBA just like Dr. HNS did.  If he and his
team could do it, why can't I?  Expect that my hw design goals and
target audience would be quite different.  I would keep the Calypso,
no UMTS, but possibly make it quad-band, copying the quad-band GSM RF
front-end from the Leonardo+ schematics - if I can find a place to get
that little passive component.  While I have no problem with the
Samsung AP on the GTA02, I realize that the component is most likely
unobtainable.  But since I would be targeting a user base for which
the part that really matters is the BP rather than the AP, I don't
really care which AP to use.  Perhaps I would borrow the OMAP AP from
the GTA04, or maybe find some significantly cheaper really basic AP
that can do the absolutely minimal functions I expect from it.  And I
would most certainly omit the features/components/complexity that is
of no interest to me: WiFi, BT and the accelerometer/etc sensors.  The
result would be a device meant to be a *phone*, not something else.

But I'm not going to put any more serious thought into that project
until and unless I can obtain the source or semi-src for the Calypso
fw, i.e., either a GTA0x/Leonardo/other non-TSM30 version or some docs
for the TSM30 which would make that already-available source version a
more viable starting point.

> I am not saying that everyone should upgrade. I would personally wait a bit 
> until i knew that the power management in GTA04 will be working - without
> that the it's not much usable as phone (i.e. charging twice a day is not
> comfortabe and will kill your battery soon). But it's up to anyone to
> collect objective information and decide.

PM issues are one of the major reasons why the absence of src/semi-src
for the Calypso fw is making my GTA02 serve as a paperweight.  From
what I understand, the engineers at Openmoko-Inc took the Leonardo
baseline code and made their own adaptations to it.  One of the latter
was the addition of the GPIO signal by way of which the BP wakes up
the AP on certain conditions - an incoming call being the prime
example, one would hope.  I've heard that they were dealing with other
PM issues on the Calypso BP as well.

I have every reason to believe that the engineers employed by Om-Inc
for that Calypso fw adaptation job were smart and knew what they were
doing.  I shall assume (blind assumption in the absence of a viewable
source is the only option) that they did a reasonably good job, maybe
even an exceptionally good job.  But they were still human, not gods.
No one can ever expect absolute perfection, and *any* frozen &
unmodifiable piece of software should be expected to have leftover
bugs, no matter how stellar its original creator(s).  Perhaps there is
a latent bug in the code they had inherited from TI which they lacked
the resources to fix, or maybe even more than one.  Power mgmt is
exactly the kind of area where such remaining bugs are likely to hide.

It is very likely that as bright and stellar as they may have been,
the Om engineers might have forgotten some corner case in which the BP
should wake up the AP, but currently doesn't.  Finding these cases and
adding more conditions under which the BP wakes up the AP would allow
the AP to put itself to sleep more liberally, extending the battery
life.  (For example, if you are holding your Neo to your ear and
talking on it, hence not using any "application" functions at the same
time, I believe that the AP should turn itself almost completely off
as it isn't needed for the analog voice path from the Iota ABB to the
audio mixer chip - but I don't know if the wake-up logic in the
existing Calypso fw is good enough for that, or if the AP has to stay
awake just to listen for some possible events from the BP.)  It is
also quite likely that PM on the Calypso/Iota/Rita block itself could
be optimized even further: I've read the chip docs very thoroughly and
know what the hw is capable of, but whether or not the fw is doing
everything it possibly can to save power is another story.

Looking for and fixing these kinds of bugs/deficiencies is the real
reason why I keep begging and pleading for a copy of that fw semi-src,
*NOT* because I want to do something evil and nefarious with it.  Yes,
I realize that the remaining PM and other bugs in need of fixing are
very likely to reside in those modules which exist only in object
form, rather than the ones for which Om got the full source.  But I'm
not afraid of disassembling a .o (or .obj or whatever it's called in
their toolchain), and because those puppies have to contain symbolic
information in other to be linkable with the source bits and with each
other, there's actually quite a bit more than just binary code in
those "blobs".  And yes, I realize that the fw is probably built with
some Windows toolchain that's totally unlike gcc/binutils, and hence
the object module format is something foreign.  Well, I understand the
principles of object modules and linkers quite well (grep GNU Binutils
ChangeLog files for my name and email), and having to reverse-eng an
unknown object module format doesn't scare me too much.

Ok, you say, if I'm not afraid of disassembling and studying ARM
machine code, why can't I just disassemble the whole Calypso fw image
starting from the ARM7 reset vector?  The answer is that while I most
certainly could, I'm not going to for as long as the community keeps
treating me like this.

The root of the injustice here is that Paul Fertser, Harald Welte and
some unknown others are holding something significantly better than
what I, the unprivileged, have access to.  If everyone were on the
same footing, i.e., if *no one* in the community had access to
anything better than the flashed byte image, approaches such as
disassembling that image w/o any aid or rewriting it from scratch a la
OsmocomBB would be eligible for consideration.

But that isn't the situation we are in.  Instead we have several
community members who are sitting on a version of that code in object
module form with full symbolic information for linking, plus some bits
in full source form.  I'm willing to do the hard work of plowing
through that code with a fine-toothed comb, looking for and fixing any
bugs or inefficiencies related to PM or other issues, and turning the
blobs from binary at least into editable ARM assembly in the process.
But the strangleholders are denying me the necessary starting point,
while they themselves don't seem to have any interest at all in doing
the kind of work I'm willing to do.

The last point is very important.  Closed firmware can be at least
somewhat tolerated if whoever is privileged to access it under NDA or
whatever is actively maintaining it and releasing new binaries in
response to community needs.  If Openmoko-Inc still existed and
maintained a public external interface to the fw which itself they
couldn't make public, that would be at least somewhat tolerable.  If
they had publicly documented all specific quirks and peculiarities of
how their fw implements the standard AT commands, as well as all
details of the sleep modes and wake-up conditions, that would be one
thing.  And static documentation wouldn't be enough, they would have
to also have someone maintaining that code, responding to bug reports
and new feature requests, and releasing new images.

Of course that is massive support work, and no one can be expected to
do it for free.  But it's also wrong to be hoarding the essential
source (or semi-src) that would allow others to do this work for free
if they so chose.  Frozen code in which *no one* can ever fix a bug is
always a terrible thing.

So here's my plea to the GTA02 users who can't or don't want to
"upgrade" to GTA04, and who would like better PM or perhaps better GSM
voice call audio quality (the Calypso fw *is* able to affect that path
somewhat, either by applying DSP patches or by twiddling Iota
registers): convince the hoarders to let me have a copy of the fw
semi-src, and your reward will be a new fw image with improved PM
and/or call audio quality!


More information about the community mailing list