baseband-devel October 2013

baseband-devel@lists.osmocom.org

14 participants
24 discussions

c139/c140 jtag anyone?
by Craig Comstock 19 May '14

19 May '14

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?

2 3

Cannot open serial device /dev/ttyUSB0
by George Andguladze 24 Dec '13

24 Dec '13

Cannot open serial device /dev/ttyUSB0 I am getting this error message when I try to connect to my C155 phone and upload hello_world.compalram.bin using this command: ./osmocon -p /dev/ttyUSB0 -m c155 ../../target/firmware/board/compal_e99/hello_world.compalram.bin Even though device ttyUSB0 exists in my /dev/ directory, and I have set modprobe cp210x, and chmod 777 /dev/ttyUSB0. Here is an output from dmesg: [ 105.110818] usb 6-3: USB disconnect, device number 2 [ 105.111098] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [ 105.111131] cp210x 6-3:1.0: device disconnected [ 113.728075] usb 6-3: new full speed USB device number 3 using ohci_hcd [ 113.901042] cp210x 6-3:1.0: cp210x converter detected [ 114.040085] usb 6-3: reset full speed USB device number 3 using ohci_hcd [ 114.206030] usb 6-3: cp210x converter now attached to ttyUSB0 Here is an output from ls -l /dev/tty : crw-rw-rw- 1 root tty 5, 0 2013-06-04 21:27 /dev/tty crw--w---- 1 root tty 4, 0 2013-06-04 20:40 /dev/tty0 crw------- 1 root root 4, 1 2013-06-04 20:40 /dev/tty1 crw--w---- 1 root tty 4, 10 2013-06-04 20:40 /dev/tty10 crw--w---- 1 root tty 4, 11 2013-06-04 20:40 /dev/tty11 crw--w---- 1 root tty 4, 12 2013-06-04 20:40 /dev/tty12 crw--w---- 1 root tty 4, 13 2013-06-04 20:40 /dev/tty13 crw--w---- 1 root tty 4, 14 2013-06-04 20:40 /dev/tty14 crw--w---- 1 root tty 4, 15 2013-06-04 20:40 /dev/tty15 crw--w---- 1 root tty 4, 16 2013-06-04 20:40 /dev/tty16 crw--w---- 1 root tty 4, 17 2013-06-04 20:40 /dev/tty17 crw--w---- 1 root tty 4, 18 2013-06-04 20:40 /dev/tty18 crw--w---- 1 root tty 4, 19 2013-06-04 20:40 /dev/tty19 crw------- 1 root root 4, 2 2013-06-04 20:40 /dev/tty2 crw--w---- 1 root tty 4, 20 2013-06-04 20:40 /dev/tty20 crw--w---- 1 root tty 4, 21 2013-06-04 20:40 /dev/tty21 crw--w---- 1 root tty 4, 22 2013-06-04 20:40 /dev/tty22 crw--w---- 1 root tty 4, 23 2013-06-04 20:40 /dev/tty23 crw--w---- 1 root tty 4, 24 2013-06-04 20:40 /dev/tty24 crw--w---- 1 root tty 4, 25 2013-06-04 20:40 /dev/tty25 crw--w---- 1 root tty 4, 26 2013-06-04 20:40 /dev/tty26 crw--w---- 1 root tty 4, 27 2013-06-04 20:40 /dev/tty27 crw--w---- 1 root tty 4, 28 2013-06-04 20:40 /dev/tty28 crw--w---- 1 root tty 4, 29 2013-06-04 20:40 /dev/tty29 crw------- 1 root root 4, 3 2013-06-04 20:40 /dev/tty3 crw--w---- 1 root tty 4, 30 2013-06-04 20:40 /dev/tty30 crw--w---- 1 root tty 4, 31 2013-06-04 20:40 /dev/tty31 crw--w---- 1 root tty 4, 32 2013-06-04 20:40 /dev/tty32 crw--w---- 1 root tty 4, 33 2013-06-04 20:40 /dev/tty33 crw--w---- 1 root tty 4, 34 2013-06-04 20:40 /dev/tty34 crw--w---- 1 root tty 4, 35 2013-06-04 20:40 /dev/tty35 crw--w---- 1 root tty 4, 36 2013-06-04 20:40 /dev/tty36 crw--w---- 1 root tty 4, 37 2013-06-04 20:40 /dev/tty37 crw--w---- 1 root tty 4, 38 2013-06-04 20:40 /dev/tty38 crw--w---- 1 root tty 4, 39 2013-06-04 20:40 /dev/tty39 crw------- 1 root root 4, 4 2013-06-04 20:40 /dev/tty4 crw--w---- 1 root tty 4, 40 2013-06-04 20:40 /dev/tty40 crw--w---- 1 root tty 4, 41 2013-06-04 20:40 /dev/tty41 crw--w---- 1 root tty 4, 42 2013-06-04 20:40 /dev/tty42 crw--w---- 1 root tty 4, 43 2013-06-04 20:40 /dev/tty43 crw--w---- 1 root tty 4, 44 2013-06-04 20:40 /dev/tty44 crw--w---- 1 root tty 4, 45 2013-06-04 20:40 /dev/tty45 crw--w---- 1 root tty 4, 46 2013-06-04 20:40 /dev/tty46 crw--w---- 1 root tty 4, 47 2013-06-04 20:40 /dev/tty47 crw--w---- 1 root tty 4, 48 2013-06-04 20:40 /dev/tty48 crw--w---- 1 root tty 4, 49 2013-06-04 20:40 /dev/tty49 crw------- 1 root root 4, 5 2013-06-04 20:40 /dev/tty5 crw--w---- 1 root tty 4, 50 2013-06-04 20:40 /dev/tty50 crw--w---- 1 root tty 4, 51 2013-06-04 20:40 /dev/tty51 crw--w---- 1 root tty 4, 52 2013-06-04 20:40 /dev/tty52 crw--w---- 1 root tty 4, 53 2013-06-04 20:40 /dev/tty53 crw--w---- 1 root tty 4, 54 2013-06-04 20:40 /dev/tty54 crw--w---- 1 root tty 4, 55 2013-06-04 20:40 /dev/tty55 crw--w---- 1 root tty 4, 56 2013-06-04 20:40 /dev/tty56 crw--w---- 1 root tty 4, 57 2013-06-04 20:40 /dev/tty57 crw--w---- 1 root tty 4, 58 2013-06-04 20:40 /dev/tty58 crw--w---- 1 root tty 4, 59 2013-06-04 20:40 /dev/tty59 crw------- 1 root root 4, 6 2013-06-04 20:40 /dev/tty6 crw--w---- 1 root tty 4, 60 2013-06-04 20:40 /dev/tty60 crw--w---- 1 root tty 4, 61 2013-06-04 20:40 /dev/tty61 crw--w---- 1 root tty 4, 62 2013-06-04 20:40 /dev/tty62 crw--w---- 1 root tty 4, 63 2013-06-04 20:40 /dev/tty63 crw--w---- 1 root tty 4, 7 2013-06-04 20:40 /dev/tty7 crw--w---- 1 root tty 4, 8 2013-06-04 20:40 /dev/tty8 crw--w---- 1 root tty 4, 9 2013-06-04 20:40 /dev/tty9 crw------- 1 root root 5, 3 2013-06-04 20:40 /dev/ttyprintk crw-rw---- 1 root dialout 4, 64 2013-06-04 20:40 /dev/ttyS0 crw-rw---- 1 root dialout 4, 65 2013-06-04 20:40 /dev/ttyS1 crw-rw---- 1 root dialout 4, 74 2013-06-04 20:40 /dev/ttyS10 crw-rw---- 1 root dialout 4, 75 2013-06-04 20:40 /dev/ttyS11 crw-rw---- 1 root dialout 4, 76 2013-06-04 20:40 /dev/ttyS12 crw-rw---- 1 root dialout 4, 77 2013-06-04 20:40 /dev/ttyS13 crw-rw---- 1 root dialout 4, 78 2013-06-04 20:40 /dev/ttyS14 crw-rw---- 1 root dialout 4, 79 2013-06-04 20:40 /dev/ttyS15 crw-rw---- 1 root dialout 4, 80 2013-06-04 20:40 /dev/ttyS16 crw-rw---- 1 root dialout 4, 81 2013-06-04 20:40 /dev/ttyS17 crw-rw---- 1 root dialout 4, 82 2013-06-04 20:40 /dev/ttyS18 crw-rw---- 1 root dialout 4, 83 2013-06-04 20:40 /dev/ttyS19 crw-rw---- 1 root dialout 4, 66 2013-06-04 20:40 /dev/ttyS2 crw-rw---- 1 root dialout 4, 84 2013-06-04 20:40 /dev/ttyS20 crw-rw---- 1 root dialout 4, 85 2013-06-04 20:40 /dev/ttyS21 crw-rw---- 1 root dialout 4, 86 2013-06-04 20:40 /dev/ttyS22 crw-rw---- 1 root dialout 4, 87 2013-06-04 20:40 /dev/ttyS23 crw-rw---- 1 root dialout 4, 88 2013-06-04 20:40 /dev/ttyS24 crw-rw---- 1 root dialout 4, 89 2013-06-04 20:40 /dev/ttyS25 crw-rw---- 1 root dialout 4, 90 2013-06-04 20:40 /dev/ttyS26 crw-rw---- 1 root dialout 4, 91 2013-06-04 20:40 /dev/ttyS27 crw-rw---- 1 root dialout 4, 92 2013-06-04 20:40 /dev/ttyS28 crw-rw---- 1 root dialout 4, 93 2013-06-04 20:40 /dev/ttyS29 crw-rw---- 1 root dialout 4, 67 2013-06-04 20:40 /dev/ttyS3 crw-rw---- 1 root dialout 4, 94 2013-06-04 20:40 /dev/ttyS30 crw-rw---- 1 root dialout 4, 95 2013-06-04 20:40 /dev/ttyS31 crw-rw---- 1 root dialout 4, 68 2013-06-04 20:40 /dev/ttyS4 crw-rw---- 1 root dialout 4, 69 2013-06-04 20:40 /dev/ttyS5 crw-rw---- 1 root dialout 4, 70 2013-06-04 20:40 /dev/ttyS6 crw-rw---- 1 root dialout 4, 71 2013-06-04 20:40 /dev/ttyS7 crw-rw---- 1 root dialout 4, 72 2013-06-04 20:40 /dev/ttyS8 crw-rw---- 1 root dialout 4, 73 2013-06-04 20:40 /dev/ttyS9 crwxrwxrwx 1 root dialout 188, 0 2013-06-04 21:07 /dev/ttyUSB0 What is it that I am doing wrong? Thanks, George

7 10

Query on flashing the loader
by Bhaskar11 08 Nov '13

08 Nov '13

This is my first attempt to flash the loader. 1) The instructions on http://bb.osmocom.org/trac/wiki/flashing require loading the file named "target/firmware/board/compal_e88/loader.*e88loader* .bin". Strangely I do not have this file after compilation. I have loader.compalram.bin and loader.highram.bin. I also have layer1.e88loader.bin and rssi.e88loader.bin. Can you please guide me? 2) The guide for flashing an application says to use rssi.e88flash.bin. Does that mean if I want to flash "layer1" as my application, then I must use layer1.*e88flash*.bin at that point? Thank you for your help. B.

2 2

Re: AMR Implementation for Osmocom-BB
by msokolov＠ivan.Harhan.ORG 27 Oct '13

27 Oct '13

Akib Sayyed <akibsayyed(a)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

1 0

Re: AMR Implementation for Osmocom-BB
by msokolov＠ivan.Harhan.ORG 27 Oct '13

27 Oct '13

Akib Sayyed <akibsayyed(a)gmail.com> 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

2 1

Re: AMR Implementation for Osmocom-BB
by msokolov＠ivan.Harhan.ORG 26 Oct '13

26 Oct '13

Akib Sayyed <akibsayyed(a)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

2 1

Re: AMR Implementation for Osmocom-BB
by msokolov＠ivan.Harhan.ORG 25 Oct '13

25 Oct '13

Akib Sayyed <akibsayyed(a)gmail.com> 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

2 1

AMR Implementation for Osmocom-BB
by Akib Sayyed 24 Oct '13

24 Oct '13

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(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

1 1

OsmocomBB without hardware phone
by clovnrian＠gmail.com 23 Oct '13

23 Oct '13

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

1 0

I have a problem when load the firmware
by zhangseuedu 23 Oct '13

23 Oct '13

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-f… Sent from the baseband-devel mailing list archive at Nabble.com.

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel October 2013