FreeCalypso sw/fw update

[Mychaela Falconia]

Hello FC community,

While we wait for our FCDEV3B baby (should be no more than two weeks
of waiting left according to what the assembly shop people told me), I
have done some work on the software side of FreeCalypso.  Here are the
new developments so far:

* The deblobbing of the full TCS211 L1 (as opposed to the subset of L1
  used in Citrine) is now complete except for the L1_GPRS-specific
  modules - all other L1 modules including l1audio and l1tm are now
  recompiled from C source.  This deblobbed L1 can be found in the
  tcs211-l1-reconst and fc-magnetite Hg repositories.

* All FC Magnetite build configurations that include FreeCalypso L1
  have been updated to rebuild everything except L1_GPRS modules from
  the reconstructed source.

* I've been doing a lot of work on the development host tools in the
  freecalypso-tools repository.  Our Test Mode Shell fc-tmsh now
  supports almost all of the Test Mode commands (both TM3 and ETM)
  provided by TCS211 fw, using the same command names and syntax as
  TI's own TMSH (of which I don't have a copy!) when sensible, and we
  now have fc-cal2text and tiaud-decomp utilities for "in vitro"
  decoding of the firmware's RF calibration and audio mode config
  files, respectively.

The one area which is currently lacking is documentation: all of these
mighty tools need to be documented, and this documentation is currently
lacking.  Writing at least some documentation is on my TODO list.  But
if you don't mind reading the source to figure things out, there is a
treasure trove of development and investigation capabilities waiting
for you to tap into it.

Once we get the FCDEV3B built and working, here are the things I would
like to do, in no particular order:

* Using the convenient access to both UARTs on the FCDEV3B, properly
  exercise the CSD and GPRS capabilities of our reference TCS211 fw,
  get a feel for them, and establish our baseline in this area.

* Using the same convenient access to both UARTs, develop a mechanism
  for dynamically switching the main MODEM UART between its regular AT
  command operation and RVTMUX.  The motivation is as follows: while
  serious development and debugging will always require both UARTs and
  all FC hardware should be designed to allow access to the second
  UART at least for developers, on many platforms it may be reasonable
  to have only one UART accessible in ordinary usage, with access to
  the second UART requiring a special cable or adapter.  Ordinary users
  aren't expected to do a whole lot with RVTMUX, but there are a few
  tasks (FFS edits like changing your IMEISV or fixing a misprogrammed
  rfcap file) which ordinary users should be able to do and which are
  best done through RVTMUX, hence my idea of allowing a dynamic switch
  to bring RVTMUX to the MODEM UART on a non-persistent basis.

* Put out a moko13 firmware release, based on Magnetite.  Relative to
  the current state of FC Magnetite, I would like to make just two
  changes prior to releasing moko13: add the RVTMUX dynamic switch
  described above, and implement a firmware version ID scheme.

* Once we have a platform (FCDEV3B) that both runs TCS211/Magnetite
  and has MCSI brought out (the pre-existing hw options satisfy one or
  the other, but not both), try out the "Bluetooth headset" voice path
  configuration (GSM voice routing to MCSI) and see if and how it
  works.  Turning this mode on should now be as simple as sending an
  auw 0 2 command through fc-tmsh; I tried it on the GTA02 and the
  command executes without crashing the fw, but further testing
  requires the FCDEV3B and an oscilloscope probe on the MCSI pins.

* The firmware we've got from TI includes a rich repertoire of
  L1/DSP-based audio services: supposedly it can play polyphonic
  melodies through the DSP, record and play back voice memos in both
  06.10 and AMR formats, and even do speech recognition against
  pre-recorded samples in the user's own voice.  I say supposedly
  because these functions have never been tested: we know the code is
  there because I just went through the trouble of deblobbing it, but
  whether it works or not is another question.  I don't know what is
  more peculiar: the fact that this code is included in the sans-UI
  modem builds (like all of mokoN, for example) despite there being no
  way to invoke it, or the fact that none of the historical commercial
  Calypso-based dumbphones I've seen seem to make use of any of these
  features.  In any case, I would like to exercise these functions by
  adding some debug AT commands that invoke them, but I want to do it
  on a platform where I don't have to hold the device up to my ear
  with cables connected from both sides, like one has to do when using
  a FreeRunner as a poor man's substitute for a proper GSM development
  board.

* We are still using the all-blobs TCS211 version of the G23M protocol
  stack; in order to progress toward our desired blob-free state, we
  need to switch to the TCS2/TCS3 hybrid configuration (the one with
  G23M taken from LoCosto source) at some point.  Once we have the
  FCDEV3B and have done all or most of the above, it will be a good
  time to tackle the hybrid modem firmware config.

* Deblobbing L1_GPRS is the lowest priority: we need to switch to
  blob-free G23M (which includes GPRS) by polishing the TCS2/TCS3
  hybrid config before it will make any sense to tackle L1_GPRS.

This is all from me for now; back to waiting for the FCDEV3B assembly.

Hasta la Victoria, Siempre,
Mychaela aka The Mother