Firmware sources, D-Sample quirks etc

Mychaela Falconia falcon at ivan.Harhan.ORG
Sun Nov 29 07:40:22 CET 2015


I wrote here just under a week ago:

> Dieter Spaar is the contractor whom Openmoko hired to produce their
> moko10 and moko11 firmwares, and to track down the infamous bug #1024.
> [...]
> I emailed
> him, but I don't have much hope for a good response, considering that
> he is probably one of those people who hate my guts for working on
> FreeCalypso instead of OsmocomBB.

Update: to his credit, Dieter was willing to converse with me, but as
I expected, he does not have any more sources than the ones we already
have.  Nor did he have any additional suggestions beyond all of the
things I've already thought of myself.

In other news, I have powered up our D-Sample board once more and did
a little experiment: I ran fc-loadtool on it (I have not yet bothered
to RE the old Calypso F741979B boot ROM and implement proper support
for it, but it just happens to work with our current code if one goes
through the MODEM UART rather than IrDA) and used abbr and abbw
loadagent commands to poke at the Iota ABB register that controls the
LED drivers.  Finding: as I suspected, Iota's LED-B driver is used for
the backlight internal to the fancy 176x220 pix LCD in the D-Sample
test handset part, and there is no backlight for the keypad.

Now here is what this finding means in terms of TI's fw: on the one
hand, it explains why there is no code in there to turn off the
display: the proto-UI code our fw came with does turn off the backlight
in the sense of LED-B; on phones like Mot C139 and Pirelli DP-L10
turning LED-B off merely turns off the separate keypad backlight, but
on the D-Sample it is the backlight internal to the display.

But here is the totally perplexing part: it is a hardware fact that
the LED-B driver in the Iota ABB requires the 13 MHz clock to be
running; if this clock is stopped, the current stops flowing and the
light goes out.  This hardware fact means that the fw must not enter
deep sleep while the backlight in question needs to be lit; entering
deep sleep while LED-B is on causes the light to flicker as the
Calypso goes in and out of deep sleep to listen on the paging channel.

The perplexing part is that the TCS211 fw we got from Sotovik contains
absolutely no provision to abstain from entering deep sleep while the
UI has the display backlight turned on, hence the light flickers as
just described.  On the C139 the light that flickered was the blue
keypad backlight, which was certainly annoying and clearly indicative
of a bug somewhere, but it did not interfere with exercising the UI on
the LCD.  But if we were to run this same TCS211 fw on a platform like
the D-Sample where LED-B is the main display backlight, it would cause
the *display* to flicker, most likely making it unusable.

How here is the head-scratching question: how in the world did TI
develop and test their UI code on the D-Sample when they have this
monster of a bug with deep sleep breaking the display?  The only
possible answer I have may lie in lines 31 and 32 of this ASCII text
file:

http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt

Perhaps the call to power_down_config() in cst_pei.c that enables sleep
modes was added fairly late in TI's fw evolution, and firmwares as late
as moko1 and moko2 (based on 20070419 code from TI, of which there is
no surviving copy to the best of my knowledge) still ran with NO sleep
modes enabled by default.  In this case TI probably ran with all sleep
disabled when they developed their UI, and by the time they added that
sleep enabling, their only remaining Calypso customers were makers of
modems rather than handsets, hence they let the UI bit-rot.

One additional confirmation for this hypothesis comes from the ampere
meter display on the bench power supply I am using to power the
D-Sample.  When I first power it up, the current meter reads between
40 and 42 mA (a little high because of debug LEDs); when I give it an
at%sleep=1 or at%sleep=4 command (enabling small sleep or all sleep,
respectively), the current draw drops to about 25 mA.  Enabling big
sleep only or deep sleep only (no small sleep) produces the same
effect as disabling all sleep: current between 40 and 42 mA.  Thus two
conclusions can be drawn:

1. When L1 is idle (not activated even for SIM-less mode of camping on
   any available cell for possible emergency calls), the only effective
   sleep mode is small sleep.

2. The 20020917 firmware in this D-Sample has all sleep disabled by
   default.

OK, I can see how they may have left sleep modes disabled back in 2002,
but did they really ship firmwares with all sleep modes disabled by
default as late as 20070419?!  Blows my mind.

Happy hacking,
Mychaela


More information about the Community mailing list