FC firmware progress

[Spacefalcon the Outlaw]

I wrote a bit earlier:

: Meanwhile, I'll do a couple of experiments on my side:
:
: [...]
:
: 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.

I performed that experiment (checked into the tcs211-patches tree on
bitbucket), and here are my findings:

* When I knocked out l1a_dyn_dsp_dwnld_process() so that no dynamic
  patches were loaded, but kept the boot-time static DSP patch unchanged
  (yes, our TCS211 ref version has a traditional static DSP patch too
  in addition to the dynamic patch mechanism), the firmware was still
  able to dial MO and receive MT calls without going berzerk.  It is
  possible that the AMR_SCH patch (the dynamic one) is needed in order
  for the voice to pass through correctly (a while back someone on the
  OsmocomBB list tried to enable AMR without applying any DSP patches,
  and he said that the voice downlink was garbled), but voice audio
  testing on the FR is a royal pita for me, so I haven't tested it.

* When I knocked the static patch out as well (in leo2moko-debug), the
  fw started behaving like our entroubled one: SMS works, but as soon
  as I tried dialing an MO call, bam - L1 started reporting DSP errors,
  and the call never went through (the called phone never rang).

So it appears that the static patch is the most critical one at our
present stage of progress, and we need to get this static DSP patch
integrated and working before addressing the dynamic patching
mechanism.  I thought that getting this static DSP patch integrated
would be trivial, and indeed I got a version of gsm-fw built with this
static patch included.  But no joy: with this static DSP patch
included (the patch bits themselves have been extracted from the
TCS211 binary object), our gsm-fw behaves even worse than it did
before:

https://www.freecalypso.org/traces/fc-1st-dsp-patch-attempt.txt

As you can see, when I issued an AT+COPS command to connect to the
default network, it did the power measurement step (measuring Rx power
on every frequency channel in every supported band to find candidate
frequency channels that might be valid GSM ones) but then as soon as
L1 got the command to try syncing to the first candidate radio channel,
the DSP blew up.

But then there is another tell-tale sign of trouble in that log:

L1: TST_C 3 TCS_3.2.0_L1_6011_1 PLUS_N5x DSP:3606h DYN:6840h CHECKSUM:15c8h

The checksum reported here comes from the DSP itself, and it is wrong.
In every working TCS211/mokoN/leo2moko variant this CHECKSUM has always
been reported as d278h.  (In the absence of any DSP patches at all,
the reported checksum is a1cah, and it is consistent between our FC
gsm-fw and the test build of TCS211 with the static DSP patch knocked
out.)

So it looks like the patch is being downloaded incorrectly in the case
of our entroubled fw, and of course if a patch is downloaded incorrectly
and the checksum doesn't match the expected value, all bets are off
from that point onward.

I don't really know how to troubleshoot it further, and I am tired -
it is late hour here.  If DS or anyone else would like to poke at it,
get the current code from Mercurial, copy configs/gtamodem-gsm or
configs/pirelli-gsm to build.conf as desired, and then add a DWNLD=1
line in there somewhere.  (It can go anywhere in that Bourne shell
script fragment.)

Happy hacking,
SF