FreeCalypso updates

[Spacefalcon the Outlaw]

Hello FC community,

While I'm still waiting for San Diego PCB (www.sdpcb.com) to get back
to me with a quote or estimate for the job of finishing our FCDEV3B
PCB layout, I did a couple of hacks on the software front.

As I pointed out earlier, we have the source for TI's reference/demo
cellphone UI code, but we had no way of seeing what this UI actually
looks like or even what LCD size (in pixels) it is designed for.  I
got TI's D-Sample kit that includes the LCD+keypad on which TI
developed their UI, but because this D-Sample has the wrong chipset
that is not supported by our only available blob-laden copy of TCS211
firmware, it is of no help.

Well, I just implemented a hack to shine a little bit of light on this
subject of TI's UI code (BMI): I hacked up their physical LCD output
code (which originally targeted the LCD on the D-Sample) to emit its
raster blits as traces on the RVTMUX debug serial port, got this
hacked-up, UI-enabled TCS211 fw to run on the GTA02 modem, and wrote a
Unix/Linux host program to display this "virtual LCD" output in an X11
window on the x86 laptop which I use as my development system.  This
work can be found in the leo2moko-debug and freecalypso-sw repositories
on bitbucket, for the target firmware and host LCD window utility,
respectively.

If anyone here would like to see TI's UI with your own eyes, here is
the recipe:

1. Get the latest code from leo2moko-debug repository, compile it in
   the 2092 configuration (./winebuild.sh 2092), and flash it into
   your Freerunner's modem.  DO NOT try running any of Openmoko's host
   software when this fw is in the modem, i.e., keep QtMoko etc fully
   shut down.

2. Connect the headset serial cable, do the magic on the GTA02 AP to
   connect it to the Calypso, but keep the modem powered off for now.
   You will need a serial cable that supports the non-standard high
   baud rate of 812500 baud.

3. With the latest version of rvinterf tools from freecalypso-sw
   compiled and installed, run a command like this:

rvinterf -B812500 -X fc-lcdemu /dev/ttyXXX

The argument after the -X option to rvinterf gives the command to be
be run via popen(3) to which the LCD output will be fed.  That command
can have its own arguments, i.e., you can do something like this:

rvinterf -B812500 -X 'fc-lcdemu -geom -100+20' /dev/ttyXXX

Running the serial port at Calypso's maximum of 812500 baud is
absolutely necessary for this hack.  This version of TI's UI code
which we got with our Calypso fw (the one leo2moko is based on)
produces output for a 176x220 pix LCD (huge by Calypso dumbphone
standards), with 16 bits per pixel (RGB 5:6:5), so the raster blits
being sent over the serial channel (instead of going to an LCD wired
directly to the Calypso) are monstrous.  Even at 812500 baud the
"virtual LCD" updates quite slowly, about 1 s per refresh, much slower
than a real LCD on a real phone handset would.

4. Power up the Calypso (echo 1 > power_on).  You should see trace
   output pouring in the rvinterf terminal window, and you should see
   the LCD output from the firmware in the fc-lcdemu window.  If you
   have a valid SIM inserted, the fw with UI enabled will bring the
   radio up and connect to the network automatically, without needing
   to be commanded to do so like the more familiar AT-controlled
   version does.

Not knowing what TI's intended UI color scheme was, I have no reliable
way of knowing whether or not the 16-bit RGB values (5:6:5) coming
from TI's R2D need to be inverted or not.  To enable inversion, add -v
to the rvinterf command line (at the rvinterf level, not at the
fc-lcdemu level) - try it both ways and judge for yourself which color
scheme looks more right.

With the above method I was able to see the "idle" home screen with
the GSM device auto-connected (no AT commands needed) to Operator
310260 (using this operator's SIM), and by making a call to the number
of this SIM, I was also able to see the incoming call screen.  The
main observation that can be made from this experiment is that the UI
code we have really does use the whole 176x220 pix LCD real estate - I
was previously unsure if perhaps it might have been written for some
smaller subset.  (One TI document gave an impression of the UI design
using 160 pixels total in the vertical dimension, but didn't say
anything about horizontal - so I thought that maybe it was a 128x160
pixel UI design.  But nope, the code we have is set up for the full
176x220 pix, the LCD size on the D-Sample and subsequent development
kits from TI.)

Thus when the time comes for us to build our own Calypso phone hw, the
LCD size will be 176x220 pix: the choice is a no-brainer given that we
have already working UI code (in full source form!) for such a fancy
large screen, complete with pretty graphics and animations.  Of course
we could rework the UI design for a smaller screen if we really had or
wanted to, but where is the fun in that?  Given that we already have a
UI that works with 176x220, I say better use this big LCD size and
give our users more freedom to invent new UI features we never thought
of.

My experiments with displaying TI's UI from TCS211 GSM fw running on
the GTA02 modem stopped at seeing the idle home screen and the
incoming call screen.  A cellphone UI expects to be driven by the user
pressing buttons on the dial keypad, and of course there is no keypad
connected to the Calypso on the GTA02.  I looked at the code that
handles keypad input to see if there can be some simple and obvious
way to feed in virtual keypresses from the RVTMUX serial channel, but
the code turned out to be quite complex, and I didn't stay on that
subproject long enough to find a good place to inject the hack.

Rather I tried a different hack: I made TCS211 fw run on the Pirelli.
Yes, the blob-laden one!  It was a whole series of hacks, but I got it
to kinda-sorta-work.  You can find it here:

https://bitbucket.org/falconian/tcs211-pirelli

It doesn't work very well, though:

* At first the fw would spontaneously reboot as I was playing with GSM
  radio bring-up, at seemingly unpredictable times.  This behavior
  stopped when I disabled deep sleep.  Throughout this project we need
  to keep in mind that Pirelli is "alien" hardware, we have no
  schematics for it, and it contains some very complex extra hw for
  non-GSM functionality which is connected to the Calypso in
  non-understood ways.  Even though that hw is for non-GSM functions
  we don't care for, it most certainly can affect the Calypso GSM core
  which we do care about - in totally non-understood ways.  Perhaps
  something in that extra non-understood hw gets unhappy when the
  13 MHz clock output suddently goes away, which is what happens in
  deep sleep.  Obviously Pirelli's own fw has to handle it somehow,
  but we have no source for it, so it doesn't help.

* The fw has a very difficult time connecting to the GSM network: most
  of the time it fails, and it can take more than 10 min of retries
  before it somehow finally succeeds.  But once it gets connected (if
  it does at all: on some boot cycles it never succeeded at all), the
  connection seems to be fine.  I was able to make calls and the voice
  codec worked correctly in both directions.

* At first I was disabling deep sleep with at%sleep=2 via fc-shell; I
  would give this command prior to at+cops.  But then I wanted to run
  the UI-enabled version, which connects to the network immediately
  upon boot w/o waiting for any AT commands.  So I tried changing the
  default sleep mode setting in cst_pei.c.  And now this
  TCS211-on-Pirelli hack-fw is unable to connect to the network at all:
  fails with DSP errors early on.  Heck, I don't even know if this
  change in behaviour resulted from the sleep mode change, or if it
  was somehow coincidental - at that point I got sick of it and didn't
  feel like going any deeper down that particular rabbit hole.

But I did get the UI-enabled version of TCS211 running on the Pirelli,
and played with it despite network search failing - it was the same
as if I were playing with a regular phone in a Faraday cage with no
GSM service - all the UI menus etc still work.  The LCD output went to
the external host via serial at 812500 baud like before (didn't use
Pirelli's LCD: how would you display a 176x220 pix UI on a 128x128 pix
physical LCD?), but I did use the real keypad on the phone to drive
this UI.  I was able to step through the UI menus, browse through the
SIM phonebook and read the saved SMS on this SIM - the UI for all of
these functions looks OK for the most part, although there is some
room for improvement.

Going forward, I feel that we need a more methodical and focused plan
of development, as opposed to going down every rabbit hole in sight:
it's a whole minefield full of rabbit holes, and we won't get to any
meaningful end goal by going down every one of them.  The way I would
like to proceed is as follows:

1. Get our FCDEV3B development board laid out and built, and have this
   board fully replace the GTA02 for all purposes within our project.
   Unlike the "alien" Pirelli (or heaven forbid, Compal) phones, this
   board is expected to run TCS211 exactly like Openmoko's modem of
   which it is a copy, i.e., solidly reliably.

2. Use that board to whip our full-source, gcc-built FC GSM fw into
   shape, i.e., make it work as well as TCS211, i.e., as well as how
   TCS211 currently works on the GTA02, and will hopefully work on the
   FCDEV3B.  Just focus on the AT-command-controlled mode of operation
   at this stage, don't bring UI code into the picture yet - the
   experiments I just did should be seen as merely taking a quick peek
   at what lies ahead.

3. If the full-source, gcc-built FC GSM fw we bring up and whip into
   shape on the FCDEV3B just happens to work well on Compal or Pirelli
   targets as well, great - keep supporting those targets in that case,
   and pursue the possibility of bringing them up with UI, turning them
   into practically usable libre phones.  But if something doesn't
   work, don't spend too much time and effort chasing after it: there
   is no point in expending Herculean efforts on undocumented,
   incompletely-understood "alien" hardware that is either in too
   short supply (Pirelli) or is too crippled for a high quality end
   user product (Compal).

4. Once we have 100% full-source, gcc-built firmware that reliably
   connects to GSM networks, makes and receives calls, sends and
   receives SMS etc, no worse than TCS211/leo2moko, running on our
   FCDEV3B board and possibly on other targets as well (the latter not
   required), even if it's just AT command control and no UI (scenario
   to consider in case both Compal and Pirelli turn out to be too-deep
   rabbit holes), we could approach the ultimate goal: building our
   own Calypso phone handset, with the Calypso core based on
   GTA02/FCDEV3B and with a 176x220 pix LCD and other peripherals
   needed in a complete handset.  Of course such a step will be a lot
   of effort, but we'll be able to approach it with confidence once we
   have our fully liberated fw in a "shining" state.

The immediate next step we need in order to move forward with the plan
above is getting PADS PCB layout done for FCDEV3B.  If we got our
FCDEV3B board built, I would be able to use it with JTAG to track down
the difference in DSP patch loading between TCS211 (which works
correctly) and our current FC GSM fw (which produces the wrong
checksum) and fix that bug.  I'll be able to do that part on the
FCDEV3B even before we get it calibrated, as the DSP patch loading
happens right at boot and does not need any radio at all, and the
error with the wrong checksum happens right at boot too, without
involving any radio bring-up.

Well, OK, since I got TCS211 kinda-sorta-working on the Pirelli, we
could do this JTAG debugging on the Pirelli as well - the problems we
have with TCS211 on Pirelli won't be an issue for this purpose just
like lack of calibration won't be on FCDEV3B, for the same reason: the
DSP patch download which we need to debug happens right at boot,
before any of the other problems begin.

However, I have a certain personal bias at play here: I spent a ton of
work to create the ready-to-layout FCDEV3B design, and I am not willing
to throw this work away.  To put it bluntly, I want my FCDEV3B built,
I want to see it turn from a tarball of design source files into a
physical board on a lab bench.  To that end, I am not particularly
interested in doing any work such as DSP patch debug on the Pirelli
that would diminish the need for FCDEV3B.

Toward that end, my current plan, subject to change as my feelings
evolve, is to pause further FreeCalypso work until someone steps
forward to do the layout of the FCDEV3B board in PADS.  Just the
layout, i.e., pure desk work, nothing physical - once the layout is
done, I'll find a way to get the board physically made.  Therefore,
anyone who would like to see FreeCalypso development continue to
fruition, please help me find a willing PADS-using PCB layout engineer
for the FCDEV3B subproject.

Hasta la Victoria, Siempre,

Mychaela aka Space Falcon