FC firmware progress

[Spacefalcon the Outlaw]

Das Signal <das.signal at freecalypso.org> wrote:

> As always you are the bringer of great news :) It's awesome that you
> got SMS working, this is a very good sign!

Yes, we now have some reassurance that our reconstruction of Calypso
GSM fw from the LoCosto source is at least somewhat viable.

> I haven't made much progress
> myself, but I'm going to follow your excellent suggestion of looking
> at the traffic on the network side, both with leo2moko-debug and gsm-fw,
> in the case of MO and MT phone calls

Does your test network setup allow you to select which GSM voice codec
should be used?  Can you test both AMR and the old-fashioned FR/EFR?

I am strongly leaning toward the hypothesis that the current voice
call failures in our gsm-fw are related to the AMR voice codec and the
lack of DSP patches.  After studying the l1_dyn_dwl sources in the
LoCosto version and comparing them against a disassembly of the
corresponding TCS211 binary objects, I figured out exactly what
patches are being dynamically downloaded by our TCS211/leo2moko
reference version and when:

* When L1 receives an MPHC_IMMED_ASSIGN_REQ primitive from whichever
  upper layer (must be either ALR or RR) commands it upon receiving an
  immediate assignment in response to RACH, the l1_dyn_dwl code
  downloads the patch contained in amr_sch_patch_file36_10.obj to the
  DSP.  The regular processing of MPHC_IMMED_ASSIGN_REQ in L1A appears
  to be paused until the download completes successfully.  (I said
  "appears to be" in the last sentence because the code in question is
  not present in the LoCosto source, and will have to be reconstructed
  from disassembly of the TCS211 version of l1_async.obj - ouch...)

* When L1 exits from dedicated mode and an L1C_STOP_DEDICATED_DONE
  message comes through L1A's queue, the AMR_SCH patch gets uninstalled
  and the GPRS patch gets loaded instead.

* The other two patches for Melody E2 and for AMR_MMS (recording and
  playback of voice memos in AMR format) are loaded when those
  respective features are exercised.  Neither feature has been
  reintegrated in FC gsm-fw yet, nor have I exercised either of them
  in leo2moko.

It appears that the DSP ROM code in our familiar Calypso silicon has a
defect in its implementation of the AMR codec such that operation on a
traffic channel with AMR enabled is not possible unless a DSP code
patch is applied - from what I understand, the OsmocomBB folks came to
the same conclusion, and to the best of my understanding, their
current solution is to run with AMR disabled altogether.  But TI's
code which we are using does NOT disable AMR, it is designed to run
with AMR enabled and with the expectation that the DSP bug is fixed in
one way or another.

It also appears that the bug was fixed properly in the DSP mask ROM in
later silicon (definitely in LoCosto and possibly in Calypso+), but
with our classic Calypso C035 (CHIPSET 10, DSP 36) the fix requires a
downloaded patch of one kind or another.  And in our TCS211 reference
version this patch happens to be of the dynamic kind.

The general mechanism for applying DSP patches dynamically is still
present in the LoCosto version for which we have the full source
(there it is used for downloading MP3 and AAC player code into LoCosto's
DSP), and this general mechanism appears to be the same as in TCS211,
but the specific logic for downloading the AMR_SCH patch when going
into dedicated mode on IMM ASS and then replacing it with the GPRS
patch when leaving dedicated mode is no longer visible anywhere in the
LoCosto source we have.  Perhaps it was implemented as a side branch
and not on the trunk, or perhaps it was so ugly that they were eager
to remove the hack as soon as they got the proper fix into newer
silicon - who knows.

It looks like we have 3 options for making voice calls work with
gcc-built firmware that doesn't include the binary libs from TCS211
verbatim:

1. Painstakingly reconstruct what TCS211 does: lift the general
   l1_dyn_dwl code from the LoCosto version, retrofit it back to the
   TCS211 configuration, and reconstruct the parts that got lost from
   disassembly.  Advantage: we'll replicate what TCS211 does.
   Disadvantage: the hack is quite ugly in purely objective terms, and
   because there are parts which we'll have to reconstruct from
   disassembly, there is always a chance that we'll miss something and
   will continue to have mysterious bugs further down the road.

2. It is very likely that the dynamic AMR_SCH patch featured in our
   version of TCS211 is not the only fix that was ever produced for
   the AMR DSP bug in the Calypso.  I consider it very likely that the
   fix had been implemented earlier as a simple static patch, and it
   seems to me that the whole idea of dynamically downloaded patches
   was invented much later, perhaps to support fancy audio festures
   like Melody E2 and AMR voice memos.

   We might be able to find a static DSP patch that matches our Calypso
   silicon and implements the fix for the AMR bug - such a patch may
   be contained in Compal's fw, for example.  (Pirelli's fw seems to
   work the same way as our TCS211 ref, judging from the trace output.)
   If we adopt a static patch from such a source, we'll eliminate the
   complexity and ugliness of dynamic patch downloading - a simple
   static patch is the next cleanest fix after fixing the silicon
   itself. :)

   But there would also be disadvantages: if we adopt a purely static
   patch, we will most likely forever give up those Melody E2 and AMR
   voice memo features (they are implemented as dynamic DSP patches in
   our TCS211 reference, and are most likely missing altogether in
   Compal's and Pirelli's fw versions).  I have yet to play with them
   in TCS211 and thus don't know as of yet if they are any good, but
   still, I have loss aversion.  And perhaps more practically, if we
   lift the DSP patch code out of some fw version for which we have no
   source, no semi-src, no header files, nothing like we have for
   TCS211, we'll be gambling that there isn't some special code needed
   on the ARM7 side to go along with that particular DSP patch...

3. We could disable AMR altogether like OsmocomBB does.  But TI's code
   has been working with AMR enabled for so long that I suspect the
   sans-AMR configuration may be bitrotten - I'm not even sure off the
   top of my head how to build a config with AMR explicitly disabled,
   and it would take some research to figure it out.  (Disabling AMR
   in L1 proper may be as simple as changing #define AMR 1 to
   #define AMR 0, but things may break, and I don't know how it may
   need to coordinated with the upper layers.  I presume it is some
   upper layer that tells the network which codecs are supported by
   the MS, and I don't know where these bits are set in our code.)
   And of course we'll have the bad feeling of giving up a feature.

I am leaning toward option 1 above, but while I pursue it (it may take
me a while, as it seems like a lot of work), it would be nice if you
(DS) could do a test: configure your test network to use the older FR
codec instead of AMR, and see if voice calls magically start working
in gsm-fw when AMR is out of the picture.

Meanwhile, I'll do a couple of experiments on my side:

1. I'll look and see if I can find the bit that tells the network
   whether the MS supports AMR or not, and try setting that bit to
   "no AMR support" without changing anything else - and see if the
   MO/MT voice call behaviour with gsm-fw on Operator 310260 changes
   at all or not.

2. I'll try building a test version of leo2moko with the dynamic patch
   downloading mechanism knocked out (patch a BX LR instruction at the
   beginning of $l1a_dyn_dsp_dwnld_process) and see if it starts
   behaving like our entroubled gsm-fw does.

Happy hacking,
SF