FreeCalypso update: progress with DSP patches and voice calls

[Mychaela Falconia]

So I got the l1_dyn_dwl code from LoCosto massaged into a form that
replicates what is found in the TCS211 binary blobs.  I did it in the
tcs211-l1-reconst tree, and the work in question has been pushed to
Bitbucket.  Results:

* TCS211 environment: I got a TCS211-based fw image built in which the
  l1_dyn_dwl part of L1 is compiled from the source I reconstructed,
  while the rest of L1 is original binary blobs.  Behavior: no difference
  from standard TCS211 that I could detect; voice calls work like they
  should.

* FreeCalypso gsm-fw environment: I got this reconstructed l1_dyn_dwl
  code integrated into our gsm-fw, and I got it to build with
  L1_DYN_DSP_DWNLD enabled.  Behavior: the expected trace output
  related to dynamic DSP download does NOT appear; attempting to dial
  a MO voice call caused the DSP to go berzerk with errors.

So the L1 code in our gcc-built GSM fw is still not where it needs to
be, and simple integration of l1_dyn_dwl code did not cure it. :-(
But to be honest, I wasn't actually expecting this l1_dyn_dwl integration
to fix things: as I wrote earlier, experiments with TCS211 where I
knocked parts of DSP patching logic out revealed that the Windows-built
TCS211 fw can still make voice calls successfully even when dynamic
DSP patch downloading has been disabled, hence it didn't seem like
this dynamic patch was the magic needed in order to get downlink audio
in the earpiece instead of noise we get with gsm-fw sans L1_DYN_DSP_DWNLD.

So where do we go from here?  I think it is time to backtrack a little
and deblob L1 in TCS211.  A general rule in scientific experiments is
to change only one variable at a time: if you change a whole bunch of
variables at once and you get totally different results, there is no
way to tell which change is responsible.

When it comes to our current gcc-built gsm-fw, it is really amazing
that it works as well as it does, meaning that it can connect to GSM
networks, maintain that connection solidly, send and receive SMS and
now connect voice calls, even though the audio is broken.  The fact
that this fw works as well as it does is nothing short of amazing,
considering how much of a wild hack it is:

* the L1 code was taken from a source targeting a *different chip*, a
  source that was not regression-tested on Calypso and is broken in
  several ways when it comes to older chipset support;

* different pieces of the full firmware suite have been mix-n-matched
  from several disparate source leaks from different times and
  different lines of development;

* we are building it with a totally different compiler and running it
  in a totally different environment than the one the code in question
  was written for.

But however spectacularly successful our wild hack has been, we now
seem to be running into some very difficult bugs that should be
generally expected with wild hacks of this kind.  Hence I think it is
time to take a step back and revisit L1 in a slower approach that
takes care to change only one variable at a time.

When we try to compare our current not-quite-working L1 in gsm-fw
against the solidly working TCS211 reference, it is not much of a
practical or actionable comparison, as too many variables are being
changed all at once: the L1 code in gsm-fw comes from a totally
different source and almost no effort was made to make it more
TCS211-like, we are building it with a totally different compiler in a
totally different environment, and we got a configuration change: in
TCS211 all extra bells and whistles are enabled (CSD, fax, GPRS, all
fancy audio features, calibration test modes), whereas in our gsm-fw
none of these extras have been integrated yet, hence they have to be
disabled.

So how can we tackle L1 in a way that would only change one variable
at a time?  I propose that we make a serious attempt at deblobbing L1
*within* the TCS211 environment, rather than outside of it.  That
means taking L1 code from the LoCosto source, one C module at a time,
and plopping these C modules into a TCS211 semi-src tree.  Tweak and
massage this "foreign" L1 code until it passes compilation and produces
object code that closely matches the original blobs.  And as we slowly
trudge through this process, one C module or a small group of modules
at a time, continually regression-test it: build TCS211-based fw images
in which the newly reconstructed L1 modules are linked together with
the original blobs for the rest of L1, and ensure that the fw keeps
working.  And if changing a given module from the original blob to
reconstructed source causes the fw to stop working, investigate that
specific module deeper.

If we can get a fully deblobbed version of L1 within the TCS211
environment (or at least a sans-GPRS subset) that works no worse than
the original TCS211, then we could re-port that reconstructed L1 to
our gsm-fw gcc environment, and see how it works then.  If there is
breakage, we would know it's the change of environment, and we would
focus our investigation there.

We shall see how it pans out.

Happy hacking,
Mychaela