FC project direction

[Spacefalcon the Outlaw]

Let me preface this post with a reminder of what the primary end goal
of our project is: to have fully source-enabled firmware running on a
Calypso GSM device that not only performs modem functions, but also
includes a classic cellphone UI running on the device itself that
would be usable to an end user, as opposed to a developer or hacker.
Having the UI run on the Calypso together with the modem fw is the
key, as otherwise we could call our work done with leo2moko.

The work between the fall of 2013 and earlier this spring entailed
putting together a full source fw that matches the modem functionality
of leo2moko, and the work still ahead of us is to make this firmware
actually work - right now it runs on the FR's modem, but cannot
successfully make a call yet.  But all this effort has just been about
modem functionality so far - the realm of Calypso-based UI has not yet
been touched at all.

If we had to reimplement the Calypso-based UI from scratch, i.e., if
the functionality in the TI reference source leaks available to us
stopped at the ACI, the task would be really daunting.  But fortunately
the situation is a little better - both of our reference sources
(TCS211 for Calypso and TCS3.2 for LoCosto) do include what TI/Condat
called "BMI", which stands for "Basic MMI", with MMI being the GSM
industry's sexist term for the UI.  In other words, the BMI component
of TI's reference firmwares is their reference/prototype/demo UI.

I knew that this BMI code was there all along, but I have yet to see
with my own eyes what this UI looks like - and where does it lie on
the axis between a demo-only prototype on one end and a potentially
shippable end product on the other end.  Well, I got some news:
although I still don't have a way to see this UI actually running and
working (more on this below), I found this document to be quite
encouraging:

http://scottn.us/downloads/peek/SW%20doc/TCS%20basic%20MMI%20specification.PDF

If we are to believe this document, TI's BMI appears to be fully or
almost fully usable as the UI of a shipping phone for end users!

Of course it would still be very very useful to bring this UI up and
see it working *before* we go through the very substantial work of
integrating it into our gcc-built fw.  It's the same situation as with
the underlying modem fw: after a year and a half we have completed the
task of putting it together, but it doesn't work, and we have debug it
in order to make it work.  The only practical way for us to debug it
and make it work is by comparing against the working leo2moko reference
running on the same FR modem - without this working reference the task
would likely be hopeless.

I predict we'll be in exactly the same situation when we reach the
point of reintegrating TI's UI code: at first it won't work, and the
only way we'll be able to debug it is by comparing against a working
reference.  (And sorry DS, Compal's or Pirelli's proprietary firmwares
do NOT count as a usable working reference for this task, even with
symbols and JTAG.)  That was when I got a bright idea: what if we can
build our known-working TCS211 reference fw in a configuration with
the UI included, and get it working in that configuration?

The TCS211 semi-src we got was originally built (by TI, presumably)
for their pdt_2091 configuration, which is an AT command only config
without UI.  But the sources for the UI components (BMI, MFW and some
others I have yet to understand) are included, hence I wondered for a
long time if we could perhaps build a config with UI included.  There
is of course the problem of the binary libs: they've been built for
just one specific config, and we don't have the corresponding source
to rebuild them for a different one.  But after some careful thought I
realized that while certain configuration choices are set in stone
with these libs and can't be changed (CSD, fax and GPRS enabled, TTY
for the deaf disabled, in-modem TCP/IP, WAP and MMS also disabled),
the differences between pdt_2091 (what we got) and pdt_2092 (its
nearest sibling with BMI enabled) affect only those components for
which we do have the original source - eureka!

With this idea in mind, I performed an experiment last night: I took
the leo2moko source, copied the binary libs etc under gsm_ac_<blah> to
gsm_mf_<blah> (the aci vs. mfw difference for the TCS211 voodoo build
system), and invoked that voodoo build system to build pdt_2092.  And
guess what, I got a successful build resulting in a gsm_<blah>.m0
image that could hypothetically (although not practically, see below)
be flashed into a device.  This experiment proves that the UI code we
have in our copy of TCS211 is complete and buildable - nothing missing,
mismatched or bitrotten.

The next problem is that I don't have any suitable hardware I could
try flashing that image into.  The UI code that gets built if one were
to take our TCS211 and build it for pdt_2092 targets the 176x220 pix
LCD on TI's D-Sample development kit, but even if I somehow got a hold
of one those kits (highly unlikely in itself), one *still* would not
be able to flash the built image into that target and play with it:
D-Sample had Clara RF instead of Rita, and the L1 binary libs are
built for the Rita RF used in all commercial products of relevance to
us.  Bummer.

Well, OK, there is a trick.  The TCS211 fw image with UI included fits
into just under 3.5 MiB (for comparison, the "standard" build w/o UI is
just under 2.25 MiB), so we could squeeze it into the available flash
on the GTA02 modem (I would need to tweak the linker script a little
bit, no big deal), and the available RAM is sufficient too.  Of course
there is no Calypso-attached LCD or other UI hardware on the GTA02.
The D-Sample LCD code writes into registers (write-only, apparently)
in the nCS3 range, and on the FR's modem this chip select is
unconnected, so the LCD writes will just go into the aether without
affecting anything.  Hence the code should run, but the LCD output
will be invisible.

Then I got another idea: what if we hack the LCD output code in TCS211
(which is in full source form) and make it send all LCD output as
bitmap blits over RVTMUX?  Then write a Unix/Linux host program that
would receive these LCD bitmap blits over RVTMUX and display them in
an X11 window on the development machine - that trick would turn our
GTA02 modem into an equivalent of a complete dumbphone with UI on the
Calypso - and we would get to exercise and experience TI's presumably
stable and working UI code in its known-working form before we break
it in our effort to port it to our gcc environment and to non-TI
targets like Pirelli or Compal.

Now on to the other thing I wanted to write about: if anyone here
feels like investing a lot of time and effort into Compal or Pirelli
targets, I very strongly discourage doing so.  I believe that those
targets can be somewhat useful side branches in our development, but
they should *not* be our trunk.  At the same time, the GTA02 modem is
also a very imperfect choice for our "trunk" target: I currently use
it not because it is somehow perfect, but because it's the only
available target that satisfies my requirements as the principal
developer - Compal and Pirelli both fail the criterion as they both
stray too far from TI's reference designs.

I believe that we as the FC community need to put a higher priority on
building our own FC GSM development board.  Make it pretty much the
same as the GTA02 modem, i.e., modem hw only, no UI hw yet, but
standalone, i.e., on a board by itself without Openmoko's application
processor part.  (We now have Openmoko's original gerbers for GTA02 up
to rev A6, but if we sent them out to fab as-is, we would have to
populate all those AP subsystem components in order to have an operable
board, and procuring some of those extra components beyond the modem
block may be mission impossible.)  Throw in the common sense changes of
triband->quadband and K5A3281->S71PL129NC0 while at it, and get this
puppy actually built!

In terms of its quality as a development platform, this dev board I am
proposing would be only marginally more convenient than the existing
GTA02 modem (more memory, JTAG available, no need to fuss with the AP),
but its primary impact would be enabling more potential fw developers
to come forth.  Right now having to have a Neo Freerunner imposes a
rather insurmountable barrier to entry: consider that at the present
moment the only member of our community besides myself who has some
realistic ability to contribute to fw development/debugging/bring-up
does not have an FR, hence it is not currently possible for him to
contribute to the project _in a way that is actually useful toward the
realisation of our primary goals_.  (C1xx and Pirelli hacks are fun,
but don't contribute much toward the primary goals.)

If we are to believe www.pulster.eu, the total number of *available*
Neo FR units in the world currently stands at 3, and at the price
point of 500 EUR per unit they are too expensive for me to buy one as
a gift for whomever wishes to join our fw development in the earnest.
And even if I did have that kind of money to spare, it would be better
spent on getting our own hardware built.

Getting our FC GSM dev board built will require two stages:

1) Design creation;
2) Physical production.

Part 2 will require money, but part 1 (which needs to be done first)
does not.  Part 1 is pure desk work, all it requires is a qualified
engineer to donate his or her time drawing schematics, choosing
components for the BOM, drawing footprints for these components and
laying out the PCB.  I already made several starts at this task
earlier, and if no volunteer steps forward to take it over, I will get
back to it myself.

If calibration weren't an issue, I would be very tempted to set the fw
subproject aside right this moment and switch to the board design
subproject.  But calibration *is* an issue: when we build these boards,
we'll need to get them calibrated in order for them to replace Neo FR
modems that were calibrated on Om's production line.  Calibration
involves two parts: external test equipment (TI apparently used R&S
CMU200, I looked on ebay and it seems that one can be bought at an
affordable price) and code running on the device being calibrated that
makes it do certain things like continuous Tx at specified VCXO and
APC DAC settings etc.  The external test equipment is "just" a matter
of going to ebay and spending $$$, but the code running on the Calypso
is something I would like to have better control over.

When it comes to calibration, at the very least I will need to develop
host side tools under rvinterf (probably add some commands to fc-tmsh)
for commanding the L1TM code on the target to perform various RF test
tasks.  I don't know yet what the ETM command packets to be sent need
to look like, but we have the L1TM target side code in full source
form in the TCS3.2/LoCosto find.  Our TCS211 version has this L1TM
code in it too (Om would not have been able to run their production
line calibration if this L1TM code weren't there), but it's in binary
libs. :-(  For this reason I would like to get the L1TM code from
TCS3.2 integrated into FC gsm-fw and actually working before we start
calibrating GSM devices of our own make.

If I have to do all the work myself, i.e., if no one volunteers to
take over certain parts and if no major financial sponsors come forth
(the latter would enable me to hire another engineer to offload some
of the work), I plan on proceeding in the following order:

1. Finish what I already started: debug our current non-working FC GSM
   fw on the gtamodem target by comparison against working leo2moko,
   and get ours to work as well.

2. Once our FC gsm-fw works on the gtamodem target no worse than
   leo2moko at the most basic level of functionality (make a call,
   receive a call, send and receive an SMS), proving that the tpudrv12
   etc code is good, then add L1TM from TCS3.2.

3. Buy a CMU200 on ebay and prove to myself that I can recalibrate my
   Om-made Neo FR using FreeCalypso tools.

4. Switch my focus to designing and building our own FC GSM dev board.

Now if we had a second developer available (either as a volunteer or
as hired help given a sponsor), some of the above tasks could be done
in parallel.  I could continue working on part 1 above (getting our FC
GSM fw working as well as TCS211 using gtamodem as the target) - I
find it very doubtful that anyone else would be able to do this part -
while someone else takes over the board design work.  The two can be
very easily done in parallel without clashes, as calibration won't be
needed until after the new board has been physically built and brought
up at a basic level - hence I can work on the fw while someone else
works on the board design.  Any takers?

It goes without saying that once we have these GSM dev boards built
and calibrated, I will provide them free of charge (or at most for the
needed non-sunk production cost with zero profit margin) to anyone who
makes a serious commitment to joining FreeCalypso fw development.

The other thing I wanted to touch upon is the role to be played by
Compal and Pirelli targets in our overall project.  As I mentioned
earlier, I see them as side branches which may or may not turn out to
be necessary.  Hypothetically speaking, if our project were to attract
some major sponsorship/funding, we could skip these Compal and Pirelli
targets altogether and proceed directly to building our own hardware
as in not just a dev board, but a complete handset with plastics and
all, using all new components besides surplus-sourced Calypso etc
chips, so we can produce them in any desired quantity - and make this
hw of our own the sole target for our fw.  Yes, I know, getting
funding of this magnitude is not a very realistic expectation, but a
girl can always dream, right?

Practically speaking, I think that we can table the question of
whether or not we need to support Compal & Pirelli until after we get
the following 3 major tasks done, in any order:

1: get our own GSM dev board built - the physical production part will
   require some money, but I predict that I'll be able to cover it
   myself without needing sponsors, as by the time we reach that point,
   my personal financial situation is expected to improve a little bit;

2: get our gcc-built FC GSM fw working no worse than TCS211 on our GSM
   dev board and/or on the GTA02 modem;

3: get TI's UI (BMI) working on sans-LCD targets by ferrying the bitmap
   output over RVTMUX to an external display application.

If some sponsors come forth during the time it takes us to do the 3
tasks above, great: we could then talk to those sponsors and convince
them that going directly to our own handset hw, without wasting energy
on the crippled and soon-to-be-gone C1xx surplus, would be the best
course of action.  But if we get done with the 3 essentials above, no
sponsors have come forth, and the core members of our community still
yearn for a Free Dumb Phone to carry in our own pockets and purses,
*then* we can bite the bullet and do the unpleasant work of porting
our pretty fw to the ugly and crippled Compal/Foxconn hardware.

So, what do others think?

Happy hacking,
Mychaela aka Space Falcon