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 _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
