FreeCalypso on the D-Sample

Mychaela Falconia mychaela.falconia at gmail.com
Sun Jan 21 19:13:53 UTC 2018


Hello again everyone,

I've done some more work on the D-Sample board and discovered a really
strange issue with its LCD.  When running our TCS211-based Magnetite
fw on this board with TI's UI enabled, the picture on the LCD looks as
expected for the home screen and the various text display screens, but
some of the main menu screens (each of the main menu items is a full
screen icon in full color) look garbled.

Some of our long-timers may remember that this weekend with the
D-Sample board is not the first time I took a peek at TI's 176x220 pix
color UI - back in 2015 I hacked the code to emit this LCD output as
raster blits on the RVTMUX serial port, and saw a few glimples of this
176x220 pix color UI with the firmware running on a GTA02 modem or on
the Pirelli, with the virtual LCD output in an X11 window on my
serially-connected x86 host.  I wasn't able to go far with that
approach because the huge amount of raster blit data was too much for
the serial channel even at 812500 baud: 176x220 times 2 bytes per
pixel (16-bit color) is 77440 bytes (almost 1 s at 812500 baud at line
rate before overhead), and the code is structured in a such a way that
the R2D layer (the place where I tapped it) ends up constantly
refreshing the entire LCD.

Back to the D-Sample LCD problem, I remember what the main menu
screens looked like (again, each item in the main menu is a full
screen icon), and they did not look garbled like they do on the
physical LCD.  Furthermore, not all of the icon screens look garbled,
only some of them, and different icons get garbled to different
degrees: some are only a little garbled, some are worse; the recent
calls icon is the worst.

Further investigation revealed that when a garbled icon is seen on the
physical LCD, the image in the R2D framebuffer is perfectly good,
nothing garbled in there.  Now consider the implications: the LCD
refresh code (you can see it in our FC Magnetite source tree in
src/cs/drivers/drv_app/r2d/lcds/D_Sample/r2d_task_i.c) takes the
16-bit color words in this framebuffer (the one which I have verified
through ETM memory reads to have the correct content) and writes them
sequentially to the physical LCD.  The LCD has a 16-bit parallel
interface, mapped at a fixed address in the Calypso ARM7 address
space, and one sends a picture to it by writing all of the pixels in
the range to be written (given as a command ahead of time)
sequentially into one fixed address that translates into a write cycle
to the LCD controller, in the left-to-right, top-to-bottom order.

Thus what we are seeing can only be a hardware problem with the
interface from the Calypso to the LCD, or even inside the LCD module
itself: what the hardware registers and displays is not what the ARM7
writes to it!  The fact that only some icons are effected, some worse
than others, and some of the other experiments I did indicate that the
hw bug must be triggered by some particular pixel color values, or
perhaps some pixel color values being sent before or after some
others.  Furthermore, I took a closer look at exactly how the picture
is garbled, and here is what's happening: as the 176x220 array of
pixels is being written sequentially to the LCD, some of the pixels
get registered twice by the LCD module, i.e., the internal RAM write
pointer inside the LCD controller seems to erroneously get incremented
twice instead of once on some pixel writes.  All subsequent pixels on
the same horizonal line are then shifted one pixel to the right from
where they should be, the last pixel on that line goes to the leftmost
position of the next line, and so forth, with the whole picture being
skewed afterward.  On some icon screens only a few pixels trigger this
bug, causing it to be only a little garbled, whereas if the picture
contains a lot of pixels which trigger the bug, the added effect of
all of these one-pixel shifts is a totally garbled picture.

Furthermore, the effect is probabilistic: the garbled screens don't
look the same every time, i.e., while certain pixel values or perhaps
sequences of pixel values in some particular order are prone to
trigger the bug, whether or not a given write of a "bad" pixel value
causes the erroneous double increment of the internal RAM write
pointer is a matter of probability.  Sometimes the effect is an
unsteady or "shaky" picture on the LCD, as the fw does nothing but
keep refreshing the same screen over and over, and different refresh
cycles trigger the hw bug differently.

I have tried everything I could to fix this display bug by tweaking
the LCD driver code: I tried some of the different LCD initialization
settings from the E-Sample version, and I even tried changing the LCD
interface configuration to the one used on E-Sample and later
platforms with dedicated LCD interfaces.  In the D-Sample version all
16 lines are wired from the Calypso to the LCD module in the handset
part, so that the ARM7 can send each 16-bit pixel in RGB565 with a
single strh instruction and a single bus cycle; on E-Sample and later
versions only the low 8 lines are connected, and they use the
dedicated LCD interface function of the Calypso+ and later chipsets
(not present in the plain Calypso) to stream blits to an 8 bit wide
LCD with the ARM7 CPU off-loaded.  The actual LCD module appears to be
the same and there is a configuration byte written that selects the
interface; the two known choices are RGB565 color, 16-bit interface,
one write cycle per pixel (the original D-Sample config) and RGB888
color, 8-bit interface, 3 write cycles per pixel, used on E-Sample and
later.  I tried changing the interface config to the E-Sample one and
having the refresh code send 3 write cycles per pixel with RGB888 in
the low byte on the bus; the behavior improved in that most icons were
less garbled, but the recent calls icon (the one that has always been
the worst) was still badly garbled.  That last result of garbling
still happening despite a total change of the interface structure
makes me suspect that the problem is more likely to be inside the LCD
module itself than in the interface from the Calypso to it.

So, what do we do about it?  My current tentative plan, subject to
change at any moment as my feelings change on a day-to-day basis, is
to still make an attempt to recover the tpudrv10 code from reverse eng
of the ancient 20020917 fw image and try to make the radio work on
this D-Sample board.  If we can reconstruct the tpudrv10 code and get
working GSM on this board, then I think I may be able to use this
D-Sample environment for the critical step of hybrid UI migration and
regression testing (see below), despite the LCD being broken in a way
that I am not able to fix by software means: only the icon screens are
garbled, and it seems that all of the screens with actual info content
on them are just text, and TI's color scheme for text screens is too
plain and boring to trigger the pixel-value-dependent LCD hw bug.
Again, this is only a tentative plan and NOT a promise.

Now aside from the hardware platform issues, let's review what is the
actual UI software work that we need to do before we can have
something for our end user folks to use on their C139 or possibly C11x
phones - in other words, if someone were to give me a perfectly
working hw platform with a defect-free D-Sample-like LCD that runs
TCS211 fw with fully working GSM, what would I do with it?

The first critical work step on the software side is that we need to
get a UI-enabled fw configuration that builds on top of the new hybrid
version of the underlying GSM modem, instead of the old one with blobs
for the G23M PS component.  Right now the only UI-enabled fw config we
have (config name 2092 in Magnetite) uses the version of the UI code
which we got with our copy of TCS211, running on top of the old TCS211
(Openmoko) version of ACI, which in turn runs on top of a G23M PS
version which we have only as binary object libraries.  For AT command
modem operation without the UI, we already have a deblobbed hybrid
config in which the TCS211 blob version of the G23M PS is replaced
with the full source version from TI's TCS3/LoCosto program, with the
ACI layer above it also replaced with the newer version from TCS3.
This hybrid config works quite well in AT-command-controlled modem
operation, but we don't have a firmware version yet that has the UI
layers on top of this hybrid config.

My first attempt was to build the BMI and MFW layers from TCS211 (the
same UI code we are currently using) on top of the new TCS3 version of
ACI.  The result was immediate breakage, i.e., the old UI code won't
compile against the new versions of cdginc and ACI headers.  Then I
tried importing the new versions of BMI and MFW from the LoCosto
source (the same source from which we took our G23M PS and ACI for the
hybrid config) and compiling them in the Magnetite environment.  Once
again I am facing a lot of breakage, as TI's uncaring sw engineers
have added a bunch of non-Calypso-compatible LoCosto-isms which I have
to find and revert one by one.  I am still nowhere close to having it
fully pass compilation, but I am slowly progressing one C module at a
time, and this approach seems more promising and feels more right than
complicating our hybrid even further by going back to the old TCS211
versions of BMI and MFW above the new ACI.

What this situation practically means for those who are anxiously
waiting for FreeCalypso on Mot C139 with a practically usable UI is
that we need to get this hybrid UI configuration to first compile,
then work without major regressions from the old TCS211 version before
we can start making the changes to support the 96x64 pixel screen size
on Mot C1xx.  Right now it appears that the versions of BMI and MFW
from TCS211 will need to be retired and replaced wholesale with the
newer TCS3 versions going forward, and if this is the case, then any
work done on the old BMI code will have to be either thrown away or
ported (with major difficulty as always) to the new version.  Thus I
am not willing to spend my unpaid volunteer work time on implementing
a UI for the C139 or any other C1xx in the old version of TI's BMI
which appears to be slated for wholesale replacement.

Thus my current work plan is to continue massaging the new BMI and MFW
code from TCS3/LoCosto (now under src/ui3 in Magnetite) with the goal
of getting it to pass compilation - this is a necessary work step that
also has the benefit of not requiring any hardware.  Once I can get it
to compile and link, I will try running it on the D-Sample board in
its current no-working-radio state, and get it to boot without
crashing - then see if it can display the phonebook and stored
messages from the SIM like the old version can do without a working
radio.  Then see where we can take it from there.

Das Signal wrote:

> Just a though, would it be possible to physically remove the screen
> of a C139 (or even C11x) and replace it with a higher resolution screen?
> This would enable the development of a better UI, than with the reduced
> screen we currently have.

I assume that you are not suggesting this idea as an end user mod - I
don't think there are any higher pixel resolution LCDs out there that
will fit into the same physical size as Motorola's C11x or C139 LCD.
As I understand it, LCD physical sizes and pixel resolutions generally
increase together - I haven't seen 128x160 pix in less than 1.77"
diagonal or 176x220 pix in less than 2" diagonal, for example.  And
even if there exists a higher pixel resolution LCD of approximately
right physical size and a compatible interface, the chances of it
being such a perfect fit that it could be a drop-in end user mod are
practically nil.

OTOH, your idea is interesting indeed from a developer perspective:
hack up a higher pixel resolution LCD to a disassembled C139 phone on
a lab bench, without any attempt to put it back together as a usable
phone.  In this case the only higher pixel resolution I would be
interested in is 176x220, for the purpose of exercising TI's UI code
in its original form prior to small-screen changes.  It might be
possible to find a 176x220 pix color LCD with a SPI interface, and it
might be possible to connect it with little hack-soldered wires to the
LCD interface pads on a gutted C139 PCB.  The first problem would be
that the write-out of a 176x220 times 16 bits per pixel framebuffer
would be *really* slow over Calypso's SPI/uWire, but then there is an
even bigger problem that kills the idea: the whole purpose of this
hack would be exercise TI's UI code in its original unstripped config,
and this config needs more RAM than the C139 has.

But it was definitely an interesting thought.

Hasta la Victoria, Siempre,
Mychaela aka The Mother


More information about the Community mailing list