From thomas.chatt at jhuapl.edu Tue Aug 12 19:37:25 2014 From: thomas.chatt at jhuapl.edu (tomc) Date: Tue, 12 Aug 2014 12:37:25 -0700 (PDT) Subject: mobile app crash In-Reply-To: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> References: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <1407872245964-4026640.post@n3.nabble.com> Were you able to stop this crash from happening? I'm encountering the same problem and haven't figured out a way to prevent it. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/mobile-app-crash-tp4026602p4026640.html Sent from the baseband-devel mailing list archive at Nabble.com. From nlhommet at gmail.com Tue Aug 12 20:48:41 2014 From: nlhommet at gmail.com (nicolas lhommet) Date: Tue, 12 Aug 2014 22:48:41 +0200 Subject: mobile app crash In-Reply-To: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> References: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: probably the same issue than in previous thread "Mobile app crashing while making call" some months ago ? : http://lists.osmocom.org/pipermail/baseband-devel/2014-April/004425.html From holger at freyther.de Wed Aug 13 07:06:01 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Aug 2014 09:06:01 +0200 Subject: mobile app crash In-Reply-To: References: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <20140813070601.GI5784@xiaoyu.lan> On Tue, Aug 12, 2014 at 10:48:41PM +0200, nicolas lhommet wrote: Hi, > probably the same issue than in previous thread "Mobile app crashing > while making call" some months ago ? : > > http://lists.osmocom.org/pipermail/baseband-devel/2014-April/004425.html http://lists.osmocom.org/pipermail/baseband-devel/2014-July/004610.html the situation has not changed. Some user needs to provide a oneliner fix. This community works by collaboration and contribution, so please consider providing a patch. holger > From thomas.chatt at jhuapl.edu Wed Aug 13 17:35:27 2014 From: thomas.chatt at jhuapl.edu (tomc) Date: Wed, 13 Aug 2014 10:35:27 -0700 (PDT) Subject: mobile app crash In-Reply-To: References: <711160384.18289.1406232941344.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <1407951327622-4026643.post@n3.nabble.com> I applied the patch that was linked to in that post, but I'm still getting the crash. Any other suggestions? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/mobile-app-crash-tp4026602p4026643.html Sent from the baseband-devel mailing list archive at Nabble.com. From igor.contato at gmail.com Thu Aug 21 04:04:38 2014 From: igor.contato at gmail.com (Igor Almeida) Date: Thu, 21 Aug 2014 01:04:38 -0300 Subject: Mobile testing branch In-Reply-To: <20140730102846.GV5744@xiaoyu.lan> References: <20140730102846.GV5744@xiaoyu.lan> Message-ID: <53F56FD6.9070404@gmail.com> Hi, On 07/30/2014 07:28 AM, Holger Hans Peter Freyther wrote: > On Wed, Jul 30, 2014 at 10:54:39AM +0200, Milinko Isakovic wrote: >> Hi I have same problem. > > Hi, > >> msgb(0x1638020): Not enough headroom msgb_push (4271669080 < 7) >> backtrace() returned 10 addresses >> /usr/local/lib/libosmocore.so.4(osmo_panic+0xb9) [0x7f2b4ea57929] >> /usr/local/lib/libosmogsm.so.5(lapdm_phsap_up+0x16f) [0x7f2b4e62378f] >> ./mobile() [0x43981c] >> ./mobile() [0x439fce] >> /usr/local/lib/libosmocore.so.4(osmo_wqueue_bfd_cb+0x93) [0x7f2b4ea550d3] >> /usr/local/lib/libosmocore.so.4(osmo_select_main+0x1b1) [0x7f2b4ea54171] >> ./mobile() [0x404be7] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f2b4e099eed] >> ./mobile() [0x404d59] > > we are still waiting for a patch. The LAPDm code is using l2h/l3h but > in rx_l1_rach_conf it is not initialized at all. > > Patches welcome. > The attached patch works for me. Anything I've missed? > holger > -- Igor Almeida From igor.contato at gmail.com Thu Aug 21 03:30:22 2014 From: igor.contato at gmail.com (Igor Almeida) Date: Thu, 21 Aug 2014 00:30:22 -0300 Subject: [PATCH] layer23: initialize l2h/l3h pointers Message-ID: Signed-off-by: Igor Almeida --- src/host/layer23/src/common/l1ctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index 91bab89..c75872e 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -148,6 +148,7 @@ static int rx_l1_rach_conf(struct osmocom_ms *ms, struct msgb *msg) } dl = (struct l1ctl_info_dl *) msg->l1h; + msg->l2h = msg->l3h = dl->payload; osmo_prim_init(&pp.oph, SAP_GSM_PH, PRIM_PH_RACH, PRIM_OP_CONFIRM, msg); -- 2.0.1 --------------070704030600070907020805-- From holger at freyther.de Fri Aug 22 15:50:32 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 22 Aug 2014 17:50:32 +0200 Subject: Mobile testing branch In-Reply-To: <53F56FD6.9070404@gmail.com> References: <20140730102846.GV5744@xiaoyu.lan> <53F56FD6.9070404@gmail.com> Message-ID: <20140822155032.GH14812@xiaoyu.lan> On Thu, Aug 21, 2014 at 01:04:38AM -0300, Igor Almeida wrote: Hi! > dl = (struct l1ctl_info_dl *) msg->l1h; > + msg->l2h = msg->l3h = dl->payload; > yes, looks fine. I had msg->l2h = msg->l3h = msg->tail but dl->payload should probably work as well. I will leave it for Sylvain/Andreas to comment. thanks a lot for the patch holger From 246tnt at gmail.com Fri Aug 22 15:58:41 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 22 Aug 2014 17:58:41 +0200 Subject: Mobile testing branch In-Reply-To: <20140822155032.GH14812@xiaoyu.lan> References: <20140730102846.GV5744@xiaoyu.lan> <53F56FD6.9070404@gmail.com> <20140822155032.GH14812@xiaoyu.lan> Message-ID: On Fri, Aug 22, 2014 at 5:50 PM, Holger Hans Peter Freyther wrote: > On Thu, Aug 21, 2014 at 01:04:38AM -0300, Igor Almeida wrote: > > Hi! > > >> dl = (struct l1ctl_info_dl *) msg->l1h; >> + msg->l2h = msg->l3h = dl->payload; >> > > yes, looks fine. I had msg->l2h = msg->l3h = msg->tail but > dl->payload should probably work as well. I will leave it for > Sylvain/Andreas to comment. > > thanks a lot for the patch I'll give it a shot this week end when I have a osmocom-bb phone handy and merge it. Cheers, Sylvain From mark.neuhaus at email.de Tue Aug 5 09:17:21 2014 From: mark.neuhaus at email.de (mark.neuhaus at email.de) Date: Tue, 5 Aug 2014 11:17:21 +0200 Subject: Aw: Re: Re: Re: Re: seL4 is open source now In-Reply-To: <53E09AC8.2010702@lorquet.fr> References: , <53DCB5E8.5090903@lorquet.fr> , <53DCBDC2.1060407@lorquet.fr> , <53DCC0C2.7090707@lorquet.fr> , <53E09AC8.2010702@lorquet.fr> Message-ID: The kernel comes with a hypervisor (under BSD on Githu, too) and you can run Linux in one virtual environment (see http://l4linux.org/) and for example an GSM stack in another virtual environment. So you can think of that kernel as a kind of virtual machine that seperates the hardware This way all virtual systems are prooven separated and I think that is what the merkel-phone does. owever NICTA is actually going much further. Thei are working on a zero-bug (verified file system) and much more. This kind of programming is entirely different from common way to write a program. (YOU don't write the program, but you write a proof in Coq or ISABEL ect and from this proof a programm can be derived automatically) > Gesendet: Dienstag, 05. August 2014 um 10:50 Uhr > Von: "Sebastien Lorquet" > An: mark.neuhaus at email.de > Betreff: Re: Aw: Re: Re: Re: seL4 is open source now > > Hello, > > Reading through the se4l FAQ at http://sel4.systems/FAQ/ , I'm reading this: > > > Unique about seL4 is its unprecedented degree of assurance, achieved through > formal verification. Specifically, the ARM version of seL4 is the first (and > still only) general-purpose OS kernel with a full code-level functional > correctness proof, meaning a mathematical proof that the implementation (written > in C) adheres to its specification. In short, the implementation is proved to be > bug-free (see below). This also implies a number of other properties, such as > freedom from buffer overflows, null pointer exceptions, use-after-free, etc. > > > Okay with that. But also: > > > There is a further proof that the binary code which executes on the hardware is > a correct translation of the C code. This means that the compiler does not have > to be trusted, and extends the functional correctness property to the binary. > > > So that is very cool, even the binary result is proved, not only the source code ! > > The only thing that bothers me is: what can I do with this cool software? It > seems that little can be done without a set of userspace servers, so I guess we > have to wait until some open source community provides useful software to run > with this microkernel. > > Best regards, > > S?bastien Lorquet > > Le 02/08/2014 12:49, mark.neuhaus at email.de a ?crit : > > > >> My idea is that at some point, the developers working at xda-developers > >> (android phone hackers) will get enough knowledge of their baseband > >> chips so that something can be done with osmocom. But this is only my > >> opinion! > > > > Yes lets hope. The calypso is just to outdated to be interesting > > for anything 'useable' beyond pure hacking-fun. > > > From msokolov at ivan.Harhan.ORG Tue Aug 5 18:44:49 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Tue, 5 Aug 2014 18:44:49 GMT Subject: Usefulness of the Calypso (was Re: seL4 is open source now) Message-ID: <1408051844.AA10718@ivan.Harhan.ORG> Someone (not clear who) said: > > [...] The calypso is just to outdated to be interesting > > for anything 'useable' beyond pure hacking-fun. I violently disagree with that statement. I personally carry a cellphone for one and only one purpose: so I can call my significant other (soon to be wife) and she can cell me at any time. A handset based on the Calypso chipset does this job wonderfully, and is IMO the optimal tool for the job. But the problem is that at the present time there does not exist any cellphone at all, of any kind (dumb, smart, old, new, whatever) that can make and receive cellular phone calls using only Free Software, as defined by the Free Software Foundation, i.e., providing the user with the most essential Four Freedoms: http://www.gnu.org/philosophy/free-sw.html Hence I am currently forced to use a cellphone that runs proprietary firmware, such that I lack the ability to fix any of the UI design flaws that constantly drive me nuts. This situation causes me severe distress, hence I have committed my hobby time and cash budget to a multi-year project to solve this pressing (for me) problem. OsmocomBB is not a solution: it works wonders for "hacking-fun" (the wording in the comment I'm responding to), but is utterly useless for a practical phone which one can carry around in a pocket or purse: my back just isn't strong enough to carry a supersized backpack containing a full PC for running the L23 stack plus a bank of lead-acid batteries. Hence I need a totally different Free Software GSM handset implementation, one that actually runs on the phone itself with proper power management exactly like the original proprietary firmware. And because no one else is working on such a thing, I started my own, and made quite a bit of progress: https://bitbucket.org/falconian/freecalypso-sw But I am using the same Calypso GSM chipset for my project as OsmocomBB uses, simply because it is IMO the optimal tool for the job at hand: allowing a person to communicate with his or her significant other by way of cellular phone calls. The word "outdated" does not exist in my vocabulary; I evaluate a tool based on how well it does the job, rather than some arbitrary irrelevant criteria like manufacture date stamps or whatever. Viva la Revolucion, SF From sweisman at pobox.com Tue Aug 5 18:58:21 2014 From: sweisman at pobox.com (Scott Weisman) Date: Tue, 5 Aug 2014 21:58:21 +0300 Subject: Usefulness of the Calypso (was Re: seL4 is open source now) In-Reply-To: <1408051844.AA10718@ivan.Harhan.ORG> References: <1408051844.AA10718@ivan.Harhan.ORG> Message-ID: I think this desire is recognized. I remember an initiative some years back, started with some enthusiasm, that never got passed the stage of deciding on NuttX as the OS to use, and forking it. On Tue, Aug 5, 2014 at 9:44 PM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > Someone (not clear who) said: > > > > [...] The calypso is just to outdated to be interesting > > > for anything 'useable' beyond pure hacking-fun. > > I violently disagree with that statement. I personally carry a > cellphone for one and only one purpose: so I can call my significant > other (soon to be wife) and she can cell me at any time. A handset > based on the Calypso chipset does this job wonderfully, and is IMO > the optimal tool for the job. > > But the problem is that at the present time there does not exist any > cellphone at all, of any kind (dumb, smart, old, new, whatever) that > can make and receive cellular phone calls using only Free Software, as > defined by the Free Software Foundation, i.e., providing the user with > the most essential Four Freedoms: > > http://www.gnu.org/philosophy/free-sw.html > > Hence I am currently forced to use a cellphone that runs proprietary > firmware, such that I lack the ability to fix any of the UI design > flaws that constantly drive me nuts. This situation causes me severe > distress, hence I have committed my hobby time and cash budget to a > multi-year project to solve this pressing (for me) problem. > > OsmocomBB is not a solution: it works wonders for "hacking-fun" (the > wording in the comment I'm responding to), but is utterly useless for > a practical phone which one can carry around in a pocket or purse: my > back just isn't strong enough to carry a supersized backpack containing > a full PC for running the L23 stack plus a bank of lead-acid batteries. > Hence I need a totally different Free Software GSM handset > implementation, one that actually runs on the phone itself with proper > power management exactly like the original proprietary firmware. And > because no one else is working on such a thing, I started my own, and > made quite a bit of progress: > > https://bitbucket.org/falconian/freecalypso-sw > > But I am using the same Calypso GSM chipset for my project as OsmocomBB > uses, simply because it is IMO the optimal tool for the job at hand: > allowing a person to communicate with his or her significant other by > way of cellular phone calls. The word "outdated" does not exist in my > vocabulary; I evaluate a tool based on how well it does the job, rather > than some arbitrary irrelevant criteria like manufacture date stamps > or whatever. > > Viva la Revolucion, > SF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Tue Aug 5 19:24:48 2014 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 05 Aug 2014 21:24:48 +0200 Subject: Usefulness of the Calypso (was Re: seL4 is open source now) In-Reply-To: <1408051844.AA10718@ivan.Harhan.ORG> References: <1408051844.AA10718@ivan.Harhan.ORG> Message-ID: <53E12F80.2000106@steve-m.de> Hi Michael, On 05.08.2014 20:44, Michael Spacefalcon wrote: > But the problem is that at the present time there does not exist any > cellphone at all, of any kind (dumb, smart, old, new, whatever) that > can make and receive cellular phone calls using only Free Software, as > defined by the Free Software Foundation, i.e., providing the user with > the most essential Four Freedoms: > > http://www.gnu.org/philosophy/free-sw.html [...] > power management exactly like the original proprietary firmware. And > because no one else is working on such a thing, I started my own, and > made quite a bit of progress: > > https://bitbucket.org/falconian/freecalypso-sw I don't quite see how waving the Free Software flag and distributing proprietary source from the TSM30/Locosto leaks (pretty much everything in freecalypso-sw/gsm-fw/) go together. Your efforts would be of much more use if you based them on top of osmocom-bb itself. As long as this main issue with your project remains, I kindly ask you to refrain from making false claims and further advertising your project on this list. Best Regards, Steve From msokolov at ivan.Harhan.ORG Tue Aug 5 19:50:42 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Tue, 5 Aug 2014 19:50:42 GMT Subject: Usefulness of the Calypso (was Re: seL4 is open source now) Message-ID: <1408051950.AA10852@ivan.Harhan.ORG> Steve Markgraf wrote: > I don't quite see how waving the Free Software flag and distributing > proprietary source from the TSM30/Locosto leaks (pretty much everything > in freecalypso-sw/gsm-fw/) go together. That source is NOT proprietary, it is *ex*-proprietary. It *was* proprietary, but not any more - it is now in the public domain. Free Software is not just a "flag" to be waved, it is a practical reality: in *practical* terms, software that is based on ex-proprietary code that has been liberated through the exercise of Eminent Domain and subsequently developed and maintained in the manner of a free sw project gives its users all of the 4 freedoms defined by FSF. However, I shall leave it here -- any further replies or comments or questions in this thread will *not* elicit a further reply from me. But if there is anyone else on this list who desires a usable cellphone for talking to his or her significant other like I do, please be assured that I have no plans of dropping the project; the work is progressing at a steady pace as you can see from the Mercurial commit history, and I have high hopes of some actually-usable result some time around the end of 2014. VLR, SF From steve at steve-m.de Tue Aug 5 20:08:50 2014 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 05 Aug 2014 22:08:50 +0200 Subject: Usefulness of the Calypso (was Re: seL4 is open source now) In-Reply-To: <1408051950.AA10852@ivan.Harhan.ORG> References: <1408051950.AA10852@ivan.Harhan.ORG> Message-ID: <53E139D2.600@steve-m.de> Hi Michael, On 05.08.2014 21:50, Michael Spacefalcon wrote: > That source is NOT proprietary, it is *ex*-proprietary. It *was* > proprietary, but not any more - it is now in the public domain. Even though the circumstances under which this code now suddenly should be public domain in the US are unclear to me: There is no such thing as the public domain in most countries - including the country where the code was written in (France) and the country where the current entity holding the copyright resides in (Germany). > However, I shall leave it here -- any further replies or comments or > questions in this thread will *not* elicit a further reply from me. You are taking the easy way out... Best Regards, Steve From 246tnt at gmail.com Tue Aug 5 21:42:21 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 5 Aug 2014 23:42:21 +0200 Subject: Usefulness of the Calypso (was Re: seL4 is open source now) In-Reply-To: <1408051950.AA10852@ivan.Harhan.ORG> References: <1408051950.AA10852@ivan.Harhan.ORG> Message-ID: > However, I shall leave it here -- any further replies or comments or > questions in this thread will *not* elicit a further reply from me. How about you do us a favor, take this a step further, and stop posting here all together ? Cheers, Sylvain From acassis at gmail.com Tue Aug 5 21:55:20 2014 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Tue, 5 Aug 2014 18:55:20 -0300 Subject: Usefulness of the Calypso (was Re: seL4 is open source now) Message-ID: Hi Scott, On 8/5/14, Scott Weisman wrote: > I think this desire is recognized. I remember an initiative some years > back, started with some enthusiasm, that never got passed the stage of > deciding on NuttX as the OS to use, and forking it. > We got NuttX running on compal phones (Motorola C1xx, W220, etc), including display support using NuttX's native graphic subsystem. The code was submitted to NuttX mainline and now it is integrated. Unfortunately nobody with more knowledge about GSM L1/L2 layers was available to help in the stack porting. During the porting we got help from Steve Markgraf. Now the scenario is more complex, the original "team" is separated and we don't have spare time to help. Best Regards, Alan From mark.neuhaus at email.de Wed Aug 6 01:03:49 2014 From: mark.neuhaus at email.de (mark.neuhaus at email.de) Date: Wed, 6 Aug 2014 03:03:49 +0200 Subject: Aw: Usefulness of the Calypso (was Re: seL4 is open source now) In-Reply-To: <1408051844.AA10718@ivan.Harhan.ORG> References: <1408051844.AA10718@ivan.Harhan.ORG> Message-ID: Pleae, then tell me where to get phones with a Calypso baseband. And I'm talking about marked relevant prices. Don't waste my time with numbers like 5000$. And to be relevant these phones must still be produced so I can get many, if I want. Do you know a source? Beside, I think its better to work on reverse engineered GSM stacks like the Qualcom project as started in https://events.ccc.de/congress/2011/Fahrplan/events/4735.en.html This would capture a lot of phones, since it seems they use more or less the same real-time GSM-OS in most (all?) of their products. > Gesendet: Dienstag, 05. August 2014 um 20:44 Uhr > Von: "Michael Spacefalcon" > An: baseband-devel at lists.osmocom.org > Cc: mark.neuhaus at email.de, sebastien at lorquet.fr > Betreff: Usefulness of the Calypso (was Re: seL4 is open source now) > > Someone (not clear who) said: > > > > [...] The calypso is just to outdated to be interesting > > > for anything 'useable' beyond pure hacking-fun. > > I violently disagree with that statement. I personally carry a > cellphone for one and only one purpose: so I can call my significant > other (soon to be wife) and she can cell me at any time. A handset > based on the Calypso chipset does this job wonderfully, and is IMO > the optimal tool for the job. > > But the problem is that at the present time there does not exist any > cellphone at all, of any kind (dumb, smart, old, new, whatever) that > can make and receive cellular phone calls using only Free Software, as > defined by the Free Software Foundation, i.e., providing the user with > the most essential Four Freedoms: > > http://www.gnu.org/philosophy/free-sw.html > > Hence I am currently forced to use a cellphone that runs proprietary > firmware, such that I lack the ability to fix any of the UI design > flaws that constantly drive me nuts. This situation causes me severe > distress, hence I have committed my hobby time and cash budget to a > multi-year project to solve this pressing (for me) problem. > > OsmocomBB is not a solution: it works wonders for "hacking-fun" (the > wording in the comment I'm responding to), but is utterly useless for > a practical phone which one can carry around in a pocket or purse: my > back just isn't strong enough to carry a supersized backpack containing > a full PC for running the L23 stack plus a bank of lead-acid batteries. > Hence I need a totally different Free Software GSM handset > implementation, one that actually runs on the phone itself with proper > power management exactly like the original proprietary firmware. And > because no one else is working on such a thing, I started my own, and > made quite a bit of progress: > > https://bitbucket.org/falconian/freecalypso-sw > > But I am using the same Calypso GSM chipset for my project as OsmocomBB > uses, simply because it is IMO the optimal tool for the job at hand: > allowing a person to communicate with his or her significant other by > way of cellular phone calls. The word "outdated" does not exist in my > vocabulary; I evaluate a tool based on how well it does the job, rather > than some arbitrary irrelevant criteria like manufacture date stamps > or whatever. > > Viva la Revolucion, > SF > From msokolov at ivan.Harhan.ORG Wed Aug 6 01:59:16 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 6 Aug 2014 01:59:16 GMT Subject: Usefulness of the Calypso (was Re: seL4 is open source now) Message-ID: <1408060159.AA11336@ivan.Harhan.ORG> mark.neuhaus at email.de wrote: > Pleae, then tell me where to get phones with a Calypso > baseband. www.ebay.com > And I'm talking about marked relevant prices. > Don't waste my time with numbers like 5000$. Several OsmocomBB-supported models are currently available on ebay for dirt cheap. > And to be relevant these phones must still be produced so > I can get many, if I want. How many? My company will be happy to produce 5000 Calypso-based phones for you if you make a non-cancelable purchase order and prepay the cost of parts and production. (5000 is the number of Calypso&co chipsets I can buy immediately from my established supplier *without doing any extensive searching*; one can probably get more with some effort.) > Beside, I think its better to work on reverse engineered > GSM stacks like the Qualcom project as started in It's easy to tell other people what they should work on. While you are busy doing that, I'll just keep working on my own solution which will actually result in a usable phone less than a year from now. VLR, SF From mark.neuhaus at email.de Thu Aug 7 14:42:00 2014 From: mark.neuhaus at email.de (mark.neuhaus at email.de) Date: Thu, 7 Aug 2014 16:42:00 +0200 Subject: support for L2/3 on chip Message-ID: Does the current version of OsmocomBB supports to run the layer 2 or the layer 3 on the baseband chip, now? I read through the arxiv of the mailing list but have maybe overlooked this. best, \jo From alexander.huemer at xx.vu Thu Aug 7 14:55:07 2014 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Thu, 7 Aug 2014 16:55:07 +0200 Subject: support for L2/3 on chip In-Reply-To: References: Message-ID: <20140807145507.GD31765@yade.xx.vu> Hi, On Thu, Aug 07, 2014 at 04:42:00PM +0200, mark.neuhaus at email.de wrote: > Does the current version of OsmocomBB supports > to run the layer 2 or the layer 3 on the baseband > chip, now? No. Kind regards, -Alex From akibsayyed at gmail.com Thu Aug 7 15:00:38 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Thu, 7 Aug 2014 20:30:38 +0530 Subject: support for L2/3 on chip In-Reply-To: <20140807145507.GD31765@yade.xx.vu> References: <20140807145507.GD31765@yade.xx.vu> Message-ID: I did some work to port layer 2 layer 3 on chip . i did ported ccch_scan and cell_log app but too lazy to port mobile app :( On Thu, Aug 7, 2014 at 8:25 PM, Alexander Huemer wrote: > Hi, > > On Thu, Aug 07, 2014 at 04:42:00PM +0200, mark.neuhaus at email.de wrote: > > Does the current version of OsmocomBB supports > > to run the layer 2 or the layer 3 on the baseband > > chip, now? > > No. > > Kind regards, > -Alex > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.co Thu Aug 7 16:03:24 2014 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Thu, 07 Aug 2014 18:03:24 +0200 Subject: support for L2/3 on chip In-Reply-To: References: Message-ID: <53E3A34C.6020009@fairwaves.co> Instead of porting it to BB directly you can use OpenMoko Neo Freerunner and run mobile on AP while talking to BP from proper GNU/Linux. Not sure how much work it would be to integrate it with FSO stack but at least you won't have such strict space constraints. BEsides you'll get much nicer screen and other hw features ;) -- best regards, Max, http://fairwaves.co From GNUtoo at no-log.org Thu Aug 7 22:49:30 2014 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 8 Aug 2014 00:49:30 +0200 Subject: support for L2/3 on chip In-Reply-To: <53E3A34C.6020009@fairwaves.co> References: <53E3A34C.6020009@fairwaves.co> Message-ID: <20140808004930.4b179ef2@X60> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 07 Aug 2014 18:03:24 +0200 ? wrote: > Instead of porting it to BB directly you can use OpenMoko Neo > Freerunner and run mobile on AP while talking to BP from proper > GNU/Linux. > > Not sure how much work it would be to integrate it with FSO stack but > at least you won't have such strict space constraints. BEsides you'll > get much nicer screen and other hw features ;) And a very limited battery life. The s3c24xx won't be able to suspend to RAM... Still there is a recipe for an old version of osmocombb for SHR. There was an attempt to port nuttx to osmocombb compatibles phones. It was stopped due to the lack of time of the developers who had some changes in their lives. I had a *very dirty*[1] port of layer1 on top of nuttx. It blocked during the scanning, it could be related to some compiler issues that were solved more recently. Note that the code has to be cleaned becuase it's very dirty and probably incomplete (some #if 0 [...] #endif might remain). Beside the dirty layer1 port, we upstreamed a lot of the work in nuttx. Upstream, in the OS part, the code has to be BSD/permissively licensed. So the code adapted from osmocombb has to be relicensed, which means that the person doing the port: 1) he/she does the port 2) he/she finds all the copyright holders of the particular driver 3) he/she submit upstream Sometimes writing a new driver is easier and makes more sense (like for the C155 LCD driver). Upstreaming worked fine for many drivers, and that can work because only some drivers need to be in the nuttx OS part, they accept a lot more licenses(including the GPL) for the nuttx applications. Some developer specifically stated that he won't relicense GSM specific code to BSD, including some GSM specific drivers, so I guess that puting theses drivers inside the application would be fine. References: - ----------- [1]repository:git://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-gta02.git branch:gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-gta02 Denis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5AJ+AAoJENWQk6o21VqZii4P/i4Cs1Osxv0z5JmZ/adjlsW/ LzHsLshzMvZZnW3e4kku+Fl1EZJeBl+0q6YEwehwCH0WLFFJYkS+ghSW9wYr6aLJ 1CysZ/qXjDQNJyElXhwn8jcxiMA9wcp9C7R5NY1BxeYhmHkqBtf9d5GFyYHc6/Fs Hmg2d3dWbArTCSmaMuOzAqNt/PWDefZg9QER1YdmvGLPBXfOAxjBohBEaCDx96Cx WiyUaoFgo8xx72GpnTsGnOqYj2wC6PStgOTq6Zlplz6zlYZGh7D+raN1FyM//q3+ ebPaZFzQMx7dYx/D4Wly/KeqJRiQEoZWzHXoElgQvguNGl2xXoizgg357qVPyY1u zMpaAy3uRjKheBSt2QHxT2zDaqRjl/gnTEVbGxo9edKP9cwpl5BZlquYKrxmB5QE NcZI37hjirUbQv/P63g0gd/aLLWIar0EmW7vvF/peH1bBfuD7irfnbnJ3PsExR/x 6cPwSgLUWFlArO3/hjWfH4HQCYtPB8m5aHU9H7Cfx7+cEi3aRiP5OxE735hNZ6Sb tRVg7d+uBP6m+j9AEkhRUNoh/sEgZ50If1X/BUBCGctNpvnrqRUIPMZRDzptJn+F iqhieAmSNx+KgmMSlp5z77sQsU+uQFV3/3+6JCJ+5IpZ2YqMCEuJYk+ND5toBgPn B44JBng9BKSpCo+uk+1w =Ojiu -----END PGP SIGNATURE----- From Max.Suraev at fairwaves.co Thu Aug 7 23:00:05 2014 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Fri, 08 Aug 2014 01:00:05 +0200 Subject: support for L2/3 on chip In-Reply-To: <20140808004930.4b179ef2@X60> References: <53E3A34C.6020009@fairwaves.co> <20140808004930.4b179ef2@X60> Message-ID: <53E404F5.1090707@fairwaves.co> 08.08.2014 00:49, Denis 'GNUtoo' Carikli ?????: > And a very limited battery life. The s3c24xx won't be able to suspend > to RAM... > > There was an attempt to port nuttx to osmocombb compatibles phones. > Interesting. Could you clarify more technical details? What is needed for s3c24xx to suspend2ram and what it has to do with nuttx? Is there some documentation/notes covering current developments? -- best regards, Max, http://fairwaves.co From GNUtoo at no-log.org Fri Aug 8 07:44:51 2014 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 8 Aug 2014 09:44:51 +0200 Subject: support for L2/3 on chip In-Reply-To: <53E404F5.1090707@fairwaves.co> References: <53E3A34C.6020009@fairwaves.co> <20140808004930.4b179ef2@X60> <53E404F5.1090707@fairwaves.co> Message-ID: <20140808094451.5cff771c@X60> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 08 Aug 2014 01:00:05 +0200 ? wrote: > 08.08.2014 00:49, Denis 'GNUtoo' Carikli ?????: > > > And a very limited battery life. The s3c24xx won't be able to > > suspend to RAM... If you use suspend to RAM on the s3c24xx, and that the s3c24xx runs the layer 2 and 3, then the layer 2 and 3 won't be able to execute anymore while the s3c24xx is suspended. So the solution, if you want to use it as a phone, would be to prevent the s3c24xx from suspending, which would mean a very poor battery life. Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5IABAAoJENWQk6o21VqZaboP/23TuuefLguYEoIA17Z9oSup 6qUhio7i+qHDWMcMPXwgdkY2v7rml07/gPkh/lATw0HLXYpERDApLQ0ZC2j3f7ft FQoseB6R+etFCc8lq1o0FaK3qBJFZpxTETfkuVtKi9zs1NLGSEg5JTj2xdZKfJJb 33GVyoxUUbG1O5D729zId2SiR95rf7iYDxSE2hCVDPz6ZeqQDCGBOqDyR+ERMRuU a0obzqplEnUNvMrMllMdaUYJgPlNHsjNN6SRvxu1dtbdeFliAc1Nyq8pNY7agTqB ndofShXD4sM9MWzxW1pJtxrLB141LsQgQ2TPe10c3XARVfNpz/61VtjBYydY1I3W VLwDoU2OlY/n8wMywhPJQOUJIyKbmO9iqr7rK+9s9tJRR2cZDMyQ/qlAwrr/c1SY MOMdmtYzJBIYnhvwNzFrV9NQwSn6aZOY5xRbDl43c9jtrzguHEVpvrfaM6pxzpTp Mk5NHqotSjXn0ibYhGjd/cKh7c7wxqu7lSTovLbmLM/RwPxbbgwmAUDJJzoosMIH 43y/6L/4Y0+B6CZMntCNMksbfKGCyOukz/MYrJRLOIQMjs7/BoUfz+kFx/Qs0i6K ZpPmUfdCTmrV5uXHLwmHYCQI3DRXfoIZjOB2d3ryIM99GuV1RLWAmOs3XoJlX5t9 hifNsVhfWr6ljDS8tu+i =o4Vg -----END PGP SIGNATURE----- From yury at bridgecommunication.co.uk Sat Aug 16 13:15:17 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sat, 16 Aug 2014 13:15:17 +0000 (UTC) Subject: pirelli dp10 Message-ID: <2061858096.62013.1408194917971.JavaMail.zimbra@bridgecommunication.co.uk> Hello, anyone has experience to use application mobile on pirelli ? there is no layer1.compalram.bin for this model, any ideas how to run app mobile? Sincerely Yours, Tsaregorodtsev Yury Bridge Communication Billing & Settlement Plan Limited Fernhills Business Center, Foerster Chambers, Todd Street Bury, Gtr Manchester, BL9 5BJ United Kingdom Tel: +441570200000 ICQ: 622719210 MSN: y.tsaregorodtsev at live.com Skype: tsarik-108 web: www.bridgecommunication.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From yury at bridgecommunication.co.uk Thu Aug 21 01:37:02 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Thu, 21 Aug 2014 01:37:02 +0000 (UTC) Subject: sap socket In-Reply-To: <2061858096.62013.1408194917971.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <704932601.65071.1408585022626.JavaMail.zimbra@bridgecommunication.co.uk> Hello, SAP socket doesn't exists anymore? any suggestions how to use external sim card? Thx in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yury at bridgecommunication.co.uk Fri Aug 22 01:18:06 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Fri, 22 Aug 2014 01:18:06 +0000 (UTC) Subject: jolly/handover doesn't work In-Reply-To: <704932601.65071.1408585022626.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <149590000.66068.1408670286595.JavaMail.zimbra@bridgecommunication.co.uk> Hello, handover features doesnt work. Tested on pirelli dp-l10. even in debug window nothing really going on which remind handover. Thx in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricsi at gmx.at Sat Aug 16 19:40:31 2014 From: ricsi at gmx.at (Richard Menedetter) Date: Sat, 16 Aug 2014 21:40:31 +0200 Subject: Pirelli phone charging function in osmocom-bb Message-ID: Hi List I have just reactivated my Pirelli Osmocom phone, and recompiled osmocom-bb. (after rolling back libosmocore it works great) But can it be that charging is not implemented on the Pirelli phone with OsmocomBB? When I attach the MiniUSB cable, I can upload the code great, but when I leave it running for a longer time, it booted into the default charging pirelli screen. I assume that the battery is not that good any more, and it seems that it is running on battery power instead of on USB power. When I upload the RSSI app to the phone it shows me an empty battery icon in the right. (Pirelli SW showed completely full battery icon) Can somebody confirm that the pirelli phone is not charging in osmocom-bb? Is there a chance tha somebody is looking into this anytime? CU, Ricsi PS: Is it still correct that the jolly/test branch is the best for 2 phone transceiver (for OpenBTS/OpenBSC)? This branch should support 2 phones. But as half rate channels are not supported you can only make one call. (ie not possible to make a testcall without going over SIP) Is this information still valid? From vogelchr at vogel.cx Sun Aug 17 10:08:30 2014 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 17 Aug 2014 12:08:30 +0200 Subject: Pirelli phone charging function in osmocom-bb In-Reply-To: References: Message-ID: <53F07F1E.5010008@vogel.cx> Hi Richard, On 16.08.2014 21:40, Richard Menedetter wrote: > But can it be that charging is not implemented on the Pirelli phone with OsmocomBB? I had written the charging code back in 2012, it only works on the C123. I don't know anything about the harware of the Pirelli. http://git.osmocom.org/osmocom-bb/tree/src/target/firmware/battery (you only have the compal_e88 platform (i.e. C123) and a dummy) Chris From ricsi at gmx.at Sun Aug 17 10:48:26 2014 From: ricsi at gmx.at (Richard Menedetter) Date: Sun, 17 Aug 2014 12:48:26 +0200 Subject: Memdump gives bad crc on Motorola C118 Message-ID: Hi I thought I try to flash some osmocom tools into a C118. I have the loader loaded succesfully onto the C118. I can do a finfo (see below) So I wanted to backup the complete flash: osmoload memdump 0x000000 0x200000 c118.bin -> I get "bad crc" for every page Same when I try to backup the loader as on the flashing wiki. Dumping 8192 bytes of memory at 0x0 to file compal_loader.bin bad crc 4190 (not 5c9a) at offset 0x00000000 bad crc f041 (not d50d) at offset 0x000000f0 bad crc f041 (not 3afa) at offset 0x000001e0 Is the C118 not supported for flashing? Can somebody give me any helpful hints? CU, Ricsi chip 0 at 0x00000000 of 2097152 bytes in 2 regions region 0 with 31 blocks of 65536 bytes each block 0 with 65536 bytes at 0x00000000 on chip 0 block 1 with 65536 bytes at 0x00010000 on chip 0 block 2 with 65536 bytes at 0x00020000 on chip 0 block 3 with 65536 bytes at 0x00030000 on chip 0 block 4 with 65536 bytes at 0x00040000 on chip 0 block 5 with 65536 bytes at 0x00050000 on chip 0 block 6 with 65536 bytes at 0x00060000 on chip 0 block 7 with 65536 bytes at 0x00070000 on chip 0 block 8 with 65536 bytes at 0x00080000 on chip 0 block 9 with 65536 bytes at 0x00090000 on chip 0 block 10 with 65536 bytes at 0x000a0000 on chip 0 block 11 with 65536 bytes at 0x000b0000 on chip 0 block 12 with 65536 bytes at 0x000c0000 on chip 0 block 13 with 65536 bytes at 0x000d0000 on chip 0 block 14 with 65536 bytes at 0x000e0000 on chip 0 block 15 with 65536 bytes at 0x000f0000 on chip 0 block 16 with 65536 bytes at 0x00100000 on chip 0 block 17 with 65536 bytes at 0x00110000 on chip 0 block 18 with 65536 bytes at 0x00120000 on chip 0 block 19 with 65536 bytes at 0x00130000 on chip 0 block 20 with 65536 bytes at 0x00140000 on chip 0 block 21 with 65536 bytes at 0x00150000 on chip 0 block 22 with 65536 bytes at 0x00160000 on chip 0 block 23 with 65536 bytes at 0x00170000 on chip 0 block 24 with 65536 bytes at 0x00180000 on chip 0 block 25 with 65536 bytes at 0x00190000 on chip 0 block 26 with 65536 bytes at 0x001a0000 on chip 0 block 27 with 65536 bytes at 0x001b0000 on chip 0 block 28 with 65536 bytes at 0x001c0000 on chip 0 block 29 with 65536 bytes at 0x001d0000 on chip 0 block 30 with 65536 bytes at 0x001e0000 on chip 0 region 1 with 8 blocks of 8192 bytes each block 31 with 8192 bytes at 0x001f0000 on chip 0 block 32 with 8192 bytes at 0x001f2000 on chip 0 block 33 with 8192 bytes at 0x001f4000 on chip 0 block 34 with 8192 bytes at 0x001f6000 on chip 0 block 35 with 8192 bytes at 0x001f8000 on chip 0 block 36 with 8192 bytes at 0x001fa000 on chip 0 block 37 with 8192 bytes at 0x001fc000 on chip 0 block 38 with 8192 bytes at 0x001fe000 on chip 0 From akibsayyed at gmail.com Sun Aug 17 17:37:38 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 17 Aug 2014 23:07:38 +0530 Subject: Memdump gives bad crc on Motorola C118 In-Reply-To: References: Message-ID: hi are you using 64bit os ? try 32bit sounds stupid but worked for me. On Sun, Aug 17, 2014 at 4:18 PM, Richard Menedetter wrote: > Hi > > I thought I try to flash some osmocom tools into a C118. > > I have the loader loaded succesfully onto the C118. > I can do a finfo (see below) > > So I wanted to backup the complete flash: > osmoload memdump 0x000000 0x200000 c118.bin > > -> I get "bad crc" for every page > > Same when I try to backup the loader as on the flashing wiki. > Dumping 8192 bytes of memory at 0x0 to file compal_loader.bin > > bad crc 4190 (not 5c9a) at offset 0x00000000 > bad crc f041 (not d50d) at offset 0x000000f0 > bad crc f041 (not 3afa) at offset 0x000001e0 > > Is the C118 not supported for flashing? > Can somebody give me any helpful hints? > > CU, Ricsi > > > chip 0 at 0x00000000 of 2097152 bytes in 2 regions > region 0 with 31 blocks of 65536 bytes each > block 0 with 65536 bytes at 0x00000000 on chip 0 > block 1 with 65536 bytes at 0x00010000 on chip 0 > block 2 with 65536 bytes at 0x00020000 on chip 0 > block 3 with 65536 bytes at 0x00030000 on chip 0 > block 4 with 65536 bytes at 0x00040000 on chip 0 > block 5 with 65536 bytes at 0x00050000 on chip 0 > block 6 with 65536 bytes at 0x00060000 on chip 0 > block 7 with 65536 bytes at 0x00070000 on chip 0 > block 8 with 65536 bytes at 0x00080000 on chip 0 > block 9 with 65536 bytes at 0x00090000 on chip 0 > block 10 with 65536 bytes at 0x000a0000 on chip 0 > block 11 with 65536 bytes at 0x000b0000 on chip 0 > block 12 with 65536 bytes at 0x000c0000 on chip 0 > block 13 with 65536 bytes at 0x000d0000 on chip 0 > block 14 with 65536 bytes at 0x000e0000 on chip 0 > block 15 with 65536 bytes at 0x000f0000 on chip 0 > block 16 with 65536 bytes at 0x00100000 on chip 0 > block 17 with 65536 bytes at 0x00110000 on chip 0 > block 18 with 65536 bytes at 0x00120000 on chip 0 > block 19 with 65536 bytes at 0x00130000 on chip 0 > block 20 with 65536 bytes at 0x00140000 on chip 0 > block 21 with 65536 bytes at 0x00150000 on chip 0 > block 22 with 65536 bytes at 0x00160000 on chip 0 > block 23 with 65536 bytes at 0x00170000 on chip 0 > block 24 with 65536 bytes at 0x00180000 on chip 0 > block 25 with 65536 bytes at 0x00190000 on chip 0 > block 26 with 65536 bytes at 0x001a0000 on chip 0 > block 27 with 65536 bytes at 0x001b0000 on chip 0 > block 28 with 65536 bytes at 0x001c0000 on chip 0 > block 29 with 65536 bytes at 0x001d0000 on chip 0 > block 30 with 65536 bytes at 0x001e0000 on chip 0 > region 1 with 8 blocks of 8192 bytes each > block 31 with 8192 bytes at 0x001f0000 on chip 0 > block 32 with 8192 bytes at 0x001f2000 on chip 0 > block 33 with 8192 bytes at 0x001f4000 on chip 0 > block 34 with 8192 bytes at 0x001f6000 on chip 0 > block 35 with 8192 bytes at 0x001f8000 on chip 0 > block 36 with 8192 bytes at 0x001fa000 on chip 0 > block 37 with 8192 bytes at 0x001fc000 on chip 0 > block 38 with 8192 bytes at 0x001fe000 on chip 0 > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricsi at gmx.at Sun Aug 17 18:22:26 2014 From: ricsi at gmx.at (Richard Menedetter) Date: Sun, 17 Aug 2014 20:22:26 +0200 Subject: Aw: Re: Memdump gives bad crc on Motorola C118 In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From abelikus at hotmail.com Wed Aug 20 17:56:40 2014 From: abelikus at hotmail.com (=?iso-8859-1?B?QWJlbCBNYWdh8WE=?=) Date: Wed, 20 Aug 2014 11:56:40 -0600 Subject: GSM DoS or conditional access project Message-ID: Hi I wonder if there is a way to develop a Denial of Service or Conditional Access system for a GSM network based on Osmocom. The idea is to develop a commercial product intended to be used to limit unlawful communication in prisons or correctional facilities. My investigation is that this is a kind of worldwide necessity as inmates use smuggled mobile phones for criminal activities (I live in Central America and constantly see news that confirm this is urgent requirement). Currently there a few options available to achieve this purpose: 1. Government authorities require telecom operators to reduce radio signal in the vicinity of confinement facilities2. The use of radio jamming systems to propagate a noise signal3. One or two commercial solutions like iNAC Managed Access from Tecore (a very clever and patented technology) I imagine a solution based on Osmocom as a base station simulating a roaming area in the correctional facility area, for authorized users, dummy network should appear as a FPLMN but for illegal users the fake network must grant access entering driving them into a dead end network with no communication. However I see there are several flaws for this aproach: one is that inmates could set their mobiles to manual network selection and connect themself to commercial mobile networks but I hope this could serve as a ground for further discussion. I will appreciate very much your comments. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From yury at bridgecommunication.co.uk Sun Aug 24 09:39:35 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 09:39:35 +0000 (UTC) Subject: pirelli dp-l10 stuck Message-ID: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> Hi, everybody has same trouble that pirelli stuck after some usage ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricsi at gmx.at Sun Aug 24 12:13:30 2014 From: ricsi at gmx.at (Richard Menedetter) Date: Sun, 24 Aug 2014 14:13:30 +0200 Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> References: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: An HTML attachment was scrubbed... URL: From yury at bridgecommunication.co.uk Sun Aug 24 12:33:11 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 12:33:11 +0000 (UTC) Subject: Aw: pirelli dp-l10 stuck In-Reply-To: References: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <2082651448.67152.1408883591388.JavaMail.zimbra@bridgecommunication.co.uk> Hi Richard, I didn't specify details because everything working properly, beside its just stuck while running mobile application probably during cell sync. Its not charger case, its something different. Beside this if we are talking about charger battery is charging anyway, it doesn't matter osmocom or no osmocom loaded, its USB. But the problem is usb power less (its limited to 100mA) then phone power consumption. do lsusb -v Bus 001 Device 020: ID 0489:e003 Foxconn / Hon Hai Pirelli DP-L10 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0489 Foxconn / Hon Hai idProduct 0xe003 Pirelli DP-L10 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 DP-L10 iSerial 3 0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA MaxPower is 100mA. this is an issue. ----- Original Message ----- From: "Richard Menedetter" To: "Yury TSAREGORODTSEV" Cc: baseband-devel at lists.osmocom.org Sent: Sunday, August 24, 2014 2:13:30 PM Subject: Aw: pirelli dp-l10 stuck Hi Yuri You need to be waaaaaaay more specific of what you have done, and what you have seen. I have not noticed any problems, except the fact that the phone is not charged when Omocom programs are running. This means that when the battery is dead, you will loose power. The phone recognizes that it is charged (default FW) and boots into charging mode. CU, Ricsi Gesendet: Sonntag, 24. August 2014 um 11:39 Uhr Von: "TSAREGORODTSEV, Yury" An: baseband-devel at lists.osmocom.org Betreff: pirelli dp-l10 stuck Hi, everybody has same trouble that pirelli stuck after some usage ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Sun Aug 24 12:59:49 2014 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 24 Aug 2014 14:59:49 +0200 Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <2082651448.67152.1408883591388.JavaMail.zimbra@bridgecommunication.co.uk> References: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> <2082651448.67152.1408883591388.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <53F9E1C5.8070703@steve-m.de> Hi, On 24.08.2014 14:33, TSAREGORODTSEV, Yury wrote: > I didn't specify details because everything working properly, > beside its just stuck while running mobile application probably during > cell sync. > Its not charger case, its something different. Which branch are you using? Make sure you have the following commit in your branch: http://cgit.osmocom.org/osmocom-bb/commit/?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e Regards, Steve From yury at bridgecommunication.co.uk Sun Aug 24 13:07:03 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 13:07:03 +0000 (UTC) Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <53F9E1C5.8070703@steve-m.de> References: <496811954.67106.1408873175732.JavaMail.zimbra@bridgecommunication.co.uk> <2082651448.67152.1408883591388.JavaMail.zimbra@bridgecommunication.co.uk> <53F9E1C5.8070703@steve-m.de> Message-ID: <2053419509.67161.1408885623084.JavaMail.zimbra@bridgecommunication.co.uk> Hi Steve, tried master and jolly/handover anyway my gcc: 4.7.2 (debian wheezy) Yury ----- Original Message ----- From: "Steve Markgraf" To: "Yury TSAREGORODTSEV" , "Richard Menedetter" Cc: baseband-devel at lists.osmocom.org Sent: Sunday, August 24, 2014 2:59:49 PM Subject: Re: Aw: pirelli dp-l10 stuck Hi, On 24.08.2014 14:33, TSAREGORODTSEV, Yury wrote: > I didn't specify details because everything working properly, > beside its just stuck while running mobile application probably during > cell sync. > Its not charger case, its something different. Which branch are you using? Make sure you have the following commit in your branch: http://cgit.osmocom.org/osmocom-bb/commit/?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e Regards, Steve From yury at bridgecommunication.co.uk Sun Aug 24 13:13:51 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 13:13:51 +0000 (UTC) Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <2053419509.67161.1408885623084.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <1395239982.67169.1408886031897.JavaMail.zimbra@bridgecommunication.co.uk> sorry to confuse, system gcc is 4.7.2 but toolchain used gcc used 4.5.2 ( http://bb.osmocom.org/trac/wiki/GnuArmToolchain ) Hi Steve, tried master and jolly/handover anyway my gcc: 4.7.2 (debian wheezy) Yury ----- Original Message ----- From: "Steve Markgraf" To: "Yury TSAREGORODTSEV" , "Richard Menedetter" Cc: baseband-devel at lists.osmocom.org Sent: Sunday, August 24, 2014 2:59:49 PM Subject: Re: Aw: pirelli dp-l10 stuck Hi, On 24.08.2014 14:33, TSAREGORODTSEV, Yury wrote: > I didn't specify details because everything working properly, > beside its just stuck while running mobile application probably during > cell sync. > Its not charger case, its something different. Which branch are you using? Make sure you have the following commit in your branch: http://cgit.osmocom.org/osmocom-bb/commit/?id=a903b3c1ee27047c79728b18ff6340d23d1aad2e Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From yury at bridgecommunication.co.uk Sun Aug 24 19:40:14 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 19:40:14 +0000 (UTC) Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <2082651448.67152.1408883591388.JavaMail.zimbra@bridgecommunication.co.uk> Message-ID: <1750853613.67319.1408909214136.JavaMail.zimbra@bridgecommunication.co.uk> Damn, yeah its not charging at all :) even when connected to hub with external power :) Hi Richard, I didn't specify details because everything working properly, beside its just stuck while running mobile application probably during cell sync. Its not charger case, its something different. Beside this if we are talking about charger battery is charging anyway, it doesn't matter osmocom or no osmocom loaded, its USB. But the problem is usb power less (its limited to 100mA) then phone power consumption. do lsusb -v Bus 001 Device 020: ID 0489:e003 Foxconn / Hon Hai Pirelli DP-L10 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0489 Foxconn / Hon Hai idProduct 0xe003 Pirelli DP-L10 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 DP-L10 iSerial 3 0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA MaxPower is 100mA. this is an issue. ----- Original Message ----- From: "Richard Menedetter" To: "Yury TSAREGORODTSEV" Cc: baseband-devel at lists.osmocom.org Sent: Sunday, August 24, 2014 2:13:30 PM Subject: Aw: pirelli dp-l10 stuck Hi Yuri You need to be waaaaaaay more specific of what you have done, and what you have seen. I have not noticed any problems, except the fact that the phone is not charged when Omocom programs are running. This means that when the battery is dead, you will loose power. The phone recognizes that it is charged (default FW) and boots into charging mode. CU, Ricsi Gesendet: Sonntag, 24. August 2014 um 11:39 Uhr Von: "TSAREGORODTSEV, Yury" An: baseband-devel at lists.osmocom.org Betreff: pirelli dp-l10 stuck Hi, everybody has same trouble that pirelli stuck after some usage ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Sun Aug 24 21:05:29 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sun, 24 Aug 2014 21:05:29 GMT Subject: Aw: pirelli dp-l10 stuck Message-ID: <1408242105.AA03672@ivan.Harhan.ORG> "TSAREGORODTSEV, Yury" wrote: > Damn, yeah > its not charging at all :) > even when connected to hub with external power :) Unfortunately there are no schematics available for the DP-L10 (and reconstructing them from steve-m's PCB layer scans is anything but easy), so everything that follows is ultimately pure guesswork, but it *seems* to me that the battery charging circuit in this phone is fundamentally the same as in the more traditional Calypso+Iota phones (Compal etc), aside from using USB VBUS as the charging power source instead of a dedicated round-plug type of power jack. If the charging circuit in the DP-L10 works the way I think it does, following common sense and all that, than the battery charging process ought to be controlled by Iota ABB. The ABB chip in this phone is TWL3014, but I'll use the more readable TWL3025 datasheet as a reference instead - back in 2011 both Steve M. and Sylvain M. said on this list that the two chips are functionally identical. The battery charging functionality is described on pages 46-48 of TWL3025_SWRS021.pdf; in particular, refer to Figure 4-10 on page 48. If my understanding of this datasheet description is correct, and if the phone in question (Pirelli DP-L10) indeed has its battery charging circuit implemented in the canonical way, then one of the following two conditions must be met in order for charging current to pass from VBUS into the battery: 1. The "precharge" function is enabled inside the ABB chip, such that an internal transistor in the ABB opens up to pass some current from the VCHG pin to the PCHG pin. This precharge function is intended for situation when the battery has discharged so low that it needs to be charged some before one can boot the CPU, hence this precharge phase has to be done entirely in hardware without any CPU firmware supervision. But it appears that this hardware-only precharge function is automatically disabled when the CPU is turned on, or maybe the precharge current is so feeble that the drain from the running CPU is greater than the amount of power coming from the precharge circuit. -or- 2. The "normal" way of charging the battery (with the CPU running) is for the CPU to enable the main charging circuit in the ABB via some register writes. In this case the power flows from the charging source (USB VBUS in the case of Pirelli DP-L10) into the battery through an external power transistor controlled by the ICTL output from the ABB. In TI's standard firmware the battery charging function lives in the PWR SWE (RiViera Software Entity) in the older versions and in the LCC SWE in newer ones. Pirelli's version appears to use PWR rather than LCC. We (the world public) have the source for the PWR SWE in the MV100 find, and that for LCC in the Sotovik find, but I haven't really looked at either of them yet - working on L1 integration currently. If you would like to get Pirelli battery charging working in OsmocomBB, I would recommend that you take the charging code for compal_e88, enable it for the DP-L10 build, and experiment from there. Don't be fooled by Pirelli's use of USB charging instead of a round-plug charger, my guess is that they use USB VBUS in exactly the same way as how Compal etc use their charging power source. It also seems to me that Pirelli's charging mechanism does not strictly comply with the USB spec. Per the spec, you are supposed to draw no more than 100 mA from VBUS until and unless you negotiate a higher power budget with the host, and that negotiation takes place over the D+ and D- wires. But in Pirelli's case these D+ and D- wires go to the CP2102 USB-serial chip and nowhere else, and only this CP2102 speaks the USB protocol - the Calypso only sees UART-serial on the other side of the CP2102. So they "illegally" tap VBUS (which per the spec must not go anywhere but to the device that speaks the USB protocol) to use it as the charging power source, but have no way to negotiate their current draw. When Pirelli's fw detects the presence of VBUS via the charger-insert interrupt from the ABB and decides to start charging the battery, it has no choice but to enable some hard-coded charging current value - the charging current can be adjusted by programming a register in the ABB, but the fw has no way of knowing how much current it is allowed to draw from VBUS, if any at all, because only the USB logic in the CP2102 has access to this knowledge. So whatever charging current it draws, it must do so blindly. I can only guess that this current must be somewhere around 500 mA, as charging at 100 mA would be too slow. I actually like Pirelli's design in this regard, and I currently plan on copying it in my own Pirelli-inspired Calypso dumbphone design: put a CP2102 inside the phone just like Pirelli did, and use the same USB charging arrangement, drawing 500 mA for charging unconditionally, showing "the middle finger" to the developer-unfriendly Unusable Serial Botch specs... Or can someone think of a better way? VLR, SF From yury at bridgecommunication.co.uk Sun Aug 24 21:39:24 2014 From: yury at bridgecommunication.co.uk (TSAREGORODTSEV, Yury) Date: Sun, 24 Aug 2014 21:39:24 +0000 (UTC) Subject: Aw: pirelli dp-l10 stuck In-Reply-To: <1408242105.AA03672@ivan.Harhan.ORG> References: <1408242105.AA03672@ivan.Harhan.ORG> Message-ID: <2082900392.67412.1408916364141.JavaMail.zimbra@bridgecommunication.co.uk> Well, accordingly to specs more or less everything same, i have few phones and ready to say goodbye to them :) but as i never been guru as so many guys here i dunno what kind of changes to do in code, as anyway c123 doesn't use usb at all, so unfortunately code should be modified anyway, if someone can do it I am gladly gonna be tester :) Yury ----- Original Message ----- From: "Michael Spacefalcon" To: baseband-devel at lists.osmocom.org Sent: Sunday, August 24, 2014 11:05:29 PM Subject: Re: Aw: pirelli dp-l10 stuck "TSAREGORODTSEV, Yury" wrote: > Damn, yeah > its not charging at all :) > even when connected to hub with external power :) Unfortunately there are no schematics available for the DP-L10 (and reconstructing them from steve-m's PCB layer scans is anything but easy), so everything that follows is ultimately pure guesswork, but it *seems* to me that the battery charging circuit in this phone is fundamentally the same as in the more traditional Calypso+Iota phones (Compal etc), aside from using USB VBUS as the charging power source instead of a dedicated round-plug type of power jack. If the charging circuit in the DP-L10 works the way I think it does, following common sense and all that, than the battery charging process ought to be controlled by Iota ABB. The ABB chip in this phone is TWL3014, but I'll use the more readable TWL3025 datasheet as a reference instead - back in 2011 both Steve M. and Sylvain M. said on this list that the two chips are functionally identical. The battery charging functionality is described on pages 46-48 of TWL3025_SWRS021.pdf; in particular, refer to Figure 4-10 on page 48. If my understanding of this datasheet description is correct, and if the phone in question (Pirelli DP-L10) indeed has its battery charging circuit implemented in the canonical way, then one of the following two conditions must be met in order for charging current to pass from VBUS into the battery: 1. The "precharge" function is enabled inside the ABB chip, such that an internal transistor in the ABB opens up to pass some current from the VCHG pin to the PCHG pin. This precharge function is intended for situation when the battery has discharged so low that it needs to be charged some before one can boot the CPU, hence this precharge phase has to be done entirely in hardware without any CPU firmware supervision. But it appears that this hardware-only precharge function is automatically disabled when the CPU is turned on, or maybe the precharge current is so feeble that the drain from the running CPU is greater than the amount of power coming from the precharge circuit. -or- 2. The "normal" way of charging the battery (with the CPU running) is for the CPU to enable the main charging circuit in the ABB via some register writes. In this case the power flows from the charging source (USB VBUS in the case of Pirelli DP-L10) into the battery through an external power transistor controlled by the ICTL output from the ABB. In TI's standard firmware the battery charging function lives in the PWR SWE (RiViera Software Entity) in the older versions and in the LCC SWE in newer ones. Pirelli's version appears to use PWR rather than LCC. We (the world public) have the source for the PWR SWE in the MV100 find, and that for LCC in the Sotovik find, but I haven't really looked at either of them yet - working on L1 integration currently. If you would like to get Pirelli battery charging working in OsmocomBB, I would recommend that you take the charging code for compal_e88, enable it for the DP-L10 build, and experiment from there. Don't be fooled by Pirelli's use of USB charging instead of a round-plug charger, my guess is that they use USB VBUS in exactly the same way as how Compal etc use their charging power source. It also seems to me that Pirelli's charging mechanism does not strictly comply with the USB spec. Per the spec, you are supposed to draw no more than 100 mA from VBUS until and unless you negotiate a higher power budget with the host, and that negotiation takes place over the D+ and D- wires. But in Pirelli's case these D+ and D- wires go to the CP2102 USB-serial chip and nowhere else, and only this CP2102 speaks the USB protocol - the Calypso only sees UART-serial on the other side of the CP2102. So they "illegally" tap VBUS (which per the spec must not go anywhere but to the device that speaks the USB protocol) to use it as the charging power source, but have no way to negotiate their current draw. When Pirelli's fw detects the presence of VBUS via the charger-insert interrupt from the ABB and decides to start charging the battery, it has no choice but to enable some hard-coded charging current value - the charging current can be adjusted by programming a register in the ABB, but the fw has no way of knowing how much current it is allowed to draw from VBUS, if any at all, because only the USB logic in the CP2102 has access to this knowledge. So whatever charging current it draws, it must do so blindly. I can only guess that this current must be somewhere around 500 mA, as charging at 100 mA would be too slow. I actually like Pirelli's design in this regard, and I currently plan on copying it in my own Pirelli-inspired Calypso dumbphone design: put a CP2102 inside the phone just like Pirelli did, and use the same USB charging arrangement, drawing 500 mA for charging unconditionally, showing "the middle finger" to the developer-unfriendly Unusable Serial Botch specs... Or can someone think of a better way? VLR, SF From sh.huang at venusource.com Mon Aug 25 08:30:44 2014 From: sh.huang at venusource.com (huang) Date: Mon, 25 Aug 2014 01:30:44 -0700 (PDT) Subject: Can osmocomBB support multi phone simultaneously for a same sniff Message-ID: <1408955444530-4026665.post@n3.nabble.com> For example, if i use three phone to catch TS0,can this three phones work at the same time -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Can-osmocomBB-support-multi-phone-simultaneously-for-a-same-sniff-tp4026665.html Sent from the baseband-devel mailing list archive at Nabble.com.