From engr.shahzad786 at gmail.com Thu Oct 3 05:35:16 2013 From: engr.shahzad786 at gmail.com (Shahzad Ahmed) Date: Thu, 3 Oct 2013 05:35:16 +0000 (UTC) Subject: Make Errors References: <20110105171509.23559.qmail@stuge.se> Message-ID: I'm installing osmocombb on Ubuntu13.04, I've already set the path for arm-elf-gcc... but I try this command.. $ sudo make I get these errors... /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: Assembler messages: /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: Error: no such instruction: `eor %edx,%ecx,%ecx,ror' make[4]: *** [gsmtap_util.lo] Error 1 make[4]: Leaving directory `/home/shahzad/arm/osmocom-bb/src/shared/libosmocore/build-target/src' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/shahzad/arm/osmocom-bb/src/shared/libosmocore/build-target/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/shahzad/arm/osmocom-bb/src/shared/libosmocore/build-target' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/shahzad/arm/osmocom-bb/src/shared/libosmocore/build-target' make: *** [shared/libosmocore/build-target/src/.libs/libosmocore.a] Error 2 Can you guys help me to solve this problem...?? Thanks... From noloader at gmail.com Thu Oct 3 06:21:32 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 3 Oct 2013 02:21:32 -0400 Subject: Make Errors In-Reply-To: References: <20110105171509.23559.qmail@stuge.se> Message-ID: On Thu, Oct 3, 2013 at 1:35 AM, Shahzad Ahmed wrote: > I'm installing osmocombb on Ubuntu13.04, > I've already set the path for arm-elf-gcc... > > but I try this command.. > > $ sudo make Bike shedding: you usually don't want to build as root. Use `sudo` on install if needed. > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: > Assembler messages: > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: > Error: no such instruction: `eor %edx,%ecx,%ecx,ror' Looks like a path problem. Ensure the assembler (AS) for the target is on-path; and not the host's assembler. How are you setting your cross compile environment? Jeff From peter at stuge.se Thu Oct 3 09:02:53 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 3 Oct 2013 11:02:53 +0200 Subject: Make Errors In-Reply-To: References: <20110105171509.23559.qmail@stuge.se> Message-ID: <20131003090253.12622.qmail@stuge.se> Jeffrey Walton wrote: > > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: > > Assembler messages: > > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: > > Error: no such instruction: `eor %edx,%ecx,%ecx,ror' > Looks like a path problem. Ensure the assembler (AS) for the target is > on-path; and not the host's assembler. Read the error message and think about that one more time. The problem is not the assembler but the header file. The original poster isn't building against a cross-compiled libosmocore. //Peter From noloader at gmail.com Thu Oct 3 20:38:39 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 3 Oct 2013 16:38:39 -0400 Subject: Make Errors In-Reply-To: <20131003090253.12622.qmail@stuge.se> References: <20110105171509.23559.qmail@stuge.se> <20131003090253.12622.qmail@stuge.se> Message-ID: On Thu, Oct 3, 2013 at 5:02 AM, Peter Stuge wrote: > Jeffrey Walton wrote: >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: >> > Assembler messages: >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: >> > Error: no such instruction: `eor %edx,%ecx,%ecx,ror' >> Looks like a path problem. Ensure the assembler (AS) for the target is >> on-path; and not the host's assembler. > > Read the error message and think about that one more time. > > The problem is not the assembler but the header file. That's an assembler error message. It does not matter where the ASM came from. You'd can get a similar error for inline ASM on a native (non-cross compile) build. For example, using AVX's pclmulqdq instruction on an older intel assembler that did not understand pclmulqdq would produce a similar result. See, for example, https://groups.google.com/forum/#!topic/cryptopp-users/6tCoUzsvXcM: > The original poster isn't building against a cross-compiled libosmocore. Oh, my bad. So OP is building for x86/x86_64, but the header file only makes available ARM routine? If so, I would think the ARM ASM would be guarded in appropriate define. Jeff From peter at stuge.se Fri Oct 4 10:00:10 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 4 Oct 2013 12:00:10 +0200 Subject: Make Errors In-Reply-To: References: <20110105171509.23559.qmail@stuge.se> <20131003090253.12622.qmail@stuge.se> Message-ID: <20131004100010.23893.qmail@stuge.se> Jeffrey Walton wrote: > >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: > >> > Assembler messages: > >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: > >> > Error: no such instruction: `eor %edx,%ecx,%ecx,ror' > >> Looks like a path problem. Ensure the assembler (AS) for the target is > >> on-path; and not the host's assembler. > > > > Read the error message and think about that one more time. > > > > The problem is not the assembler but the header file. > > That's an assembler error message. Yes, that's right. > It does not matter where the ASM came from. It really does. > You'd can get a similar error for inline ASM on a native (non-cross > compile) build. You get that error if you have a mismatch between the assembly and the assembler. > > The original poster isn't building against a cross-compiled libosmocore. > > Oh, my bad. So OP is building for x86/x86_64, but the header file only > makes available ARM routine? No. As the error very clearly states the "eor" instruction is unknown. eor is a 64-bit x86 instruction, so clearly the header file is for x86_64, meaning that the assembler is for ARM. The way that can happen is, as I wrote above, that the poster isn't building against a cross-compiled libosmocore. > If so, I would think the ARM ASM would be guarded in appropriate define. I think it would be useful if you sent some patches to improve the osmocom-bb build system. Thank you! //Peter From 246tnt at gmail.com Fri Oct 4 11:06:01 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 4 Oct 2013 07:06:01 -0400 Subject: Make Errors In-Reply-To: <20131004100010.23893.qmail@stuge.se> References: <20110105171509.23559.qmail@stuge.se> <20131003090253.12622.qmail@stuge.se> <20131004100010.23893.qmail@stuge.se> Message-ID: >> >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h: >> >> > Assembler messages: >> >> > /home/shahzad/arm/osmocom-bb/src/target/firmware/include/asm/swab.h:32: >> >> > Error: no such instruction: `eor %edx,%ecx,%ecx,ror' Retry with a fresh checkout. Attempting to build without the ARM toolchain, then installing it, then retrying in the same directory doesn't work. There are some leftovers from the failed attempt and you need to start everything from scratch. Cheers, Sylvain From george_lopes at live.com Thu Oct 10 23:50:55 2013 From: george_lopes at live.com (Rave) Date: Thu, 10 Oct 2013 23:50:55 +0000 (UTC) Subject: Set fixed TMSI and Kc References: <4F7F4295.7010005@ymail.com> Message-ID: Simian Denson ymail.com> writes: > > Hi, > > in the osmocom bb mobile.cfg I don't see any posibility to set a fixed > Kc encryption key and the tmsi. > > How could I achieve that osmocom uses my defined Kc and tmsi? > > cheers, > Simian > > Hi, Can anyone please answer Simians question, How do you add KC to osmocom-bb mobile.cfg? Thank you Rave From zero-kelvin at gmx.de Thu Oct 24 21:42:00 2013 From: zero-kelvin at gmx.de (dexter) Date: Thu, 24 Oct 2013 23:42:00 +0200 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <20130605121428.GA10030@nataraja.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> Message-ID: <52699428.5020700@gmx.de> Hi All. It's time Again! This is the announcement for the next Osmocom Berlin meeting. Oct 30, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. I am looking forward to see you there! regards. Philipp From zero-kelvin at gmx.de Wed Oct 30 18:37:25 2013 From: zero-kelvin at gmx.de (dexter) Date: Wed, 30 Oct 2013 19:37:25 +0100 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <20130605121428.GA10030@nataraja.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> Message-ID: <527151E5.8050703@gmx.de> Hi All. Sorry, i might be some minits late today - i am on my way! regards. Philipp From craig_comstock at yahoo.com Wed Oct 2 04:12:57 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 1 Oct 2013 21:12:57 -0700 (PDT) Subject: bad crc when trying to flash application In-Reply-To: References: <20130930164454.GA18693@pocken.who.de> Message-ID: <1380687177.37919.YahooMailNeo@web121003.mail.ne1.yahoo.com> I was able to get most of this working on the C139 but can't get an app to start when I power the phone on after flash programming. I connect the phone via usb and do minicom --device /dev/ttyUSB0 with either short power press or a long one in minicom I get: ?A at ftmtoolerror and the screen turns white on the phone. I copied the loader.lds from compal_e88 and added to compal_e86 as well as the Makefile in firmware. Modified things to reflect the larger amount of flash (4mb instead of 2mb) even though this probably doesn't matter a whole lot. I then program the C139 like this: host/osmocon/osmoload memdump 0x000000 0x2000 compal_loader.bin host/osmocon/osmoload funlock 0x000000 0x10000 host/osmocon/osmoload ferase 0x000000 0x10000 host/osmocon/osmoload fprogram 0 0x000000 compal_loader.bin host/osmocon/osmoload fprogram 0 0x002000 target/firmware/board/compal_e86/hello_world.e86loader.bin I tried other apps like loader and rssi to the same effect. target/firmware/Makefile additions: ENV_e86loader_LDS=board/compal_e86/loader.lds ENV_e86loader_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirect.o ENV_e86flash_LDS=board/compal_e86/flash.lds ENV_e86flash_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirected.o board/compal/handlers.o target/firmware/board/compal_e86/loader.lds ??? /* 4 MBytes of external flash memory */ ??? FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x400000 ??? /* 256 kBytes of internal zero-waitstate sram */ ??? IRAM? (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 ??? /* 256 kBytes of external slow sram */ ??? ERAM? (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 I was able to grab the first three flash pages (I cleared three pages to make room for trying rssi fw) from another c140, reprogram them, and the phone starts fine with stock firmware again. I assume that a long power press causes a jump to 0x2000. Am I right? If that's not the case then I would suppose I would need to write a firmware which loads at 0x000000, injects the magic value at 0x83ce0 and then continues with code as normal. Thanks, Craig ________________________________ From: Sylvain Munaut <246tnt at gmail.com> To: Andreas Cc: baseband-devel Sent: Monday, September 30, 2013 1:03 PM Subject: Re: bad crc when trying to flash application > bad crc 9bf1 (not e0bc) at offset 0x00000000 > status 5242976, aborting Make sure to use the very latest git. A patch was very recently pushed wrt to this. Cheers, ? ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Wed Oct 2 16:28:54 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 2 Oct 2013 09:28:54 -0700 (PDT) Subject: problems flashing firmware to c139 In-Reply-To: <1380687177.37919.YahooMailNeo@web121003.mail.ne1.yahoo.com> References: <20130930164454.GA18693@pocken.who.de> <1380687177.37919.YahooMailNeo@web121003.mail.ne1.yahoo.com> Message-ID: <1380731334.35172.YahooMailNeo@web121004.mail.ne1.yahoo.com> I thought that having the debug cable plugged in might have affected things but it seems that is not the case. I also noticed something strange. When I plug in the battery the screen goes to white without me even pressing the power key. Could this be because the normal phone might jump to 0x2000 when the battery is plugged in? I know that a special screen is shown when the power supply is plugged in as well. Maybe the white screen is the first steps of LCD initialization and somehow things are going wrong after that. I will test the hello_world compalram/highram firmwares and ensure they work properly. Thanks, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Thu Oct 3 14:57:13 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 3 Oct 2013 07:57:13 -0700 (PDT) Subject: c139/c140 jtag anyone? Message-ID: <1380812233.84280.YahooMailNeo@web121001.mail.ne1.yahoo.com> I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway. Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment? From craig_comstock at yahoo.com Fri Oct 4 15:08:50 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 4 Oct 2013 08:08:50 -0700 (PDT) Subject: c139/c140 jtag anyone? In-Reply-To: <1380812233.84280.YahooMailNeo@web121001.mail.ne1.yahoo.com> References: <1380812233.84280.YahooMailNeo@web121001.mail.ne1.yahoo.com> Message-ID: <1380899330.47346.YahooMailNeo@web121004.mail.ne1.yahoo.com> I cracked open the shield on my C139 and didn't see the TPs I expected from the schematic. I thought maybe the angle of the photo on osmocom hid the TPs but it really didn't. I'll try my C115 instead since that is more clear and accessible. Flashing hello_world on my C115 seemed to fail in a similar fashion as it does on my C139 so maybe the same issue exists there. I was wrong too... it was TP16 not TP6, so I found TP16 but still haven't located TP8 on the C139 schematic. -Craig ________________________________ From: Craig Comstock To: "baseband-devel at lists.osmocom.org" Sent: Thursday, October 3, 2013 9:57 AM Subject: c139/c140 jtag anyone? I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway. Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment? From edachleger at yahoo.com Tue Oct 15 17:05:11 2013 From: edachleger at yahoo.com (Erich Dachleger) Date: Tue, 15 Oct 2013 18:05:11 +0100 (BST) Subject: l1ctl_tx_fbsb_req Message-ID: <1381856711.59555.YahooMailNeo@web171206.mail.ir2.yahoo.com> Hi list, Sometimes when I run ./mobile -i 127.0.0.1, after output as below -------excerpt---------------- <000b> gsm48_rr.c:2174 PAGING REQUEST 1 <000b> gsm48_rr.c:2132? TMSI ***** (not for us) <0001> gsm48_rr.c:2450 IMMEDIATE ASSIGNMENT: <0001> gsm48_rr.c:2462? (ta 30/16615m ra 0x7f chan_nr 0x0e MAIO 0 HSN 38 TS 6 SS 0 TSC 4) <0001> gsm48_rr.c:2478 Not for us, no request. <000b> gsm48_rr.c:2174 PAGING REQUEST 1 -----execerpt-end---------------------------------- I then want to launch ccch_scan, after calling the function l1ctl_tx_fbsb_req,with the from mobile obtained parameters, similar to what Bhaskar did here: http://lists.osmocom.org/pipermail/baseband-devel/2013-February/003799.html But how and from? where did Bhaskar call? l1ctl_tx_fbsb_req? function? Via netcat or socat to the osmocom-socket? Regards erich -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Tue Oct 15 18:18:14 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Tue, 15 Oct 2013 18:18:14 GMT Subject: Looking for Leonardo+ PCB layout Message-ID: <1310151818.AA20464@ivan.Harhan.ORG> As I wrote here two months ago, I am seeking to build my own totally free, end-user-usable Calypso-based quad-band GSM plain phone, as well as possibly a Calypso-based free GSM modem module for smartphone projects done by others, such as this: http://talk.maemo.org/showthread.php?p=1376708 I already have the Calypso etc chips in qty 100 sitting in my desk drawer - buying them on the Chinese surplus market turned out to be surprisingly easy, and they most definitely have quite a bit more of them available than the 100 I have bought. Making my GSM device(s) quad-band as in 850/900/1800/1900 MHz is an important part of my goal - contrast with the current OsmocomBB- supported devices, which are only dual-band or tri-band at best. My belief in the idea that our familiar Calypso/Iota/Rita chipset is capable of supporting the quad-band configuration stems from the existence of this TI reference design: ftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_RD122.pdf ftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf ftp://ftp.ifctf.org/pub/GSM/Calypso/M034F.pdf The first PDF is something I just found on 52rd.com 2 days ago: it has the Leonardo+ quad-band schematics plus a component placement drawing. The 2nd PDF is the schematic which we have had for 2y now (might be a very slightly different version, haven't visually diffed the two closely enough) and the last PDF is for the quad-band RF FEM they used, all from 52rd.com. What I am still missing is a copy of the PCB layout (in whatever format TI used for their reference designs all those years ago) corresponding to those schematics. I have not yet found that article in my trawls through 52rd.com - that's a search for a needle in a giant haystack. (We also have a Leonardo_rev05.dsn file, in the same directory as the ones listed above, but I assume it's the EDA source file for the schematic capture phase only, no layout.) I have already found a layout for a dual-band phone on an 8-layer PCB: ftp://ftp.ifctf.org/pub/GSM/PCB/unknown-phone-pcb1.zip and I can probably find a layout for a tri-band phone on an 8-layer PCB too, something like Pirelli DP-L10. In contrast, Leonardo+ is a very elegant quad-band design, and this TI doc says it's only a 6-layer PCB: ftp://ftp.ifctf.org/pub/GSM/Calypso/chipsets+refdesigns.pdf (see page 10) We also have this: http://scottn.us/downloads/peek/HW%20doc/I-Sample%20ref.%20design/Full%20package%20-%20I-sample%202.7/ I-sample is TI's LoCosto board, and it is quad-band. But LoCosto's built-in RF block has separate LNA inputs for 850 and 900 MHz unlike Rita, and I-sample uses a weird arrangement: the PA and the antenna switch are integrated into one, but the Rx SAW filters are discrete. So it isn't the same as Leonardo+. Thus I am putting out this loud call for anyone who may have found a copy of the Leonardo+ PCB layout somewhere on 52rd.com or some other site of a similar nature. If you have a copy of this PCB layout or know of a place where it can be downloaded, please speak up! By helping me obtain a copy of that PCB layout, you would be helping not only me, but also all those end users who would appreciate having a quad-band GSM plain phone (or a modem for Neo900 etc) that is fully documented and capable of running 100% free baseband firmware. TIA, SF From noloader at gmail.com Thu Oct 17 04:50:25 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 17 Oct 2013 00:50:25 -0400 Subject: OT: Repeater for Sprint Network Message-ID: Hi All, Please forgive me for the off-topic post. My cell service is so bad at the house I can't hold it in any longer. Does anyone have a recommendation for a repeater of the Sprint network? I'd like a low power omni for the house, and a directional back to the tower. (Or some step-by-step instructions for building one?) I'm less interested in a Femtocell because I have about an acre of land, and I'd like to get some coverage in the back yard too. For completeness, I have an iPhone and EVO 4G. So I would like 800 ESMR, 1900 PCS, and 2500 WiMax, if possible. Thanks in advance and sorry about wandering a bit. From zhangseuedu at sjtu.edu.cn Fri Oct 18 08:55:00 2013 From: zhangseuedu at sjtu.edu.cn (zhangseuedu) Date: Fri, 18 Oct 2013 01:55:00 -0700 (PDT) Subject: I have a problem when load the firmware Message-ID: <1382086500078-4026182.post@n3.nabble.com> Hi, all. I am a newer to the osmocomBB project. And i was trying to load the firmware to my C118 phone using CP210X converter. But after i input the command below: /.*/osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/PHONE_TYPE/FIRMWARE.compalram.bin*/ i can only get some reponse shown in the terminal like this: got 1 bytes from modem, data looks like: 40 @ got 1 bytes from modem, data looks like: f8 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: e0 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 20 got 1 bytes from modem, data looks like: 00 . It was pretty different from the instruction in the osmocomBB website as i did not get the below messages: Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=13404, hdr_len=4, dnload_len=13411 so, i was confused if i have something wrong? can anyone help me with this? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/I-have-a-problem-when-load-the-firmware-tp4026182.html Sent from the baseband-devel mailing list archive at Nabble.com. From manuel at elektret.de Fri Oct 18 17:49:19 2013 From: manuel at elektret.de (Manuel Bieling) Date: Fri, 18 Oct 2013 19:49:19 +0200 Subject: I have a problem when load the firmware In-Reply-To: <1382086500078-4026182.post@n3.nabble.com> References: <1382086500078-4026182.post@n3.nabble.com> Message-ID: <20131018174919.GA28731@localhost> On 2013.10.18 01:55:00 -0700, zhangseuedu wrote: > Hi, all. > I am a newer to the osmocomBB project. And i was trying to load the firmware > to my C118 phone using CP210X converter. But after i input the command > below: > /.*/osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/PHONE_TYPE/FIRMWARE.compalram.bin*/ > i can only get some reponse shown in the terminal like this: > got 1 bytes from modem, data looks like: 40 @ > got 1 bytes from modem, data looks like: f8 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: e0 . > got 1 bytes from modem, data looks like: 00 . > got 1 bytes from modem, data looks like: 20 > got 1 bytes from modem, data looks like: 00 . Looks nearly as expected. I suppose you turned the phone on and started osmocon after that or something... Please try the following first. Turn phone off, connect serial jack, start osmocon from command line. Watch the output and push the red power button on the phone. Maybe that helps. -- Best regards, Manuel From zhangseuedu at sjtu.edu.cn Sat Oct 19 08:17:21 2013 From: zhangseuedu at sjtu.edu.cn (zhangseuedu) Date: Sat, 19 Oct 2013 01:17:21 -0700 (PDT) Subject: I have a problem when load the firmware In-Reply-To: <20131018174919.GA28731@localhost> References: <1382086500078-4026182.post@n3.nabble.com> <20131018174919.GA28731@localhost> Message-ID: <1382170641012-4026184.post@n3.nabble.com> Thanks for your reply! I have followed the instructions in the website. And I have turned the phone off and started osmocom from the command line. And I pushed the red button after that but i can not see the output indicating that the phone is updating the firmware. What i see was just some data, i wonder whether it is the problem about the link from the PC to the phone? Bset regards! Wei -- View this message in context: http://baseband-devel.722152.n3.nabble.com/I-have-a-problem-when-load-the-firmware-tp4026182p4026184.html Sent from the baseband-devel mailing list archive at Nabble.com. From pge at ring0.de Tue Oct 22 10:14:47 2013 From: pge at ring0.de (Peter Gewald) Date: Tue, 22 Oct 2013 12:14:47 +0200 Subject: I have a problem when load the firmware In-Reply-To: <1382170641012-4026184.post@n3.nabble.com> References: <1382086500078-4026182.post@n3.nabble.com> <20131018174919.GA28731@localhost> <1382170641012-4026184.post@n3.nabble.com> Message-ID: <1382436887.17780.18.camel@shadow> Am Samstag, den 19.10.2013, 01:17 -0700 schrieb zhangseuedu: > And I pushed the red button > after that but i can not see the output indicating that the phone is > updating the firmware. I guess you have a self build seriel cable betweeen your phone and your serial adapter? Check the cables in the plug, maybe they are too close, so there could be a bypass. May also check rx/tx, there are some serial adapters that mixed up the description on the harware. Hope this is helpful. Best regards, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From zhangseuedu at sjtu.edu.cn Wed Oct 23 07:33:22 2013 From: zhangseuedu at sjtu.edu.cn (zhangseuedu) Date: Wed, 23 Oct 2013 00:33:22 -0700 (PDT) Subject: I have a problem when load the firmware In-Reply-To: <1382436887.17780.18.camel@shadow> References: <1382086500078-4026182.post@n3.nabble.com> <20131018174919.GA28731@localhost> <1382170641012-4026184.post@n3.nabble.com> <1382436887.17780.18.camel@shadow> Message-ID: <1382513602899-4026186.post@n3.nabble.com> Peter Gewald wrote > Am Samstag, den 19.10.2013, 01:17 -0700 schrieb zhangseuedu: >> And I pushed the red button >> after that but i can not see the output indicating that the phone is >> updating the firmware. > > I guess you have a self build seriel cable betweeen your phone and your > serial adapter? Check the cables in the plug, maybe they are too close, > so there could be a bypass. > > May also check rx/tx, there are some serial adapters that mixed up the > description on the harware. Hope this is helpful. > > Best regards, > Peter > > > > signature.asc (853 bytes) > <http://baseband-devel.722152.n3.nabble.com/attachment/4026185/0/signature.asc> Yes,the problem is that something was wrong with the cables in the plug. Now it works. Thanks a lot. Best regards, Wei -- View this message in context: http://baseband-devel.722152.n3.nabble.com/I-have-a-problem-when-load-the-firmware-tp4026182p4026186.html Sent from the baseband-devel mailing list archive at Nabble.com. From clovnrian at gmail.com Wed Oct 23 19:45:45 2013 From: clovnrian at gmail.com (clovnrian at gmail.com) Date: Wed, 23 Oct 2013 21:45:45 +0200 Subject: OsmocomBB without hardware phone Message-ID: <52682769.3090801@gmail.com> Hi, I am trying to modify osmocomBB to work without the phone as layer 1. My goal is that application will using socket to communicate with BTS (modified BTS which can send and receive message throught sockets). I analyzed the osmocomBB code and I found that I'll have to modify osmocon.c (host/osmocon/osmocon.c) file. This file is interface between serial communication and layer2. If I am right, I have to do this changes: 1. Delete functions handle the serial interface 2. Add new tool server to dnload structure 3. Creating new tool server for L1 interface (UNIX socket or IP socket with GSMTAP) 4. Add callback function for reading from layer2 socket and forward this messages to L1 socket interface. Simplified I have to listen and forward packets from BTS to layer2 socket and from L2 to L1. Do I think in right direction or I am wrong and it will need more modifications? Best regards, Miroslav Babjak -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Thu Oct 24 14:32:21 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Thu, 24 Oct 2013 20:02:21 +0530 Subject: AMR Implementation for Osmocom-BB Message-ID: Hello folks I am trying to implement AMR codec for osmocom-bb. I got assignment commend which is same as T_AMR_CONFIGURATION amr_param; amr_param.noise_suppression_bit=0; amr_param.initial_codec_mode_indicator=1; amr_param.initial_codec_mode=0; amr_param.active_codec_set=0x95; amr_param.threshold[0]=0x0a; amr_param.threshold[1]=0x10; amr_param.threshold[2]=0x18; amr_param.threshold[3]=0x24;------------just random value amr_param.hysteresis[0]=0x04; amr_param.hysteresis[1]=0x04; amr_param.hysteresis[2]=0x04; amr_param.hysteresis[3]=0x04;----------just copied value from rest config for hysteresis l1ddsp_load_amr_param( amr_param); Now when i make a call I here gliches or random noise. also after some time there is radio signal loss and call is dropped. I am not getting why this is happening. -- 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: From akibsayyed at gmail.com Thu Oct 24 14:32:21 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Thu, 24 Oct 2013 20:02:21 +0530 Subject: AMR Implementation for Osmocom-BB Message-ID: Hello folks I am trying to implement AMR codec for osmocom-bb. I got assignment commend which is same as T_AMR_CONFIGURATION amr_param; amr_param.noise_suppression_bit=0; amr_param.initial_codec_mode_indicator=1; amr_param.initial_codec_mode=0; amr_param.active_codec_set=0x95; amr_param.threshold[0]=0x0a; amr_param.threshold[1]=0x10; amr_param.threshold[2]=0x18; amr_param.threshold[3]=0x24;------------just random value amr_param.hysteresis[0]=0x04; amr_param.hysteresis[1]=0x04; amr_param.hysteresis[2]=0x04; amr_param.hysteresis[3]=0x04;----------just copied value from rest config for hysteresis l1ddsp_load_amr_param( amr_param); Now when i make a call I here gliches or random noise. also after some time there is radio signal loss and call is dropped. I am not getting why this is happening. -- 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: From akibsayyed at gmail.com Thu Oct 24 14:32:43 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Thu, 24 Oct 2013 20:02:43 +0530 Subject: AMR Implementation for Osmocom-BB In-Reply-To: References: Message-ID: btw Voice uplink works fine On Thu, Oct 24, 2013 at 8:02 PM, Akib Sayyed wrote: > Hello folks > > I am trying to implement AMR codec for osmocom-bb. I got assignment > commend which is same as > > T_AMR_CONFIGURATION amr_param; > amr_param.noise_suppression_bit=0; > amr_param.initial_codec_mode_indicator=1; > amr_param.initial_codec_mode=0; > amr_param.active_codec_set=0x95; > amr_param.threshold[0]=0x0a; > amr_param.threshold[1]=0x10; > amr_param.threshold[2]=0x18; > amr_param.threshold[3]=0x24;------------just random value > amr_param.hysteresis[0]=0x04; > amr_param.hysteresis[1]=0x04; > amr_param.hysteresis[2]=0x04; > amr_param.hysteresis[3]=0x04;----------just copied value from rest > config for hysteresis > l1ddsp_load_amr_param( amr_param); > > > > Now when i make a call I here gliches or random noise. also after some > time there is radio signal loss and call is dropped. > > > I am not getting why this is happening. > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > -- 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: From msokolov at ivan.Harhan.ORG Thu Oct 24 20:39:24 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Thu, 24 Oct 2013 20:39:24 GMT Subject: AMR Implementation for Osmocom-BB Message-ID: <1310242039.AA03730@ivan.Harhan.ORG> Akib Sayyed wrote: > I am trying to implement AMR codec for osmocom-bb. Doesn't AMR support require applying some DSP code patches? Locating the DSP patch bits within a binary fw image read out of C1xx or whatever would probably be an incredible pain, but you can use this source/object mixed version instead: ftp://ftp.ifctf.org/pub/GSM/TI_src/Sotovik/ If you download ti-libs-extract.tar.bz2 from the above, you'll find all DSP patches in various *.obj modules in the l1_ext subdirectory inside that tarball. The names of the little individual object modules in that bunch are quite descriptive. The object format is TI's variant of COFF; you will need this patch to GNU Binutils in order to grok these objects: ftp://ftp.ifctf.org/pub/embedded/ti-arm/ Enjoy! Viva la Revolucion, SF From akibsayyed at gmail.com Fri Oct 25 06:32:36 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 25 Oct 2013 12:02:36 +0530 Subject: AMR Implementation for Osmocom-BB In-Reply-To: <1310242039.AA03730@ivan.Harhan.ORG> References: <1310242039.AA03730@ivan.Harhan.ORG> Message-ID: I am using TSM30 code for reference. Steps i Followed : - get multirate config from RR layer - pass them to l23 api - set sync_amr =1 : to tell dsp multirate config are ready in ndb - load multirate config into ndb.amr_config I am able to send uplink properly and can hear on other side. but about downlink i here only random noise with gliches. On Fri, Oct 25, 2013 at 2:09 AM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > Akib Sayyed wrote: > > > I am trying to implement AMR codec for osmocom-bb. > > Doesn't AMR support require applying some DSP code patches? > > Locating the DSP patch bits within a binary fw image read out of C1xx > or whatever would probably be an incredible pain, but you can use this > source/object mixed version instead: > > ftp://ftp.ifctf.org/pub/GSM/TI_src/Sotovik/ > > If you download ti-libs-extract.tar.bz2 from the above, you'll find > all DSP patches in various *.obj modules in the l1_ext subdirectory > inside that tarball. The names of the little individual object modules > in that bunch are quite descriptive. The object format is TI's variant > of COFF; you will need this patch to GNU Binutils in order to grok > these objects: > > ftp://ftp.ifctf.org/pub/embedded/ti-arm/ > > Enjoy! > > Viva la Revolucion, > 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: From msokolov at ivan.Harhan.ORG Sat Oct 26 04:28:34 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sat, 26 Oct 2013 04:28:34 GMT Subject: AMR Implementation for Osmocom-BB Message-ID: <1310260428.AA05406@ivan.Harhan.ORG> Akib Sayyed 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 From akibsayyed at gmail.com Sat Oct 26 13:42:49 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 26 Oct 2013 19:12:49 +0530 Subject: AMR Implementation for Osmocom-BB In-Reply-To: <1310260428.AA05406@ivan.Harhan.ORG> References: <1310260428.AA05406@ivan.Harhan.ORG> Message-ID: 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 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: From msokolov at ivan.Harhan.ORG Sat Oct 26 18:05:42 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sat, 26 Oct 2013 18:05:42 GMT Subject: AMR Implementation for Osmocom-BB Message-ID: <1310261805.AA06149@ivan.Harhan.ORG> Akib Sayyed wrote: > Harald and Dieter Spaar You should consider the possibility of accepting help from more than just them... > my question is does tsm30 support AMR operation Do you have an actual physical TSM30 phone? If you do, you must be the luckiest person on Earth, as these phones must be worth way more than their weight in gold. If you don't have an actual TSM30, why does it matter whether it supports AMR or not? IOW, it seems to me that you are posing the question the wrong way: rather than ask whether TSM30 supported AMR or not, you should be asking how to get AMR support working on your current phone, which I presume is one of the models supported by OsmocomBB, all of which use a much newer Calypso+ABB+RF chipset than what the TSM30 had in it. So, if you want to get help from those people who actually *are* willing to help you (such as me), please answer the following two questions: 1. Which phone are you using for your OsmocomBB/AMR experiments? 2. Please show us the console output you get from osmocon/layer1; I want to see the "DSP API Version:" line in particular, which should be printed twice. My hypothesis is that getting AMR to work probably requires applying at least one patch to the DSP code (others here have posted the same), but before we can proceed further down that road, we need to know which phone you are using and which DSP ROM version it has - hence my two questions above; please answer them. VLR, SF From akibsayyed at gmail.com Sun Oct 27 06:21:20 2013 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 27 Oct 2013 11:51:20 +0530 Subject: AMR Implementation for Osmocom-BB In-Reply-To: <1310261805.AA06149@ivan.Harhan.ORG> References: <1310261805.AA06149@ivan.Harhan.ORG> Message-ID: Thanks Michael I was checking code given by you and tsm30 phone. header files are same. I just need to know what dsp patch needed. btw here are answer of your questions. On Sat, Oct 26, 2013 at 11:35 PM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > Akib Sayyed wrote: > > > Harald and Dieter Spaar > > You should consider the possibility of accepting help from more than > just them... > > > my question is does tsm30 support AMR operation > > Do you have an actual physical TSM30 phone? If you do, you must be > the luckiest person on Earth, as these phones must be worth way more > than their weight in gold. If you don't have an actual TSM30, why > does it matter whether it supports AMR or not? > > IOW, it seems to me that you are posing the question the wrong way: > rather than ask whether TSM30 supported AMR or not, you should be > asking how to get AMR support working on your current phone, which I > presume is one of the models supported by OsmocomBB, all of which use > a much newer Calypso+ABB+RF chipset than what the TSM30 had in it. > > So, if you want to get help from those people who actually *are* > willing to help you (such as me), please answer the following two > questions: > > 1. Which phone are you using for your OsmocomBB/AMR experiments? > > Using c118 for experiments > 2. Please show us the console output you get from osmocon/layer1; I > want to see the "DSP API Version:" line in particular, which should be > printed twice. > > Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x0000 0x0000 Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 LOST 330! > My hypothesis is that getting AMR to work probably requires applying > at least one patch to the DSP code (others here have posted the same), > but before we can proceed further down that road, we need to know > which phone you are using and which DSP ROM version it has - hence my > two questions above; please answer them. > > 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: From msokolov at ivan.Harhan.ORG Sun Oct 27 22:00:00 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sun, 27 Oct 2013 22:00:00 GMT Subject: AMR Implementation for Osmocom-BB Message-ID: <1310272200.AA07432@ivan.Harhan.ORG> Akib Sayyed 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: 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