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