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