baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

20 Apr '17

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

5 6

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)
by Craig Comstock 19 Apr '17

19 Apr '17

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.

2 3

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)
by Craig Comstock 13 Apr '17

13 Apr '17

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.

1 0

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)
by Craig Comstock 13 Apr '17

13 Apr '17

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.

2 1

Re: Fun with the MTK 6573 Baseband (Patching / Replacing)
by RootZero 13 Apr '17

13 Apr '17

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.

3 2

FreeCalypso GSM MS development board built and mostly works
by Mychaela Falconia 11 Apr '17

11 Apr '17

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

3 3

Re: Connecting OsmocomBB to OpenBTS
by Vadim Yanitskiy 01 Apr '17

01 Apr '17

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.

2 1

Re: ARM Core and UI
by Vadim Yanitskiy 29 Mar '17

29 Mar '17

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.

1 0

OsmocomBB MNCC socket implementation without LCR
by Gerard Pinto 29 Mar '17

29 Mar '17

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.

3 8

ARM Core and UI
by Anton Gorbachev 29 Mar '17

29 Mar '17

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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel