From laforge at gnumonks.org Wed Apr 6 12:52:16 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 6 Apr 2016 14:52:16 +0200 Subject: OsmoDevCon 2016 update Message-ID: <20160406125216.GB11349@nataraja> Dear attendees of OsmoDevCon 2016, below are some updates regarding OsmoDevCon 2016 = Lunch Catering = OsmoDevCon lunch catering has been finalized by now. I wanted to try some change by having (authentic) thai food, but unfortunately that didn't work out and we're back to our trusted old suppliers for all of the lunches. More details are available on http://projects.osmocom.org/projects/openbsc/wiki/OsmoDevCon2016 = Dinner Catering = In terms of dinner catering, we didn't plan/schedule anything yet. I know it was a request to have it and we introduced it (last year?) but I didn't have time to actively look for a sponsor for this in 2016, sorry. If you think it's important, I can try to get something organized for dinner too, but there's not much time left. It might be easier to simply go out in 2-3 groups, order pizza from the place down the road or even place a larger 'a la carte' order from another place. = Schedule / Talks = Thre's already a list of topics listed at the wiki, specifically: http://projects.osmocom.org/projects/openbsc/wiki/OsmoDevCon2016#TalksDiscussions I think we still have plenty of slots for talks, presentations, discussions, workshops, you name it. Each of you: Please take some time to think about a) topics that you would be able to contribute to the event by giving a talk or leading a discussion or workshop b) topics that you would like to hear about from somebody else Even if we do the actual scheduling ad-hoc at the event itself, it still is useful to have some advance notice about the topics, as the speaker(s) will need to prepare accordingly. = Attendance = If you have registered but will not attend, please let us know as we can still adjust the amount of food we get delivered, and we might offer your seat to somebody else. If you did not register but are an active contributor to the project(s) and would like to attend, let me know, too. I will let you know if somebody cancels their attendance. Looking forward to meeting all of you in Berlin soon. 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 nhofmeyr at sysmocom.de Wed Apr 6 16:34:05 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 6 Apr 2016 18:34:05 +0200 Subject: OsmoDevCon 2016 update In-Reply-To: <20160406125216.GB11349@nataraja> References: <20160406125216.GB11349@nataraja> Message-ID: <20160406163405.GI2470@dub6> On Wed, Apr 06, 2016 at 02:52:16PM +0200, Harald Welte wrote: > = Dinner Catering = > > In terms of dinner catering, we didn't plan/schedule anything yet. I'd recommend Gasthaus Figl [1] in Urbanstr 47 for one evening, where there's outstanding (!!) pizza as well as quite an interesting ancient Kegelbahn [2] in the basement we might be able to book for an hour after diner. Even without a sponsor, I'd book a table for us "on own accord". I'd go for thursday since I expect a higher probability of having room for as many guests. Who would be interested in coming along on thursday? [1] https://en.wikipedia.org/wiki/Kegeln [2] http://gasthaus-figl.de/ ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Wed Apr 6 17:27:09 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 6 Apr 2016 19:27:09 +0200 Subject: OsmoDevCon 2016 update In-Reply-To: <20160406163405.GI2470@dub6> References: <20160406125216.GB11349@nataraja> <20160406163405.GI2470@dub6> Message-ID: <20160406172709.GC8524@nataraja> Hi Neels, On Wed, Apr 06, 2016 at 06:34:05PM +0200, Neels Hofmeyr wrote: > I'd recommend Gasthaus Figl [1] in Urbanstr 47 for one evening, where there's > outstanding (!!) pizza as well as quite an interesting ancient Kegelbahn [2] in > the basement we might be able to book for an hour after diner. generally peple seemed concerned with not spending too much time going to the other end of town (a bit of an exaggeration, but still...) and rather prefer somethign quick in the vicinity of the venue. But that's just my observation from past events, of course that might have been a wrong impression, and of course this year people could be in a different mood. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From madhu at macaque.in Mon Apr 11 15:20:17 2016 From: madhu at macaque.in (Madhu Macaque Labs) Date: Mon, 11 Apr 2016 20:50:17 +0530 Subject: Openphone Message-ID: I am the project lead for the SHAKTI open source processor project. See bitbucket.org/casl This is a large Indian processor development effort that aims to develop a range of processors (from uController to high end servers) based on the RISCV ISA. We work closely with UCB and Cambridge as part of this effort. As part of our processor family, we have just started on a mobile SoC. The goal is to have an octa core SoC with the performance of a snapdragon 820 or the Apple A9. the CPU core is pretty much under control but we are exploring the DSP needed for running the lower levels of the 3G/LTE stack. Another group does LTE stacks and so we have complete testing equipment available to test for compliance. I am basically looking for co-conspirators who can help identify the components I can use from the osmocom stack and figure out what else we need to develop. Then of course we need to develop the DSP core. We are currently reusing the UCB vector processor and we are trying to figure out if a vector thread processor or a conventional DSP will do the trick. Our goal is to have am SoC that will the functionality of a basic smart phone but we do not intend to focus only on a basic phone with voice/data ca[ability but with basic display (even 4 line display is OK). Plan to use the AD SDR board for the SDR section. So it will be a large board that is not optimized for size. Any comments, thoughts appreciated . In case you are wondering, yes we realize this a mammoth task but we are well funded ! This is part of the India processor project. And most importantly all our work will be patent free open source. HW will be BSD, SW will be GPL3/2 -- Regards, Madhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhu at macaque.in Mon Apr 11 15:35:37 2016 From: madhu at macaque.in (Madhu Macaque Labs) Date: Mon, 11 Apr 2016 21:05:37 +0530 Subject: Openphone In-Reply-To: References: Message-ID: I forgot to add. Since the first variant will be on an altera or xilinx board, the first cut design will use the DSP blocks on the FPGA. Cores will be the quad core A53 that is found in the new FPGAs. We can use our cores in the FPGA variants but soft cores will not be as fast as the hard cores. Our SoC development will proceed in parallel. On Mon, Apr 11, 2016 at 8:50 PM, Madhu Macaque Labs wrote: > I am the project lead for the SHAKTI open source processor project. > > See bitbucket.org/casl > > This is a large Indian processor development effort that aims to develop > a range of processors (from uController to high end servers) based > on the RISCV ISA. We work closely with UCB and Cambridge as part of this > effort. > > As part of our processor family, we have just started on a mobile SoC. > The goal is to have an octa core SoC with the performance of a > snapdragon 820 or the Apple A9. the CPU core is pretty much under > control but we are exploring the DSP needed for running the lower levels > of the 3G/LTE stack. > > Another group does LTE stacks and so we have complete testing equipment > available to test for compliance. > > I am basically looking for co-conspirators who can help identify the > components > I can use from the osmocom stack and figure out what else we need to > develop. > Then of course we need to develop the DSP core. We are currently reusing > the UCB vector processor and we are trying to figure out if a vector thread > processor or > a conventional DSP will do the trick. > > Our goal is to have am SoC that will the functionality of a basic smart > phone > but we do not intend to focus only on a basic phone with voice/data > ca[ability but with basic display (even 4 line display is OK). Plan to use > the > AD SDR board for the SDR section. So it will be a large board that is > not optimized for size. > > Any comments, thoughts appreciated . In case you are wondering, yes we > realize > this a mammoth task but we are well funded ! This is part of the India > processor project. And most importantly all our work will be patent free > open source. HW will be BSD, SW will be GPL3/2 > > > > -- > Regards, > Madhu > -- Regards, Madhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Apr 15 20:06:06 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 15 Apr 2016 22:06:06 +0200 Subject: Openphone In-Reply-To: References: Message-ID: <20160415200606.GE1832@nataraja> Hi Madhu, On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote: > I am the project lead for the SHAKTI open source processor project. Thanks a lot for introducing yourself, your extremely ambitious project and for reaching out to us. I can hardly grasp the complexity of your enormous task, and I think it would still be extremely challenging if you would only focus on the cellular side of things, ignoring the application processor side. > snapdragon 820 or the Apple A9. the CPU core is pretty much under > control but we are exploring the DSP needed for running the lower levels > of the 3G/LTE stack. I am not aware of anyone having done any free software work on the MS/UE side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from scratch there - not only ergarding the DSP performance/capability requirements, but also regarding the actual implementation. There's the OsmocomBB work that focusses on classic circuit-switched GSM only, and there is srsUE (see below) for LTE. But everything in between is a big gap. You might be able to extend and re-use OsmocomBB Layer3 for UMTS circuit-switched NAS, but that's just a very small fraction of the problem. Most of the other Osmocom wokr has been focusing on the netwokr side of the protocol stacks, so we have GSM, GPRS and partial EDGE support for all of the network side (PHY to RAN to CN), and we are working on the core-network parts of UMTS/HSPA at this point. But that's of very little use for UE side work, at least on anything beyond message encoding/decoding, some definitions. > Another group does LTE stacks and so we have complete testing equipment > available to test for compliance. I would seriously have a look at the excellent work been done at Software Radio Systems on their srsUE implementation of LTE. They implemented a full LTE UE from PHY via AS to NAS as free software under AGPLv3. They are running all of this on an Intel Core i7 CPU, but I'm sure you could re-implement the performance criticla SDR part of the PHY in your DSP and re-use everything on top. FOSS is abut collaboration and not re-inventing the wheel, after all :) > I am basically looking for co-conspirators who can help identify the > components I can use from the osmocom stack and figure out what else > we need to develop. I personally would love to be involved, but I am already working what other people would consider two full time jobs and there is absolutely no time left to engage in any additional projects without long-term scheduling and planning, sorry. Maybe there are others in Osmocom who'd have more time and interest. In any case, it would be great if you could keep us posted in some way about your progress. 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 madhu at macaque.in Sat Apr 16 07:38:19 2016 From: madhu at macaque.in (Madhu Macaque Labs) Date: Sat, 16 Apr 2016 13:08:19 +0530 Subject: Openphone In-Reply-To: <20160415200606.GE1832@nataraja> References: <20160415200606.GE1832@nataraja> Message-ID: On Sat, Apr 16, 2016 at 1:36 AM, Harald Welte wrote: > Hi Madhu, > > On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote: > > I am the project lead for the SHAKTI open source processor project. > > Thanks a lot for introducing yourself, your extremely ambitious project > and for reaching out to us. I can hardly grasp the complexity of your > enormous task, and I think it would still be extremely challenging if > you would only focus on the cellular side of things, ignoring the > application processor side. > We have in fact decided to split the work into two projects. I have no option but to do the AP and other server SoCs since that is the core project. But we now have a separate LTE/5G modem effort. Focus will be more on programmability than the lower power core. The turbo encoder/decoder is tricky. But then I have a lot of Mater's students at my disposal ! > > > snapdragon 820 or the Apple A9. the CPU core is pretty much under > > control but we are exploring the DSP needed for running the lower levels > > of the 3G/LTE stack. > > I am not aware of anyone having done any free software work on the MS/UE > side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from > scratch there - not only ergarding the DSP performance/capability > requirements, but also regarding the actual implementation. > There seem to be a few openLTE efforts including UE stacks. Looking at those. Fortunately we have a full fledged LTE lab on campus with all the necessary test equipment. > > There's the OsmocomBB work that focusses on classic circuit-switched GSM > only, and there is srsUE (see below) for LTE. But everything in between > is a big gap. You might be able to extend and re-use OsmocomBB Layer3 > for UMTS circuit-switched NAS, but that's just a very small fraction of > the problem. > > Most of the other Osmocom wokr has been focusing on the netwokr side of > the protocol stacks, so we have GSM, GPRS and partial EDGE support for > all of the network side (PHY to RAN to CN), and we are working on the > core-network parts of UMTS/HSPA at this point. But that's of very > little use for UE side work, at least on anything beyond message > encoding/decoding, some definitions. > > > Another group does LTE stacks and so we have complete testing equipment > > available to test for compliance. > > I would seriously have a look at the excellent work been done at > Software Radio Systems on their srsUE implementation of LTE. They > implemented a full LTE UE from PHY via AS to NAS as free software under > AGPLv3. They are running all of this on an Intel Core i7 CPU, but I'm > sure you could re-implement the performance criticla SDR part of the PHY > in your DSP and re-use everything on top. > Have looked at it. Trying to figure out how complete it will be. It is a circular problem. Want to co-design the DSP along with the stack and not dump a DSP on the SW team. My only problem is that our language of choice is Bluespec and not everybody has the toolchain for it. It is a high level HW desgn language (actually a Haskell derivative). Would love to have other enhancing our RTL too. Fortunately the tool is free for open source developers. > > FOSS is abut collaboration and not re-inventing the wheel, after all :) > > > I am basically looking for co-conspirators who can help identify the > > components I can use from the osmocom stack and figure out what else > > we need to develop. > > I personally would love to be involved, but I am already working what > other people would consider two full time jobs and there is absolutely > no time left to engage in any additional projects without long-term > scheduling and planning, sorry. Maybe there are others in Osmocom who'd > have more time and interest. > That is OK. Just spread the work around. The key is to get a completely open LTE HW platform that can be the basis for many commercial implementations. I already have two major phone OEMs signed up for using our modem (when it arrives !). > In any case, it would be great if you could keep us posted in some way > about your progress. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- Regards, Madhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Apr 16 10:54:29 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 16 Apr 2016 13:54:29 +0300 Subject: Openphone In-Reply-To: References: Message-ID: Madhu, On Mon, Apr 11, 2016 at 6:20 PM, Madhu Macaque Labs wrote: > Plan to use the AD SDR board for the SDR section. So it will be a large board that is > not optimized for size. Just curious - which exact transceiver chip are you planing to use? Would be great to have more open-source SDR designs out there for different use cases. We've developed open-source SDR based on LMS6, but it targets network side and is too power hungry for an MS. Otherwise I would offer our help, as I appreciate your effort. This a really amazing project and I hope you'll be able to pull it off. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co Subscribe to Fairwaves news: http://eepurl.com/baL_pf From madhu at macaque.in Sat Apr 16 12:23:22 2016 From: madhu at macaque.in (Madhu Macaque Labs) Date: Sat, 16 Apr 2016 17:53:22 +0530 Subject: Openphone In-Reply-To: References: Message-ID: We do plan to have large PCIe card type format to test the UE side, so we will probably end up using your setup first. W are also using the ADR xcvr for our GPS/IRNSS design. For MS apps, we are evaluating the various parts used in mid range handsets. Will select the one that has the most open documentation. No sure how open silicon motion is. I have no illusions about the difficulty of our project ! But high speed digital design is our bread and butter, so hopefully we should be able to make progress. L1 processing is the tricky part. The main RISCV CPU core is already developed and online in our repository. Probably 2-4 cores with a vector processor accelerator will suffice for the L2/L3 stack. Will use a ringbus or a crossbar as the interconnect. It would help if folks in this forum had any opinions on the UCB VP. See hwacha.org. On Sat, Apr 16, 2016 at 4:24 PM, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > Madhu, > > On Mon, Apr 11, 2016 at 6:20 PM, Madhu Macaque Labs > wrote: > > Plan to use the AD SDR board for the SDR section. So it will be a large > board that is > > not optimized for size. > > Just curious - which exact transceiver chip are you planing to use? > Would be great to have more open-source SDR designs out there for > different use cases. > > We've developed open-source SDR based on LMS6, but it targets network > side and is too power hungry for an MS. Otherwise I would offer our > help, as I appreciate your effort. This a really amazing project and I > hope you'll be able to pull it off. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves, Inc. > https://fairwaves.co > > Subscribe to Fairwaves news: http://eepurl.com/baL_pf > -- Regards, Madhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From evilsocket at gmail.com Thu Apr 21 14:23:03 2016 From: evilsocket at gmail.com (Simone Margaritelli) Date: Thu, 21 Apr 2016 16:23:03 +0200 Subject: Help with a bricked C118 Message-ID: <0DA82F0D-78A0-4708-B2ED-357A9CD5E194@gmail.com> Hi everyone, I just got today a Motorola C118 with a CP2102 interface, so I?ve cloned and compiled the osmocom-bb and started playing with it, everything looked great ( osmocon working, hello world app, rssi and so forth, everything 100% perfect ). Then I started following this page http://osmocom.org/projects/baseband/wiki/Flashing_new Until I reached the point where the menu.e88loader.bin file was referenced ? I don?t have this file (I?m on the master branch), so I closed every tabs of the terminal to search which branch contained that file. Problem is, I?ve executed all the commands prior to this one: host/osmocon/osmoload fprogram 0 0x012000 target/firmware/board/compal_e88/menu.e88loader.bin ( also saved the original loader ) and now the phone doesn?t turn on anymore, neither osmocon is able to detect it ? so I guess it?s bricked? is there any way to unbrick it? Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: