Hello community, I was able to make some progress with our FreeCalypso firmware over the past few days. First off, I found and fixed the bug that was causing GPF memory allocation errors when one attempts to dial a MO call. It was a matter of GPF partition memory configuration. In TI's original TCS211 firmware there were two separate GPF configurations for the GSM+GPRS and GSM-only fw configs (gprscomp.c vs. gsmcomp.c), and the GSM-only configuration (gsmcomp.c) is further conditionalized on whether or not FAX_AND_DATA features are enabled. Our current FreeCalypso configuration is the absolutely minimal voice-only one; we have to start with this bare minimal config and then later re-add CSD, fax and GPRS. But the voice-only config we got from TI in TCS211 gsmcomp.c had a very tightly squeezed partition memory configuration, and it turned out that TI squeezed it down a little too tight.
In all TI-supplied configurations except voice-only (i.e., both GPRS and GSM-only with FAX_AND_DATA enabled) the largest PRIM pool partition size is 1600 bytes, but in the voice-only config TI had it set to 900 bytes instead. Well, as it turns out, the implementation of %CPI (call progress indication) in TI's ACI (both the trusty TCS211 version and the one from TCS3.2 we are using in FC) does an ACI_MALLOC of 1012 bytes. 1012 > 900, ergo blow up. I don't know whether TI considered this behavior to be a bug or a feature: it occurs only when AT command strings are used (as opposed to ACI calls from compiled-in UI code), and it appears that TI did not "officially support" using AT command strings on super-stripped-down firmwares in the voice-only configuration. But the needs of our FC project are different, we do want to be able to exercise a voice+SMS- only modem via AT commands when we have neither the UI nor CSD nor GPRS code integrated yet, so I fixed the problem by bumping the voice-only GPF partition memory config to be a little closer to its FAX_AND_DATA-enabled sibling. With this fix the current status of our FC firmware is as follows: * The deep sleep problem is still there, or at least I assume it is - I haven't done anything that could possibly fix it. * If one disables deep sleep with AT%SLEEP=2, the firmware can successfully connect to a live commercial GSM network, or at least to Operator 310260 in my case: do AT+CFUN=1 followed by AT+COPS. This part has been working quite reliably for me. * Once connected to the network, it stays registered solidly w/o glitches as long as deep sleep is disabled. * SMS works! I can send SMS from our experimental fw with AT+CMGS, and if an incoming SMS arrives while we are registered with the network running our fw, it will get saved to the SIM or diverted directly to the AT command channel depending on AT+CNMI setting. * SIM access works: I can read my phonebook entries and stored SMS. * Voice calls don't work yet. I never succeeded in dialing a MO call, and it's hard to tell at which point it fails, but one can get a little more insight with MT calls. On one occasion I actually got a couple of MT calls to work in that I dialed a call to the number of my test SIM in the Freerunner running our gsm-fw, RING indications appeared along with %CPI indications showing the number from which I was calling, and when I gave it an ATA (answer) command, the calling phone showed the call as fully connected. The call remained connected until hung up from either side. I couldn't test if the voice path worked because the calling and called phones were right next to each other. I haven't been able to reproduce that level of success reliably, though: right now when I test an MT call, the device running gsm-fw gets the paging, responds with RACH, gets an immediate assignment and I see a %CPI indication with the calling number in it, but then something goes bonkers. * Occasionally something goes bonkers at the L1-DSP interface, it seems. When this behavior occurs, there are "> DSP" and "> COM" error traces from L1 (look in the source to see what they mean), and then the trace output starts to pour garbage like "IQ LOW" - and it never seems to recover afterward. So far I have seen this behavior when attempting a voice call (either MO or MT), but not every time. Given these errors that seem to involve the L1-DSP interface, I wonder if our current inability to connect a voice call without falling over may have something to do with FreeCalypso currently running without any DSP patches. As you probably know, the DSP part of the Calypso (not the ARM7 part where firmwares run) has most of its code in mask ROM (hard-cast in the silicon itself), but it can be extended with downloadable patches at run time. All production firmwares that I know of run with some patches applied, but FreeCalypso currently runs over the unpatched DSP ROM. I knew from even before our FC project started that running with an unpatched DSP is possible at least at a basic level (that's what OsmocomBB does too), but obviously there has to be some reason why all known production firmwares do apply some DSP patches - hence I reason that the lack of these patches may be at least partially responsible for the instability we are seeing, especially given that the ARM-side code we are running was most definitely written with the assumption that the associated DSP patches will be there - unlike OsmocomBB. The good working TCS211 firmware (mokoN/leo2moko) that serves as our reference is no exception in that it also applies some DSP patches. However, it is pretty complicated: whereas earlier firmwares (TSM30 era, and apparently also the one from Compal for which we found a map file) had just one single DSP patch that is loaded upon boot (lifting such a single patch out of a binary fw version and plopping it into FC would be trivial), our TCS211 reference version implements dynamic downloading of DSP patches: there are multiple DSP patch images embedded into the fw, and they are downloaded dynamically on demand! It seems as complicated as it sounds, I have yet to take a proper close look at that code, so all I have for now is speculation based on a very cursory glance. But the good news is that the version of L1 in the LoCosto source appears to implement the same kind of dynamic downloading of DSP patches, so I'm hoping that we can recreate what our blob-laden TCS211 reference does with the sources we have available. My plan is to study the DSP patch dynamic download code in the LoCosto L1 source, figure out how to backport it to Calypso, integrate it into our FC GSM fw, and lift the actual DSP patch codes out of TCS211 COFF objects. Something to work on later. Of course there is no guarantee that applying these DSP patches will cause our current problems to go away, but because I feel that we need to be up to par with TCS211 on all counts, we need to integrate those dynamic DSP patches anyway, so it seems reasonable to me to do that integration and then see if it fixes the current issues or not. And finally, the most recent development: our gsm-fw now runs as summarized above on both gtamodem and pirelli targets! To build for the pirelli target, one needs to omit feature at-modem, leaving only feature at-rvtmux, so AT commands given over rvinterf with fc-shell are the only way to control our pseudo-modem fw on this target. Omitting feature at-modem causes the "fax & data" UART driver (the piece which is inapplicable to targets other than gtamodem) to be omitted, but the UART protocol stack entity is still there, attached by the code in serialswitch.c to a dummy UART driver, doing nothing but wasting code space. A to-do list item is to rework the code so that this dead piece will be omitted when building without feature at-modem. (The interface provided with feature at-rvtmux is much leaner inside the fw, just a tiny piece of code added to ACI.) With feature at-modem omitted, getting our gsm-fw to run on the Pirelli DP-L10 was a matter of teaching it how to control Pirelli's RFFE wiring (tpudrv12.[ch]) and how to read Pirelli's factory calibration and IMEI records, and then just shaking a few bugs out. Right now it works exactly the same on target pirelli as on target gtamodem. Don't put your Freerunners away yet - whenever one needs to compare the operation of our fw against the TCS211 reference, the latter runs only on the GTA01/02 modem - but when it works, the Pirelli is a much more convenient target: for one, experimental fw images can be loaded with fc-xram instead of flashing. I'll probably use it as a platform for testing the upcoming dynamic DSP patching integration. Happy hacking, SF P.S. I hope everyone had a great leap second. I missed it myself - I was at Walmart with my partner shopping for some new dresses when it happened. _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
