From technosabby at gmail.com Sat Oct 2 12:17:45 2010 From: technosabby at gmail.com (Marten Christophe) Date: Sat, 2 Oct 2010 12:17:45 +0000 Subject: OsmocomBB.TCH. In-Reply-To: <4ca45018.mirider@mirider.augusta.de> References: <4ca45018.mirider@mirider.augusta.de> Message-ID: Hello All, And thank you so much , Mr. Spaar, for your valuable time. I'm doing a bit different work then normal phone software developing, here my objective is, for my practical, TO tune to a particular ARFCN or desired ARFCN, and then picking the burst from TDMA frame, with desired TS. something like , assignment message does from BTS to set it in osmocomBB software like ARFCN, channel , subchannel , TS, hopping parameter like HSN, MIO and sequencing , ciphering, ets. I wish to develop a API which can configure my phone by inserting these values , but I'm running short on programming skills, also have no idea which resister values get change of DSP. also all this i need to done along with DSP functionality to fetch TCH burst from specific TS or subchannel , and process it to DBB and produce and deliver audio / data(by analogue modulation) by its speakers. but all without ciphering, by doing this i will have fully configurable radio around 35 KM range . with amassing prince only @ $5 - 8 for this filter level adjustment done to receive up link frequency range at 900Mh, also used Rita PLL VCO divider table. again, can any one tell me the parameter advised by assignment command (fromBTS) massage is read by DSP or ARM , and how they processed, also which all resistors need to manipulate to do manual configuration i think Mr. Spaar have test code which just fix to a AFRCN and TS , so if we need to change these, values we need to change it in source code and burn binary within c123 ram.? but still it will be help me to understand which part he tuched to tune DSP, and received 20 minutes voice call. if i can get that test code i will be grateful for the same. >You have to write your one code if you want to do this without Signalling <<<< .being involved. >You can use the L1CTL API to setup a TCH with your own code, but its >probably easier to setup the TCH with signalling (either MOC or MTC), <<<<<<<< >this way you don't need to modify the code and still get the TCH running. Kindly advise me if I'm not irritating you, what do u mean by signalling ? or suggest me some document to learn more about it. Thank you , Bien cordialement, -------------- next part -------------- An HTML attachment was scrubbed... URL: From technosabby at gmail.com Sat Oct 2 12:26:25 2010 From: technosabby at gmail.com (Marten Christophe) Date: Sat, 2 Oct 2010 12:26:25 +0000 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> Message-ID: > Hello All, > > And Thank you so much , Mr. Spaar, for your valuable time. > > I'm doing a bit different work then normal phone software developing, > here my objective is, for my practical, > TO tune to a particular ARFCN or desired ARFCN, and then picking the burst > from TDMA frame, with desired TS. > > something like , assignment message does from BTS to set it in osmocomBB > software (or normal MS) > like > ARFCN, channel , subchannel , TS, hopping parameter like HSN, MIO and > sequencing , ciphering, ets. > > I wish to develop a API which can configure my phone by inserting these > values , but I'm running short on programming skills, also have no idea > which resister values get change of DSP. also all this i need to done along > with DSP functionality to fetch TCH burst from specific TS or subchannel , > and process it to DBB and produce and deliver audio / data(by analogue > modulation) by its speakers. > > but all without ciphering, > > by doing this i will have fully configurable radio around 35 KM range . > with amassing prince only @ $5 - 8 > for this filter level adjustment done to receive up link frequency range at > 900Mh, also used Rita PLL VCO divider table. > > again, can any one tell me the parameter advised by assignment command > (fromBTS) massage is read by DSP or ARM , and how they processed, also > which all resistors need to manipulate to do manual configuration > i think Mr. Spaar have test code which just fix to a AFRCN and TS , so if > we need to change these, values we need to change it in source code and > burn binary within c123 ram.? but still it will be help me to understand > which part he tuched to tune DSP, and received 20 minutes voice call. if i > can get that test code i will be grateful for the same. > > > >You have to write your one code if you want to do this without > Signalling <<<< > .being involved. > > >You can use the L1CTL API to setup a TCH with your own code, but its > >probably easier to setup the TCH with signalling (either MOC or MTC), > <<<<<<<< > >this way you don't need to modify the code and still get the TCH running. > > Kindly advise me if I'm not irritating you, what do u mean by signalling > ? or suggest me some document to learn more about it. > > Thank you , > Bien cordialement, > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Oct 2 13:22:40 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 2 Oct 2010 15:22:40 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> Message-ID: Hi, > I?wish to develop a API which can configure my phone by inserting these > values , but I'm?running short on programming skills, Well you may want to learn to program first. (I don't mean to sound harsh, but please, _do_ learn the basics first !) Then learn about how the phone itself works by reading the code, and then try to hack it to do your bidding. > by?doing this i will have fully configurable radio around 35 KM range?. with > amassing prince only?@ $5 - 8 You're a little optimistic. 35km range works because one of the side (the BTS) is high up above the ground and has a huge antenna. When both sides are close to the ground with essentially 0dB antenna, it's not gonna be so great. Also, your radio won't work where there is no common cell phone coverage at both location. For this application you need clock sync between the two mobile. You're also gonna need to remove the RX filters on one of the phone to RX in the uplink band. So you need precise soldering skills. (believe me, I've done it :) Alternatively you could TX in the downlink band, which require no soldering and doesn't even involve out of spec tuning since PCS1900 uplin covers part of DCS1800 downlink. >?also which all?resistors need to manipulate to do manual configuration resistors ? GSM are a little more modern than that ... they don't have tuning potentiometers ... They use a VXCO controlled by a DAC and a PLL to select the frequency. > i think Mr. Spaar have test code which just fix to ?a AFRCN and TS , so if We all have test code to do various stuff, but it's often hacked up together on the moment we need it and we don't necessarily keep it around. Tuning to a specific channel is pretty easy. And it's far from all that needed to turn a GSM into a two way radio. Cheers, Sylvain PS: Could you try not to send your messages twice ? From technosabby at gmail.com Sun Oct 3 20:54:45 2010 From: technosabby at gmail.com (Marten Christophe) Date: Sun, 3 Oct 2010 20:54:45 +0000 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> Message-ID: Hello Sylvain , Apologies to disturb you people. I can see you all are too busy to give this osmocombb a final shape. good luck , i again say it was gra8 idea and gr8 work. Also thanks to clear up my mind doubts and misconceptions. ===== I just seeking list members help to give me advise only where to start in order to create a API to tune specific ARFCN and TS when DSP is configured in Speech processing mode, though i have check you source code and it is easy to understand from where to change the parameter to change ARFCN , even layer2/3 is able to do that, but whether DSP flags/resistors will be in TCH burst reception mode. i could understand so far that TPU will be involved somewhere, but only stucked at point where i'm suspecting if the present source code hacked and i change ARFCN and TS if DSP(Calypso ) will be in TCH/ speech coding mode or not ? whether Layer 2/3 application will change ARFCN but still keeps DPS in fictionally to process GSM burts to TCH/Speech and can change to Audio , what interrupts/flags/register used to fetch the burst from ADC in ABB , how does it sequenced and done BB processing, even TSM30Layer1 is not providing good idea can any one plz help me to suggest docks or links from where i can understand how DSP( process Immediate assignment command.) you know the most difficult part is GSM burst processing that include alot many thing no need to discuss right not even GSM BB processing i tried to write DSP block in matlab and Labviev, but was so difficult, there was the quarter bit issue which for delay insertion bcoz the guard period is contains 1/4 bit, and pedding of this is not possible in both of them. hence i searched the net and find this project .. PS just enligten my path so , that i Can devlop API to enter ARFCN TS and processes GSM (TCH) burts from a specific timeslot and process DBB to TCH/Speech. > also which all resistors need to manipulate to do manual configuration >resistors ? >>>> GSM are a little more modern than that ... they don't have tuning >>>>potentiometers ... it was typo error , uff register , I never meant this as potentiometers , and rita_pll is giving me good idea , also i seen your ./bcch_scan, and understand how the frequency getting change. in source code files. even i have done too many things with No---kia's 3210 RF section, even i have control the RF Base Band HAGAR_3, through Atmel micro controller and my PC . though Hagar reset generation was difficult part, again the problem arises to fetch data from the CONT a ADC in 3210. there is nothing inside the RF Base Band HAGAR_3, but Nationals LMX23xx series PLL. ohh but it,s getting something out of topic, sorry for that. Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sun Oct 3 21:22:39 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 3 Oct 2010 23:22:39 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> Message-ID: <20101003212239.12677.qmail@stuge.se> Marten Christophe wrote: > I can see you all are too busy to give this osmocombb a final shape. I think you misunderstand the way open source works. If *you* want OsmocomBB to have some particular shape, then it is *your* responsibility to make that happen. Also keep in mind that a lot of open source work is done on people's spare time, for free, for fun, which of course again means that *you* yourself have to make the project suit *your* needs. You can only do so in close cooperation with the project members, if you go out on your own and do this without any collaboration then you have created what is called a fork, and your changes will most likely not be accepted into the project. Maybe this means that open source is not an acceptable way for you to work. Too bad, I think it could save a lot of time, and life is short. //Peter From technosabby at gmail.com Mon Oct 4 02:03:53 2010 From: technosabby at gmail.com (Marten Christophe) Date: Mon, 4 Oct 2010 02:03:53 +0000 Subject: OsmocomBB.TCH. In-Reply-To: <20101003212239.12677.qmail@stuge.se> References: <4ca45018.mirider@mirider.augusta.de> <20101003212239.12677.qmail@stuge.se> Message-ID: Hello Peter, Thank you for your Reply, > I can see you all are too busy to give this osmocombb a final shape. plz don't take me Wong, by this i men to say , these people are already busy and I'm just disturbing them ... see, i'm not asking some one should develop custom application for me , but i just want a hint , you know some times .. you need to read a thousand pages to understand some thing , but only a hint from expert can enlighten your path to right direction.. I'm reading for hard work but only .. a hint required from where should i start.. what all subjects should be referred. can you do me a favor tell me how can i tune to specific or desired TS Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Oct 4 06:09:38 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 4 Oct 2010 08:09:38 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> <20101003212239.12677.qmail@stuge.se> Message-ID: > can you do me a favor tell me how can i tune to specific or desired ?TS Well, Dieter _told_ you in his first reply: look at the L1CTL API ... Sylvain From bouchtaoui at gmail.com Mon Oct 4 07:43:36 2010 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 04 Oct 2010 09:43:36 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca45018.mirider@mirider.augusta.de> <20101003212239.12677.qmail@stuge.se> Message-ID: <4CA985A8.6000401@gmail.com> Maybe he needs just a simple example how you guys do that. That might help him to see some logic in the code and can pick it up quickly. Also, you never know what experience he has, maybe with some help he can help you back more. But than again, it's all up to your free time, which is always too short. On 4-10-2010 8:09, Sylvain Munaut wrote: >> can you do me a favor tell me how can i tune to specific or desired ? TS > Well, Dieter _told_ you in his first reply: look at the L1CTL API ... > > > Sylvain > > From spaar at mirider.augusta.de Mon Oct 4 11:38:55 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 04 Oct 2010 11:38:55 CEST Subject: OsmocomBB.TCH. Message-ID: <4ca9bccf.mirider@mirider.augusta.de> Hello Nordin, On Mon, 04 Oct 2010 09:43:36 +0200, "Nordin" wrote: > Maybe he needs just a simple example how you guys do that. That might > help him to see some logic in the code and can pick it up quickly. Also, > you never know what experience he has, maybe with some help he can help > you back more. But than again, it's all up to your free time, which is > always too short. The code I used when I started to implement the TCH in Layer-1 will no longer work with the current version of OsmocomBB so it is of no help. This means I have to rewrite it and test it to be sure that it works as expected which will take some time, time as you already mentioned, is my free time and this free time is valuable. I have the impression that in this case a quite detailed explanation including a working example is necessary and some hints won't help but only result in more questions. Although it might sound harsh, but knowledge in GSM and being able to read/understand/modify foreign source code is necessary, noone can expect this to learn here by asking the list. If one takes OsmocomBB as it is and registers to a cell and makes a call, the logging output should give a lot of hints what calls to L1CTL have to be done. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From technosabby at gmail.com Mon Oct 4 19:47:45 2010 From: technosabby at gmail.com (Marten Christophe) Date: Tue, 5 Oct 2010 01:17:45 +0530 Subject: OsmocomBB.TCH. In-Reply-To: <4ca9bccf.mirider@mirider.augusta.de> References: <4ca9bccf.mirider@mirider.augusta.de> Message-ID: Thanks Nordin, Deiter, Sylvain, So nice you people are, >The code I used when I started to implement the TCH in Layer-1 will >no longer work with the current version of OsmocomBB so it is of >no help. This means I have to rewrite it and test it to be sure I'm Keeping the copies of OsmocomBB source code, from Ari 2010. l onwards , with almost 5 -6 days interval i saved it to local drive with date tag, as i seen few of similar project were shut down due to legal issue hence i kept copy. thus i have more then 15 source code with date( of main branch), so far, including the one you enabled the TCH in August. month. will it work? like if replacing some files. . also i just want to know there is some branches in source code apart from main branch. can it be download and workable ? Kind regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Oct 4 19:55:41 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Oct 2010 21:55:41 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> Message-ID: <20101004195541.11594.qmail@stuge.se> Marten Christophe wrote: > I'm Keeping the copies of OsmocomBB source code, from Ari 2010. l > onwards , with almost 5 -6 days interval i saved it to local drive I'd suggest that you clone the git repository instead. Then you have the complete code history, and a very powerful tool to work with it. :) git clone git://git.osmocom.org/osmocom-bb.git //Peter From technosabby at gmail.com Mon Oct 4 20:06:28 2010 From: technosabby at gmail.com (Marten Christophe) Date: Tue, 5 Oct 2010 01:36:28 +0530 Subject: OsmocomBB.TCH. In-Reply-To: <20101004195541.11594.qmail@stuge.se> References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: Hello Peter, I just want to know, as Mr. Deiter replied in his mail, that, current version will not work for my purpose so i have almost, 15 copy of git clone git://git.osmocom.org/osmocom-bb.git, date wise , means i have old source code also, i remember that Mr. Deiter had deployed the TCH support in August , and right after i made a copy of it , will that work any ways with some small hacks ? keeping right from April to till date. from the same link advised by you. right now I'm traveling , for collecting fund for a NGO , so might i have no Internet access in remote areas.. it is a developing nation Thanks for you time, Kind Regards, On Tue, Oct 5, 2010 at 1:25 AM, Peter Stuge wrote: > Marten Christophe wrote: > > I'm Keeping the copies of OsmocomBB source code, from Ari 2010. l > > onwards , with almost 5 -6 days interval i saved it to local drive > > I'd suggest that you clone the git repository instead. Then you have > the complete code history, and a very powerful tool to work with it. > :) > > git clone git://git.osmocom.org/osmocom-bb.git > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Oct 4 20:13:13 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 4 Oct 2010 22:13:13 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: > I just want to know, as Mr. Deiter replied in his mail, that, current > version will not work for my purpose so i have almost, > 15 copy of git clone git://git.osmocom.org/osmocom-bb.git, And what Pete pointed out is that _each_ of those clone actually has the entire history and can be used to revert back to any previous version of the code back to it's origins .... And Dieter's code probably worked on some internal version of the code that were never even commited on the public tree and he may not even have any more ... So would you _please_ open the damn code and search for L1CTL and more precisely L1CTL_DM_REQ and read it ... Oh and btw, the main branch _doesn't_ have TCH or audio support ... use the sylvain/testing branch for now. Sylvain From technosabby at gmail.com Mon Oct 4 21:09:34 2010 From: technosabby at gmail.com (Marten Christophe) Date: Tue, 5 Oct 2010 02:39:34 +0530 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: > > Hello All, > > How can i download the source code for sylvain/testing branch . > to my PC ? > > I just downloaded git://git.osmocom.org/osmocom-bb.git, > but it is not reflecting / having the file addition and modification or > the changes sylvain/testing branch commited one hour before. > > is there any new trunck for this. or other command then git clone git:// > git.osmocom.org/osmocom-bb.git, > > Kind Regards, > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Mon Oct 4 21:38:04 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 4 Oct 2010 23:38:04 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: Hi You should learn more about git. Let me google that for you: http://git-scm.com/ Sebastien On Mon, Oct 4, 2010 at 11:09 PM, Marten Christophe wrote: > > >> Hello All, >> >> How can i download the source code for sylvain/testing branch . >> to my PC ? >> >> I just downloaded git://git.osmocom.org/osmocom-bb.git, >> but it is not reflecting / having the file addition and modification or >> the changes sylvain/testing branch commited one hour before. >> >> is there any new trunck for this. or other command then git clone git:// >> git.osmocom.org/osmocom-bb.git, >> >> Kind Regards, >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Oct 4 21:45:11 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 05 Oct 2010 05:45:11 +0800 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: <4CAA4AE7.10303@freyther.de> On 10/05/2010 05:09 AM, Marten Christophe wrote: Dear Marten, your ambition and knowledge appear to have quite a gap. I understand that a SCM like GIT, Cross-Compiling for Embedded Firmware, GSM, C is all a bit too much at the same time. Maybe you should re-consider your goal and start with something simple? E.g. understanding the concept of a branch and being able to compile sylvians code, then use wireshark to look at packets coming from the network? regards holger From technosabby at gmail.com Tue Oct 5 12:24:44 2010 From: technosabby at gmail.com (Marten Christophe) Date: Tue, 5 Oct 2010 17:54:44 +0530 Subject: OsmocomBB.TCH. In-Reply-To: <4CAA4AE7.10303@freyther.de> References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> Message-ID: Hello All, > I have cross compiled my code, long time back and it is running successfully on my c123, done all prerequisite like libtoolchan and ARM elf cross compiling. Layer1.bin , even i run ./bcc_scan and all other commands. successfully. I compiled the code downloaded from * git://git.osmocom.org/osmocom-bb.git, but as Sylvain suggested me the TCH support is available only in *sylvain/testing branch for now. i again downloaded new copy *git://git.osmocom.org/osmocom-bb.git, from and manually verified the file he done changes like layer1/makefile but the changes was not present hence , my question is very simple, how i can download codes for ** *sylvain/testing branch or if there is something other method to compile * ** *sylvain/testing branch, kindly advise me plz. Hello Mr. Deiter, Yes i want to get same TCH on all mobile a BTS is transmitting , Plz Plz ,Kindly elobarate me MOC or MTC stand for. if you have some spare time Kindl Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Tue Oct 5 12:48:06 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Tue, 5 Oct 2010 14:48:06 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> Message-ID: Hi, the git:// thing you downloaded contains what you need. but please learn how to use git and switch to another branch. this is what you need to do. It will be useful for your own global IT culture. Sebastien On Tue, Oct 5, 2010 at 2:24 PM, Marten Christophe wrote: > Hello All, > > >> I have cross compiled my code, long time back and it is running > successfully on my c123, done all prerequisite like libtoolchan and ARM elf > cross compiling. > Layer1.bin , even i run ./bcc_scan and all other commands. successfully. > > I compiled the code downloaded from * > git://git.osmocom.org/osmocom-bb.git, > > but as Sylvain suggested me the TCH support is available only in *sylvain/testing > branch for now. > > i again downloaded new copy *git://git.osmocom.org/osmocom-bb.git, from > and manually verified the file he done changes > > like layer1/makefile > > but the changes was not present hence , my question is very simple, how i > can download codes for ** *sylvain/testing branch > or if there is something other method to compile * ** *sylvain/testing > branch, kindly advise me plz. > > Hello Mr. Deiter, > > Yes i want to get same TCH on all mobile a BTS is transmitting , > > Plz Plz ,Kindly elobarate me MOC or MTC stand for. > if you have some spare time > > Kindl Regards, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Tue Oct 5 13:28:46 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 05 Oct 2010 15:28:46 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> Message-ID: <4CAB280E.1040407@gmail.com> On 5-10-2010 14:24, Marten Christophe wrote: > Hello All, > > >> I have cross compiled my code, long time back and it is running > successfully on my c123, done all prerequisite like libtoolchan and ARM elf > cross compiling. > Layer1.bin , even i run ./bcc_scan and all other commands. successfully. > > I compiled the code downloaded from * git://git.osmocom.org/osmocom-bb.git, Maybe you already did that, but do something like this: git clone git://git.osmocom.org/osmocom-bb.git This copies master branch to your local system. To see all branches do following, First cd to the newly created directory from git and than: git branch -a This will list all the branches, those remote branches are prefixed with origin/ You can than create a new branch based on the sylvain branch like this: git checkout -b sylvain_testing origin/sylvain/testing Now you created a local branch called sylvain_testing with a copy of origin/sylvain/testing If you do: git branch , you'll see a master branch and sylvain_testing branch. The one prefixed with *, that's the branch you are on at the moment. You should be at sylvain_testing branch. From there on, compile, build or whatever on that branch. I hope this helps, success. From technosabby at gmail.com Tue Oct 5 18:37:06 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 6 Oct 2010 00:07:06 +0530 Subject: OsmocomBB.TCH. In-Reply-To: <4CAB280E.1040407@gmail.com> References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> Message-ID: Hello Mr. Nordin, So nice of you, thanks it worked perfectly. End Mr. Dieter , Thank you alot No need to tell me about MOC and MTC ,i searched internet and got plenty of understanding, well, i let me introduce you all my work here , i'm assosiated with a NGO, who works for education of poor children specially located to very remote sites of the devloping or under develop poor countries. and students, have travel long distance for there schooling , you wont belive that some of the villages are on mountain, end even childrens have cross rivers tgrogh rope , hanging on a spin roller , can you imagin the situation. and most of the student give up their education. My future plans are : Hence a top Tecchnelogical and Engineering instititute and a Local top IT and computer manafaturing company along with my NGO, are developing a $10 note book computer, just for edcational purpose , and will be distributed them for free .(60% bearing the local govt.) these notebooks will be install with their 6 moth curricular( one semester or term) all course material will be pre-installed. the fedaral goverments will also be helping in this purpose. who will ask local telecommunication athourities , to provide us,at least one ARFCN , without licensing fee, but there is no intrastucture for internet and in some villages no PSTN or mobile network available My planning here is to setup a USRP1( i have to write Matt Ettus to provide it on concessional price , cause it is for charity) based BTS , at each visnity of a village, which might cover near by villages also. I know, Timing Advance and power control will challenge for me, but i'll overcome the same , as far as RX part is concerned , it wont be a huge problem because one village is less then 1 KM redious , if USRP BTS installed in center. will install compal based hardware, within, notebook, pre-tuned it to a fix Time slot (TS), most of the traffic will be from BTS to MS , we will left only one or 2 TX slot , and will be share amoung all the students in token ring fashion ( let say there is 15 students are in one visnity if any on student want to ask any question to their remote teachers (mostly volunteers, or Govt add) located in NGO'S head office) all USRP's backbone pipe/link will be interconnected through RF links ( a Israel based company have very cheap solution for small bandwidth RF connectivity ) finally this backbone pipe/link will terminate at nearest city or place where Internet facility is available. and all the traffic will be routed to NGO's head quarter. so for this we need only 64 KB max bandwidth. that we can afford. thats it , by this we are able to provide secondary education even children are at their home. at first we thout to install a IP DSLAM but the price and copper cost (to provide line to each student is so high and out of budget) in future i can enable GPRS functionality of compal and might able to provide Internet access too, to them but we have to put higher bandwidth Backbone , so its not in my list now. Wish me luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Oct 5 18:50:40 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 5 Oct 2010 20:50:40 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> Message-ID: <20101005185040.16309.qmail@stuge.se> Marten Christophe wrote: > developing a $10 note book computer I hope you are aware of the OLPC project, because you seem to share some of the same goals. See http://laptop.org/ > fedaral goverments will also be helping in this purpose. who will > ask local telecommunication athourities , to provide us,at least > one ARFCN, without licensing fee, .. > setup a USRP1 based BTS .. which might cover near by villages also. .. > will install compal based hardware, within, notebook, pre-tuned it to > a fix Time slot (TS), most of the traffic will be from BTS to MS , we > will left only one or 2 TX slot Did you research other RF interfaces than the one used by GSM? > ( a Israel based company have very cheap solution for small > bandwidth RF connectivity ) Define cheap and small bandwidth? //Peter From technosabby at gmail.com Tue Oct 5 19:10:42 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 6 Oct 2010 00:40:42 +0530 Subject: OsmocomBB.TCH. In-Reply-To: <20101005185040.16309.qmail@stuge.se> References: <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005185040.16309.qmail@stuge.se> Message-ID: Hi Peter, I hope you are aware of the OLPC project, because you seem to share some of the same goals. See http://laptop.org/ > > Yes I'm .... and HCL is taken up into manufacture it > setup a USRP1 based BTS .. which might cover near by villages also. With 11 dbi Anettena and appropriate PA . we can do it up 5 to 10 KM ( send a mail to Ettus) >Did you research other RF interfaces than the one used by GSM? Yes , and are legacy . need higher bandwidth. and Why I'm not thinking for Armature radio or Air broadcasting .. it is only One way..and other drawbacks do you have any suggestion ? >>> Define cheap and small bandwidth? They have very cheap equipments ( out of store almost) for providing low bandwidth. like 64 Kbps, 54 Kbps even 9 Kbps RF interface. on demand they can supply. you will be kind enough you you give me other cheap solution after all its all for charity.. rather then GSM , and one more cause to attract me here is in some places we have GSM infrastructure and , Govt and some private operator will let us user some part of it. Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Tue Oct 5 19:39:40 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Tue, 5 Oct 2010 21:39:40 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005185040.16309.qmail@stuge.se> Message-ID: Hi, Your project purpose is very interesting. however I hope you are not alone to implement it, and you know people that can help you for the technical choices. I wouldn't neglect the amateur radio technology in your case. The main problem is not technical but regulatory because every operator need to be licenced: there is a small exam. Government support may help somewhere to get authorizations for your group, I'm not a legal expert. Apart from that, you can establish bidirectional audio links with very basic techniques, nothing as complex as gsm. internet access can also be provided by amateur service thanks to packet radio, 9600bps is common and may be upgradeable. and amateur low frequency bands have a far longer range than GSM's UHF bands. you should speak about your project to amateur communities. Just to know what they think about it. I wish you success. Regards Sebastien On Tue, Oct 5, 2010 at 9:10 PM, Marten Christophe wrote: > Hi Peter, > > > I hope you are aware of the OLPC project, because you seem to share > some of the same goals. See http://laptop.org/ > >> >> Yes I'm .... and HCL is taken up into manufacture it > > > > > > setup a USRP1 based BTS .. which might cover near by villages also. > > With 11 dbi Anettena and appropriate PA . we can do it up 5 to 10 KM ( > send a mail to Ettus) > > > >Did you research other RF interfaces than the one used by GSM? > > Yes , and are legacy . need higher bandwidth. > and Why I'm not thinking for Armature radio or Air broadcasting .. it is > only One way..and other drawbacks > > do you have any suggestion ? > > > >>> Define cheap and small bandwidth? > They have very cheap equipments ( out of store almost) for providing low > bandwidth. like 64 Kbps, 54 Kbps even 9 Kbps RF interface. > > on demand they can supply. > > you will be kind enough you you give me other cheap solution after all its > all for charity.. > > rather then GSM , > > and one more cause to attract me here is in some places we have GSM > infrastructure and , Govt and some private operator will let us user some > part of it. > > Kind Regards, > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Oct 5 19:40:13 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 5 Oct 2010 21:40:13 +0200 Subject: Overloading sanctioned private networks on GSM In-Reply-To: References: <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005185040.16309.qmail@stuge.se> Message-ID: <20101005194013.21575.qmail@stuge.se> Marten Christophe wrote: > >Did you research other RF interfaces than the one used by GSM? > > Yes , and are legacy . need higher bandwidth. If all you looked at was legacy solutions with too low bandwidth for your needs then obviously you should look for further solutions. :) Some research in the particular area of long distance using variations of WiFi: http://tier.cs.berkeley.edu/drupal/wireless http://tier.cs.berkeley.edu/drupal/publications#wireless They used to have a wiki, but I guess they've changed their site structure and have not yet updated all links. Archived pages: http://web.archive.org/web/20070613191117/http://tier.cs.berkeley.edu/wiki/Wireless http://web.archive.org/web/20080527020040/http://tier.cs.berkeley.edu/wiki/Publications:Abstracts > and Why I'm not thinking for Armature radio or Air broadcasting .. > it is only One way..and other drawbacks I don't believe your idea of amateur radio is very accurate. Actually I don't think amateur radio has ever been about one way communication. :) Broadcasting is, but maybe that's also something your application can benefit from if governments help with spectrum. > do you have any suggestion ? I think that using GSM in this application is a hack, with both the good and bad things that implies. I think the plan can work, and it does have some advantages, but more importantly I think that all the disadvantages, some of which may be significant, must be evaluated carefully before investing too much in the idea. The advantages are probably mostly non-technical. The disadvantages are mostly technical. (E.g. you already know it does not scale.) > >>> Define cheap and small bandwidth? > They have very cheap equipments ( out of store almost) for providing > low bandwidth. like 64 Kbps, 54 Kbps even 9 Kbps RF interface. So it seems that you should have a closer look at the work by TIER. > you will be kind enough you you give me other cheap solution after > all its all for charity.. I can't give you any solution at all, but I am trying to point out that there may be quite significant and relevant research and publically available resources which you seem to have been overlooking completely in the project so far. This suggest that you need to do (much) more research. > and one more cause to attract me here is in some places we have GSM > infrastructure and , Govt and some private operator will let us > user some part of it. This is one of the significant non-technical advantages of using GSM for your project. On the other hand, if you can create something else which is much better and comes at much lower cost, then there's much less of an advantage. //Peter From technosabby at gmail.com Tue Oct 5 22:08:09 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 6 Oct 2010 03:38:09 +0530 Subject: Overloading sanctioned private networks on GSM In-Reply-To: <20101005194013.21575.qmail@stuge.se> References: <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005185040.16309.qmail@stuge.se> <20101005194013.21575.qmail@stuge.se> Message-ID: Hi Peter, Thanks *S?bastien*, Thanks *Benjamin, It looks some useful let me understand this *Yes , I'm alone for this project as my NGO's planned for installing the, course-ware and distribute them. but I'm insisting , this interactive feature , and hardly i get permission for pilot work and no one here from Telecommunication field , and as technical as I'm. if i could not prof my self they will go as previous plan. means students have to visit nearest center for help. if i successful demonstrate only then the company who is manufacturing this will be ready to install compal hardware within it we can't insist them also coz they are working on this project for no loss no profit. Thanks all for help, i will PM you from next time , if i need any help from you , coze i dont feel this mailing list is right place to discuss this, before Harald scold me i should pack-up :) >If all you looked at was legacy solutions with too low bandwidth for >your needs then obviously you should look for further solutions. :) Forgive me for my english Legacy means proprietary equipments, solutions and technology. and deliver more bandwidth then required. so its useless spending money.. when you already in lacking. already modification to $10 OLPC hardware reached it around 6 times high.( to accommodate course ware for intermediate schooling and player) this is not as same as OLPC. it's much facilitated.(i should not disclose its under development) >I don't believe your idea of amateur radio is very accurate. Actually >I don't think amateur radio has ever been about one way >communication. :) Broadcasting is, but maybe that's also something >your application can benefit from if governments help with spectrum. I don't mean to say it cant, communicate bi directional, but limitation is there , who will tune it ? in remote villages, also how costly it will to provide a ameture or hame radio set to each student? where as the compal mother board only ( dont need LCD, keypad enclosure) and as i searched they have it in production until 2009 might give me under $5. at least i can gather 10-15 from obsolete , repairing even junk seller shops form my pilot projet so i drooped the Idea. there are few contries where even in single region more then 4-5 regional languages spoken. initially we will start 2 regional language channels on each TS of a single ARFCN, in just 200KHz b/w, we have 7 TS. means 7 channels, every regional language will be associated to specific TS and ARFCN, will be configured at the time of production. for pilot project. think it like this , One lecture being broadcasting on TS-1, 20 students are tuned to it. In the same ARFCN one TX slot free and they will use it to ask question , and it will obvious that students ask question one by one, even in normal classes. so i don't need continuous two way communication. , transmitting part will be shared among all 20 or more. Kind Regards, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.grela at gmail.com Wed Oct 6 08:07:52 2010 From: maciej.grela at gmail.com (Maciej Grela) Date: Wed, 6 Oct 2010 10:07:52 +0200 Subject: Overloading sanctioned private networks on GSM In-Reply-To: References: <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005185040.16309.qmail@stuge.se> <20101005194013.21575.qmail@stuge.se> Message-ID: 2010/10/6 Marten Christophe : > Hi Peter, > > Thanks? S?bastien, > > Thanks Benjamin, > > It looks some useful let me understand this > > Yes , I'm alone for this project as my NGO's? planned for installing the, > course-ware and distribute them. > but I'm insisting , this interactive feature , and hardly i get permission > for pilot work > > and no one here from Telecommunication field , and as technical as I'm. if i > could not prof my self they will go as previous plan. > means students have to visit nearest center for help. > if i successful demonstrate only then the company who is manufacturing this > will be ready to install compal hardware within it > we can't insist? them also coz they are working on this project for no loss > no profit. > > > Thanks all for help, i will PM you from next time? , if i need any help from > you , coze i dont feel this mailing list is right place to? discuss this, > > before Harald scold me i should pack-up :) > >>If all you looked at was legacy solutions with too low bandwidth for >>your needs then obviously you should look for further solutions. :) > Forgive me? for my english Legacy means proprietary equipments, solutions > and technology. > and deliver more bandwidth then required. so its useless spending money.. > when you already in lacking. > already modification to $10 OLPC hardware reached it around 6 times high.( > to accommodate course ware for intermediate schooling and player) > this is not as same as OLPC. it's much facilitated.(i should not disclose > its under development) >>I don't believe your idea of amateur radio is very accurate. Actually >>I don't think amateur radio has ever been about one way >>communication. :) Broadcasting is, but maybe that's also something >>your application can benefit from if governments help with spectrum. > I don't mean to say it cant, communicate bi directional, but limitation is > there , who will tune it ? in remote villages, > also how costly it will to provide a ameture or hame radio set to each > student? > where as the compal mother board only ( dont need LCD, keypad enclosure) and > as i searched they have it in production until 2009 > might give me under $5. at least i can gather 10-15 from obsolete , > repairing even junk seller shops form my pilot projet > so i drooped the Idea. > there are few contries where even in single ? region? more then 4-5 > regional? languages spoken. > > initially we will start 2 regional language channels on each TS of a single > ARFCN, in just? 200KHz b/w, we have 7 TS. > means 7 channels, every regional language will be associated to specific TS > and ARFCN, will be configured at the time of production. > for pilot project. > think it like this , One lecture being broadcasting on TS-1, ? 20 students > are tuned to it. In the same ARFCN one TX slot free and they will use it to > ask question , and it will obvious that students ask question one by one, > even in normal classes. > > so i don't need continuous two way communication. ,? transmitting part will > be shared among all 20 or more. > Aren't you reinventing PoC (http://en.wikipedia.org/wiki/Push_to_talk) ? It may prove easier to base your work on that. Best regards, Maciej Grela From benny at benny.de Tue Oct 5 21:22:01 2010 From: benny at benny.de (Benjamin Hagemann) Date: Tue, 5 Oct 2010 23:22:01 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> Message-ID: <20101005212201.GH16932@quelle.benny.de> Hello Marten, do you know "Village Telco"? http://www.villagetelco.org/ They use wifi for data and voice connections in a mesh network with low-cost hardware and open source software. Primary for voip (asterisk). E.g. they have set up containers with their hardware in south africa. May be an other / alternative way :) -- Regards, Benny gpg 0xFC505AB0 jabber benny at benny.de sip benny at benny.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From laforge at gnumonks.org Wed Oct 6 05:11:17 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 06 Oct 2010 07:11:17 +0200 Subject: OsmocomBB.TCH. In-Reply-To: <20101005212201.GH16932@quelle.benny.de> References: <20101004195541.11594.qmail@stuge.se> <4CAA4AE7.10303@freyther.de> <4CAB280E.1040407@gmail.com> <20101005212201.GH16932@quelle.benny.de> Message-ID: <3e2a3276-a1ac-401f-8a3f-1618bb70b5bb@email.android.com> Hi all, This discussion has for a large part been off-topic. Please understand that this mailing list has a very narrow scope: Development of the OsmocomBB gsm baseband processor firmware / protocol stack. Thanks for your understanding and for keeping it on-topic. -- Sent from a mobile device, excuse my short response From bouchtaoui at gmail.com Tue Oct 5 07:38:23 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 05 Oct 2010 09:38:23 +0200 Subject: OsmocomBB.TCH. In-Reply-To: References: <4ca9bccf.mirider@mirider.augusta.de> <20101004195541.11594.qmail@stuge.se> Message-ID: <4CAAD5EF.4000103@gmail.com> Marten, I think Silvain is right, you do need some technical skills to get things working here. Some knowledge of autotools, corsscompiling (compiling for another platform), git and a bit of understanding how stuff works in the sourcecode is necessary. I think the first thing to do is try to git-clone the project and build it according to the wiki. From there on, study the sourcecodes and try to understand how it works and hopefully you'll understand more and will ask better questions. On 4-10-2010 23:09, Marten Christophe wrote: >> Hello All, >> >> How can i download the source code for sylvain/testing branch . >> to my PC ? >> >> I just downloaded git://git.osmocom.org/osmocom-bb.git, >> but it is not reflecting / having the file addition and modification or >> the changes sylvain/testing branch commited one hour before. >> >> is there any new trunck for this. or other command then git clone git:// >> git.osmocom.org/osmocom-bb.git, >> >> Kind Regards, >> >> >> From spaar at mirider.augusta.de Tue Oct 5 00:02:59 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Tue, 05 Oct 2010 00:02:59 CEST Subject: OsmocomBB.TCH. Message-ID: <4caacda4.mirider@mirider.augusta.de> Hello Sylvain, On Mon, 4 Oct 2010 22:13:13 +0200, "Sylvain Munaut" <246tnt at gmail.com> wrote: > > And Dieter's code probably worked on some internal version of the code > that were never even commited on the public tree and he may not even > have any more ... Yes, exactly, this code was never commited. Its main purpose was to get the TCH up and running. BTW, I still do not fully understand what Marten wants to do: - send a TCH ? If yes, with which device, a BTS or a GSM testset like I did with the HP8922 ? If it is the HP8922, this sending of audio data over one the external connectors of the testset also works with a full MOC or MTC, so no need to hack anything. Just use Sylvain's TCH testing branch and perform a MOC or MTC. This of course works with any GSM phone, so no need to use OsmocomBB at all... - something else I have not understand yet which requires just TCH receiving and no signalling ? Or recieve the same TCH on multiple phones ? Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From 246tnt at gmail.com Mon Oct 4 22:15:05 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 5 Oct 2010 00:15:05 +0200 Subject: OsmocomBB.TCH. In-Reply-To: <4caacda4.mirider@mirider.augusta.de> References: <4caacda4.mirider@mirider.augusta.de> Message-ID: > BTW, I still do not fully understand what Marten wants to do: I think he wants to turn the GSM into a simple two way radio / talkie-walkie, making two phones talk directly together on a TCH. (with only 2 devices) If both are pre-aligned on the same cell and if you appropriately set the uplink/downlink frequencies, and make sure there are tracking for frequency offset/toa it could work. But it's way more complex than just 'opening' a TCH with L1CTL, and without a good undertanding of how to setup all that ... I had thought of this some time ago and its among my 'list of fun thing to try', but I didn't quite get to it yet ... Cheers, Sylvain From spaar at mirider.augusta.de Thu Oct 7 12:58:42 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 07 Oct 2010 12:58:42 CEST Subject: OsmocomBB.TCH. Message-ID: <4cadc402.mirider@mirider.augusta.de> Hello Marten, just some basic technical note about what you are planning to do. The following _could_ work (to be sure if this is really usable in the planed environment much more research has to be investigated): - The BTS is based on a modified version of OpenBTS which allows to send a TCH without the need for signalling to setup the TCH. Similar everything on the uplink TCH will be played back. - The phones are based on OsmocomBB and receive the TCH from the BTS and play it back, they do not send anything on the TCH yet. - If you make sure that only one phone at once will send, it would be possible to press a button on the phone which will start transmitting on the TCH and then talk, similar to simple CB Radio handsets. On the BTS side you will hear the result. However all the adjustments to OpenBTS and OsmocomBB, even for a simple "Proof of concecpt" are not trivial. So you have to understand OpenBTS and OsmocomBB to make the required changes, you cannot expect that a short answere here on the list is the solution for the problem. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From wbg_1000 at yahoo.com Wed Oct 6 16:29:50 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Wed, 6 Oct 2010 09:29:50 -0700 (PDT) Subject: osmocom on windows Message-ID: <534307.7391.qm@web112120.mail.gq1.yahoo.com> Hello everybody. I've done my reading on GSM these last months and have a general ideea how it works. I would like to try to run osmocom on Windows? (hope don't get stoned for this :) ) I've been going throgh the files and see how interprocess communication is done (between osmocom and osmoload for example). Do you have any recommendation about what to use on windows as the interface between the 2 programs? Has anyone else tried it? Cheers, Mihai. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.grela at gmail.com Wed Oct 6 17:02:44 2010 From: maciej.grela at gmail.com (Maciej Grela) Date: Wed, 6 Oct 2010 19:02:44 +0200 Subject: osmocom on windows In-Reply-To: <534307.7391.qm@web112120.mail.gq1.yahoo.com> References: <534307.7391.qm@web112120.mail.gq1.yahoo.com> Message-ID: 2010/10/6 eisencah eisenach > > Hello everybody. > I've done my reading on GSM these last months and have a general ideea how it works. > I would like to try to run osmocom on Windows? (hope don't get stoned for this :) ) > I've been going throgh the files and see how interprocess communication is done (between osmocom and osmoload for example). > Do you have any recommendation about what to use on windows as the interface between the 2 programs? Has anyone else tried it? Have you tried to use http://www.cygwin.com/ ? -- Maciej Grela From wbg_1000 at yahoo.com Thu Oct 7 09:22:52 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Thu, 7 Oct 2010 02:22:52 -0700 (PDT) Subject: osmocom on windows In-Reply-To: Message-ID: <824074.95730.qm@web112104.mail.gq1.yahoo.com> I would like to compile the hole thing for windows (change in the osmocore lib the suport functions - use maybe pipes instead of sockets). Mihai. --- On Wed, 10/6/10, Maciej Grela wrote: From: Maciej Grela Subject: Re: osmocom on windows To: "eisencah eisenach" Cc: baseband-devel at lists.osmocom.org Date: Wednesday, October 6, 2010, 8:02 PM 2010/10/6 eisencah eisenach > > Hello everybody. > I've done my reading on GSM these last months and have a general ideea how it works. > I would like to try to run osmocom on Windows? (hope don't get stoned for this :) ) > I've been going throgh the files and see how interprocess communication is done (between osmocom and osmoload for example). > Do you have any recommendation about what to use on windows as the interface between the 2 programs? Has anyone else tried it? Have you tried to use http://www.cygwin.com/ ? -- Maciej Grela -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Oct 7 09:33:04 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 7 Oct 2010 11:33:04 +0200 Subject: osmocom on windows In-Reply-To: <824074.95730.qm@web112104.mail.gq1.yahoo.com> References: <824074.95730.qm@web112104.mail.gq1.yahoo.com> Message-ID: > I would like to compile the hole thing for windows (change in the osmocore lib the suport functions - use maybe pipes instead of sockets). I think you're on your own on this one. The only core developer using windows is Dieter and AFAIK he does use cygwin. Good luck ... you're probably gonna need it. Sylvain From peter at stuge.se Thu Oct 7 09:37:52 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Oct 2010 11:37:52 +0200 Subject: osmocom on windows In-Reply-To: <824074.95730.qm@web112104.mail.gq1.yahoo.com> References: <824074.95730.qm@web112104.mail.gq1.yahoo.com> Message-ID: <20101007093752.2075.qmail@stuge.se> eisencah eisenach wrote: > I would like to compile the hole thing for windows (change in the > osmocore lib the suport functions - use maybe pipes instead of > sockets). If you do it, may I suggest that you switch to using some IP based sockets for IPC. Then it'll work on Windows just fine with fairly little change. (send() instead of write() etc.) //Peter From spaar at mirider.augusta.de Thu Oct 7 11:44:50 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 07 Oct 2010 11:44:50 CEST Subject: osmocom on windows Message-ID: <4cadb2b2.mirider@mirider.augusta.de> On Thu, 7 Oct 2010 02:22:52 -0700 (PDT), "eisencah eisenach" wrote: > > I would like to compile the hole thing for windows (change in the osmocore > lib the suport functions - use maybe pipes instead of sockets). What is the whole thing ? The phone firmware has to be compiled by an ARM compiler, and if you use GNU ARM, you need Cygwin anyway. If you want to use a different compiler for the host software, you most certainly have to adjust quite a lot of the source code, expecially when using the Microsoft C compiler. And why use pipes instead of sockets, Windows has sockets. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From peter at stuge.se Thu Oct 7 09:54:28 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Oct 2010 11:54:28 +0200 Subject: osmocom on windows In-Reply-To: <4cadb2b2.mirider@mirider.augusta.de> References: <4cadb2b2.mirider@mirider.augusta.de> Message-ID: <20101007095428.7972.qmail@stuge.se> Dieter Spaar wrote: > > I would like to compile the hole thing for windows (change in the osmocore > > lib the suport functions - use maybe pipes instead of sockets). > > What is the whole thing ? The phone firmware has to be compiled by an > ARM compiler, and if you use GNU ARM, you need Cygwin anyway. Does e.g. the CodeSourcery toolchain really need Cygwin? That would suck. //Peter From bouchtaoui at gmail.com Thu Oct 7 10:16:55 2010 From: bouchtaoui at gmail.com (Nordin) Date: Thu, 07 Oct 2010 12:16:55 +0200 Subject: osmocom on windows In-Reply-To: <20101007095428.7972.qmail@stuge.se> References: <4cadb2b2.mirider@mirider.augusta.de> <20101007095428.7972.qmail@stuge.se> Message-ID: <4CAD9E17.3050003@gmail.com> On 7-10-2010 11:54, Peter Stuge wrote: > Dieter Spaar wrote: >>> I would like to compile the hole thing for windows (change in the osmocore >>> lib the suport functions - use maybe pipes instead of sockets). >> What is the whole thing ? The phone firmware has to be compiled by an >> ARM compiler, and if you use GNU ARM, you need Cygwin anyway. > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. So does windows :P (Sorry for being off-topic) From wbg_1000 at yahoo.com Thu Oct 7 12:25:27 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Thu, 7 Oct 2010 05:25:27 -0700 (PDT) Subject: osmocom on windows In-Reply-To: <4cadb2b2.mirider@mirider.augusta.de> Message-ID: <821744.13086.qm@web112109.mail.gq1.yahoo.com> I was planning on using the winarm package to compile the firmware. What other specific OS suport? is used on the host code? (I've seen serial port and timers) Thanks, Mihai. PS. The thing is I've done windows programming up until now, but maybe I should adapt instead of trying to the sw :) --- On Thu, 10/7/10, Dieter Spaar wrote: From: Dieter Spaar Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Thursday, October 7, 2010, 2:44 PM On Thu, 7 Oct 2010 02:22:52 -0700 (PDT), "eisencah eisenach" wrote: > > I would like to compile the hole thing for windows (change in the osmocore > lib the suport functions - use maybe pipes instead of sockets). What is the whole thing ? The phone firmware has to be compiled by an ARM compiler, and if you use GNU ARM, you need Cygwin anyway. If you want to use a different compiler for the host software, you most certainly have to adjust quite a lot of the source code, expecially when using the Microsoft C compiler. And why use pipes instead of sockets, Windows has sockets. Best regards, ? Dieter -- Dieter Spaar, Germany? ? ? ? ? ? ? ? ? ? ? ? ???spaar at mirider.augusta.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Thu Oct 7 12:18:48 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 07 Oct 2010 12:18:48 CEST Subject: osmocom on windows Message-ID: <4cadbaa8.mirider@mirider.augusta.de> Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From peter at stuge.se Thu Oct 7 11:24:50 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Oct 2010 13:24:50 +0200 Subject: osmocom on windows In-Reply-To: <4cadbaa8.mirider@mirider.augusta.de> References: <4cadbaa8.mirider@mirider.augusta.de> Message-ID: <20101007112450.19833.qmail@stuge.se> Hi, Dieter Spaar wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > > suck. > > I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. > According to the CodeSourcery FAQ, they do not require Cygwin. Ok, I think that's good. > Are there any benefit using CodeSourcery ? I had issues in the past > with the firmware using a different GNU ARM version, so I switched > back to 4.0.2 which seems to be the same other use on Linux and > so far it works OK. They are both just binary distributions of GCC for ARM. I doubt there are major differences. Maybe CS do more complete testing before they package up their versions, but there's no guarantee. GNUARM is clearly more focused on GNU environments, so I think it just makes sense that it is Cygwin affine. > You don't seem to like Cygwin, my experience with it is not that bad, Ah, no, I don't have anything against Cygwin, and I think it's really great in many ways, but it *is* something different than Windows. CS G++ Lite has the advantage of being plain native Windows programs. Cygwin people are always very careful to mention that Cygwin is not Windows, and I think their point is sound. Cygwin is an extra layer. In practise it can be negligeable, just another DLL, but it isn't Windowsy, and for someone who wants Windowsy, Cygwin isn't a really good answer. (But it can save plenty of time instead!) > OpenBSC (not with GPRS yet due to the need for the TUN device), OpenVPN has one, it's signed too. > OsmocomBB, GNUradio and Airprobe run with minor adjustments (just > to name GSM related stuff I use under Cygwin). Cool, that's proof that Cygwin is pretty good stuff. It doesn't say almost anything about how these projects run on Windows though. That isn't neccessarily a bad thing at all, evolving the project internally or the featureset or whatever can be much more important than adapting the project to work "on" more operating systems. //Peter From wbg_1000 at yahoo.com Thu Oct 21 17:00:37 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Thu, 21 Oct 2010 10:00:37 -0700 (PDT) Subject: osmocom on windows In-Reply-To: <4cadbaa8.mirider@mirider.augusta.de> Message-ID: <400214.5815.qm@web112110.mail.gq1.yahoo.com> Here's another one. Regarding the select mechanism (the one in select.c). Other then the serial port and sockets is anything else registered there? Cause I would like to keep sockets for communication after all (but the select function will not work on windows for serial ports handles). So I would use a different mechanism only for serial port scheduling. Cheers, Mihai. --- On Thu, 10/7/10, Dieter Spaar wrote: From: Dieter Spaar Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Thursday, October 7, 2010, 3:18 PM Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, ? Dieter -- Dieter Spaar, Germany? ? ? ? ? ? ? ? ? ? ? ? ???spaar at mirider.augusta.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Thu Oct 21 17:09:51 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 21 Oct 2010 19:09:51 +0200 Subject: osmocom on windows In-Reply-To: <400214.5815.qm@web112110.mail.gq1.yahoo.com> References: <400214.5815.qm@web112110.mail.gq1.yahoo.com> Message-ID: <4CC073DF.6050700@freyther.de> On 10/21/2010 07:00 PM, eisencah eisenach wrote: > Here's another one. Regarding the select mechanism (the one in select.c). > Other then the serial port and sockets is anything else registered there? > Cause I would like to keep sockets for communication after all (but the select > function will not work on windows for serial ports handles). So I would use a > different mechanism only for serial port scheduling. > Cheers, > Mihai. well.. we handle the timers with it too. From peter at stuge.se Thu Oct 21 17:11:48 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 21 Oct 2010 19:11:48 +0200 Subject: osmocom on windows In-Reply-To: <400214.5815.qm@web112110.mail.gq1.yahoo.com> References: <4cadbaa8.mirider@mirider.augusta.de> <400214.5815.qm@web112110.mail.gq1.yahoo.com> Message-ID: <20101021171148.10363.qmail@stuge.se> eisencah eisenach wrote: > I would like to keep sockets for communication after all (but the > select function will not work on windows for serial ports handles). > So I would use a different mechanism only for serial port > scheduling. I'd suggest abstracting the io and using overlapped on Windows. //Peter From spaar at mirider.augusta.de Thu Oct 7 15:09:05 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 07 Oct 2010 15:09:05 CEST Subject: osmocom on windows Message-ID: <4cade291.mirider@mirider.augusta.de> Hello Mihai, On Thu, 7 Oct 2010 05:25:27 -0700 (PDT), "eisencah eisenach" wrote: > > PS. The thing is I've done windows programming up until now, but maybe I > should adapt instead of trying to the sw :) I am mainly doing Windows software development, but I don't see any benefits from spending lots of time to adopt C language specific things in the source code so that it compiles with the MS compiler (be it either gcc specific language features or missing language features in the MS compiler). So I use Cygwin which also emulates at least those Unix specific features used in OpenBSC/OsmocomBB/Airprobe. And the C standard libraries are not that different that you won't understand what is going on. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From spaar at mirider.augusta.de Thu Oct 7 15:27:45 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 07 Oct 2010 15:27:45 CEST Subject: osmocom on windows Message-ID: <4cade6f2.mirider@mirider.augusta.de> Hello Peter, On Thu, 7 Oct 2010 13:24:50 +0200, "Peter Stuge" wrote: > > In practise it can be negligeable, just another DLL, but it isn't > Windowsy, and for someone who wants Windowsy, Cygwin isn't a really > good answer. (But it can save plenty of time instead!) Exactly, saving time is the point. A software developer, regardless of coming from Windows or Linux should have no problem to understand OpenBSC/OsmocomBB/Airprobe from the OS or C language perspective (I don't talk about GSM specific things, this is something else). I want to use those project and develop for them and not waste my time with things like adopting C language specific issues. > OpenVPN has one, it's signed too. I know, but you have to use the TUN device differently than on Linux, so some adjustments are necessary (besides not knowing if Windows will do proper NAT with the IP traffic from the phone). So I run OpenBSC in a VM if I need GPRS support instead spending time on issues I don't care if I want to use this software or develop for it. > Cool, that's proof that Cygwin is pretty good stuff. It doesn't say > almost anything about how these projects run on Windows though. They work for me, I want to use them and I want to develop for them and so far I could do all I want. Of course this is something else if you for example want to run OpenBSC in a production environment with lots of BTSs. A native Windows port is surely possible, but for me I don't see any benefits besides wasting time. Of course if someone want to sponsor a native port, why not, than at least the time for this effort is paid ;-) > That isn't neccessarily a bad thing at all, evolving the project > internally or the featureset or whatever can be much more important > than adapting the project to work "on" more operating systems. I don't have the impression that more people would work on those GSM related projects if they would directly run on Windows. I think the main obstacle is that you need to know quite a lot of GSM to make use of them. And if you are able to learn and understand the GSM related stuff, using Windows and/or Linux should be no problem at all for you ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From wbg_1000 at yahoo.com Sat Oct 16 16:53:08 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Sat, 16 Oct 2010 09:53:08 -0700 (PDT) Subject: osmocom on windows In-Reply-To: <4cade6f2.mirider@mirider.augusta.de> Message-ID: <51489.61479.qm@web112120.mail.gq1.yahoo.com> Hello to everyone. Against all advices I've started to try porting some of the code to windows (rainy day today, nothing much to do) . So I've started with the osmocom program. Cannot figure out where sercomm_drv_pull is defined. I suppose it is defined in sercomm.h but I cannot find any references to it.? Some small hint? Cheers, Mihai. --- On Thu, 10/7/10, Dieter Spaar wrote: From: Dieter Spaar Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Thursday, October 7, 2010, 6:27 PM Hello Peter, On Thu, 7 Oct 2010 13:24:50 +0200, "Peter Stuge" wrote: > > In practise it can be negligeable, just another DLL, but it isn't > Windowsy, and for someone who wants Windowsy, Cygwin isn't a really > good answer. (But it can save plenty of time instead!) Exactly, saving time is the point. A software developer, regardless of coming from Windows or Linux should have no problem to understand OpenBSC/OsmocomBB/Airprobe from the OS or C language perspective (I don't talk about GSM specific things, this is something else). I want to use those project and develop for them and not waste my time with things like adopting C language specific issues. > OpenVPN has one, it's signed too. I know, but you have to use the TUN device differently than on Linux, so some adjustments are necessary (besides not knowing if Windows will do proper NAT with the IP traffic from the phone). So I run OpenBSC in a VM if I need GPRS support instead spending time on issues I don't care if I want to use this software or develop for it. > Cool, that's proof that Cygwin is pretty good stuff. It doesn't say > almost anything about how these projects run on Windows though. They work for me, I want to use them and I want to develop for them and so far I could do all I want. Of course this is something else if you for example want to run OpenBSC in a production environment with lots of BTSs. A native Windows port is surely possible, but for me I don't see any benefits besides wasting time. Of course if someone want to sponsor a native port, why not, than at least the time for this effort is paid ;-) > That isn't neccessarily a bad thing at all, evolving the project > internally or the featureset or whatever can be much more important > than adapting the project to work "on" more operating systems. I don't have the impression that more people would work on those GSM related projects if they would directly run on Windows. I think the main obstacle is that you need to know quite a lot of GSM to make use of them. And if you are able to learn and understand the GSM related stuff, using Windows and/or Linux should be no problem at all for you ;-) Best regards, ? Dieter -- Dieter Spaar, Germany? ? ? ? ? ? ? ? ? ? ? ? ???spaar at mirider.augusta.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Oct 16 17:05:53 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 16 Oct 2010 19:05:53 +0200 Subject: osmocom on windows In-Reply-To: <51489.61479.qm@web112120.mail.gq1.yahoo.com> References: <4cade6f2.mirider@mirider.augusta.de> <51489.61479.qm@web112120.mail.gq1.yahoo.com> Message-ID: > Against all advices I've started to try porting some of the code to windows (rainy day today, nothing much to do) . > So I've started with the osmocom program. > Cannot figure out where sercomm_drv_pull is defined. I suppose it is defined in sercomm.h but I cannot find any references to it. > Some small hint? Use git grep ? Sylvain From peter at stuge.se Sat Oct 16 17:08:21 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 16 Oct 2010 19:08:21 +0200 Subject: osmocom on windows In-Reply-To: <51489.61479.qm@web112120.mail.gq1.yahoo.com> References: <4cade6f2.mirider@mirider.augusta.de> <51489.61479.qm@web112120.mail.gq1.yahoo.com> Message-ID: <20101016170821.30379.qmail@stuge.se> eisencah eisenach wrote: > Cannot figure out where sercomm_drv_pull is defined. $ git grep sercomm_drv_pull src/host/osmocon/osmocon.c: if (sercomm_drv_pull(&c) != 0) { src/target/firmware/calypso/uart.c: if (!sercomm_drv_pull(&ch)) { src/target/firmware/comm/sercomm.c:int sercomm_drv_pull(uint8_t *ch) src/target/firmware/include/comm/sercomm.h:int sercomm_drv_pull(uint8_t *ch); //Peter From wbg_1000 at yahoo.com Sat Oct 16 17:38:03 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Sat, 16 Oct 2010 10:38:03 -0700 (PDT) Subject: osmocom on windows In-Reply-To: <20101016170821.30379.qmail@stuge.se> Message-ID: <115703.70187.qm@web112108.mail.gq1.yahoo.com> Thanks. The thing is I didn't thought those files where used on the host too (cause they were in the firmware folder). Many thanks fellows. --- On Sat, 10/16/10, Peter Stuge wrote: From: Peter Stuge Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Saturday, October 16, 2010, 8:08 PM eisencah eisenach wrote: > Cannot figure out where sercomm_drv_pull is defined. $ git grep sercomm_drv_pull src/host/osmocon/osmocon.c:? ???if (sercomm_drv_pull(&c) != 0) { src/target/firmware/calypso/uart.c:? ? ? ? ? ? ? ? ? ???if (!sercomm_drv_pull(&ch)) { src/target/firmware/comm/sercomm.c:int sercomm_drv_pull(uint8_t *ch) src/target/firmware/include/comm/sercomm.h:int sercomm_drv_pull(uint8_t *ch); //Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From wbg_1000 at yahoo.com Thu Oct 21 17:48:09 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Thu, 21 Oct 2010 10:48:09 -0700 (PDT) Subject: osmocom on windows Message-ID: <118246.2006.qm@web112114.mail.gq1.yahoo.com> :D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I) --- On Thu, 10/21/10, Holger Hans Peter Freyther wrote: From: Holger Hans Peter Freyther Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Thursday, October 21, 2010, 8:09 PM On 10/21/2010 07:00 PM, eisencah eisenach wrote: > Here's another one. Regarding the select mechanism (the one in select.c). > Other then the serial port and sockets is anything else registered there? > Cause I would like to keep sockets for communication after all (but the select > function will not work on windows for serial ports handles). So I would use a > different mechanism only for serial port scheduling. > Cheers, > Mihai. well.. we handle the timers with it too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Fri Oct 22 07:39:07 2010 From: bouchtaoui at gmail.com (Nordin) Date: Fri, 22 Oct 2010 09:39:07 +0200 Subject: osmocom on windows In-Reply-To: <118246.2006.qm@web112114.mail.gq1.yahoo.com> References: <118246.2006.qm@web112114.mail.gq1.yahoo.com> Message-ID: <4CC13F9B.6060008@gmail.com> Another thread is possible, but you could also do a non-blocking read of the serial port, when Select call timed out. If nothing, you'll return back to the WSASelect() and the whole process repeats. This means you do serial port handling on the time-out of the WSASelect() call. This way you omit synchronization between threads, but if you're familiar with multithreading, go ahead :) On 21-10-2010 19:48, eisencah eisenach wrote: > :D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I) > > --- On Thu, 10/21/10, Holger Hans Peter Freyther wrote: > > From: Holger Hans Peter Freyther > Subject: Re: osmocom on windows > To: baseband-devel at lists.osmocom.org > Date: Thursday, October 21, 2010, 8:09 PM > > On 10/21/2010 07:00 PM, eisencah eisenach wrote: >> Here's another one. Regarding the select mechanism (the one in select.c). >> Other then the serial port and sockets is anything else registered there? >> Cause I > would like to keep sockets for communication after all (but the select >> function will not work on windows for serial ports handles). So I would use a >> different mechanism only for serial port scheduling. >> Cheers, >> Mihai. > well.. we handle the timers with it too. > > > > > From vogelchr at vogel.cx Mon Oct 11 20:40:26 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Mon, 11 Oct 2010 22:40:26 +0200 Subject: PATCH: Framebuffer for C123 and C155 Message-ID: <20101011204025.GA15325@vogel.cx> Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris From vogelchr at vogel.cx Mon Oct 11 20:50:53 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Mon, 11 Oct 2010 22:50:53 +0200 Subject: PATCH: Framebuffer for C123 and C155 In-Reply-To: <20101011204025.GA15325@vogel.cx> References: <20101011204025.GA15325@vogel.cx> Message-ID: <20101011205053.GA15936@vogel.cx> Two things I did want to mention, but forgot to write in my first email are: (1) For future work, it should be attempted to call the synchronisation of the framebuffer memory and the LC display in a low-priority task or timer so that the fb_flush() method that blocks on updates is no longer necessary (2) The price we pay for having the framebuffer, in terms of object-size, is detailed below, by comparing the original version of hello_world with the "new and improved" framebuffer. Comparing hello world before/after transition to framebuffer code. For hello world on E88 (C123) (with HelvR08 and HelvB14 fonts): .text +1696 byte (grows from 0x3fd0 - 0x3930) .rodata +944 byte (0xc76 - 0x1026) .data +80 byte (0x15c - 0x10c) .bss +860 byte (0x4470 - 0x47cc) For hello world on E99 (C155) (w/ HelvR08, HelvB14): .text +1344 byte .rodata +1088 byte .data +80 byte .bss +6564 byte Generally .rodata is mostly due to font data, .bss is our in-ram framebuffer. .text increase is due to the code for character- and box drawing. Individual sizes: $ /usr/opt/arm-gcc/bin/arm-elf-size *.o text data bss dec hex filename 1873 0 0 1873 751 fb_bw8.o (C123 ) 1764 0 0 1764 6e4 fb_rgb332.o ( C155) 706 72 6568 7346 1cb2 fb_ssd1783.o ( C155) 328 72 864 1264 4f0 fb_st7558.o (C123 ) 76 8 0 84 54 font.o (C123, C155) 0 0 0 0 0 framebuffer.o (C123, C155) 1804 0 0 1804 70c helvB14.o (C123, C155) 1212 0 0 1212 4bc helvR08.o (C128, C155) (Currently unused, optional further fonts:) 60 56 0 116 74 fb_dummy.o 1220 0 0 1220 4c4 helvB08.o 3548 0 0 3548 ddc helvB24.o 3480 0 0 3480 d98 helvR24.o 1116 0 0 1116 45c 4x6.o 1188 0 0 1188 4a4 5x8.o Old display code (everything compiled in for all mobiles): 88 0 0 88 58 display.o 2048 0 0 2048 800 font_r8x8_horiz.o 2048 0 0 2048 800 font_r8x8.o 920 0 0 920 398 ssd1783.o 399 0 0 399 18f st7558.o 638 0 0 638 27e td014.o From vogelchr at vogel.cx Mon Oct 11 21:01:02 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Mon, 11 Oct 2010 23:01:02 +0200 Subject: PATCH: Framebuffer for C123 and C155 Message-ID: {Resent, it didn't appear on the list after 20 minutes.} Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris From vogelchr at vogel.cx Tue Oct 12 09:41:49 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Tue, 12 Oct 2010 11:41:49 +0200 Subject: PATCH: Framebuffer for C123 and C155 In-Reply-To: References: Message-ID: <20101012094149.GA5111@vogel.cx> Hi Everyone, Thanks to Sylvain for pointing out the correct way to generate the git patches. I've put them up separately at: http://vogel.cx/git/20101011_fb/ or http://vogel.cx/git/20101011_fb.tar.gz Greetings, Chris From nico at chdir.org Wed Oct 13 14:13:23 2010 From: nico at chdir.org (Nicolas Bareil) Date: Wed, 13 Oct 2010 16:13:23 +0200 Subject: Newbie: C123 + layer1.compalram.bin + layer23 Message-ID: <87pqve18qk.fsf@chdir.org> Hello, I try to use the 'host23/mobile' application on a C123 but without success. I followed Steve's instructions[1] with today's git tree (d95eddad): 1. osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin 2. ./host/layer23/src/mobile/mobile 3. Power on the phone (output of theses commands is thereafter) But I'm not sure it really works: the firmware seems to freeze (not responding to the power button anymore) and the last output of 'mobile' is: <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) Based on the low rxlevel, I guess it is not acquiring any meaningful signal? In [2], Steve said the internal antenna was switched off when the cable is plugged in, is it still true? I tried to RTFM but I am stuck here. Thanks for your patience, Footnotes: [1] http://baseband-devel.722152.n3.nabble.com/Running-osmocombb-on-a-Motorol-C118-tp937345p937416.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2010-May/000435.html ,---- | % osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin | ... | Received DOWNLOAD ACK from phone, your code is running now! | | OSMOCOM Layer 1 (revision osmocon_v0.0.0-598-gd95edda) | ====================================================================== | Device ID code: 0xb4fb | Device Version code: 0x0000 | ARM ID code: 0xfff3 | cDSP ID code: 0x0128 | Die ID code: ebd8283cba021198 | ====================================================================== | REG_DPLL=0x2413 | CNTL_ARM_CLK=0xf0a1 | CNTL_CLK=0xff91 | CNTL_RST=0xfff3 | CNTL_ARM_DIV=0xfff9 | ====================================================================== | | THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! | Assert DSP into Reset | Releasing DSP from Reset | Setting some dsp_api.ndb values | Setting API NDB parameters | DSP Download Status: 0x0001 | DSP API Version: 0x0000 0x0000 | Finishing download phase | DSP Download Status: 0x0002 | DSP API Version: 0x3606 0x0000 | LOST 7478! | L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124 | PM MEAS: ARFCN=0, 27 dBm at baseband, -110 dBm at RF | PM MEAS: ARFCN=0, 26 dBm at baseband, -112 dBm at RF | PM MEAS: ARFCN=1, 30 dBm at baseband, -107 dBm at RF | PM MEAS: ARFCN=2, 29 dBm at baseband, -108 dBm at RF | PM MEAS: ARFCN=3, 43 dBm at baseband, -94 dBm at RF | PM MEAS: ARFCN=4, 32 dBm at baseband, -105 dBm at RF | ../.. | PM MEAS: ARFCN=1023, 33 dBm at baseband, -104 dBm at RF | L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=104, flags=0x7) | Starting FCCH RecognitionFB0 (1748:10): TOA=11712, Power=-106dBm, Angle=-22058Hz | FB0 (1775:11): TOA=12528, Power= -65dBm, Angle=-3818Hz | FB0 (1796:5): TOA= 5280, Power= -68dBm, Angle=-16117Hz | FB0 (1799:1): TOA= 96, Power=-109dBm, Angle= 7082Hz `---- ,---- | % ./host/layer23/src/mobile/mobile | ... | Failed to connect to '/tmp/osmocom_sap'. | Failed during sap_open(), no SIM reader | <000e> sim.c:1206 init SIM client | <0005> gsm48_cc.c:61 init Call Control | <0001> gsm48_rr.c:5330 init Radio Ressource process | <0004> gsm48_mm.c:1220 init Mobility Management process | <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. | <0002> gsm322.c:3466 init PLMN process | <0003> gsm322.c:3467 init Cell Selection process | <0003> gsm322.c:3521 No stored BA list | VTY available on port 4247. | Mobile initialized, please start phone now! | <0002> gsm322.c:3093 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN selection in state 'A0 null' | <000d> gsm322.c:1055 SIM is removed | <0002> gsm322.c:1056 SIM is removed | <0002> gsm322.c:511 new state 'A0 null' -> 'A6 no SIM inserted' | <0003> gsm322.c:3313 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in state 'C0 null' | <0003> gsm322.c:2986 Switch on without SIM. | <0003> gsm322.c:540 new state 'C0 null' -> 'C6 any cell selection' | <0003> gsm322.c:2404 Getting PM for frequency 0 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 3 rxlev -94 (16)) | <0003> gsm322.c:2415 Found signal (frequency 8 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 16 rxlev -93 (17)) | ... | <0003> gsm322.c:2415 Found signal (frequency 819 rxlev -97 (13)) | <0003> gsm322.c:2404 Getting PM for frequency 955 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 982 rxlev -98 (12)) | ... | <0003> gsm322.c:2415 Found signal (frequency 1004 rxlev -91 (19)) | <0003> gsm322.c:2415 Found signal (frequency 1007 rxlev -89 (21)) | <0003> gsm322.c:2415 Found signal (frequency 1009 rxlev -97 (13)) | <0003> gsm322.c:2415 Found signal (frequency 1010 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1011 rxlev -67 (43)) | <0003> gsm322.c:2415 Found signal (frequency 1012 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1013 rxlev -80 (30)) | <0003> gsm322.c:2415 Found signal (frequency 1014 rxlev -87 (23)) | <0003> gsm322.c:2415 Found signal (frequency 1021 rxlev -82 (28)) | <0003> gsm322.c:2415 Found signal (frequency 1022 rxlev -98 (12)) | <0003> gsm322.c:2348 Found 97 frequencies. | <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) `---- From 246tnt at gmail.com Wed Oct 13 14:41:03 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 13 Oct 2010 16:41:03 +0200 Subject: Newbie: C123 + layer1.compalram.bin + layer23 In-Reply-To: <87pqve18qk.fsf@chdir.org> References: <87pqve18qk.fsf@chdir.org> Message-ID: > <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) > > Based on the low rxlevel, I guess it is not acquiring any meaningful > signal? -65 dBm is a pretty strong signal actually :) It should be able to sync down to -105 dBm or so. > In [2], Steve said the internal antenna was switched off when the cable > is plugged in, is it still true? It's true and won't ever change ... it's a hardware switch, when you plug something in the antenna plug, it disconnects the built-in antenna. > | L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=104, flags=0x7) > | Starting FCCH RecognitionFB0 (1748:10): TOA=11712, Power=-106dBm, Angle=-22058Hz > | FB0 (1775:11): TOA=12528, Power= -65dBm, Angle=-3818Hz > | FB0 (1796:5): TOA= 5280, Power= -68dBm, Angle=-16117Hz > | FB0 (1799:1): TOA= ? 96, Power=-109dBm, Angle= 7082Hz It's weird that the power varies so much ... it's also weird that it even _tried_ to sync with a 22kHz frequency error .. It might try to sync to something that's not a C0 ... Try to force the ARFCN to a known good cell (that you get from a phone with netmonitor) using the stick option. Cheers, Sylvain From Andreas.Eversberg at versatel.de Thu Oct 14 07:15:11 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 14 Oct 2010 09:15:11 +0200 Subject: AW: Newbie: C123 + layer1.compalram.bin + layer23 Message-ID: > But I'm not sure it really works: the firmware seems to freeze (not > responding to the power button anymore) and the last output of 'mobile' > is: > > <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) hi nicolas, be sure to use the branch of sylvain: sylvain/testing (i think you did) the process freezes after many sync requests due to a memory leak that has not been fixed. without the fix, the full network search process should run several times without freeze. but in your case it looks like freezing every first sync request. can you watch the display of your c123? see if it gets a little darker at the point it freezes (when trying to sync). regards, andreas From nico at chdir.org Thu Oct 14 07:54:42 2010 From: nico at chdir.org (Nicolas Bareil) Date: Thu, 14 Oct 2010 09:54:42 +0200 Subject: AW: Newbie: C123 + layer1.compalram.bin + layer23 References: Message-ID: <87hbgp53zk.fsf@chdir.org> Good morning, First, thanks to both of you for your replies! Sylvain Munaut <246tnt at gmail.com> writes: > -65 dBm is a pretty strong signal actually :) Ooops :) > Try to force the ARFCN to a known good cell (that you get from a phone > with netmonitor) using the stick option. That's the hard part, I don't have such feature on any phones I own :-( I thought I could find one at work today but... no. "Andreas.Eversberg" writes: >> <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) > > be sure to use the branch of sylvain: sylvain/testing (i think you did) I was using master, I changed that now. I'm currently at 7e25c8bd > the process freezes after many sync requests due to a memory leak that > has not been fixed. without the fix, the full network search process > should run several times without freeze. but in your case it looks like > freezing every first sync request. In fact, the whole problem disappeared when I compiled the project with the gnuarm.com toolchain instead of mine (built with crosstool-ng[1]). So now, 'mobile' application seems to work but I still have an issue with layer23: after a few seconds, it keeps dropping frames (like 90% of packet loss): ,---- | % host/layer23/src/misc/layer23 -a 544 -i 1.2.3.4 | .. | <000a> lapdm.c:1529 fmt=B | <000a> lapdm.c:843 UI received | <000a> lapdm.c:875 length=0 (discarding) | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/20/32) -102 dBm: 00 01 03 03 2d 06 1e e0 4c 02 f8 10 65 00 54 ff 2b 2b 2b 2b 2b 2b 2b | <000a> lapdm.c:1520 fmt=B4 | <000a> lapdm.c:843 UI received | <0000> rslms.c:66 RSLms UNIT DATA IND chan_nr=0x40 link_id=0x40 | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/13/00) -105 dBm: 03 42 9d 3a 17 8e ba 17 fd a5 a3 87 35 56 2b 0f 09 a4 a3 c7 87 fc 98 | <000b> l1ctl.c:210 Dropping frame with 86 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/12/00) -101 dBm: e6 2c f6 80 de 37 0c f9 29 10 7f e3 ed df 86 e5 2d 58 63 85 d7 5f 5c | <000b> l1ctl.c:210 Dropping frame with 104 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/18/32) -98 dBm: 1b 6e 07 1c 36 18 e1 40 c7 b6 49 d3 4a ea 58 63 6a 02 34 fd 0a 87 4f | <000b> l1ctl.c:210 Dropping frame with 77 bit errors | <000b> l1ctl.c:155 SDCCH/8(0) on TS0 (0064/11/00) -95 dBm: 96 85 20 62 92 7e 4a e4 47 ec 17 f7 bb 82 0d 78 10 a9 90 81 db f0 aa | <000b> l1ctl.c:210 Dropping frame with 63 bit errors `---- Full layer23 dump available at http://pastebin.org/167286 The osmocom dump is available at http://pastebin.org/167278 Could it be a bad serial cable? Is there anything I can do to debug further? Thanks, Footnotes: [1] http://ymorin.is-a-geek.org/projects/crosstool From 246tnt at gmail.com Wed Oct 13 21:35:44 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 13 Oct 2010 23:35:44 +0200 Subject: Removing the C123 RX filter Message-ID: Hi, As a prelude to various experimentations, I had to remove the RX filter on some C123. As this can be useful to others, I've done a little summary of how I do it. It's not for the faint of heart tough :) http://www.246tnt.com/gsm/rx_filter.html Comments welcome of course. Cheers, Sylvain Munaut From peter at stuge.se Wed Oct 13 22:02:00 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 14 Oct 2010 00:02:00 +0200 Subject: Removing the C123 RX filter In-Reply-To: References: Message-ID: <20101013220200.3780.qmail@stuge.se> Sylvain Munaut wrote: > remove the RX filter on some C123. Nice writeup! Going at the shielding with a Dremel is a bit rough for my taste. I might have tried to use something like Chip Quik to desolder it. http://www.chipquikinc.com/ I don't have experience with the product, but it looks like a good sensible method and the videos I've seen look fine. //Peter From steve at steve-m.de Wed Oct 13 22:17:19 2010 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 14 Oct 2010 00:17:19 +0200 Subject: Removing the C123 RX filter In-Reply-To: <20101013220200.3780.qmail@stuge.se> References: <20101013220200.3780.qmail@stuge.se> Message-ID: <4CB62FEF.2070109@steve-m.de> On 14.10.2010 00:02, Peter Stuge wrote: > Nice writeup! Indeed! > Going at the shielding with a Dremel is a bit rough for my taste. I > might have tried to use something like Chip Quik to desolder it. I have removed some of those shieldings with a small caliper. The trick is to use the round holes and to seize the metal there. Then rotate the caliper and pull off stripes of metal like with a can opener. You just have to be careful on the soldered edges, since you can accidentially pull some copper off the top layer. With a little bit of wiggling the shielding will come off nicely. Regards, Steve From laforge at gnumonks.org Fri Oct 15 12:27:05 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 15 Oct 2010 14:27:05 +0200 Subject: Removing the C123 RX filter In-Reply-To: References: Message-ID: <20101015122705.GF23263@prithivi.gnumonks.org> Hi Sylvain, On Wed, Oct 13, 2010 at 11:35:44PM +0200, Sylvain Munaut wrote: > As a prelude to various experimentations, I had to remove the RX > filter on some C123. As this can be useful to others, I've done a > little summary of how I do it. It's not for the faint of heart tough > :) great! > Comments welcome of course. My only comment would be: Please consider adding this to the OsmocomBB wiki rather than [just] your personal page :) It's good to have one central spot where we collect the information, I believe. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From akilesh at akileshsethu.net Wed Oct 20 06:23:40 2010 From: akilesh at akileshsethu.net (Akilesh Sethu) Date: Wed, 20 Oct 2010 14:23:40 +0800 Subject: Inquiry on osmocom Message-ID: Hey, I am working on Android Mobile Operating System. Is it possible for me to port osmocom GSM stack to any of the Android compatible mobiles. Regards, Akilesh Sethu -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Wed Oct 20 15:33:27 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 20 Oct 2010 17:33:27 +0200 Subject: Inquiry on osmocom In-Reply-To: References: Message-ID: <4CBF0BC7.6090003@gmail.com> You're free to do that, as long as you stick to the gpl license :) But what do you want to do with the stack, I think it's useless if you don't have access to the baseband chip. On 20-10-2010 8:23, Akilesh Sethu wrote: > Hey, > > > I am working on Android Mobile Operating System. Is it possible for me to > port osmocom GSM stack to any of the Android compatible mobiles. > > > > > Regards, > Akilesh Sethu > From Andreas.Eversberg at versatel.de Thu Oct 21 06:51:42 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 21 Oct 2010 08:51:42 +0200 Subject: wrong decoding of bit vectors Message-ID: /* check if the bit is L or H for a given position inside a bitvec */ enum bit_value bitvec_get_bit_pos_high(const struct bitvec *bv, unsigned int bitnr) { unsigned int bytenum = bytenum_from_bitnum(bitnr); unsigned int bitnum = 7 - (bitnr % 8); uint8_t bitval; if (bytenum >= bv->data_len) return -EINVAL; bitval = bitval2mask(H, bitnum); if (bv->data[bytenum] & bitval) return H; return L; } hi, this is part of bitvec.c of libosmocore. it returns if a given bit in the vector is "high" or "low". the bitval that represents "high" depends on the bit position. bitval2mask returns that. so we must check if the bit in the vector equals the returned bitval. i suggest to fix it that way: if (bv->data[bytenum] & (1 << bitnum) == bitval) return H; any complains? without it we cannot check the system information's rest octets. they are essential for any multiband mobile. regards, andreas From Andreas.Eversberg at versatel.de Thu Oct 21 06:58:53 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 21 Oct 2010 08:58:53 +0200 Subject: AW: wrong decoding of bit vectors Message-ID: > if (bv->data[bytenum] & (1 << bitnum) == bitval) > return H; i must correct: if ((bv->data[bytenum] & (1 << bitnum)) == bitval) return H; From laforge at gnumonks.org Thu Oct 21 08:05:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Oct 2010 10:05:38 +0200 Subject: wrong decoding of bit vectors In-Reply-To: References: Message-ID: <20101021080538.GB3614@prithivi.gnumonks.org> On Thu, Oct 21, 2010 at 08:58:53AM +0200, Andreas.Eversberg wrote: > > if (bv->data[bytenum] & (1 << bitnum) == bitval) > > return H; > > i must correct: > if ((bv->data[bytenum] & (1 << bitnum)) == bitval) > return H; sounds good to me. feel free to commit a fix to libosmocore.git -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Oct 21 18:39:00 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 21 Oct 2010 20:39:00 +0200 Subject: DSP TCH task : time to get/put FAACH Message-ID: Hi Dieter, Hi everyone, (cc'd the list, for the record and if other people are interested in the inner workings :) I'm pretty satisfied with the current state of the TCH primitive (as it is in my testing branch now). But there is still two things I'm stumbling upon: * When to put / read data for FACCH. Getting downlink FACCH blocks looks quite logic: just check the B_BLUD bit on the TCH response of the last burst of the block. So with rx_time being the time at which the burst was received (i.e., one frame before the response is executed) - For TCH/F: (rx_time.fn % 13) % 4 == 3 - For TCH/H: (rx_time.t2 - subchannel) in {6,15,23} But for when to load the next FACCH block, it seems weird. From what I understand of what you did and what the TSM30 does, you need to load the data on the TCH cmd corresponding to the bursts _before_ the first burst. So with tx_time being the time at which the burst will transmitted (i.e., one frame after the command is executed = l1s.next_time) - For TCH/F (tx_time.fn % 13) % 4 == 3 - For TCH/H (tx_time.t2 - subchannel) in {6,15,23} (2 TDMA before the first burst because on TCH/H, we're executed one once every two frame) Why the need to load it one burst in advance ? (while on the RX side, which seems more complex to do, data is available directly after the last burst is received). * TCH/H support: AFAIK, I did everything that should be required for it to work: - set fn_report properly for TCH/H - set chan_type to TCH_H in dsp_load_tch_parameters - Use a different condition for when to put/read FACCH bursts (according to 05.02) - Schedule the TCH task appropriately ... But still can't get it to work (testing with the racal). SACCH seems to work fine (I see the SI messages), but I don't see a single FACCH message (and eventually the racal says T3107 expired, assignement to TCH failed). Do you see anything else that would be required ? Cheers, Sylvain From 246tnt at gmail.com Fri Oct 22 21:47:16 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 22 Oct 2010 23:47:16 +0200 Subject: DSP TCH task : time to get/put FAACH In-Reply-To: References: Message-ID: Some news from the front on this : > ?* When to put / read data for FACCH. > [snip] Ok, I've accepted it's a requirement of the DSP ... (I looked into the DSP code to make sure it was) ... > ?* TCH/H support: AFAIK, I did everything that should be required for > it to work: After fixing some bugs, and some debugging sessions with steve|m (thanks btw :): - Half subchannel 0: Call establishement / FACCH works. But no audio. Steve confirmed that audio _is_ sent from the mobile, by recording it with the racal and then playing it back on a phone with stock firmware. So it's a downlink issue ... - Half subchannel 1: FACCH works, but can't establish a call anyway ... The problem seems to be in the upper layer. My current theory is that we hit some race condition somewhere and the slight timing difference between subchannel 0 and subchannel 1 triggers it in one case but not the other ... Basically on FACCH: - we send the SABM - we get the UA back - we send the ASSIGNEMENT COMPLETE N(S)=0, N(R)=0 - we get RR N(R)=1 - we send 3 times RR N(R)=0 ( <-- this is weird ) - then lapdm doesn't xmit anything from the upper layer anymore. Cheers, Sylvain From technosabby at gmail.com Thu Oct 21 20:30:48 2010 From: technosabby at gmail.com (Marten Christophe) Date: Fri, 22 Oct 2010 02:00:48 +0530 Subject: TCH.. OsmocomBB Message-ID: Hello Deiter ,Sylvian As u advised I completed reading GSM standard, and dig down source code AFAIK , i have recognized the files and parameters where i need to change values to tune for particular TCH, and also understood that how important signaling is to be involved . I just want to know one thing that is , during the channel request MS send burst on RACH with RA ref number, where this RAF or RA reference number stored on MS side , because when Immediate assignment send from the network it must be match before tuning to particular SDCCH, i want to apply a trick here i will copy the RA reference from the immediate assignment message and will replace with original one stored in MS, hence MS will think this channel is for me and tune to the SDCCH accordingly, further it will keep on listening all process like authentication, location updating , again the TCH channel information is send SDCCH without encryption as only authentication procedure needs Kc Ki and SRES, SDCCH is not encrypted and all MS hosting on that SDCCH can decode TCH parameter like FN , TS, ARFCN hopping sequence. but again i need to clarify how L1ctl.c and L23_api.c fetch the decoded data, from immediate assinment masseg. as it is written printf..........%u . From where this will scan or fetch. if i will be able to know, where MS kept stored the input values advised in signaling messages by BTS on PCH, or AGCH. so i can manipulate them and land on CCCH, and then SDCCH then TCH. kindly tell me if it is feasible , or there is more i need to think. Kind Regards, From 246tnt at gmail.com Thu Oct 21 20:44:36 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 21 Oct 2010 22:44:36 +0200 Subject: TCH.. OsmocomBB In-Reply-To: References: Message-ID: Hi, > Hello Deiter ,Sylvian btw, it's Dieter and Sylvain :) > I just want to know one thing that is , during the channel request MS > send burst on ?RACH with RA ref number, where this RAF or RA reference > number stored on MS side In the 'mobile' application (full phone stack), it's kept in a cr_hist (Channel request history) list in gsm48_rr.c In the test 'layer23' application, it's not stored and we just follow the first assignement we see (which on a real network is probably not ours). > , because ?when Immediate assignment send > from the network it must be match before tuning to particular SDCCH, i > want to apply a trick here i will copy the RA reference from the > immediate assignment message and will replace with original one stored > in MS, ?hence MS will think this channel is for me and tune to the > SDCCH accordingly, further ?it will keep on listening all process like > authentication, location updating I assume you're talking about the 'mobile' application. If you have TX enabled, all it's gonna do is jam the other mobile, preventing any kind of traffic ... (because you'll TX at the same time as the 'real' phone to which the assignement was for. For this kind of work you shouldn't use the 'mobile' application stack and just hack a small program like 'layer23' does. > kindly tell me if it is feasible , or there is more i need to think. Well you obviously missed a big point : You _shouldn't_ use the 'mobile' stack at all and just rewrite everything above l1ctl for your own app ... Cheers, Sylvain From 246tnt at gmail.com Sat Oct 23 16:28:55 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 23 Oct 2010 18:28:55 +0200 Subject: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state Message-ID: Hi, In GSM 05.06 Section 5.5.7 at the end it says : --- The timer recovery condition is only cleared if the data link layer entity receives a valid supervisory frame response with the F bit set to "1". If the N(R) of this received supervisory frame is within the range from its current state variable V(A) to its current send state variable V(S) inclusive, it shall set its send state variable V(S) to the value of the received N(R). Timer T200 shall be reset if the received supervisory frame response is an RR or REJ response with F bit set to "1". The data link layer entity shall then resume with I frame transmission or retransmission, as appropriate. Timer T200 shall be set if the received supervisory response is an RNR response, and the data link layer shall proceed with the enquiry process in accordance with subclause 5.5.5. --- And I don't see where this is supposed to be handled in the code. I tried this quick fix: diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index b1c0d40..8bd42a7 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -1081,8 +1081,12 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.2.2: Inidcate error on supervisory reponse F=1 */ if (LAPDm_ADDR_CR(mctx->addr) == CR_BS2MS_RESP && LAPDm_CTRL_PF_BIT(mctx->ctrl)) { - LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); - rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + if (dl->state != LAPDm_STATE_TIMER_RECOV) { + LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); + rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + } else { + dl->state = LAPDm_STATE_MF_EST; + } } switch (dl->state) { which seems to fix the issue I encountered but my understanding of how lapdm.c works is very limited and I doubt that it's all that's needed to properly handle this case. Cheers, Sylvain Munaut From technosabby at gmail.com Sun Oct 24 19:20:50 2010 From: technosabby at gmail.com (Marten Christophe) Date: Mon, 25 Oct 2010 00:50:50 +0530 Subject: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state In-Reply-To: References: Message-ID: Hello Sylvain, Thanks, for all your support, as you told me in your last reply, if i use layer23 -a arfcn , then it will , automatic tune to first immediate assignment command and follow to it until assignment command and tune to TCH/f for that particular immediate assignment command. but when i doing so , it is chasing up to SDCCH , and after this it is started to dropping frames .. and not getting tune to any TCH/F though there is no encryption being used. A5/0, i have seen , no ciphering. in traces. ******* Dropping frame with 59 bit errors <000b> l1ctl.c:166 Dropping frame with 59 bit errors <000b> l1ctl.c:155 SDCCH/8(0) on TS1 (1796/14/32) -62 dBm: ***** SACCH queue SDCCH queue SDCCH queue SACCH queue ***** kindly confirm with layer1.compalram.bin , if i will be able to listen TCH/F assign to some other MS , i have tried all other branches like Sylvain/voice, Sylvain/testing. but none of successful. Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Mon Oct 25 07:50:53 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 25 Oct 2010 09:50:53 +0200 Subject: AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state Message-ID: > The timer recovery condition is only cleared if the data link layer > entity receives a valid supervisory frame response > with the F bit set to "1". If the N(R) of this received supervisory > frame is within the range from its current state variable > V(A) to its current send state variable V(S) inclusive, it shall set > its send state variable V(S) to the value of the received > N(R). Timer T200 shall be reset if the received supervisory frame > response is an RR or REJ response with F bit set to > "1". The data link layer entity shall then resume with I frame > transmission or retransmission, as appropriate. > Timer T200 shall be set if the received supervisory response is an RNR > response, and the data link layer shall proceed > with the enquiry process in accordance with subclause 5.5.5. hi sylvain, you are right. in case of an RR "response" (or an I frame) with the F bit set to "1", there is no clearing of the "timer recovery state". in other cases (RNR, REJ) it is handled. i would like to test this with a prepared frame drop tonight. if this works, i will commit it. regards, andreas From 246tnt at gmail.com Mon Oct 25 08:12:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 25 Oct 2010 10:12:42 +0200 Subject: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state In-Reply-To: References: Message-ID: Hi, > you are right. in case of an RR "response" (or an I frame) with the F > bit set to "1", there is no clearing of the "timer recovery state". in > other cases (RNR, REJ) it is handled. Where did you see that an I-Frame with the F bit set should clear the condition ? I read this : >> The timer recovery condition is only cleared if the data link layer >> entity receives a valid supervisory frame response and it only talks about supervisory frame, not I frames. Cheers, Sylvain From Andreas.Eversberg at versatel.de Mon Oct 25 09:25:31 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 25 Oct 2010 11:25:31 +0200 Subject: AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state Message-ID: >> you are right. in case of an RR "response" (or an I frame) with the F >> bit set to "1", there is no clearing of the "timer recovery state". in >> other cases (RNR, REJ) it is handled. > Where did you see that an I-Frame with the F bit set should clear the > condition ? you are right. i searched through the document. the I-Frame is handled during "timer recovery state", but this state is not cleared then. anyway: i am missing the description for "Receiving RR frames". A general description for RR, RNR, REJ is given in 5.5.3, but it does not describe what todo on a valid RR response with F bit set to "1". this is why i missed it. From jakborg at fastmail.fm Sun Oct 24 14:46:34 2010 From: jakborg at fastmail.fm (jakob borg) Date: Sun, 24 Oct 2010 07:46:34 -0700 Subject: libosmocom VERSION doesn't get set properly Message-ID: <1287931594.6585.1401667611@webmail.messagingengine.com> hi, when building libosmocom in osmocom-bb/src/shared (using the git-subtree script to keep everything up to date), the Makefile in src/shared/libosmocore/build-host doesn't have the version information set properly, instead i get: PACKAGE_VERSION = UNKNOWN VERSION = UNKNOWN this is causing problems compiling stuff that require libosmocom at a specific version, like some of the airprobe tools. i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. when building the master git branch of libosmocom outside of osmocom-bb (bootstrapping using the bootstrap script from airprobe/gsm-receiver), the version gets set properly. thanks jakob -- jakob borg jakborg at fastmail.fm -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html From laforge at gnumonks.org Tue Oct 26 10:54:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Oct 2010 12:54:47 +0200 Subject: libosmocom VERSION doesn't get set properly In-Reply-To: <1287931594.6585.1401667611@webmail.messagingengine.com> References: <1287931594.6585.1401667611@webmail.messagingengine.com> Message-ID: <23cbf870-f3e6-4222-8a2a-59e037c592b5@email.android.com> yes, this is sort of a known problem. it's an artefact resulting from the way libosmocore autotools magic generates its verwion from git tags. As the version tags don't exist in the osmocom-bb repo, things go wrong I haven't really come up with a good solution to the problem, but feel free to propose one. -- Sent from a mobile device, excuse my short response From peter at stuge.se Tue Oct 26 16:17:43 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 26 Oct 2010 18:17:43 +0200 Subject: libosmocom VERSION doesn't get set properly In-Reply-To: <23cbf870-f3e6-4222-8a2a-59e037c592b5@email.android.com> References: <1287931594.6585.1401667611@webmail.messagingengine.com> <23cbf870-f3e6-4222-8a2a-59e037c592b5@email.android.com> Message-ID: <20101026161743.17261.qmail@stuge.se> Harald Welte wrote: > libosmocore autotools magic generates its verwion from git tags. > As the version tags don't exist in the osmocom-bb repo, things go wrong > > I haven't really come up with a good solution to the problem, but feel > free to propose one. Is libosmocore a submodule in osmocom-bb? In that case I would expect tags to be included. //Peter From laforge at gnumonks.org Tue Oct 26 17:41:59 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Oct 2010 18:41:59 +0100 Subject: libosmocom VERSION doesn't get set properly In-Reply-To: <20101026161743.17261.qmail@stuge.se> References: <1287931594.6585.1401667611@webmail.messagingengine.com> <23cbf870-f3e6-4222-8a2a-59e037c592b5@email.android.com> <20101026161743.17261.qmail@stuge.se> Message-ID: <20101026174159.GT25165@prithivi.gnumonks.org> Hi Peter, On Tue, Oct 26, 2010 at 06:17:43PM +0200, Peter Stuge wrote: > Harald Welte wrote: > > libosmocore autotools magic generates its verwion from git tags. > > As the version tags don't exist in the osmocom-bb repo, things go wrong > > > > I haven't really come up with a good solution to the problem, but feel > > free to propose one. > > Is libosmocore a submodule in osmocom-bb? In that case I would expect > tags to be included. we use git-subtree and not sub-modules. I don't remember the problem with modules, but they didn't really do what we need. regards, harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jakborg at fastmail.fm Sun Oct 24 14:56:18 2010 From: jakborg at fastmail.fm (jakob borg) Date: Sun, 24 Oct 2010 07:56:18 -0700 Subject: cross-compiling osmocom on mac os x Message-ID: <1287932178.8503.1401669081@webmail.messagingengine.com> hi, i'm struggling to get a working cross-compile toolchain for osmocom-bb on os x, i've been playing with a script called summon-arm-toolchain (http://github.com/esden/summon-arm-toolchain) for a while now without success, my toolchain seems to build fine, but when trying to compile for my target, i get: checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no config.log says: configure:3106: checking whether the C compiler works configure:3128: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 /usr/local/arm-elf/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /usr/local/src/summon-arm-toolchain/build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.18.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' collect2: ld returned 1 exit status i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. any idea what i might be doing wrong? has anybody successfully cross-compiled the arm part of osmocom-bb on osx? thanks jakob -- jakob borg jakborg at fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow From peter at stuge.se Sun Oct 24 18:27:31 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 24 Oct 2010 20:27:31 +0200 Subject: cross-compiling osmocom on mac os x In-Reply-To: <1287932178.8503.1401669081@webmail.messagingengine.com> References: <1287932178.8503.1401669081@webmail.messagingengine.com> Message-ID: <20101024182731.3724.qmail@stuge.se> jakob borg wrote: > checking for arm-elf-linux-gcc... arm-elf-gcc .. > any idea what i might be doing wrong? configure should not be checking for arm-elf-linux-gcc. In particular the linux part is very wrong, but in general you should instead try to use --host=arm-none-eabi. This requires another toolchain obviously. I have a script somewhere that I will try to dig out. It worked on MacOS X in August. In particular everything in macports is unusable. > has anybody successfully cross-compiled the arm part of osmocom-bb > on osx? No, but other ARM bare metal binaries. //Peter From 246tnt at gmail.com Sun Oct 24 19:36:27 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 24 Oct 2010 21:36:27 +0200 Subject: Switching to TCH Message-ID: > but when i doing so , it is chasing up to SDCCH , and after this it is > started to dropping frames .. and not getting tune to any TCH/F Have you even _read_ the code of layer23 ... it _will_ not do what you want directly. It's a starting point, but you're gonna have to learn to write things by yourself. > though there is no encryption being used. A5/0, i have seen , no ciphering. > in traces. Well it's a perfectly normal behavior that after some time you only see lost frames. I suggest you re-read the code and the specs until you understand _why_ it's normal. > kindly confirm with layer1.compalram.bin , if i will be able to listen > TCH/F assign to some other MS , Not out of the box, as I said, you will need to do some programming. Given the question you ask, you obviously don't understand GSM or the code enough yet to do it. Cheers, Sylvain PS: Please don't hijack a thread that has nothing to do with what you're writing about by just clicking the reply button and not even bothering to change the subject ... seems like you need to read the emails RFC as well ... From technosabby at gmail.com Sun Oct 24 20:08:23 2010 From: technosabby at gmail.com (Marten Christophe) Date: Mon, 25 Oct 2010 01:38:23 +0530 Subject: Switching to TCH In-Reply-To: References: Message-ID: Hi Sylvain, My Apologies for not changing subject line , i just forgot while sending. Thanks for you help Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Tue Oct 26 12:35:36 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 26 Oct 2010 14:35:36 +0200 Subject: command line options for layer23 apps Message-ID: hi, i like to change the handling of command line options in layer23 applications, because different layer23 applications require different individual options, and common options also. (e.g. the "mobile" application does not required "--arfcn" option, but "--vty-port". others do not require "--vty-port", but might require a "--gps-device". all apps together require "--socket" and "--gsmtap-ip".) therefore i like to leave all common options in common/main.c. additional options i like to put in the individual app_*.c files. each options i like to check at the individual app file. if it doesn't exist there, the main.c checks if the option is a common option: ... c = l23_app_handle_options(); if (c == -1) c = getopt_long(argc, argv, "hs:S:a:i:v:d:", long_options, &option_index); if (c == -1) break; ... an individual help for each application: l23_app_print_help(); any suggestions or complains? best regards, andreas From vogelchr at vogel.cx Tue Oct 26 15:48:53 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Tue, 26 Oct 2010 17:48:53 +0200 Subject: command line options for layer23 apps In-Reply-To: References: Message-ID: Hi Andreas, > therefore i like to leave all common options in common/main.c. > additional options i like to put in the individual app_*.c files. each > options i like to check at the individual app file. if it doesn't exist > there, the main.c checks if the option is a common option: > ... > c = l23_app_handle_options(); > if (c == -1) > c = getopt_long(argc, argv, "hs:S:a:i:v:d:", > long_options, &option_index); > if (c == -1) > break; > ... To be honest, I don't like the idea of calling two different "instances" of getopt/getopt_long. But that's just me, probably. What about a app-specific function to call early where the application can register the relevant options: /* in app.c, called before getopt is started */ l32_app_setup_options(){ l32_add_option('q',"quux",1); /* short, long, hasarg */ l32_add_option('d',"debug",0); } /* in common/main.c */ l32_add_option(char short,char *long,int hasarg){ /* append short to a global getopts-type-string */ /* append long opts to global table of long opts */ /* mark long-opt index in table (for long-only opts) so that we know to call l32_app_option */ } And a callback if the option is given: l32_app_option(char short,char *long,char *val){ if(short == 'q' or !strcmp(long,"quux")){ quux = 42 + atoi(val); } if(short == 'd' or !strcmp(long,"debug")){ debugflag++; } } I think that makes for even shorter apps with less getopt branching. Of course it makes it more difficult to handle options where the meaning is position dependant, you have to keep state in global structures then. But we don't want to recreate ffmpeg, do we? Chris From laforge at gnumonks.org Tue Oct 26 17:44:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Oct 2010 18:44:30 +0100 Subject: command line options for layer23 apps In-Reply-To: References: Message-ID: <20101026174430.GU25165@prithivi.gnumonks.org> Hi Christian, On Tue, Oct 26, 2010 at 05:48:53PM +0200, Christian Vogel wrote: > >therefore i like to leave all common options in common/main.c. > >additional options i like to put in the individual app_*.c files. each > >options i like to check at the individual app file. if it doesn't exist > >there, the main.c checks if the option is a common option: > >... > >c = l23_app_handle_options(); > >if (c == -1) > > c = getopt_long(argc, argv, "hs:S:a:i:v:d:", > > long_options, &option_index); > >if (c == -1) > > break; > >... > > To be honest, I don't like the idea of calling two different "instances" > of getopt/getopt_long. But that's just me, probably. I agree. > What about a app-specific function to call early where the application > can register the relevant options: > > /* in app.c, called before getopt is started */ > l32_app_setup_options(){ > l32_add_option('q',"quux",1); /* short, long, hasarg */ > l32_add_option('d',"debug",0); yes, I would like that. But don't make it layer23 specific but put it in libosmocore. This way, even individual code parts like the log file handling can register their own options. For the cross-compilation case we can simply make all the functions no-ops. > Of course it makes it more difficult to handle options where the meaning > is position dependant, you have to keep state in global structures then. > But we don't want to recreate ffmpeg, do we? No, please don't do it. We've done it for iptables, and it is a nightmare :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vogelchr at vogel.cx Wed Oct 27 20:28:53 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Wed, 27 Oct 2010 22:28:53 +0200 Subject: [PATCH] Modular Commandline Parsing [Re: command line options for layer23 apps] In-Reply-To: <20101026174430.GU25165@prithivi.gnumonks.org> References: <20101026174430.GU25165@prithivi.gnumonks.org> Message-ID: <20101027202834.GA7858@vogel.cx> Hi everyone, I was trying to iterate on that subject again, but I think those are things more easily programmed than discussed. So, my first attempt looks like the attached commit to libosmocore, you can also download it at http://vogel.cx/git/0001-Modular-commandline-parsing.patch . It uses a few arrays and singly linked lists which get iterated way too often, but I think for commandline parsing it doesn't really matter. It's used like this: /* callback function, called for each option given */ int option_callback(struct cmdline_item *p, char *argument){ if(p->shortopt == 'v') verbose++; if(!strncmp(p->longopt,"port")) portnum = atoi(argument); } struct cmdline_group mygroup = { .name = "Program Options Group", .nitems = 2, .callback = option_callback, .items = { { 'v',"verbose", 0,"Add verbosity." }, { 0 ,"port", 1,"Specify tcp port." }, } }; /* somewhere during initialisation */ cmdline_register_group(&mygroup); --- configure.in | 1 + include/osmocore/cmdline.h | 37 +++++++++ src/Makefile.am | 2 +- src/cmdline.c | 184 ++++++++++++++++++++++++++++++++++++++++++ tests/Makefile.am | 2 +- tests/cmdline/Makefile.am | 5 + tests/cmdline/cmdline_test.c | 55 +++++++++++++ 7 files changed, 284 insertions(+), 2 deletions(-) create mode 100644 include/osmocore/cmdline.h create mode 100644 src/cmdline.c create mode 100644 tests/cmdline/Makefile.am create mode 100644 tests/cmdline/cmdline_test.c diff --git a/configure.in b/configure.in index 30f9d9c..d9c0d30 100644 --- a/configure.in +++ b/configure.in @@ -114,4 +114,5 @@ AC_OUTPUT( tests/sms/Makefile tests/msgfile/Makefile tests/ussd/Makefile + tests/cmdline/Makefile Makefile) diff --git a/include/osmocore/cmdline.h b/include/osmocore/cmdline.h new file mode 100644 index 0000000..e322b45 --- /dev/null +++ b/include/osmocore/cmdline.h @@ -0,0 +1,37 @@ +#ifndef _OSMOCORE_CMDLINE_H +#define _OSMOCORE_CMDLINE_H + +struct cmdline_item { + char shortopt; /* option "-s" */ + char *longopt; /* option "--longopt" */ + int hasarg; /* option has args */ + char *helptext; /* annotate usage */ + union cmdline_item_data { /* random data you want to keep track of */ + char c; + int i; + void *ptr; + } data; +}; + +struct cmdline_group { + char *name; /* name of this group, for usage */ + /* if an option is called, this callback will trigger. + 1st function parameter is the cmdline_item. + 2nc function parameter is the option argument (hasarg != 0). + Return != 0 from the callback to signal an error! */ + int (*callback)(struct cmdline_item*,char *); + + int nitems; /* number of items */ + struct cmdline_group *next; /* used internally */ + struct cmdline_item items[]; /* items in this group */ +}; + +/* add cmdline_group to osmocore command line parser */ +extern void cmdline_register_group(struct cmdline_group *p); + +/* do the actual parsing */ +extern int cmdline_parse(int argc,char **argv,int *optind); + +extern void cmdline_usage(char *argv0); + +#endif diff --git a/src/Makefile.am b/src/Makefile.am index 64310e0..e4fe4a8 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -13,7 +13,7 @@ libosmocore_la_SOURCES = timer.c select.c signal.c msgb.c rxlev_stat.c \ tlv_parser.c bitvec.c comp128.c gsm_utils.c statistics.c \ write_queue.c utils.c rsl.c gsm48.c gsm48_ie.c \ logging.c gsm0808.c rate_ctr.c gsmtap_util.c \ - gprs_cipher_core.c crc16.c panic.c process.c gsm0480.c + gprs_cipher_core.c crc16.c panic.c process.c gsm0480.c cmdline.c if ENABLE_PLUGIN libosmocore_la_SOURCES += plugin.c diff --git a/src/cmdline.c b/src/cmdline.c new file mode 100644 index 0000000..ddf5747 --- /dev/null +++ b/src/cmdline.c @@ -0,0 +1,184 @@ +/* command line parsing for osmocom applications */ + +/* + * (C) 2010 Christian Vogel + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include + +#include +#include +#include +#include + +static struct cmdline_group *cmdline_groups = NULL; + +/* + * Find short / long option registered with us. shortopt may be \0 + * and longopt may be NULL, then we ignore this part of an item. + * + * Returns item found. If grpret != NULL the variable pointed to + * will be set to the specific group. + */ +static struct cmdline_item * +cmdline_find_item(char shortopt, + const char *longopt, + struct cmdline_group **grpret) +{ + struct cmdline_group *grp = cmdline_groups; + int i; + + while(grp){ + for(i=0;initems;i++){ + struct cmdline_item *item = &grp->items[i]; + if( (shortopt && shortopt== item->shortopt )|| + (longopt && !strcmp(longopt,item->longopt))){ + if(grpret) + *grpret=grp; + return item; + } + } + grp = grp->next; + } +} + +/* add cmdline_group to osmocore command line parser */ +void +cmdline_register_group(struct cmdline_group *p) +{ + /* insert group into chain */ + struct cmdline_group *ogrp,**last = &cmdline_groups; + struct cmdline_item *oitem,*item; + int i; + + /* just for debugging / finding duplicate options */ + for(i=0;initems;i++){ + item = &p->items[i]; + oitem = cmdline_find_item(item->shortopt,item->longopt,&ogrp); + if(oitem){ + fprintf(stderr,"%s: duplicate option registered!", + __FUNCTION__); + if(item->shortopt) + fprintf(stderr," (short: \'%c\')", + item->shortopt); + if(item->longopt) + fprintf(stderr," (long: \"%s\")",item->longopt); + fprintf(stderr,"Old group: %s, this group: %s.\n", + p->name,ogrp->name); + } + } + + while(*last) // add as last group + last = &( (*last)->next ); + *last = p; +}; + +void cmdline_usage(char *argv0){ + struct cmdline_group *grp; + char buf[80]; + int i; + + if(!cmdline_groups){ + fprintf(stderr,"Usage: %s arguments\n",basename(argv0)); + return; + } + fprintf(stderr,"Usage: %s [option] arguments\n\n",basename(argv0)); + for(grp=cmdline_groups;grp;grp=grp->next){ + fprintf(stderr,"*** Options in group %s ***\n",grp->name); + for(i=0;initems;i++){ + struct cmdline_item *item = & grp->items[i]; + if(item->shortopt && item->longopt){ + sprintf(buf,"-%c|--%s", + item->shortopt,item->longopt); + } else if(item->shortopt) { + sprintf(buf,"-%c",item->shortopt); + } else { + sprintf(buf,"--%s",item->longopt); + } + if(item->hasarg) + strcat(buf," ARG"); + if(item->helptext) + fprintf(stderr," %-32s %s\n",buf,item->helptext); + else + fprintf(stderr," %s\n",buf); + } + } +} + +int cmdline_parse(int argc,char **argv,int *optind){ + struct cmdline_group *grp; + struct cmdline_item *item; + struct option *opts,*o; + char *optstr,*s; + int i=0,j; + int ret=0; + + /* how many items do we have? */ + for(grp=cmdline_groups;grp;grp=grp->next) + i += grp->nitems; + + /* allocate memory for getopt_long data structures */ + o = opts = talloc_array(NULL,struct option,i+1); + s = optstr = talloc_size(NULL,1+2*i); // worst case + + /* build struct option array and short option string */ + for(grp=cmdline_groups;grp;grp=grp->next){ + for(i=0;initems;i++){ + item = & grp->items[i]; + if(item->longopt){ + o->name = item->longopt; + o->has_arg = item->hasarg; + o->flag = NULL; + o->val = 0; + o++; + } + if(item->shortopt){ + *s++ = item->shortopt; + if(item->hasarg) + *s++ = ':'; + } + } + } + o->name = NULL; + o->has_arg = 0; + o->flag = NULL; + o->val = 0; + *s = '\0'; + + while(-1 != (i=getopt_long(argc,argv,optstr,opts,&j))){ + item = NULL; + if(i==':' || i=='?'){ + ret=-1; // getopt should write error message + goto out; + } + if(i==0) // long option + item = cmdline_find_item(0,opts[j].name,&grp); + else + item = cmdline_find_item(i,NULL,&grp); + if(grp->callback) + grp->callback(item,optarg); + } +out: + talloc_free(opts); + talloc_free(optstr); + return ret; +} + + diff --git a/tests/Makefile.am b/tests/Makefile.am index 0166b4f..ecdc8ad 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,5 +1,5 @@ if ENABLE_TESTS -SUBDIRS = timer sms ussd +SUBDIRS = timer sms ussd cmdline if ENABLE_MSGFILE SUBDIRS += msgfile endif diff --git a/tests/cmdline/Makefile.am b/tests/cmdline/Makefile.am new file mode 100644 index 0000000..3b155e1 --- /dev/null +++ b/tests/cmdline/Makefile.am @@ -0,0 +1,5 @@ +INCLUDES = $(all_includes) -I$(top_srcdir)/include +noinst_PROGRAMS = cmdline_test + +cmdline_test_SOURCES = cmdline_test.c +cmdline_test_LDADD = $(top_builddir)/src/libosmocore.la diff --git a/tests/cmdline/cmdline_test.c b/tests/cmdline/cmdline_test.c new file mode 100644 index 0000000..295b5aa --- /dev/null +++ b/tests/cmdline/cmdline_test.c @@ -0,0 +1,55 @@ +#include +#include +#include + +#include + +int option_callback(struct cmdline_item *p,char *argument){ + printf("Option specified:"); + if(p->shortopt) + printf(" -%c",p->shortopt); + if(p->shortopt && p->longopt) + printf(" or"); + if(p->longopt) + printf(" --%s",p->longopt); + if(p->hasarg) + printf(" argument=%s",argument); + printf("\n"); + return 0; +} + +struct cmdline_group group_quux = { + .name = "The QUUX group.", + .nitems = 3, + .callback = option_callback, + .items = { + // -s --long, hasarg, description + { 'a',"aaaah", 1,"The Aaaaaaah option."}, + { 'b',"bleech",0,"The Bleech option."}, + { 'c',"cccc", 1,"The CCCC option."} + } +}; + +struct cmdline_group group_foo = { + .name = "The FOO group.", + .callback = option_callback, + .nitems = 2, + .items = { + { 0 ,"foo", 0,"The foo option."}, + { 'v',NULL , 1,"The v option."} + } +}; + + +int main(int argc,char **argv){ + int optind; + + /* in layer23, these would each go into a different + part of the application, e.g. logging, gsm, ... */ + cmdline_register_group(&group_quux); + cmdline_register_group(&group_foo); + + /* in layer23, this would go to the "common" code */ + if(-1 == cmdline_parse(argc,argv,&optind)) + cmdline_usage(argv[0]); +} -- 1.6.3.3 From laforge at gnumonks.org Tue Oct 26 15:50:15 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Oct 2010 16:50:15 +0100 Subject: command line options for layer23 apps In-Reply-To: References: Message-ID: <20101026155015.GJ25165@prithivi.gnumonks.org> Hi Andreas, On Tue, Oct 26, 2010 at 02:35:36PM +0200, Andreas.Eversberg wrote: > i like to change the handling of command line options in layer23 > applications, because different layer23 applications require different > individual options, and common options also. (e.g. the "mobile" > application does not required "--arfcn" option, but "--vty-port". others > do not require "--vty-port", but might require a "--gps-device". all > apps together require "--socket" and "--gsmtap-ip".) > > therefore i like to leave all common options in common/main.c. > additional options i like to put in the individual app_*.c files. each > options i like to check at the individual app file. if it doesn't exist > there, the main.c checks if the option is a common option: > [...] > any suggestions or complains? looks fine to me. I wonder though, if it actoually would work, I've never tried to do multiple getopt_long() calls with different opstring/longopt arguments. I always pondered if it would be worth to have a modular commandline option parser as part of libosmocore, as it is something that we could also need in OpenBSC / OsmoBSC / OsmoSGSN & co. In reality, certain protocol modules have a command line argument, or other parts like the logging subsystem inside libosmocore. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed Oct 27 12:01:06 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 27 Oct 2010 14:01:06 +0200 Subject: osmocom and map Message-ID: hi, recently i committed a conversion tool to convert logged cell information ("SYSTEM INFORMATION" messages) from "cell_log" application into a geographical KML map layer. the quick and dirty name "gsmmap" is about confusing. MAP is actually a short term for "mobile application part", which has absolutely nothing todo with a geographical map. does anyone have a name for it? (my best idea so far: "bcch2kml") regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Oct 28 13:56:43 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 28 Oct 2010 14:56:43 +0100 Subject: Linux + u-boot port to MT6235 Message-ID: <20101028135643.GE26901@prithivi.gnumonks.org> Hi All! At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe, one of the attendees (Marcin, see Cc) came to me after the talk and told me he had recently done a u-boot and Linux kernel port to the MT6235 (that's the ARM926 based chipsets found in the touchscreen MTK phones). He said he has no understanding of GSM or the existing MTK firmware, but is interested in working together with us to try to make the GSM part work. I think that chipset is very intesting, as we could implement the layer1 inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and layer3 implementations as userspace processes on the Linux system, together with the user interface. The performance of those devices should be somewhere between the Openmoko GTA01 and GTA02, and the GSM stack is certainly not going to eat away a lot of the CPU either. I have asked Marcin to write mail to the OsmocomBB mailing list on where we can find the code. He has so far downloaded the code using JTAG. Combining his code with our ramloader might remove that JTAG dependency... Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a separate trac installation for your mtk-linux work, pleaes let me know, I'd be happy to host that. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From technosabby at gmail.com Thu Oct 28 20:10:07 2010 From: technosabby at gmail.com (Marten Christophe) Date: Fri, 29 Oct 2010 01:40:07 +0530 Subject: TCH/F Message-ID: Hello All, Can Any one expert in programming add new command line in full stack GSM application like , ./mobile. to tune or enter for particular. ARFCN , Time slot, hopping sequence. my understanding here is , once i will logged to any cell , it will automatically find FCCH, and SCH and my MS will synchronize, to a cell and read bcch. only thing left over to finish my work is to tune to right ARFN and TS with appropriate HS i want signaling to be involved without it it wont receive TCH. see, to be frank my not expert in C language and even lots of try i couldn't make API for it . so any one can help me . Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From technosabby at gmail.com Thu Oct 28 22:01:01 2010 From: technosabby at gmail.com (Marten Christophe) Date: Fri, 29 Oct 2010 03:31:01 +0530 Subject: TCH/F In-Reply-To: References: Message-ID: Hello All, I just forgot to mention there TSC ( training code sequence ), and ss, ALSO NEED TO ADD IN COMMAND LINE OPTION ALONG WITH TS, and ARFCN Kind Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Oct 29 10:17:25 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 29 Oct 2010 12:17:25 +0200 Subject: TCH/F In-Reply-To: References: Message-ID: <20101029101725.GB3544@prithivi.gnumonks.org> Hi! I think you have some severe misunderstanding how Open Source development works. On Fri, Oct 29, 2010 at 03:31:01AM +0530, Marten Christophe wrote: > I just forgot to mention there TSC ( training code sequence ), and ss, ALSO > NEED TO ADD IN COMMAND LINE OPTION ALONG WITH TS, and ARFCN 1) USING UPPERCASE IS LIKE SHOUTING and considered an INSULT! 2) if you need some extensions of OsmocomBB, you have two options: a) do it yourself. It is Open Soruce software for exactly that reason! b) hire somebody to do it for you. Why do you think that one of us will spend his time (rather than working e.g. on customer projects) to implement the particular features you need? If you need it, you have to do it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From technosabby at gmail.com Fri Oct 29 18:51:54 2010 From: technosabby at gmail.com (Marten Christophe) Date: Fri, 29 Oct 2010 18:51:54 +0000 Subject: TCH/F In-Reply-To: <20101029101725.GB3544@prithivi.gnumonks.org> References: <20101029101725.GB3544@prithivi.gnumonks.org> Message-ID: Hello All, Sorry, I was not aware the fact that using upper case latter does mean shouting, and how i can dare to shout on such a nice people like you all are, i was just requesting and was in hurry while typing nothing else. so forget my mistake I respect you all very much. will never use uppercase . Kind Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.mielczarczyk at gmail.com Fri Oct 29 06:14:50 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Fri, 29 Oct 2010 08:14:50 +0200 Subject: Linux + u-boot port to MT6235 Message-ID: Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: mt6235_setup.jpg Type: image/jpeg Size: 66378 bytes Desc: not available URL: From laforge at gnumonks.org Fri Oct 29 16:11:41 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 29 Oct 2010 18:11:41 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: Message-ID: <20101029161141.GN3544@prithivi.gnumonks.org> Hi Marcin, thanks for introducing yourself and your project. On Fri, Oct 29, 2010 at 08:14:50AM +0200, Marcin Mielczarczyk wrote: > That's true, I managed to run U-Boot on MT6235, but linux kernel is > not fully functional yet (it's fresh stuff as I managed to ran it on > Tuesday and then I was off to conference). sure. > For MT6235 development I chose Sciphone G2, which is pretty cheap. > After some time I managed to download code to SRAM (just 64KB) using > MTK's FlashTool. > MTK FlashTool communicates over UART directly with MT6235 bootloader > and sends its own chunk of code (about 58KB) which is executed in SRAM > and communicates with FlashTool. Have you tried to use the MT622x support in osmocon ? Steve Margraf has added support for MT622x to it, you can see it from http://git.osmocom.org/gitweb?p=osmocom-bb.git;a=commitdiff;h=dd95bcec33237d39274092e2ab1f42eb2633985c If we assume the ROM loader of MTK has not changed between MT622x and MT623x, it may actually work. > I found on pudn.com some pack to customize code loaded by FlashTool, > thanks to which I could download my own code to SRAM (without JTAG). > The problem was that it had to be linked with some security libraries > which occupied about 56KB and not much memory left for my own code. Ok, I see. Could you provide that code? Do you know if the MTK secure boot mode is used on the phone model you use? If yes, than indeed it will need some cryptographic verified 2nd stage loader, Dieter has done some investigation on this. > Then I decided to try find JTAG pins to get all control on MT6235. > That took me sometime, but finally I succeeded. This is great. So far, we have not seen any MT622x based phone that has JTAG exposed. Even the Huayu development modules for the MT622x don't have it. > The other bigger issue was initializing DRAM controller to be able to > download bigger code (linux kernel + uboot) to external RAM. In > sciphone there is problem that all interesting chips are under metal > shield which is pretty havily soldered. In this case I couldn't read > what kind of RAM memory is mounted without destroying the board (I > don't have such soldering machine which could unsolder so big metal > shield). Using a scalpel to remove the shielding sometimes is easier than unsoldering. Other people have reported success using a small dremel tool. > Thanks to JTAG I could attach to target and then dump DRAM > controller registers from processor running MTK's software, but > setting these values after processor start and configuration of PLL > didn't work. Yes, typically for DRAM there is some kind of initialization sequence that you run through, it's not just a static set of registers. > I decided to disassemble bootloader which could show me how DRAM > controller is initialized and how code fron NAND is loaded (to be able > to flash U-Boot and kernel to NAND so MT6235 will start my code > automatically and I will not have to use JTAG). Currently I have > knowledge how internal MT6235 bootloader is loading code from memory > during startup and I also extracted procedure of DRAM controller > initialization. Thanks to that I'm able to run U-Boot from the very > begining of processor startup. this is great. > The problem is that I have just one piece of Sciphone G2 and I don't > want to flash it yet to not break existing code in it. Sure. Even today, we don't flash any of our OsmocomBB software to the target phone yet. Loading code in ram and executing it is much more convenient for development anyway. I think if you can publish the pinout of the JTAG on the Sciphone G2, this would be sufficient for other people to join the project. Many people have a JTAGkey, Openmoko debug board or other OpenOCD compatible JTAG adapter... The second step would be to go back to the ROM loader again and try to get code running through this again. In the end, we will need a development mode where we can e.g. load u-boot via the ROM loader (serial) and then load the kernel + rootfs from SD/MMC card. This should provide rapid development cycles. > You can see how my setup looks on attached picture. Great :) > The good thing about it is that the same bootloader is used in MT622x, > so it should be fairly easy to do the same on phones based on that > SoCs (but unfortuantely it's just ARM7). If it is the same, we should already have code for it (see above). > If it comes to code, of course I can share it on "git.osmocom.org". > Currently it's just basic port of U-Boot and not much for linux > kernel, but I'm working on this now so I'll push it when it'll be > ready. Please send your SSHv2 public key to me in private e-mail and I will give you an account on our git server for u-boot. > Currently I'm working on driver for NAND memory for U-Boot, so we > could flash linux kernel. When that will be ready I'll push the code. great. I think SD/MMC support is almost equally important. It is definitely interesting for us to follow your work if you simply do your changes (even if it's not working yet, or unstable) in git. > If it comes to GSM I didn't work with it before. That shouldn't matter - this is where our experience comes in. There are a lot of unknown variables when it comes to the MT6235 and the corresponding ABB and RF transceiver chips, but given that we've done similar work before for the Calypso, and that we now have a vision where we can run Linux with a L1 inside the kernel and L2/L3 in userspace programs, there should be quite some motivation to make it work. Regards and thanks for all the good news, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marcin.mielczarczyk at gmail.com Sat Oct 30 11:51:28 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Sat, 30 Oct 2010 13:51:28 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101029161141.GN3544@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> Message-ID: Hi, On Fri, Oct 29, 2010 at 6:11 PM, Harald Welte wrote: > > Have you tried to use the MT622x support in osmocon ? ?Steve Margraf > has added support for MT622x to it, you can see it from > http://git.osmocom.org/gitweb?p=osmocom-bb.git;a=commitdiff;h=dd95bcec33237d39274092e2ab1f42eb2633985c > > If we assume the ROM loader of MTK has not changed between MT622x and MT623x, > it may actually work. > No I didn't do this, but of course I can try it. > > Ok, I see. ? Could you provide that code? ?Do you know if the MTK secure > boot mode is used on the phone model you use? ?If yes, than indeed > it will need some cryptographic verified 2nd stage loader, Dieter has > done some investigation on this. > In this case, first I'll explain how it works. Nomenclature: 1) internal bootloader - bootloader placed at 0x48000000 in System ROM 2) 2nd stage bootloader or extarnal bootloader - bootloader placed in NAND - initializes DRAM controller and boots MTK's software - this bootloader prints info on UART by default When MT6235 processor starts it has RM1 bit disabled in EMI_GENA register (External Memory Interface controller), which forces ARM926 core to jump first to System ROM (0x48000000). When internal bootloader is executed it initializes UART to 19200n8 and checks if specific character is received. If no character will be received it continues "normal" boot, so fetches code from NAND (checks bootloader header at 0x0 address, then gets 2nd stage bootloader from NAND). In this case there is no security at all. If we would like to boot from NAND, it's just matter of placing proper bootloader header at address 0x0 in NAND, and then placing U-Boot in proper addresses of NAND (I saw that internal bootloader doesn't fetch code from continues addresses, which means that code is scattered). The prove there is no security is that I can execute my own code from the very beginning. When I initialize CPU with JTAG it's hold at 0x0 address (first address executed) and then I just initialize PLL, DRAM controller, load UBoot to external RAM and execute it. Everything works perfect. There is Secure Engine (SEJ) in MT6235 to protcect program in external memory, but it doesn't look like it's used. The other story is second path which can be taken in internal bootloader. This path is taken when some character will be received by UART at the beginning of internal bootloader startup. That's where FlashTool comes in. Flashtool communicates with internal bootloader and sends its own chunk of code which is executed in SRAM. This code is called Download Agent (DA) and it's linked against some security libraries. If you'll try to download your own code (without these libraries) through FlashTool it'll just fail. You can find DA customization kit under following link: http://en.pudn.com/downloads153/sourcecode/comm/mtk/detail675309_en.html This is source code where you can build your own Download Agent. This is how I first executed my own code on MT6235. It has all make files and it's prepared for ADS compiler. When you'll build your own Download Agent you just select this file in FlashTool and you have your code executed in RAM. I saw that you can use it on all MTK platforms. FlashTool links are also available on pudn.com I didn't analyze this path of bootloader, but it could be good to have it if we would like to create our own flashing tool under Linux (i.e. for flashing U-Boot). > > This is great. ?So far, we have not seen any MT622x based phone that has > JTAG exposed. ?Even the Huayu development modules for the MT622x don't have > it. > It means that I was lucky ... > > Using a scalpel to remove the shielding sometimes is easier than unsoldering. > Other people have reported success using a small dremel tool. > Exactly, I wanted to do this with dremel tool but keyboard is sticked on that metal shield (it's visible on attached picture). If I would remove it, then it would be not possible to assemble my phone back. I had just one piece, so decided to make more elegant way. > > Yes, typically for DRAM there is some kind of initialization sequence > that you run through, it's not just a static set of registers. > In this case there is register EMI_CONN which has to have single bits enabled/disabled one by one for init sequence. That was the missing point. > > Sure. ?Even today, we don't flash any of our OsmocomBB software to the > target phone yet. ?Loading code in ram and executing it is much more > convenient for development anyway. > I agree, but now I have bootloader disassembled and I think it could be possible to download UBoot permanently without risk. We could use that to load our own code to RAM over MMC/SD/serial. > > I think if you can publish the pinout of the JTAG on the Sciphone G2, > this would be sufficient for other people to join the project. ?Many > people have a JTAGkey, Openmoko debug board or other OpenOCD compatible > JTAG adapter... > Of course, no problem. In attachment you can find pinout of JTAG for Sciphone G2. > > The second step would be to go back to the ROM loader again and try to get code > running through this again. ?In the end, we will need a development mode where > we can e.g. load u-boot via the ROM loader (serial) and then load the kernel + > rootfs from SD/MMC card. ?This should provide rapid development cycles. > Yes, I agree. In this case to download U-Boot to NAND we can use FlashTool (only for Windows). Then as you stated we can use U-Boot to load code from SD/MMC/serial. > > If it is the same, we should already have code for it (see above). > That's great! > > It is definitely interesting for us to follow your work if you simply > do your changes (even if it's not working yet, or unstable) in git. > OK, no problem. > > That shouldn't matter - this is where our experience comes in. ?There are > a lot of unknown variables when it comes to the MT6235 and the corresponding > ABB and RF transceiver chips, but given that we've done similar work before > for the Calypso, and that we now have a vision where we can run Linux with a L1 > inside the kernel and L2/L3 in userspace programs, there should be quite some > motivation to make it work. > That's great. BR, Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: scig2_jtag.JPG Type: image/jpeg Size: 87959 bytes Desc: not available URL: From steve at steve-m.de Sat Oct 30 12:53:01 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 30 Oct 2010 14:53:01 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> Message-ID: <4CCC152D.5040400@steve-m.de> Hi Marcin, On 30.10.2010 13:51, Marcin Mielczarczyk wrote: > In this case, first I'll explain how it works. > Nomenclature: > 1) internal bootloader - bootloader placed at 0x48000000 in System ROM > 2) 2nd stage bootloader or extarnal bootloader - bootloader placed in > NAND - initializes DRAM controller and boots MTK's software - this > bootloader prints info on UART by default > > When MT6235 processor starts it has RM1 bit disabled in EMI_GENA > register (External Memory Interface controller), > which forces ARM926 core to jump first to System ROM (0x48000000). > When internal bootloader is executed it initializes UART to 19200n8 > and checks if specific character is received. Alright, this is how it works on the MT622x as well. > This is source code where you can build your own Download Agent. This > is how I first executed my own code on MT6235. It has all make files > and it's prepared for ADS compiler. > When you'll build your own Download Agent you just select this file in > FlashTool and you have your code executed in RAM. > I saw that you can use it on all MTK platforms. > FlashTool links are also available on pudn.com > I didn't analyze this path of bootloader, but it could be good to have > it if we would like to create our own flashing tool under Linux (i.e. > for flashing U-Boot). That's pretty interesting, since it could be used to create authentificated code for other phones with the secure romloader, too. >> This is great. So far, we have not seen any MT622x based phone that has >> JTAG exposed. Even the Huayu development modules for the MT622x don't have >> it. Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD successfully detected the CPU, but I couldn't halt the ARM core (same problem on the Calypso btw). I tried other random ARM7 targets which had the same EmbeddedICE revision and there it worked. > Yes, I agree. > In this case to download U-Boot to NAND we can use FlashTool (only for Windows). > Then as you stated we can use U-Boot to load code from SD/MMC/serial. Getting osmocon to work with the secure romloader could be an option as well. Currently it only supports the non-secure romloader without that *.auth and SLA_Challenge.dll stuff. Plus we have a CFI-flash driver for the Compal phones, which might work on the MTK platform with a few modifications. If that works, we could flash U-Boot without any proprietary Flashtool/DownloadAgent. Regards, Steve From peter at stuge.se Sat Oct 30 13:19:18 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 30 Oct 2010 15:19:18 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CCC152D.5040400@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <4CCC152D.5040400@steve-m.de> Message-ID: <20101030131918.5393.qmail@stuge.se> Steve Markgraf wrote: >>> This is great. So far, we have not seen any MT622x based phone >>> that has JTAG exposed. > > Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD > successfully detected the CPU, but I couldn't halt the ARM core > (same problem on the Calypso btw). I tried other random ARM7 > targets which had the same EmbeddedICE revision and there it > worked. Did you check the config? I've seen bad reset signal settings in tcl/target/*.cfg (trst/srst) which stopped me from getting proper control over the core. //Peter From marcin.mielczarczyk at gmail.com Sat Oct 30 14:13:18 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Sat, 30 Oct 2010 16:13:18 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CCC152D.5040400@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <4CCC152D.5040400@steve-m.de> Message-ID: Hi Steve On Sat, Oct 30, 2010 at 2:53 PM, Steve Markgraf wrote: > > Alright, this is how it works on the MT622x as well. > I thought so, as I already saw that bootloader checks hardware ID and compares it with values 6228, 6226, 6223, etc. > > That's pretty interesting, since it could be used to create authentificated > code for other phones with the secure romloader, too. > That's true, it should work. > > Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD > successfully detected the CPU, but I couldn't halt the ARM core (same > problem on the Calypso btw). I tried other random ARM7 targets which had the > same EmbeddedICE revision and there it worked. > I see that we were going through the same stuff. I had the same problem with Sciphone G2. I could attach to core but I couldn't halt it. At the beginning I detected just four JTAG lines (TCK, TMS, TDI, TDO) and could attach to CPU, but couldn't do more. Then I discovered two more lines: RTCK and nTRST. When I connected them, I still couldn't halt core, but it was just matter of configuration. When PLL is configured (CPU: 208/104MHz, AHBx4: 52MHz and AXBx8: 104MHz) 10MHz clock for JTAG should be used. When PLL is not configured, then RTCK clock should be used. I use Lauterbach for JTAG communication, but in openOCD should work as well. > > Getting osmocon to work with the secure romloader could be an option as > well. Currently it only supports the non-secure romloader without that > *.auth and SLA_Challenge.dll stuff. > Plus we have a CFI-flash driver for the Compal phones, which might work on > the MTK platform with a few modifications. If that works, we could flash > U-Boot without any proprietary Flashtool/DownloadAgent. > Sounds good. BR, Marcin From laforge at gnumonks.org Sat Oct 30 14:25:55 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 30 Oct 2010 16:25:55 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> Message-ID: <20101030142554.GL8939@prithivi.gnumonks.org> Hi Marcin, did you ever find schematics of the Sciphone G2 anywhere online? It would be great to understand which of the I/O lines are connected to which peripherals, especially for the GSM part. Also, do you know the RF transceiver chip used in the device? We already know the MT6129 and MT6139 from the MT622x based phones, but it might be a different one for the MT6235. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marcin.mielczarczyk at gmail.com Sat Oct 30 15:01:17 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Sat, 30 Oct 2010 17:01:17 +0200 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101030142554.GL8939@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> Message-ID: Hi Harald, On Sat, Oct 30, 2010 at 4:25 PM, Harald Welte wrote: > Hi Marcin, > > did you ever find schematics of the Sciphone G2 anywhere online? ?It would > be great to understand which of the I/O lines are connected to which > peripherals, especially for the GSM part. > No I haven't found schematics for Sciphone G2. That's the only thing missing actually. But I found MT6235 reference schematics and I don't think Sciphone change to much. Schematics are attached in this message. > Also, do you know the RF transceiver chip used in the device? ?We already know > the MT6129 and MT6139 from the MT622x based phones, but it might be a different > one for the MT6235. > It's under plastic antenna, but it seems that I can unsolder it so I can check. I checked on reference schematics and there is MT6140D. BR, Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: MT6235____.pdf Type: application/pdf Size: 256221 bytes Desc: not available URL: From 246tnt at gmail.com Fri Oct 29 13:55:27 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 29 Oct 2010 15:55:27 +0200 Subject: L1 TCH code status Message-ID: Hi, Just a quick update for those that don't follow the git or IRC: A few days ago, I merged most of was in my sylvain/testing branch into master. It's now in a state where you can place a call on a BS11 or nanobts. It took a while for me to go from the raw prototype from Dieter to a state I was happy with. (especially because I wanted to understand the purpose of every line I was rewriting since my main goal is to learn :) There were also some extensions (mode switching / bugs fixes / partial HR support / ...). There are still somethings that are only in my testing/ because they're hacks (or even missing): - SIM support: The code is clearly [WIP]. I may get to cleaning it myself at some point, but that's not a priority for me ... - TS change fixup: There is a bug when going from a high TS to a low TS that's tricky to fix. I'm still thinking about the best way to handle this. There is a hack to work around it in my testing branch. This case can't happen on nanoBTS or BS-11 but it may happen on a real network. - TOA loop: I want to check if I can re-use the common code from our AFC/AGC loop rather than adding some other regulation stuff. - Enabling HR: Well ... it doesn't work yet, so no point in putting it in master :) All theses will be added when I have the time to do it. Cheers, Sylvain Munaut From laforge at gnumonks.org Fri Oct 29 15:56:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 29 Oct 2010 17:56:42 +0200 Subject: L1 TCH code status In-Reply-To: References: Message-ID: <20101029155642.GM3544@prithivi.gnumonks.org> Thanks for your update, and I'm happy about the progress you're making! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From hfortier at recon.cx Sat Oct 30 06:34:08 2010 From: hfortier at recon.cx (Hugo Fortier) Date: Sat, 30 Oct 2010 02:34:08 -0400 Subject: 850Mhz support Message-ID: <4CCBBC60.7050804@recon.cx> Hi everyone, I am fairly new to OsmocomBB. Been in North America I acquired a C118(850Mhz/1900Mhz version of the C123) and a C156(850Mhz / 1900mhz version of the C155) but from what I understand at this point is that only 900Mhz and 1800Mhz are supported. I am trying to figure out what modification I need to do in order to implement North American support for OsmocomBB, do I need to modify the firmware or do I only need to modify the host application? Any pointer would be greatly appreciated. I tried to modify the host application but I didn't had any success so far... Also I am trying to acquire a C123 and I find it quite difficult to find in North America, anyone know where I could acquire it from? I have look online but I could only find it on https://www.samstores.com/ and it seem a bit pricey and I have no idea if this store is trust worthy. I am also interested to acquire a BTS for OpenBSC(I currently have OpenBTS running on my USRP) so if you have any pointer on how I could acquire one, let me know. Thanks, Hugo From 246tnt at gmail.com Sat Oct 30 07:20:44 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 30 Oct 2010 09:20:44 +0200 Subject: 850Mhz support In-Reply-To: <4CCBBC60.7050804@recon.cx> References: <4CCBBC60.7050804@recon.cx> Message-ID: > I am fairly new to OsmocomBB. Been in North America I acquired a > C118(850Mhz/1900Mhz version of the C123) and a C156(850Mhz / 1900mhz > version of the C155) but from what I understand at this point is that > only 900Mhz and 1800Mhz are supported. Yes. Most dev being in Europe we never tested anything else. But "most" of the code should already be ok (just not tested), but not all of it. > I am trying to figure out what modification I need to do in order to > implement North American support for OsmocomBB, do I need to modify the > firmware or do I only need to modify the host application? Any pointer > would be greatly appreciated. I tried to modify the host application but > I didn't had any success so far... You definitely need to modify the firmware as well. At the very least I see that the RITA PLL configuration routine doesn't support all the bands. There are probably other places. > Also I am trying to acquire a C123 and I find it quite difficult to find > in North America, anyone know where I could acquire it from? I have look > online but I could only find it on https://www.samstores.com/ and it > seem a bit pricey and I have no idea if this store is trust worthy. Definitely quite expensive ... I bought mine for 19 eur + 8 eur shipping (to EU) from 3gsm.de But it seems they only ship to EU. You could still ask them tough. For a single phone, the shipping might be quite expensive ... OTOH If you're in the US there will be no 900/1800 network anyway. And if you're "close" to the BTS (like an openbts / openbsc you run yourself), the C118 should work fine in the 900 / 1800 band (just choose either a low ARFCN in the 900 band or a high ARFCN in the 1800 band). Cheers, Sylvain From hfortier at recon.cx Sat Oct 30 07:51:58 2010 From: hfortier at recon.cx (Hugo Fortier) Date: Sat, 30 Oct 2010 03:51:58 -0400 Subject: 850Mhz support In-Reply-To: References: <4CCBBC60.7050804@recon.cx> Message-ID: <4CCBCE9E.8080105@recon.cx> > OTOH If you're in the US there will be no 900/1800 network anyway. And > if you're "close" to the BTS (like an openbts / openbsc you run > yourself), the C118 should work fine in the 900 / 1800 band (just > choose either a low ARFCN in the 900 band or a high ARFCN in the 1800 > band). > Thanks for the Tip! it worked! Hugo