- baseband-devel - lists.osmocom.org

Re: removing ancient libosmocore fork from osmocom-bb.git

by Craig Comstock

Looks like in package libnewlib-dev for stretch (unstable) we have sys/select.h but in jessie (stable) it is not included. https://packages.debian.org/stretch/libnewlib-dev https://packages.debian.org/jessie/libnewlib-dev craig@box:~/libosmocore$ ./configure --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-shared CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" craig@box:~/libosmocore$ make make all-recursive make[1]: Entering directory '/home/craig/libosmocore' Making all in include make[2]: Entering directory '/home/craig/libosmocore/include' make all-am make[3]: Entering directory '/home/craig/libosmocore/include' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/craig/libosmocore/include' make[2]: Leaving directory '/home/craig/libosmocore/include' Making all in src make[2]: Entering directory '/home/craig/libosmocore/src' make all-am make[3]: Entering directory '/home/craig/libosmocore/src' CC select.lo select.c:27:24: fatal error: sys/select.h: No such file or directory #include <sys/select.h> ^ compilation terminated. Makefile:510: recipe for target 'select.lo' failed make[3]: *** [select.lo] Error 1 make[3]: Leaving directory '/home/craig/libosmocore/src' Makefile:373: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/craig/libosmocore/src' Makefile:519: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/craig/libosmocore' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 -------------------------------------------- On Tue, 5/16/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: removing ancient libosmocore fork from osmocom-bb.git To: baseband-devel(a)lists.osmocom.org Date: Tuesday, May 16, 2017, 11:18 AM Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years

1
0
0 0

removing ancient libosmocore fork from osmocom-bb.git

by Harald Welte

Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years

2
1
0 0

Re: CalypsoBTS and modern OsmoBSC

by Vadim Yanitskiy

Hi, > I found that the manual from the main site is outdated. Yeah, still couldn't find some time to update the wiki. > If I understood it correct, I have to setup calypso bts > as bts of type nanoBTS, correct? Why do you think so? No, CalypsoBTS has nothing related toip.access nanoBTS. From the other side, we don't have a dedicated type for OsmoBTS, so you can use 'sysmoBTS'. > I can sync with commercial cell, I can run OsmoBSC and > OsmoBTS but I still cannot find my network from my personal > phone in searching mode. Please watch a great Sylvain's talk, where he explained almost everything you need to know: "Further hacks on the Calypso platform" https://media.ccc.de/v/29c3-5226-en-further_hacks_calypso_h264 In short: BTS should transmit a continuous beacon on C0 to be detected. Normal MS can't do that. CalypsoBTS was hacked to perform the following timeslot layout: Tt_R_ttt, where 'T' means TX on Downlink, 'R' means RX on Uplink, and 't' means channel filling - dummy bursts. Phone cannot RX and TX at the same time, so one phone serves only one TS. With two phones you have the following layout: TT_RRttt, so you have two timeslots served. This is why you will have some detection troubles even with working BSS setup :/ > In logs of osmo-bts I can see: > > <0000> rsl.c:246 Tx RSL RF RESource INDication > <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with > response: 'RSP SETTSC -1' > <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO Just delete the 'settsc' line from your config, because CalypsoBTS transceiver only supports 'setbsic'. Have a fun! With best regards, Vadim Yanitskiy.

7 years

3
8
0 0

Timeslot allocation

by Anton Gorbachev

Dear colleagues, Could you please tell me when I am wrong in my assumptions? My story is about beacon channel. >From different resourses I got the information that we transmit bcch data (fcch,sch,bcch) which is required for MS to find our network. OK? On the pictures it's drawn like we transmit BCCH on C0T0. So DL TS1-7 can be used for i.e. TCH. So if we want just to create bts which can be found by MS and that's all, we may not transmit on TS1-7 at all. OK? When we are talking about CalypsoBTS we say that we must transmit several burst in a row. So here I am a bit confused. So if we want to just transmit bcch messages we can transmit every TS0 and rest on TS1-7. Why not? Why I can see in manuals and videos pictures like Ttt_R_tt? Why do I need these dummy "t" bursts? Why one burst is "t" and another is "T"? Sure I understand that we must receive something for normal BTS operation like RACH and need some time to switch Tx/Rx. But why we just cannot use mask like T_R_T_R_ ...? I understood that we cant use mask TTT_RR because calypso phone was not hacked to receive two bursts in a row. Thanks in advance!

7 years

1
0
0 0

CalypsoBTS and modern OsmoBSC

by Anton Gorbachev

Dear colleagues, I am trying to set up CalypsoBTS with the last version of OsmoNTIB and branch jolly/testing (so using two phones). I found that the manual from the main site is outdated. It doesn't work with the config provided os I am trying to figure out how to tune it manually. If I understood it correct, I have to setup calypso bts as bts of type nanoBTS, correct? I can sync with commercial cell, I can run OsmoBSC and OsmoBTS but I still cannot find my network from my personal phone in searching mode. Could you please tell me what can be wrong? I tried both GSM900 and DSC1800, different channels selected after RSSI checking... Both phones are w/o filter rework, they are motorola c113 and c113a. In logs of osmo-bts I can see: <0000> rsl.c:246 Tx RSL RF RESource INDication <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with response: 'RSP SETTSC -1' <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO In osmo-bsc log everything looks fine: <001e> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3003 <0005> abis_nm.c:2513 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0005> abis_nm.c:698 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK <0004> bsc_init.c:288 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 29 using MCC=1 MNC=1 LAC=5 CID=5 BSIC=5 <0003> system_information.c:544 Serving cell: 29 <0003> bsc_init.c:105 SI1: 55 06 19 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 e5 04 00 2b Here below are my configs: ======================================= osmo-bts.cfg phy 0 instance 0 bts 0 band GSM900 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 0 paging queue-size 200 paging lifetime 0 ms-power-loop -60 timing-advance-loop settsc setbsic trx 0 phy 0 instance 0 ========================================= open-bsc.cfg phy 0 instance 0 bts 0 band GSM900 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 0 paging queue-size 200 paging lifetime 0 ms-power-loop -60 timing-advance-loop settsc setbsic trx 0 phy 0 instance 0 root@osmobox:~/.osmocom# cat open-bsc.cfg ! ! OpenBSC (0.15.0.754-c6e8) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll everything logging level cc everything logging level mm everything logging level rr everything logging level rsl everything logging level nm everything logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice log file logfile logging filter all 0 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice logging level cc notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 1 mobile network code 1 short name HomeGSM long name HomeGSM auth policy closed authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 0 paging any use tch 0 rrlp mode none mm info 0 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 40 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 0 bts 0 type nanobts band GSM900 cell_identity 5 location_area_code 5 base_station_id_code 5 ms max power 0 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 ip.access rsl-ip 127.0.0.1 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr hr amr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 29 nominal power 23 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/H hopping enabled 0 timeslot 2 phys_chan_config TCH/H hopping enabled 0 timeslot 3 phys_chan_config TCH/H hopping enabled 0 timeslot 4 phys_chan_config TCH/H hopping enabled 0 timeslot 5 phys_chan_config TCH/H hopping enabled 0 timeslot 6 phys_chan_config TCH/H hopping enabled 0 timeslot 7 phys_chan_config TCH/H hopping enabled 0 mncc-int default-codec tch-f amr default-codec tch-h amr nitb subscriber-create-on-demand assign-tmsi

7 years

1
0
0 0

Re: CalypsoBTS + GPRS and SDR suggestion

by Vadim Yanitskiy

Hi, > I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the > best way to do that, but I would like to have a cheap solution. I got the > setup working with a normal phone and the BTS seems to work correctly > (using jolly/testing), but from my understanding it support only GSM calls > and SMS and GPRS is not implemented into the transceiver. I'm wrong or this > part has not been implemented yet? Right, isn't implemented. When you run OsmoBTS, it first does some basic configuration of transceiver, including timeslot type setting. PDCH has its own dedicated type, which is being indicated by the SETSLOT command. So you can look at OsmocomBB sources, and check whether the transceiver handles this type or not. > Also, given that CalypsoBTS can only provide single (or two?) timeslot, > there are a long list of reasons why it would not work straight-forward. > But technically also possible to make work. With two Calypso phones it becomes possible to serve two timeslots. Basically, second phone serves one TCH timeslot, but (if I am correct) PDCH has no fundamental differences from TCH, so its support could be implemented too. After a quick look at OsmoTRX source code, I can assume, that the only difference between TCH channel combinations (I, II and III) and PDCH channel combination (XIII) is a fillerModulus value. Correct me if I am wrong. With best regards, Vadim Yanitskiy.

7 years

3
2
0 0

CalypsoBTS + GPRS and SDR suggestion

by inode

Hi everybody, I'm pretty new to the GSM/UMTS environment and I'm doing some tests. Currently I need to analyze some IoT devices that use 2G network to comunicate via GPRS. I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the best way to do that, but I would like to have a cheap solution. I got the setup working with a normal phone and the BTS seems to work correctly (using jolly/testing), but from my understanding it support only GSM calls and SMS and GPRS is not implemented into the transceiver. I'm wrong or this part has not been implemented yet? If needed to use a GPRS BTS can you suggest the best cheap SDR to use with OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they are full supported via OsmoBTS) Thank you in advance. inode

7 years

3
2
0 0

Re: to qcom hexagon porting

by Craig Comstock

> what are problem should i expect > while porting to qcom hexagon > is it a bad idea There would be a lot of questions and things to research. I am not familiar with qcom hexagon SDK. I am a little familiar with osmocom-bb source code and 2G GSM details. I am currently in the very beginning stages of porting osmocom-bb to the MediaTek 6260/6261 chip which supports 2G. I also have ideas to try and work through 3G on a MediaTek 6735 (ZTE Obsidian phone). Recently there have been mentions of re-writing the PHY layer of osmocom-bb for an SDR platform like LimeSDR. https://github.com/axilirator/osmocom-bb So at the current time I assume that osmocom-bb communicates with the DSP chip on the motorola phones in a way that abstracts the PHY layer details away and relies on the proprietary Texas Instruments firmware in the DSP as-is. So I would imagine you might have to implement the PHY layer and also the interface to the PHY layer. There was a discussion about this recently on IRC #osmocom. It seems the thought was that qcom had released enough with their Hexagon SDK to allow development of a PHY layer + whatever else. Some links of interest. https://developer.qualcomm.com/ - SDK https://github.com/ttsou/openphy - LTE PHY for Ettus USRP https://androiddatahost.com/fgd43 - qcom flash image loader I have a few qcom modems that I'd be happy to do experiment on if that helps. -Craig

7 years

1
0
0 0

to qcom hexagon porting

by thayyil09 yil

what are problem should i expect while porting to qcom hexagon is it a bad idea

7 years

1
0
0 0

Re: CalypsoBTS no sync, ms hang

by Vadim Yanitskiy

> isn't fixed in branch jolly/testing I am using for calypsoBTS. > So all I needed is just implement the fix and recompile from sources. You can also use an older version of toolchain as a temporary solution: https://github.com/axilirator/gnu-arm-installer - in this repo I have fixed some installation (texinfo) related issues. With best regards, Vadim Yanitskiy.

7 years

2
1
0 0

CalypsoBTS no sync, ms hang

by Anton Gorbachev

Dear colleagues, I am trying to setup CalypsoBTS with two c113 phones. Don't you know why can't I sync to any commercial cell with transceiver from branch jolly/testing? What I have: Motorola c113 and c113a, tried both. All other apps like, RSSI, mobile, ccch_scan works like a charm. What I am doing: Built jolly/testing according to maual https://osmocom.org/projects/baseband/wiki/CalypsoBTS Load firmware ./osmocon -r 99 -m c123xor -p /dev/ttyUSB0 -c ../../target/firmware/board/compal_e88/trx.highram.bin Found several strongest cells with RSSI and cell_log. Trying to sync: ./transceiver -a 50 -r 99 -e 1 Here is the log: 50 41 1 <000c> l1ctl.c:77 Tx Reset Req (1) <000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 ' <0012> l1ctl.c:383 Reset received: Starting sync. <000c> l1ctl.c:95 Sync Req <000c> l1ctl_link.c:171 Sending: '01 00 00 00 00 32 00 64 27 10 03 20 03 07 00 00 00 ' After that phone hangs, no reaction in osmocon on key pressures, holding on power off button... The last messages are: L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=50, flags=0x7) Starting FCCH RecognitionFB0 (2515:4): TOA= 3552, Power= -64dBm, Angle= 1328Hz FB1 (2525:8): TOA= 8543, Power= -64dBm, Angle= 114Hz fn_offset=2523 (fn=2525 + attempt=8 + ntdma = 6) delay=8 (fn_offset=2523 + 11 - fn=2525 - 1 scheduling next FB/SB detection task with delay 8 =>FB @ FNR 2523 fn_offset=2523 qbits=3988 Synchronize_TDMA LOST 3398! I tried different cells, maybe I need to wait some time to warm the crystal? But can it be so important? Kind regards, Anton

7 years

1
1
0 0

Re: OsmocomBB full Opensouce?

by Vadim Yanitskiy

Hi Anton, > There are some ideas floating around of doing a new run of this using > OsmoTRX as basis, but I don't know if there is any actual progress yet. > Vadim should be able to say more about it. Yeah, I started to work on SDR based PHY about a year ago, but so far I was busy with libosmocore development. Right now almost everything (including libosmocoding of course) is in master branch, so it's good point to resume this work. If you would like to contribute this direction or something else, we are always open for that, so feel free! The source code is currently on GitHub: https://github.com/axilirator/osmocom-bb/ BTW: Harald, is it possible to create a new branch for that work in the project's repo? If yes, I can send you my public key in PM. Thanks! With best regards, Vadim Yanitskiy.

7 years

4
3
0 0

Phone not receiving calls

by samir

Hello, I test osmocombb for some time with motorola c115. I can make calls but not always receive calls. I tried 2 sim cards one of them is working fine but the other doesn’t receive anything. I really need some help to solve my problem. thanks in advance.

7 years

1
0
0 0

CalypsoBTS + GPRS and SDR suggestion

by Maurizio Agazzini

Hi everybody, I'm pretty new to the GSM/UMTS environment and I'm doing some tests. Currently I need to analyze some IoT devices that use 2G network to comunicate via GPRS. I setup CalypsoBTS to work with 2 old motorola c123, I know that isn't the best way to do that, but I would like to have a cheap solution. I got the setup working with a normal phone and the BTS seems to work correctly (using jolly/testing), but from my understanding it support only GSM calls and SMS and GPRS is not implemented into the transceiver. I'm wrong or this part has not been implemented yet? If needed to use a GPRS BTS can you suggest the best cheap SDR to use with OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they are full supported via OsmoBTS) Thank you in advance. inode

7 years

1
0
0 0

OsmocomBB full Opensouce?

by Anton Gorbachev

Dear collegues, Could you please help me to understand one thing.. If I understood everything correct, osmocombb project consist of all the code for GSM stack L1-L3 functionality but Calypdo DSP code is not Opensource and layer1.bin ask non-opensource DSP module to do execute L1 tasks from ghis list: https://osmocom.org/projects/baseband/wiki/TSM30Layer1#DSP-Tasks Of cource we can patch DSP and ask it to do whatever we want, like send raw bursts to the host, but now osmocombb uses mostly DSP firmware written by Texas Instruments, not its own opdnsource. Is it correct or not? Thanks in advance!

7 years

2
1
0 0

osmocombb for qcom

by thayyil09 yil

is it possible to add new project page to osmocom site. as i mentioned earlear sourcecode already available for qcom i think none intrested in it. is it true .why?

7 years

1
0
0 0

Re: osmocom-bb moved to gerrit

by Vadim Yanitskiy

Hi, > The osmocom-bb git repository has now moved to gerrit. Great news! > There are no tests in osmocom-bb yet, but I wonder if it would be possible to add > simple jenkins job which checks that arm cross-compilation for osmocom-bb > succeeds as a patch check? I can take this task and try to write a Jenkins script. Also, we need to have cross-compiler installed on the build machines. With best regards, Vadim Yanitskiy.

7 years

4
6
0 0

osmocom-bb moved to gerrit

by Neels Hofmeyr

The osmocom-bb git repository has now moved to gerrit. For patch submission to osmocom-bb, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit ~N

7 years

2
1
0 0

osmocombb on qualcom android phones

by thayyil09 yil

7 years

2
1
0 0

Re: gerrit for osmocom-bb

by Vadim Yanitskiy

Hi, > I'm not sure if it's just me or if I'm using it wrong but > I'm always annoyed when I have to login to gerrit ... +1 here, Gerrit login is (for now) a bit unfriendly. Even so, there are also some advantages to have OsmocomBB in Gerrit: - Jenkins builder: maintainers / reviewers don't need to manually check whether a new commit fails build or not. - I don't need to copy-paste the source code to leave a contextual comment or ask a question. - Doing 'git push gerrit ...' is simpler and faster for me, than 'git format-patch ...', 'git send-email ...'. So, I would be definitely happy to see OsmocomBB in Gerrit. With best regards, Vadim Yanitskiy.

7 years

1
0
0 0

gerrit for osmocom-bb

by Max

Hi. I've just noticed that OsmocomBB is not on the list of projects at https://gerrit.osmocom.org/#/admin/projects/ Is this because nobody bothered adding it there yet or it's because maintainers do not find it suitable? If it's the latter than I'd love to see it added to streamline contributions and patch review process. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years

5
6
0 0

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)

by Craig Comstock

RootZero/bruce lee sent me this github with baseband sources very similar to what I already have for MT626x: https://github.com/zxp86021/MediaTek-HelioX10-Baseband Looking there it seems we have layer 1 GSM/2G support for many more RF chips. The trick is to figure out what AP/SOC they are used in. For example the MediaTek-HelioX10 is a MT6795 which seems to use the MT6169 transciever chip (based on some other files in the sources). My ZTE Obsidian seems to use this same TRX chip (based on a MT6735 datasheet) http://www.datasheet4u.com/pdf/MT6735-pdf/925384 Comparing L1D_RF_PowerOn functions it seems the MT6252 might be the closest to the MT626x which are completely missing from this newer set of sources that are maybe a year or so newer than the MT626x sources I have. m12196.c:/*BRIGHT2*/ void L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT4*/ void L1D_RF_PowerOn( void ) m12196.c:/*BRIGHT5P*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO1+*/ void L1D_RF_PowerOn( void ) m12196.c:/*RFMD*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74117*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74400*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6119*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6119C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129A*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140A*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140B*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140C*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) m12196.c:/*CMOSEDGE*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1T*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74045*/ void L1D_RF_PowerOn( void ) m12196.c:/*AERO2*/ void L1D_RF_PowerOn( void ) m12196.c:/*SKY74137*/ void L1D_RF_PowerOn( void ) m12196.c:/*GRF6201*/ void L1D_RF_PowerOn( void ) m12196.c:/*IRFS3001*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6163*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6280RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6169*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6166*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6165*/ void L1D_RF_PowerOn( void ) one set of MT626x sources is called 11CW1418SP4 and supports the following baseband chips. Probably MT626x has an integrated baseband? m12196.c:/*MT6129D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6139E*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6140D*/ void L1D_RF_PowerOn( void ) m12196.c:/*MTKSOC1*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6252RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6261RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6260RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6250RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6256RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6255RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6251RF*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6548*/ void L1D_RF_PowerOn( void ) m12196.c:/*AD6546*/ void L1D_RF_PowerOn( void ) m12196.c:/*MT6162*/ void L1D_RF_PowerOn( void ) So I guess I need to look elsewhere in the sources to puzzle out my MT6735 ZTE Obsidian which would give me I think the cheapest/oldest chip that supports 4G/LTE: GSM, UMTS, GPRS, HSPA+, HSUPA, TD-SCDMA, EVDO, LTE Cat 4 (from https://en.wikipedia.org/wiki/MediaTek) -Craig p.s. here are some sources I used to research both github and "from the internet": http://git.huayusoft.com/tomsu/AP7350_MDK-kernel.git https://github.com/akibsayyed/CELLTEL82_WET_KK_GPRS_HSPA_MOLY.WR8.W1315.MD.… https://github.com/akibsayyed/HSPA_MOLY.WR8.W1449.MD.WG.MP.V16.git https://github.com/zxp86021/MT6795.kernel.git mt626x stuff: 11CW1352MP_CENON61D_3232_11C_V2_GPRS_MMI 11CW1418SP4_CORETEK02A_WIFI_BT_V13_GPRS_MMI MTK60D-11B1308-V2 -------------------------------------------- On Thu, 4/13/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" <craig_comstock(a)yahoo.com> Date: Thursday, April 13, 2017, 11:40 AM check this out. it is modem firmwear source code and this guy's github https://github.com/luckasfb/Development_Documents alots of good stuff.but do not have what am looking for. bruce. From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Thursday, April 13, 2017 2:10:15 PM To: bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) Looking at some kernel sources I see a few things that look familiar to me from mt626x source. Grepping for RIL (radio interface layer) https://github.com/eagleeyetom/android_kernel_mtk_mt6572.git ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x0A00000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h: #define RIL_SIZE 0x1600000 ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RIL_SIZE 0x100000 //for connsys memory ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define MEM_PRELOADER_START (DRAM_PHY_ADDR) //placed mem in RIL 256KB ./mediatek/platform/mt6572/lk/include/platform/mt_reg_base.h:#define RESERVE_MEM_SIZE (RIL_SIZE) they mentioned infrasys and connsys near the RIL bits... craig@z500:~/android_kernel_mtk_mt6572/mediatek$ find | xargs grep -s infrasys ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/kernel/core/include/mach/mt_reg_base.h:/* infrasys */ ./platform/mt6572/kernel/core/core.c: /* infrasys AO first half */ ./platform/mt6572/kernel/core/core.c: /* infrasys AO second half */ ./platform/mt6572/kernel/core/core.c: /* infrasys */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys AO */ ./platform/mt6572/lk/include/platform/mt_reg_base.h:/* infrasys */ craig@z500:~/android_kernel_mtk_mt6572/mediatek$ vi platform/mt6572/kernel/core/core.c So... mt_reg_base.h looks a little familiar to mt626x stuff. There is also this: https://android.googlesource.com/kernel/mediatek/ and this: https://github.com/profglavcho/mt6735-kernel-3.10.61 -------------------------------------------- On Thu, 4/13/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org>, "Craig Comstock" <craig_comstock(a)yahoo.com> Date: Thursday, April 13, 2017, 1:49 AM maybe it is easiest for developing on some boards which has UART port to look it boot up message. some mt6572 based boards one can find on China market. they event can share code with us if we buy it. it is android based. so should/can we make a osmocom-bb based BP for this android board? or other smartphone? thanks RZ From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Thursday, April 13, 2017 3:21 AM To: baseband-devel(a)lists.osmocom.org; bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip craigcomstock/osmocom-bb github.com Contribute to osmocom-bb development by creating an account on GitHub. I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" <craig_comstock(a)yahoo.com>, "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org> Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel(a)lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero <bbsoo7(a)live.com> wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-P… - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble • Free Forum • Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years

2
3
0 0

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)

by Craig Comstock

I don't know much about the architecture of these MT based Android phones yet. We would need some source for the actual baseband part of the code in order to port osmocom-bb. I was able to quickly search for mt6572 kernel sources but that's not what we need. I also found custom ROMs like CyanogenMod. That might get us a bit further. Also there are "scatter" files that newer MT based devices use as a sort of map for fastboot flashing images onto a device (I think, not much experience here). So that might give a clue as well. This one has U-Boot! That might be helpful. https://github.com/GoldRenard/AllegroROM_4.2.2_mt6572/blob/master/HWPackage… So if you can purchase a 6572 based board and get enough source that might be what is needed to make progress. If you find a link to something share it I suppose. I'm mostly focused on porting osmocom-bb to 626x at this point and figuring out how to get layer1+modem built as nuttx-bb... but... as I mentioned I work slow so if others push forward with a newer chip that would be cool. If we could end up with something like AOSP + osmocom-bb image for RILD I suppose that might be fun. I am more interested in NOT using Android for what it's worth. -Craig -------------------------------------------- On Thu, 4/13/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org>, "Craig Comstock" <craig_comstock(a)yahoo.com> Date: Thursday, April 13, 2017, 1:49 AM maybe it is easiest for developing on some boards which has UART port to look it boot up message. some mt6572 based boards one can find on China market. they event can share code with us if we buy it. it is android based. so should/can we make a osmocom-bb based BP for this android board? or other smartphone? thanks RZ From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Thursday, April 13, 2017 3:21 AM To: baseband-devel(a)lists.osmocom.org; bruce lee Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip craigcomstock/osmocom-bb github.com Contribute to osmocom-bb development by creating an account on GitHub. I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" <craig_comstock(a)yahoo.com>, "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org> Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel(a)lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero <bbsoo7(a)live.com> wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-P… - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble • Free Forum • Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years, 1 month

1
0
0 0

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)

by Craig Comstock

I don't have the files mentioned in that patch. They look very much like some part of an Android source code tree. So far I am working mostly not with Android at all... only osmocom-bb, nuttx, fernly and fernvale-nuttx. My work on the newer MT chip in the ZTE Obsidian is a ways down the road. One thing that was VERY encouraging is that I have tested the beginnings of interaction with it's bootloader (as in the fernly project) and it seems at least the initial MSG and ACK from the bootloader works the same as for fernly types of MT chips (6260/6261). So that might be a good starting point in terms of experimenting/fuzzing/??? Maybe you could find a custom rom source tree and find those files that are being patched. In terms of participating in my project, I have a github repo and am primarily using the fernvale board I purchased from sysmocom as well as some mt6260/6261 based watches and the Seeed Studio RePhone. So I'd say go get one or more of those things and start hacking on fernly, fernvale-nuttx, osmocom-bb and nuttx-bb (combo of osmocom-bb and nuttx). I don't work too hard on the project. This branch is my latest not-working work in progress: https://github.com/craigcomstock/osmocom-bb/tree/feb-22-2017-mt62xx-wip I have since changed my strategy and so this branch will likely rot. :( But it might give some indication of what I'm up to. -Craig -------------------------------------------- On Wed, 4/12/17, bruce lee <bbsoo7(a)live.com> wrote: Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) To: "Craig Comstock" <craig_comstock(a)yahoo.com>, "baseband-devel(a)lists.osmocom.org" <baseband-devel(a)lists.osmocom.org> Date: Wednesday, April 12, 2017, 9:39 PM Craig, do you have the files mentioned at https://github.com/shadowsim/shadowsim/blob/master/mdlogger.patch and for your project, seem very interesting, and I would like to participate in. thanks RZ From: Craig Comstock <craig_comstock(a)yahoo.com> Sent: Tuesday, April 11, 2017 11:35 AM To: baseband-devel(a)lists.osmocom.org; RootZero Subject: Re: Fun with the MTK 6573 Baseband (Patching / Replacing) My target was Mt6735 in a Zte Obsidian. I chose it for 4g lte. I could root one and see if similar techniques work. My hope was to leverage leaked source for mt626x and hope to work my way up the chip models. I am currently working on porting osmocom-bb and nuttx-bb to fernvale/rephone/mt626x. On April 11, 2017 4:39:46 AM CDT, RootZero <bbsoo7(a)live.com> wrote: Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-P… - Fun with the MTK 6573 Baseband (Patching / Replacing)baseband-devel.722152.n3.nabble.comFun with the MTK 6573 Baseband (Patching / Replacing). -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm Markus, a security researcher from Germany. I recently did some work on MTK 6573... Sent from the baseband-devel mailing list archive at Nabble.com.Nabble • Free Forum • Embeddable Web Appsnabble.comEmbed into any Website. All Nabble apps are naturally embeddable, which means that they can be easily displayed inside any web page. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years, 1 month

2
1
0 0

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)

by RootZero

Markus and all, I am very interesting in this project/hack. can you share more information with US? I searched lots web pages and do not find the source of mdlogger.cpp file. I do have the source code of "modem.img" if you want please let me know. thanks RootZero -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fun-with-the-MTK-6573-Baseband-P… Sent from the baseband-devel mailing list archive at Nabble.com.

7 years, 1 month

3
2
0 0

FreeCalypso GSM MS development board built and mostly works

by Mychaela Falconia

Hello fellow GSM baseband hackers, Harald invited me to share this news with this list, so here it goes: the FreeCalypso project's GSM MS development board with the TI Calypso+Iota+Rita chipset, called FCDEV3B, has been built, and it mostly works, although there are still some issues being debugged. Pictures of this board can be seen here: https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7580.jpeg https://www.freecalypso.org/members/falcon/fcdev3b/IMG_7581.jpeg Now the following part is bad news for me, but probably good news for you guys: right now OsmocomBB works on this board to the point of being able to connect to the live commercial GSM network in my part of the world, send and receive SMS and make a call, but my own preferred firmware is not currently able to the connect to the network (fails in the FB/SB acquisition step) because of the lack of VCXO calibration. To run OsmocomBB on my board, the same version of layer1.highram.bin that is currently built in board/gta0x works unchanged on the FCDEV3B, as my board design is derived from Openmoko GTA02. Both Calypso UARTs are equally accessible on header pins, so use whichever you prefer - tweak board/gta0x/init.c if you prefer to use the IrDA UART - for example, if you wish to use the external serial port when running the same layer1.highram.bin on Openmoko hardware. The on-board SIM socket wired to the Calypso+Iota chipset works - I used this native SIM socket (not an external SIM adapter) for the real SIM used to connect to Operator 310260's live commercial GSM network, and SMS sending and receiving worked without a hitch. After several tries I was also able to dial and connect a voice call - it took several tries, but voice calls from OsmocomBB have always been unreliable for me, even on pre-existing Calypso targets where they work flawlessly with the official firmware. However, the voice path has not been tested yet, as the hardware is not complete enough for it yet. I designed the FCDEV3B with the intent of being able to make test calls from the lab bench without needing anything except the board itself, and for this purpose there is a loudspeaker driver circuit and a microphone input circuit on the board, based on TI's Leonardo schematics. However, the actual loudspeaker and microphone themselves aren't on the board, instead there are headers meant for connecting them. At some point I will need to acquire some loudspeaker and microphone parts, wire them up to the headers and test these on-board audio circuits, but right now there are higher priorities. The following parts do not work properly yet: * There is a flash + external RAM chip on the board, the same part as used in the Pirelli DP-L10, with the gigantic capacity of 16 MiB of flash and 8 MiB of RAM. The external RAM works (I can run the large FreeCalypso firmware entirely from RAM without flashing), and the flash works in that I can erase, program and verify images in both banks of the flash - it is organized as two chip select banks of 8 MiB each. However, some strange problems happen when booting FreeCalypso fw that has been flashed - I will need to hook up JTAG (and exercise that hardware path) in order to debug it further. I am guessing that this problem affects only FreeCalypso and not OsmocomBB, as it is my understanding that you guys have no interest in producing firmware that runs fully on the baseband processor, instead of an attached PC host, and for the purpose of running your teensy-tiny L1 you don't need any flash or external RAM at all. (Sure, one can build a flashable version of this little L1, but what is the point of doing so if you still need to run osmocon in order to talk to it?) * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso) expects per-unit RF calibration to be performed on the production line, and the VCXO calibration appears to be the most critical step: if I delete the VCXO calibration files on an Openmoko-made GTA02, the modem stops working (fails to acquire FB/SB in the network search just like on my FCDEV3B), whereas all other RF calibration files can be deleted and it still works. Hence I reason that the lack of this VCXO calibration is the cause of my current inability to connect to the network from my board using my preferred firmware. Now here is the part I don't understand: how are you able to get away with not requiring RF calibration in OsmocomBB? As I understand it, the requirement that each individual GSM MS unit must be RF-calibrated in production was not specific to TI Calypso, but is a general industry-wide requirement, or at least was in that time period. Per-unit calibration adds to the production test time, time is money, and the calibration equipment (R&S CMU200 is the industry gold standard) is not cheap either - so there is a non-trivial cost to this calibration requirement. So I figure that there must have been some good reason for TI and other mainstream GSM MS chipset manufacturers to require per-unit RF calibration - if they could have dispensed away with this calibration requirement like you did in OsmocomBB, they surely would have done it. So where is the catch? There must be some good reason why TI's TCS211 fw requires VCXO calibration, and when the fw is redesigned to not require such calibration as you seem to have done in OsmocomBB, something else (something important probably) must be sacrificed. So what is the good reason for requiring accurate VCXO calibration, and what is sacrificed when one cheats on this requirement like you seem to be doing? Viva La Revolucion, Mychaela aka Spacefalcon the Outlaw

7 years, 1 month

3
3
0 0

Re: Connecting OsmocomBB to OpenBTS

by Vadim Yanitskiy

Hi, > I'm guessing I would need to perform surgery on OSMOCOM-BB code in order to > connect it to another network? Is there any in built feature that would > allow me to do so directly? As I understand, you want to connect the network you running yourself on OpenBTS. There are two modes of network selection: manual and automatic (when MCC/MNC from SIM card are used). Have a look at the 'network-selection-mode' in your config file (~/.osmocom/bb/mobile.cfg). Also, have a look at the 'network' command in VTY. You can also create a virtual SIM card in your ~/.osmocom/bb/mobile.cfg (look at the 'test-sim' section) with desired IMSI and RPLMN (001 / 01 by default). Then you will be able to attach one using the 'sim testcard 1'. With best regards, Vadim Yanitskiy.

7 years, 1 month

2
1
0 0

Re: ARM Core and UI

by Vadim Yanitskiy

Hi Anton, Feel free to watch OsmocomBB related talks, such as: https://youtu.be/ihbRtTzc0NI https://youtu.be/H7rNKZdASBE You'll wind a lot of useful information. Good luck! With best regards, Vadim Yanitskiy.

7 years, 1 month

1
0
0 0

OsmocomBB MNCC socket implementation without LCR

by Gerard Pinto

Greetings, I have been working with Layer23 stack of OsmocomBB since a couple of months. I decided to try MNCC socket interface without LCR (I'm aware there is an implementation embedded in LCR gsm-ms). I reverse engineered and wrote a simple C application taking mncc.h. Problem: I'm unable to make a call on live network, although it does channel allocation, ciphering etc. Flow: 1. Create MNCC struct and write on to the osmocomBB socket 2. OsmocomBB parses it well and request for channel, ciphering mode, init MM, sending SETUP etc works great. 3. However, in response to step.2 after sending SETUP it returns with (ms 1) Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC? 4. I further debugged, the reason for release is in fn. gsm48_cc_rx_release_compl in (gsm8_cc.c) it says mncc-cause = *GSM48_IE_CAUSE*. with no description. I really don't know whats causing this issue. Any help would be much appreciated. Or It would be very kind if someone could guide me. My mncc socket create code: struct gsm_mncc *mncc; int i = 0; int call_ref = new_callref++; mncc = create_mncc(MNCC_SETUP_REQ, call_ref); if (!strncasecmp(number, "emerg", 5)) { printf("Make emergency call\n"); mncc->emergency = 1; } else { printf("make call to %s\n", number); mncc->fields |= MNCC_F_CALLED; if(number[0] == '+') { number++; mncc->called.type = 1; /*international*/ } else { mncc->called.type = 0; /*auto-unknown -prefix must be used*/ } mncc->called.plan = 1; strncpy(mncc->called.number, number, sizeof(mncc->called.number) - 1); printf("Calling number %s\n", mncc->called.number); /* bearer capability (mandatory) */ mncc->fields |= MNCC_F_BEARER_CAP; mncc->bearer_cap.coding = 0; mncc->bearer_cap.speech_ctm = 0; mncc->bearer_cap.radio = 3; /** Support TCH/H also*/ /** Supported rates **/ mncc->bearer_cap.speech_ver[i++] = 2; /* support full rate v2 */ mncc->bearer_cap.speech_ver[i++] = 0; /* support full rate v1 */ mncc->bearer_cap.speech_ver[i++] = 1; /* support half rate v2 */ mncc->bearer_cap.speech_ver[i] = -1; /* end of list */ /** END **/ mncc->bearer_cap.transfer = 0; mncc->bearer_cap.mode = 0; /* CC capabilities (optional) DTMF */ mncc->fields |= MNCC_F_CCCAP; mncc->cccap.dtmf = 1; mncc->fields |= MNCC_F_CCCAP; mncc->clir.inv = 1; mncc->clir.sup = 1; } return send_and_free_mncc(mncc->msg_type, mncc); Looking forward to the reply, Thanks, Gerard -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OsmocomBB-MNCC-socket-implementa… Sent from the baseband-devel mailing list archive at Nabble.com.

7 years, 1 month

3
8
0 0

ARM Core and UI

by Anton Gorbachev

Dear Osmocom members, I am new in OsmocomBB but trying to understand how all the stuff works. And I have a question. As I understood we have DigitalBB Calypso in our Motorola phones which consist of DSP and ARM Cores. If we are talking about "normal" phone firmware, In DSP L1 processing is done, in ARM core L2 and L3 processing of GSM stack is done. But we must also have some "regular" OS somewhere, am I right? So I mean all the menus, applications like "Settings", "Phone book", etc. In modern phones, I believe Adnroid or iOS communicate with some RTOS running in ARM core of DigitalBB. But what is about Motorola phone? Does it have separate ARM processor/RAM for a refular firmware? Did you create some applications for ARM part of DigitalBB and some applications for UI which run outside the RTOS? It's possible that I am confusing with all the terms but I would appreciate if you help me to understand. Kind regards, Anton

7 years, 1 month

2
1
0 0

Connecting OSMOCOM to OpenBTS

by Usama Muneeb

I recently set up OpenBTS which is working perfectly. I can make a test call by calling 2600 using an Android phone. However when I try "show subscriber" in OSMOCOM, various BTS are listed, with their MNC and MCC values but OpenBTS is not listed. Any solution to this? P.S. I've determined the MNC and MCC values for OpenBTS which are 001 and 01 respectively.

7 years, 1 month

3
3
0 0

git.osmocom.org cgit improvements

by Harald Welte

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 1 month

3
3
0 0

Complexity of emergency-only baseband development

by Denver Gingerich

Hi everyone, I'm building some FOSS tools that let people send/receive calls/SMS without a cell plan (mainly using VoIP carriers that also offer SMS/MMS). Eventually I would like to be able to bundle these tools with a phone that runs only free software. In order to still provide standard emergency calling features (112/999/911 calling/SMS), the phone would require a free baseband (like OsmocomBB), but it would not need to offer any non-emergency phone features, since those would be handled by the aforementioned FOSS tools primarily on wifi. As I understand it, OsmocomBB can currently be run on certain Calypso-based phones, but does require a larger computer be connected to run part of the baseband. If one were to only require emergency calling features in OsmocomBB, would that larger computer still be required? If so, would developing the remaining pieces needed to run directly on the phone be substantially easier for an emergency-only use case than for a complete all-purpose use case? I'm guessing that there are certain parts of OsmocomBB that would not be required for emergency-only operation (perhaps some of the SIM card communication, for example), but I haven't written baseband software before so I don't have a good sense of how large the differences would be. So I'd be curious to know if the emergency-only use case is substantially easier to develop for, or if it's roughly the same complexity as developing for the all-purpose use case, or somewhere in between. My apologies if this isn't the right list for such questions; I'm happy to post elsewhere if that is more appropriate. Thanks for reading! Denver http://soprani.ca/

7 years, 2 months

3
2
0 0

Quectel modem documentation etc

by Fisher Grubb

Hi all, I know of some publicly available documentation and tools. I assume you have it, let me know if you don't and I'll post links. I downloaded it last year for UC20 (124MB zip file),and EC21 (60MB zip file). Fisher

7 years, 2 months

1
0
0 0

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)

by Sebastian Stumpf

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…). The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…). The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

7 years, 2 months

1
0
0 0

Re: Virtual layer 1 - Questions

by Harald Welte

Hi Sebastian, On Sun, Feb 12, 2017 at 02:29:05PM +0100, Sebastian Stumpf wrote: > The virtual layer 1 is currently in a state where the l23 app can > successfully connect to the bts and most of the signaling messages > will be forwarded and handled. TCH is not yet implemented. this is excellent news! Thanks for sticking with this and pushing it forward. > - Trying to initiate a call via the mobile vty will result in > VTY: > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been rejected > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been released > And no actual call setup message is transfered over the Um interface. > What could be reasons for that? I am using the test-sim option the > mobile app offers. I'm not sure if this is the root cause, but it seems there is some timeslot mis-matches in your traces. The Immediate Assignment contains TS 2 or TS 7, but I see Uplink frames for FACH on TS0, which is impossible (TS0 never has a channel combination with FACCH). Also, The uplink frames don't have the Uplink bit set in the GSMTAP header. This is a bit confusing, and I think it would be a good idea to introduce some consistency/invariant checking on both sides, i.e. the BTS should drop all non-uplink frames received, and the MS should drop all uplink frames received. I'm also surprised to see you're seeing an immediate assignment reject in downlink. This should only happen if all channels are allocated and the BTS is out of resources. Also, in your traces, there are typically several frames that are on the same timeslot in the same GSM frame number. This is not possible (probably related to the wrong TS above?). At maximum, there can be one L2 signalling message for a given TS + FN. Also, on the real radio interface a MAC block takes typically four frames on that channel, so the actual rate is lower. > - Occasionaly the T3210 timer is fired, which causes a new registering > within the network. well, it means that something got lost between MS and MSC for such a long time (between sending the LU REQ and receving a response) that the MS gives up. > LOG: > gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired > How can i prevent that? The underlying problem must be resolved. On the simulated L1 you shouldn't loose messages, so this shouldn't happen if all messages arrive as expected on both sides. > - I did not implement a tdma or multiframe scheduler in the mobile > uplink as the logical channel is directly put to the gsmtap-header and > thus known by the bts. As Harald used a multiframe based scheduling > for the bts downlink, i wonder if this might be necessary, though. To > submit msgs with the correct frame number for example. It is primarily a question of how real the simulation should be. By using a multiframe scheduler one can make sure that the actual bandwidth/speed of GSM is maintained even over a virtual L1. Also, on the BTS side it must be present to schedule the BCCH (system information, ...) without which a MS would never even see the cell. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. > - In my wireshark capture files, the gsmtap messages sent over the > multicast sockets are only recognized as UDP messages. I have to > "cast" them with the wireshark context menu "Decode as...". Why? This seems because you're using a non-standard port for the messages: In the capture I see UDP port 6666 rather than the IANA-registered port for GSMTAP which is 4729. > I would be super happy if someone of you could check out my project > (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch > stumpf/virt-phy) try to run it with the config files lying within the > project folders and tell me the problems they see :). I'll have a look, but not straight away now, sorry. > Here you can find a wireshark capture file of 2 mobiles connecting to > a virt bts. I also tried to init calls from both of them but the call > setup is not send. Already the LU is not working stable, so I think the first step is to stabilize this. You can see in packet 740 that the MS is sneding a LU Req, which the BTS forwards in frame 741 as RSL message to the NITB. The NITB then responds with an IDENTITY REQUEST which can be seen on RSL but which seems to disappear in the BTS without being ever sent on the virtual Um interface. As a result, the MS never sends the identity response, and the NITB will give up. I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. Also, RACH retransmissions are happening way too quick. See Packets 600...644 where there are 7 RACH requests all within soemething like 10ms. The BTS then allocates 7 channels rather than one, ... So I think those lower-layer issues should be addressed before moving on to voice calls. Keep up the good work! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 2 months

2
6
0 0

Re: Flashing Problem: C117

by Craig Comstock

You know that generally flashing the phone isn't needed. You can load all of the different osmocom images just with the osmocon loader into ram and "do things". The flashing can brick your device. Just my $0.02, Craig -------------------------------------------- On Sat, 2/18/17, Dennis Schneck <dennisschneck(a)web.de> wrote: Subject: Flashing Problem: C117 To: baseband-devel(a)lists.osmocom.org Date: Saturday, February 18, 2017, 2:44 AM Hello, i try to Flash a Motorola C117. But did not work ... what did i wrong ? $ sudo host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor target/firmware/board/compal_e88/loader.compalram.bin got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 00 00 .. got 4 bytes from modem, data looks like: 1b f6 02 00 .... got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(target/firmware/board/compal_e88/loader.compalram.bin): file_size=27072, hdr_len=4, dnload_len=27079 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/27079) handle_write(): 4096 bytes (8192/27079) handle_write(): 4096 bytes (12288/27079) handle_write(): 4096 bytes (16384/27079) handle_write(): 4096 bytes (20480/27079) handle_write(): 4096 bytes (24576/27079) handle_write(): 2503 bytes (27079/27079) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! Received DOWNLOAD ACK from phone, your code is running now! battery_compal_e88_init: starting up OsmocomBB Loader (revision osmocon_v0.0.0-1773-g0cdf4b0-modified) ====================================================================== Running on compal_e88 in environment compalram $ sudo host/osmocon/osmoload memdump 0x000000 0x2000 compal_loader.bin [sudo] password for builder: Dumping 8192 bytes of memory at 0x0 to file compal_loader.bin ...................................done. builder@buildervm:~/build/osmocom-bb/src$ sudo host/osmocon/osmoload funlock 0x010000 0x10000 Unlocking 65536 bytes of flash at 0x10000 requesting flash info to determine block layout chip 0 at 0x00000000 of 2097152 bytes in 2 regions region 0 with 31 blocks of 65536 bytes each block 0 with 65536 bytes at 0x00000000 on chip 0 block 1 with 65536 bytes at 0x00010000 on chip 0 block 2 with 65536 bytes at 0x00020000 on chip 0 block 3 with 65536 bytes at 0x00030000 on chip 0 block 4 with 65536 bytes at 0x00040000 on chip 0 block 5 with 65536 bytes at 0x00050000 on chip 0 block 6 with 65536 bytes at 0x00060000 on chip 0 block 7 with 65536 bytes at 0x00070000 on chip 0 block 8 with 65536 bytes at 0x00080000 on chip 0 block 9 with 65536 bytes at 0x00090000 on chip 0 block 10 with 65536 bytes at 0x000a0000 on chip 0 block 11 with 65536 bytes at 0x000b0000 on chip 0 block 12 with 65536 bytes at 0x000c0000 on chip 0 block 13 with 65536 bytes at 0x000d0000 on chip 0 block 14 with 65536 bytes at 0x000e0000 on chip 0 block 15 with 65536 bytes at 0x000f0000 on chip 0 block 16 with 65536 bytes at 0x00100000 on chip 0 block 17 with 65536 bytes at 0x00110000 on chip 0 block 18 with 65536 bytes at 0x00120000 on chip 0 block 19 with 65536 bytes at 0x00130000 on chip 0 block 20 with 65536 bytes at 0x00140000 on chip 0 block 21 with 65536 bytes at 0x00150000 on chip 0 block 22 with 65536 bytes at 0x00160000 on chip 0 block 23 with 65536 bytes at 0x00170000 on chip 0 block 24 with 65536 bytes at 0x00180000 on chip 0 block 25 with 65536 bytes at 0x00190000 on chip 0 block 26 with 65536 bytes at 0x001a0000 on chip 0 block 27 with 65536 bytes at 0x001b0000 on chip 0 block 28 with 65536 bytes at 0x001c0000 on chip 0 block 29 with 65536 bytes at 0x001d0000 on chip 0 block 30 with 65536 bytes at 0x001e0000 on chip 0 region 1 with 8 blocks of 8192 bytes each block 31 with 8192 bytes at 0x001f0000 on chip 0 block 32 with 8192 bytes at 0x001f2000 on chip 0 block 33 with 8192 bytes at 0x001f4000 on chip 0 block 34 with 8192 bytes at 0x001f6000 on chip 0 block 35 with 8192 bytes at 0x001f8000 on chip 0 block 36 with 8192 bytes at 0x001fa000 on chip 0 block 37 with 8192 bytes at 0x001fc000 on chip 0 block 38 with 8192 bytes at 0x001fe000 on chip 0 confirmed operation on chip 0 address 0x00010000, status FAILED operation done Thanks

7 years, 2 months

1
0
0 0

Flashing Problem: target/firmware/board/compal_e88/menu.e88loader.bin mssing

by Dennis Schneck

7 years, 2 months

1
0
0 0

Flashing Problem: C117 - additional info

by Dennis Schneck

7 years, 2 months

1
1
0 0

Flashing Problem: C117

by Dennis Schneck

7 years, 2 months

1
0
0 0

Motorola C117 - Is compal E87 ?

by Dennis Schneck

7 years, 2 months

2
2
0 0

Aw: Re: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed

by Dennis Schneck

7 years, 2 months

2
3
0 0

Aw: Re: Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed

by Dennis Schneck

7 years, 3 months

2
1
0 0

Compile error - osmocom-bb | No package 'libosmocore' found but libosmocore is installed

by Dennis Schneck

Hello, I am suing Manjaro Linux (Arch Linux based) and do not get the osmocom-bb compiled. git clone https://github.com/osmocom/osmocom-bb cd osmocom-bb/src make .... .... checking pkg-config is at least version 0.9.0... yes checking for LIBOSMOCORE... no configure: error: Package requirements (libosmocore) were not met: No package 'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOCORE_CFLAGS and LIBOSMOCORE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [Makefile:69: host/layer23/Makefile] Fehler 1 but libosmocore is compiled and installed ( /usr/local ) $ ls -la /usr/local/include/osmocom/ insgesamt 40 drwxr-xr-x 10 root root 4096 12. Feb 06:45 . drwxr-xr-x 3 root root 4096 12. Feb 06:45 .. drwxr-xr-x 2 root root 4096 12. Feb 06:45 codec drwxr-xr-x 2 root root 4096 12. Feb 06:45 core drwxr-xr-x 2 root root 4096 12. Feb 06:45 crypt drwxr-xr-x 2 root root 4096 12. Feb 06:45 ctrl drwxr-xr-x 3 root root 4096 12. Feb 06:45 gprs drwxr-xr-x 3 root root 4096 12. Feb 06:45 gsm drwxr-xr-x 2 root root 4096 12. Feb 06:45 sim drwxr-xr-x 2 root root 4096 12. Feb 06:45 vty $ ls -la /usr/local/lib/ insgesamt 3408 drwxr-xr-x 3 root root 4096 12. Feb 06:45 . drwxr-xr-x 11 root root 4096 16. Feb 2015 .. -rwxr-xr-x 1 root root 981 12. Feb 06:45 libosmocodec.la lrwxrwxrwx 1 root root 21 12. Feb 06:45 libosmocodec.so -> libosmocodec.so.0.0.0 lrwxrwxrwx 1 root root 21 12. Feb 06:45 libosmocodec.so.0 -> libosmocodec.so.0.0.0 -rwxr-xr-x 1 root root 26968 12. Feb 06:45 libosmocodec.so.0.0.0 -rwxr-xr-x 1 root root 945 12. Feb 06:45 libosmocore.la lrwxrwxrwx 1 root root 20 12. Feb 06:45 libosmocore.so -> libosmocore.so.8.0.0 lrwxrwxrwx 1 root root 20 12. Feb 06:45 libosmocore.so.8 -> libosmocore.so.8.0.0 -rwxr-xr-x 1 root root 441216 12. Feb 06:45 libosmocore.so.8.0.0 -rwxr-xr-x 1 root root 1033 12. Feb 06:45 libosmoctrl.la lrwxrwxrwx 1 root root 20 12. Feb 06:45 libosmoctrl.so -> libosmoctrl.so.0.0.0 lrwxrwxrwx 1 root root 20 12. Feb 06:45 libosmoctrl.so.0 -> libosmoctrl.so.0.0.0 -rwxr-xr-x 1 root root 100072 12. Feb 06:45 libosmoctrl.so.0.0.0 -rwxr-xr-x 1 root root 1021 12. Feb 06:45 libosmogb.la lrwxrwxrwx 1 root root 18 12. Feb 06:45 libosmogb.so -> libosmogb.so.4.0.0 lrwxrwxrwx 1 root root 18 12. Feb 06:45 libosmogb.so.4 -> libosmogb.so.4.0.0 -rwxr-xr-x 1 root root 430400 12. Feb 06:45 libosmogb.so.4.0.0 -rwxr-xr-x 1 root root 969 12. Feb 06:45 libosmogsm.la lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmogsm.so -> libosmogsm.so.6.1.0 lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmogsm.so.6 -> libosmogsm.so.6.1.0 -rwxr-xr-x 1 root root 957032 12. Feb 06:45 libosmogsm.so.6.1.0 -rwxr-xr-x 1 root root 1018 12. Feb 06:45 libosmosim.la lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmosim.so -> libosmosim.so.0.0.0 lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmosim.so.0 -> libosmosim.so.0.0.0 -rwxr-xr-x 1 root root 175416 12. Feb 06:45 libosmosim.so.0.0.0 -rwxr-xr-x 1 root root 969 12. Feb 06:45 libosmovty.la lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmovty.so -> libosmovty.so.3.0.0 lrwxrwxrwx 1 root root 19 12. Feb 06:45 libosmovty.so.3 -> libosmovty.so.3.0.0 -rwxr-xr-x 1 root root 378280 12. Feb 06:45 libosmovty.so.3.0.0 -rw-r--r-- 1 root root 578174 6. Jan 2016 libphysfs.a lrwxrwxrwx 1 root root 14 6. Jan 2016 libphysfs.so -> libphysfs.so.1 lrwxrwxrwx 1 root root 18 6. Jan 2016 libphysfs.so.1 -> libphysfs.so.2.0.3 -rwxr-xr-x 1 root root 340504 6. Jan 2016 libphysfs.so.2.0.3 $ pacman -Ss arm- community/arm-none-eabi-binutils 2.27-2 [Installiert] A set of programs to assemble and manipulate binary and object files for the ARM EABI (bare-metal) target community/arm-none-eabi-gcc 6.3.0-1 [Installiert] The GNU Compiler Collection - cross compiler for ARM EABI (bare-metal) target community/arm-none-eabi-gdb 7.12-3 [Installiert] The GNU Debugger for the ARM EABI (bare-metal) target community/arm-none-eabi-newlib 2.5.0-1 [Installiert] A C standard library implementation intended for use on embedded systems (ARM bare metal) What did i wrong ? Thanks

7 years, 3 months

1
0
0 0

Re: Why not have the “sim spoof MS” command in now OSMOCOM-BB

by Etraud

Hi! Which branch was that code in? Thank you. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Why-not-have-the-sim-spoof-MS-co… Sent from the baseband-devel mailing list archive at Nabble.com.

7 years, 3 months

1
0
0 0

Downtime due FreeBSD upgrade.

by Holger Freyther

Hi, the machine hosting most of *.osmocom.org is running FreeBSD9.3 which EOLed end of december and I would like to upgrade to FreeBSD10.3. I do not expect many problems but I also don't want to interfere with other peoples work. Even if it is short notice, any objections for Saturday->Sunday night of a European timezone? Otherwise I would pick next Friday->Saturday. regards holger

7 years, 3 months

2
2
0 0

osmocom-BB

by salar007

Hi all, 1) Is it possible to increase the number of phones from two to three or more phones as TS in osmocom-BB? plz answer just this question. I strongly need it's answer, if NOT I STOP my working.. 2) what's this ERROR : "DSP Error Status: 24" thank you. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/osmocom-BB-tp4026767.html Sent from the baseband-devel mailing list archive at Nabble.com.

7 years, 4 months

3
2
0 0

Contribute to Osmocom and receive a free 3.5G femtocell

by Harald Welte

Dear all, not everyone might have seen the news item that was posted in late December on our website at http://osmocom.org/news/62 I'm looking forward to receiving your proposal on how you would contribute to the Osmocom project if you were to receive one of those free 3.5G femtocells. Quote of the news item below: ------ So please excuse me to cross-post this over several Osmocom project mailing lists. I know that a number of people have either hacked on femtocells in the past, or at least expressed interest in doing so... Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking on the next level: 3G/3.5G. The key to running your own 3G network is to obtain actual 3G cell hardware -- here is an exciting opportunity to get started: No less than 50 femtocells will be given away for free by sysmocom, one of the main drivers of the Osmocom project. To receive a free 3G femtocell, tell us how you will help the Osmocom project drive 3.5G forward if you had one, before the end of January 2017. This marks the launch of the 3.5G Acceleration Project, backed by the Osmocom community. Join us! Find further details on the 3.5G Acceleration Project and receiving your own 3G femtocell for free at https://sysmocom.de/downloads/accelerate_3g5_cfp.pdf. ------ Best regards and happy hacking, Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

7 years, 4 months

1
0
0 0

Moving from trac to a single redmine

by Holger Freyther

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

7 years, 4 months

8
26
0 0

More phones through Transceiver

by salar007

Hi all, I've a question about transceiver module in osmocomBB.. I'm gonna to increase the number of TS as the number of connected phones.. now I'll be able to sync 2 phones but in order to have more TS => more traffic channel , I should be able to sync more phones as TS , how can I? plz help me.. tanx. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/More-phones-through-Transceiver-… Sent from the baseband-devel mailing list archive at Nabble.com.

7 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel