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