Akib Sayyed &lt;akibsayyed(a)gmail.com&gt; wrote: Well, they aren't exactly the same, just very similar-looking. I have not yet studied the diffs in detail. Yet is the operative word in the previous sentence: as I've said before, my goal is to produce a code version that works exactly like this Sotovik semi-src works on my Neo Freerunner, but have it also work on my Pirelli DP-L10, and replace the binary-only libs with reconstructed source pieces so I can make changes like porting to the Pirelli and build with gcc. When it comes to Layer1, in order to de-blob that part of our Leonardo semi-src, I will need to lift L1 C files from either the TSM30 source or the LoCosto one (probably some pieces from each), and then massage them until they compile into code that matches what's in the current binary objects. At that point I will need to become an expert on the differences in the L1 code/headers between the different (semi-)source leaks we are working with - but I am not at that point yet, I am still working on reintegrating the lower layers of TI's software stack like the BSP (aka "drivers", not DSP) initialization and the serial trace mechanism. Well, see, I don't know the answer to that question myself yet! But your osmocon/layer1 output is telling me that the Calypso Lite chip in your Compal phone has the same DSP ROM version (i.e., version 36) as the 751992A in the Openmoko and the Pirelli, so whatever works for me in that department should work for you as well. In fact, I find it strange that any patches are needed at all for DSP ROM version 36. The description of various DSP versions in TI's XML configuration voodoo file g23m/system/busyb/unbusy_configset.xml (inside the semi-src from Sotovik) reads: <propertySet name="DSP" description="DSP code selection" shortName="SYS"> <valueDef value="1" valname="_fr" description="GSM 1.0: Full Rate" /> <valueDef value="2" valname="_fh" description="GSM 1.0: Full and Half Rate" /> <valueDef value="3" valname="_fe" description="GSM 1.0: Full and Enhanced Full Rate" /> <valueDef value="4" valname="_ac" description="GSM 1.0: All 3 Vocoder and Echo Cancellation" /> <valueDef value="6" valname="_al" description="GSM 1.0: All 3 Vocoder" /> <valueDef value="7" valname="_ad" description="GSM 1.0: All 3 Vocoder + Fax and Data" /> <valueDef value="9" valname="_2d" description="GSM 1.0: Full and Enhanced Full Rate plus Fax and Data" /> <valueDef value="16" valname="_16" description="GSM 1.5: All 3 Vocoder + Fax and Data - Vega+Omega - Ulysse rev B" /> <valueDef value="17" valname="_17" description="GSM 1.5: All 3 Vocoder + Fax and Data - Vega+Omega - Ulysse rev A" /> <valueDef value="30" valname="_30" description="GSM 1.5: All 3 Vocoder + CHED GPRS + Scheduler GPRS" /> <valueDef value="31" valname="_31" description="FIXME:???" /> <valueDef value="32" valname="_32" description="FIXME:???" /> <valueDef value="33" valname="_33" description="GPRS 1.5: All 3 Vocoder + CHED GPRS + Scheduler GPRS - Calypso" /> <valueDef value="34" valname="_34" description="GPRS 1.5: All 3 Vocoder + AMR + CHED GPRS + Scheduler GPRS - Calypso C035" /> <valueDef value="35" valname="_35" description="FIXME:???" /> <valueDef value="36" valname="_36" description="FR/HR/EFR/AMR, AEC, GPRS, SAM/CAL/CAL+ , OMEGA/IOTA/SYREN, Rework DSP34 (AMR, MELODY E2)" /> </propertySet> So we see that GPRS first appeared in DSP version 30 (on some unknown DBB chip before Calypso - maybe Samson?), then the early Calypso C05 chips had 33 in them (that's what the TSM30 apparently used - a very early Calypso C05 rev A chip), then early Calypso C035 chips came out with DSP version 34. The comments in l1_confg.h describe DSP 34 as the first version with AMR. There are no informative comments for DSP version 35, but I'm guessing that it was probably the version released with the first Calypso+ chips. But then look at the description for DSP version 36 quoted above: it is explicitly described as supporting AMR in addition to the "regular" voice codecs, 3 different DBB chips (Samson, Calypso and Calypso+), and 3 different ABB chips: Omega, Iota and Syren. So I'm guessing that the later fab runs of both Calypso C035 (what we have in our current OsmocomBB-supported phones) and Calypso+ (that's the one with the evil "secure" bootloader) were made with DSP code 36 instead of 34 or 35. And this DSP version 36 is described as a "rework" of DSP 34, whatever that means, with AMR and Melody E2 being mentioned explicitly. Does "rework" mean bugfixes? Thus it sounds from the description that DSP 36 is supposed to have all of the bugs already fixed in it so that AMR ought to work out of the box. Yet the TCS211/Leonardo code we've got from Sotovik does apply a whole bunch of patches to the DSP code, and these patches are definitely made specifically against DSP ROM code 36. And your observation on your C118 that the DSP sends out good uplink when configured for AMR, but puts out garbage on the voice downlink path also suggests that our DSP ROM 36 still has buggy AMR support in it. We will most likely find the correct answer when my FreeCalypso project advances to the point where I have a de-blobbed version of this newly found TCS211 code running on my Openmoko and Pirelli phones. Hopefully this de-blobbed version that applies all of the same DSP patches as the original will have AMR that "just works" - in that case we can then disable the patches one by one until we find the critical one whose presence or absence differentiates between AMR working or not. If you don't want to wait for me to get to that point, feel free to beat me to it. You can buy a Neo Freerunner from www.pulster.eu if you don't have one already, then flash my leo2moko port into it, and confirm that AMR works. Then you can try disabling some or all of the DSP patches (you should be able to do that with some minor surgery on the existing blobs, without going through the slow and painstaking de-blobbing/reconstruction process I'm doing for FreeCalypso) and thereby find out which DSP patch (if any) is required for AMR to work properly. Or you could try extracting all of the DSP patches from this TCS211 semi-src (see my first reply to you in this thread for the links to the extracted objects and the needed GNU Binutils patch), have your experimental OsmocomBB/AMR code apply all of them in the same order as the semi-closed firmware does (again, do a bit of disassembly with objdump to find what this correct order is), and see if the application of all of these patches makes AMR work for you. VLR, SF