This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Akib Sayyed akibsayyed at gmail.comHarald 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: > > http://lists.openmoko.org/pipermail/community/2013-October/069010.html > > 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... > > VLR, > SF > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20131026/69fd172a/attachment.htm>