Status of TCS211 on C139

[Mychaela Falconia]

Hello fellow yearners for a libre phone,

I got the LCD driver implemented in tcs211-c139, for now pretending to
be a monochrome 84x48 pix display from TI's C-Sample to the rest of
the firmware suite - the actual LCD on the Mot C139/140 is 96x64 pix
full color (16 bits per pixel), but TI's demo/prototype UI (remember,
TI sold chipsets, not handsets - UI design for real products was the
responsibility of TI's customers) only supports two screen types at
the opposite extremes: monochrome (1 bit per pixel) 84x48 pix at one
extreme (C-Sample and earlier TI dev kits) and 16 bits per pixel full
color 176x220 pix at the other extreme (D-Sample and later).  Thus a
reasonable starting point for the C139 port is to bring up the UI in
the 84x48 mono "C-Sample" configuration, using only 2 colors out of
the 65536 our LCD can physically display and using only 84x48 pix out
of the physically available 96x64, and play from there.

But unfortunately we are not at the point of being able to see this UI
working yet.  I got tcs211-c139 to compile and link into a flashable
image for the C139 in the pdt_2092 config (UI code enabled) with the
just-described C-Sample-emulating C139 LCD driver and other necessary
support, but this firmware crashes somewhere on boot. :(  Without
additional debug patches (i.e., if you take the source currently on
Bitbucket, compile it and flash the image) the crash takes the form of
an endless reboot: as the phone boots up, something goes bonkers, a
reset is invoked, the second and subsequent boot cycles don't fare any
better, so it just does an endless cycle of reboot attempts.

After a lot of head-scratching and digging, I am now able to determine
that the crash/reset takes the form of some piece of the firmware
calling the DAR component's (Diagnose And Recovery) "emergency scuttling"
function, i.e., some other part of the fw suite gets unhappy about
something and invokes the fatal error reboot path.  Now we need to find
out which part of the fw gets unhappy (where the call to DAR emergency
scuttling is coming from) and why.  I am going to need to implement
yet another devious hack in order to obtain a stack backtrace from the
dar_process_emergency() function...

Another perplexing aspect to the present failure is that when I #if 0'ed
out the guts of the display refresh function (the code that actually
sends the pixels to the LCD), the crash-reboot went away and the
UI-enabled fw booted!  Obviously with the actual LCD output removed it
is not usable, but I could see in the rvinterf output that it was
doing what UI-enabled fw does in the absence of a SIM - it brings the
radio up and finds a cell to camp on, but does not try to register as
there is no SIM - the UI-enabled fw makes itself ready for the
possibility that someone needs to make an emergency call without a SIM.
(In contrast, fw built in the ACI config does not bring the radio up
at all on its own, SIM or no SIM, without being AT-commanded to do so.)

The investigation continues.

Hasta la Victoria, Siempre,
Mychaela