AMR Implementation for Osmocom-BB
akibsayyed at gmail.com
Sat Oct 26 13:42:49 UTC 2013
Harald and Dieter Spaar
I guess you people have much more idea about TSM30 code.
my question is does tsm30 support AMR operation
On Sat, Oct 26, 2013 at 9:58 AM, Michael Spacefalcon <
msokolov at ivan.harhan.org> wrote:
> Akib Sayyed <akibsayyed at gmail.com> wrote:
> > I am using TSM30 code for reference.
> I assume you meant "I am using the TSM30 source as a reference for
> what the ARM part of the Calypso should do" - which still doesn't
> answer my question as to what you are doing as far as code running in
> the Calypso DSP.
> The TSM30 source targets a very old version of the Calypso chip (C05
> rev A) that has DSP code version 33 in its ROM. The PD751992A version
> of the Calypso that appears in the phones supported by OsmocomBB (at
> least in the Openmoko and Pirelli ones, dunno about Compal as I don't
> have any of the latter) seems to have DSP code version 36 in its ROM;
> I say so based on this line in the osmocon/layer1 console output from
> my Pirelli DP-L10:
> DSP API Version: 0x3606 0x0000
> The version of Layer1 code included in the TSM30 source contains
> support for DSP versions up to 35, but not 36. Supposedly versions 34
> and 35 (original Calypso C035 and Calypso+, respectively) can do AMR,
> although probably with some patches required, but DSP 33 can't do AMR
> at all, from what I understand. So it appears to me that the TSM30
> source as a whole does not support the AMR codec (at least for calls;
> there seems to be some support for AMR voice memos implemented in the
> TSM30's separate TMS320DA250 processor), hence whatever AMR support
> may be present in various individual components (bits of code which
> Purple Labs got from TI) is likely to be incomplete or buggy or not
> properly integrated etc.
> FWIW, the TSM30 source includes DSP patches that are meant to be
> applied atop DSP ROM versions 33, 34 and 35. But I doubt that any of
> these patch versions would apply atop DSP ROM 36 in a working manner.
> But the new Sotovik firmware semi-src (see my previous post) does
> target the right version of the Calypso/Iota/Rita chipset (same as in
> my Pirelli DP-L10 and Openmoko GTA02), and it is built for DSP version
> 36 - so it makes a much better reference version than TSM30. And it
> does contain DSP patch files with "36_10" in the filenames. It is
> unfortunate that this properly-matching version is not full-src like
> TSM30, but only a semi-src, i.e., many of the important modules are in
> object form only. But they are linkable/relocatable objects with full
> symbolic info, so examining them with objdump (again, see my previous
> post for the Binutils patch to support TI's variant of COFF) yields
> quite a bit of useful insight.
> This Sotovik firmware compiles into a functioning image, and with a
> little bit of work I was able to get it to run on my Om GTA02:
> I was able to get this fw to work on the GTA02 keeping all of the
> object blobs as they are because the GTA02 happens to use the same
> TSPACT signal arrangement for its tri-band RFFE as the Russian cell
> modem for which we got the fw semi-src, which is in turn based on TI's
> Leonardo+ quad-band reference design with minimal changes. My next
> step is to get this code to run on my Pirelli DP-L10 - it's also
> tri-band, but the TSPACT signal arrangement is gratuitously different.
> Thus before I can get the code to run on my Pirelli, I need to replace
> the object blobs with something that I can compile conditionally for
> CONFIG_TARGET_GTAMODEM vs. CONFIG_TARGET_PIRELLI. I am working on
> that in my FreeCalypso project, but I'm currently pretty far from
> approaching L1 - still working on the lower BSP layers.
> If you want to get to the bottom of the AMR support mystery, my
> recommendation would be to start with this known-working version which
> targets our hardware (either do it on an Openmoko phone, or wait for
> me to de-blob the code to make it work on the Pirelli too, or beat me
> to it) - I am reasonably sure that this version has working AMR - and
> then experiment from there. It appears that the code as it stands
> (i.e., the current set of object blobs) applies a whole bunch of
> different patches to the DSP code. You could try omitting these
> patches and testing if AMR still works or if it breaks. (Or perhaps
> some other things will stop working without the patches - you'll get
> to find out!) If AMR works with the original full set of patches but
> doesn't work when no patches are applied, you can then bisect to
> determine which of the several patches is the critical one...
akibsayyed at gmail.com
akibsayyed at matrixshell.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel