FC firmware progress

[Spacefalcon the Outlaw]

Hello community,

I was able to make some progress with our FreeCalypso firmware over
the past few days.  First off, I found and fixed the bug that was
causing GPF memory allocation errors when one attempts to dial a MO
call.  It was a matter of GPF partition memory configuration.  In TI's
original TCS211 firmware there were two separate GPF configurations
for the GSM+GPRS and GSM-only fw configs (gprscomp.c vs. gsmcomp.c),
and the GSM-only configuration (gsmcomp.c) is further conditionalized
on whether or not FAX_AND_DATA features are enabled.  Our current
FreeCalypso configuration is the absolutely minimal voice-only one; we
have to start with this bare minimal config and then later re-add CSD,
fax and GPRS.  But the voice-only config we got from TI in TCS211
gsmcomp.c had a very tightly squeezed partition memory configuration,
and it turned out that TI squeezed it down a little too tight.

In all TI-supplied configurations except voice-only (i.e., both GPRS
and GSM-only with FAX_AND_DATA enabled) the largest PRIM pool partition
size is 1600 bytes, but in the voice-only config TI had it set to 900
bytes instead.  Well, as it turns out, the implementation of %CPI (call
progress indication) in TI's ACI (both the trusty TCS211 version and
the one from TCS3.2 we are using in FC) does an ACI_MALLOC of 1012
bytes.  1012 > 900, ergo blow up.

I don't know whether TI considered this behavior to be a bug or a
feature: it occurs only when AT command strings are used (as opposed
to ACI calls from compiled-in UI code), and it appears that TI did not
"officially support" using AT command strings on super-stripped-down
firmwares in the voice-only configuration.  But the needs of our FC
project are different, we do want to be able to exercise a voice+SMS-
only modem via AT commands when we have neither the UI nor CSD nor
GPRS code integrated yet, so I fixed the problem by bumping the
voice-only GPF partition memory config to be a little closer to its
FAX_AND_DATA-enabled sibling.

With this fix the current status of our FC firmware is as follows:

* The deep sleep problem is still there, or at least I assume it is -
  I haven't done anything that could possibly fix it.

* If one disables deep sleep with AT%SLEEP=2, the firmware can
  successfully connect to a live commercial GSM network, or at least
  to Operator 310260 in my case: do AT+CFUN=1 followed by AT+COPS.
  This part has been working quite reliably for me.

* Once connected to the network, it stays registered solidly w/o
  glitches as long as deep sleep is disabled.

* SMS works!  I can send SMS from our experimental fw with AT+CMGS,
  and if an incoming SMS arrives while we are registered with the
  network running our fw, it will get saved to the SIM or diverted
  directly to the AT command channel depending on AT+CNMI setting.

* SIM access works: I can read my phonebook entries and stored SMS.

* Voice calls don't work yet.  I never succeeded in dialing a MO call,
  and it's hard to tell at which point it fails, but one can get a
  little more insight with MT calls.  On one occasion I actually got a
  couple of MT calls to work in that I dialed a call to the number of
  my test SIM in the Freerunner running our gsm-fw, RING indications
  appeared along with %CPI indications showing the number from which I
  was calling, and when I gave it an ATA (answer) command, the calling
  phone showed the call as fully connected.  The call remained
  connected until hung up from either side.  I couldn't test if the
  voice path worked because the calling and called phones were right
  next to each other.  I haven't been able to reproduce that level of
  success reliably, though: right now when I test an MT call, the
  device running gsm-fw gets the paging, responds with RACH, gets an
  immediate assignment and I see a %CPI indication with the calling
  number in it, but then something goes bonkers.

* Occasionally something goes bonkers at the L1-DSP interface, it
  seems.  When this behavior occurs, there are "> DSP" and "> COM"
  error traces from L1 (look in the source to see what they mean), and
  then the trace output starts to pour garbage like "IQ LOW" - and it
  never seems to recover afterward.  So far I have seen this behavior
  when attempting a voice call (either MO or MT), but not every time.

Given these errors that seem to involve the L1-DSP interface, I wonder
if our current inability to connect a voice call without falling over
may have something to do with FreeCalypso currently running without
any DSP patches.

As you probably know, the DSP part of the Calypso (not the ARM7 part
where firmwares run) has most of its code in mask ROM (hard-cast in
the silicon itself), but it can be extended with downloadable patches
at run time.  All production firmwares that I know of run with some
patches applied, but FreeCalypso currently runs over the unpatched DSP
ROM.  I knew from even before our FC project started that running with
an unpatched DSP is possible at least at a basic level (that's what
OsmocomBB does too), but obviously there has to be some reason why all
known production firmwares do apply some DSP patches - hence I reason
that the lack of these patches may be at least partially responsible
for the instability we are seeing, especially given that the ARM-side
code we are running was most definitely written with the assumption
that the associated DSP patches will be there - unlike OsmocomBB.

The good working TCS211 firmware (mokoN/leo2moko) that serves as our
reference is no exception in that it also applies some DSP patches.
However, it is pretty complicated: whereas earlier firmwares (TSM30
era, and apparently also the one from Compal for which we found a map
file) had just one single DSP patch that is loaded upon boot (lifting
such a single patch out of a binary fw version and plopping it into FC
would be trivial), our TCS211 reference version implements dynamic
downloading of DSP patches: there are multiple DSP patch images
embedded into the fw, and they are downloaded dynamically on demand!

It seems as complicated as it sounds, I have yet to take a proper
close look at that code, so all I have for now is speculation based on
a very cursory glance.  But the good news is that the version of L1 in
the LoCosto source appears to implement the same kind of dynamic
downloading of DSP patches, so I'm hoping that we can recreate what
our blob-laden TCS211 reference does with the sources we have available.
My plan is to study the DSP patch dynamic download code in the LoCosto
L1 source, figure out how to backport it to Calypso, integrate it into
our FC GSM fw, and lift the actual DSP patch codes out of TCS211 COFF
objects.  Something to work on later.  Of course there is no guarantee
that applying these DSP patches will cause our current problems to go
away, but because I feel that we need to be up to par with TCS211 on
all counts, we need to integrate those dynamic DSP patches anyway, so
it seems reasonable to me to do that integration and then see if it
fixes the current issues or not.

And finally, the most recent development: our gsm-fw now runs as
summarized above on both gtamodem and pirelli targets!  To build for
the pirelli target, one needs to omit feature at-modem, leaving only
feature at-rvtmux, so AT commands given over rvinterf with fc-shell
are the only way to control our pseudo-modem fw on this target.
Omitting feature at-modem causes the "fax & data" UART driver (the
piece which is inapplicable to targets other than gtamodem) to be
omitted, but the UART protocol stack entity is still there, attached
by the code in serialswitch.c to a dummy UART driver, doing nothing
but wasting code space.  A to-do list item is to rework the code so
that this dead piece will be omitted when building without feature
at-modem.  (The interface provided with feature at-rvtmux is much
leaner inside the fw, just a tiny piece of code added to ACI.)

With feature at-modem omitted, getting our gsm-fw to run on the
Pirelli DP-L10 was a matter of teaching it how to control Pirelli's
RFFE wiring (tpudrv12.[ch]) and how to read Pirelli's factory
calibration and IMEI records, and then just shaking a few bugs out.
Right now it works exactly the same on target pirelli as on target
gtamodem.  Don't put your Freerunners away yet - whenever one needs to
compare the operation of our fw against the TCS211 reference, the
latter runs only on the GTA01/02 modem - but when it works, the
Pirelli is a much more convenient target: for one, experimental fw
images can be loaded with fc-xram instead of flashing.  I'll probably
use it as a platform for testing the upcoming dynamic DSP patching
integration.

Happy hacking,
SF

P.S. I hope everyone had a great leap second.  I missed it myself - I
was at Walmart with my partner shopping for some new dresses when it
happened.