AMR Implementation for Osmocom-BB

Michael Spacefalcon msokolov at ivan.Harhan.ORG
Sun Oct 27 22:00:00 UTC 2013


Akib Sayyed <akibsayyed at gmail.com> wrote:

> I was checking code given by you and tsm30 phone. header files are same.

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.

> I just need to know what dsp patch needed.

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




More information about the baseband-devel mailing list