baseband-devel February 2010

baseband-devel@lists.osmocom.org

24 participants
27 discussions

New build process / libosmocore
by Harald Welte 20 Feb '10

20 Feb '10

Hi! After much delibeation I have devoted today to 'fix' the way how we build the project and how things depend on each other. We have a couple of challenges: 1) there is (and should be!) a lot of infrastructure code sharing between OpenBSC and OsmocomBB Layer2/3. I'm referring to stuff like linuxlist.h, msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc. 2) we want to do the layer2/layer3 development on the PC, while the layer1 resides on the target phone. However, the code should be API compatible and just compile when we later decide to move (parts of) it into the phone. 3) there is already some code like "msgb" which is used both in layer2(PC) and the phone. 4) I don't want to have too many build dependencies as it makes it unneccesarily difficult to get started with the project. So everything should build from the git tree we provide 5) we dislike the idea of code duplication or copy+paste. This means that we need to build some stuff like libosmocore twice; for the host PC and for ARM The solution looks like this: * libosmocore lives in its own git://git.osmocom.org/libosmocore.git repository. This is where we make changes to it. * libosmocore is 'squashed' into the osmocom-bb.git repository by means of git-subtree[1] to make sure challenge '4' is fulfilled. This is transparent to the user who clones our tree. However, if you want to make changes, please ensure that a commit either only touches files within src/shared/libosmocore or outside of that directory. Mixed commits will require manual action and are tiresome. * everything is built using autotools, except for the 'firmware' (what used to be hello_world) * there's now a top-level Makefile, which * builds libosmocore for the host * builds libosmocore for the target * builds osmocon for the host * builds layer2 for the host * builds the target firmware I understand that this process is quite a bit more complex than what we used to have, but it is the best option that I could come up with. I particularly hope that I didn't do something stupid which would break Cygwin builds... we want to keep Dieter as productive as he currently is, after all :) Regards, Harald [1] git://github.com/apenwarr/git-subtree.git -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[PATCH] fix typo in documentation
by Timo Juhani Lindfors 20 Feb '10

20 Feb '10

--- src/README.building | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/README.building b/src/README.building index f940d09..bfd86b6 100644 --- a/src/README.building +++ b/src/README.building @@ -23,5 +23,5 @@ we do not officially support this. # cd osmocom-bb/src/host/layer2 # autoreconf -i - # ./confiugre + # ./configure # make -- 1.5.6.5

2 1

OpenBSC questions
by Christopher Friedt 20 Feb '10

20 Feb '10

So let me ask a couple of questions about OpenBSC to clarify things for myself. What are the requirements for running OpenBSC ? a) a USRP2 b) some kind of computer with gigabit ethernet (recommended hardware? what kind of load would this be responsible for?) b) a broadband internet connection c) anything else? Some kind of VOIP account somewhere? The reason I'm asking is that I've been doing quite a bit of work with the USRP2 at university, and have been considering buying one for myself for quite some time (although as a student, it's hard to justify the price). My professional / academic / hobby interests definitely involve hacking mobiles, investigating mobile radio, hacking various arm devices, even hardware design, etc, and I guess that OpenBSC would be ideal to for testing out osmocom baseband firmware (rather than having a commercial provider's black box for a BS). I guess another question I could pose to the list would be: Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc? I know that the spec sheets say that it's capable of 50 MHz of instantaneous bandwidth, but I believe that the high data rate 3G (and further) protocols are using wideband OFDM. From my understanding, I would imagine that it would be necessary to support much more than 50 MHz of instantaneous bandwidth, or somehow be able to load the transceiver buffers quickly and sequentially. then push a broad spectrum in parallel. Perhaps this can be achieved with a MIMO configuration, or with a specialized daughter card. Any thoughts? C

5 5

newer more expensive phones
by Mohammad Hosein 20 Feb '10

20 Feb '10

i've got a couple of newer Motorola phones like the milestone also some new HTC phones around any chance these can be used to start playing ?

3 2

Layer2 Wireshark integration
by Harald Welte 19 Feb '10

19 Feb '10

Hi! I've recycled the old GSMTAP wireshark plugin that I originally wrote for project airprobe. Using this patch (now in our git tree as well, applies against current wireshark svn) and the layer2 host program as well as the l1test.bin target program, you can watch BCCH messages in realtime. The architecture is like this: * DSP forwards decoded normal burst data to layer1/sync.c * layer1/sync.c generates L1A_L23 protocol message and sends it via the SERCOMM HDLC layer over RS232 * "osmocon" receives the HDLC frame and relays it to the Unix domain socket * "layer2" receives the L1A_L23 protocol message on the Unix domain socket, adds a GSMTAP header and sends it to the GSMTAP UDP port on localhost * wireshark captures on the 'lo' interface and calls the GSMTAP dissector plugin for everything received on the GSMTAP UDP port number. Have fun! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

good work!
by Christopher Friedt 19 Feb '10

19 Feb '10

Congratulations to all of the developers that worked on this project - you must be very proud at this point! At some point, when I have some free time, I hope to contribute to the codebase (although I don't have a motorola c123, I'm hacking on some other handhelds currently). C

1 0

Announcing project OsmocomBB: Open Source GSM Stack
by Harald Welte 19 Feb '10

19 Feb '10

Good news, everyone [tm]! I am hereby publicly announcing project OsmocomBB: A Free and Open Source software project to create a Free Software GSM baseband firmware. The baseband chipset is the part of a mobile phone that actuall communicates directly with the GSM network. It typically includes a DSP and a microprocessor running some RTOS, drivers for the baseband chipset, the GSM protocol stack and some kind of user interface. GSM has been deployed first 19 years ago. Despite billions of phones deployed world wide, all of them run a proprietary baseband firmware, consisting of proprietary drivers, RTOS and GSM protocol stack. OsmocomBB has set out to change this. We do not want our phones to be a black box connected 24/7 to a public network. We want to decide what kind of data our phone reveals about us or not. The authors behind the project have already spent the last 15 months implementing an Open Source GSM network side protocol implementation called OpenBSC. In January 2010, they decided to go after the phone side protocol stack - which turned into OsmocomBB. => What is the project status? Right now we are at a state where we have full control over the baseband hardware, including the DSP and ARM cores, the analog baseband chip, the RF transceiver, keypad, LCD display and other components. We can scan the GSM band for cells, perform FCCH detection, run automatic gain control to synchronize to the cells carrier, detect the SCH to get BSIC and GSM frame number, as well as dump the BCCH and CCCH of the cell. => What does Osmocom mean? Open Source MObile COMmunications. It is meant as an umbrella name for various FOSS projects related to communications, including OsmocomBB but also including sister projects like OpenBSC. => Can I make phone calls yet? No. We are currently in Rx (receive) only mode, and have no Layer2 or Layer3 implementation yet. However, the difficult parts of driving the GMS hardware and implementing a minimal Layer1 are behind us, so we are confident to proceed to actual phone calls during the months to come. => Where can I get the source? The git repository is at git://git.osmocom.org/osmocom-bb.git The mailing lists are at http://lists.osmocom.org/ The project homepage including wiki is at http://bb.osmocom.org/ => What phones are supported? We are implementing OsmocomBB as hardware-independent as possible. At the moment, we only have drivers for the Ti Calypso Digital Baseband chip. Our main target are the following Motorola-branded phones (made by Compal): C115/116/117/118/119/120/121/122/123/139/140/155 Adding support for other Calypso-based phones should be relatively easy, but porting it to a different baseband chip is a lot of work, especially without access to good documentation. => How can you help? We need developers who have experience in microcontroller development working on an ARM7TDMI core. You do not need to know anything about GSM in order to help us with tasks such as the UI, driving the battery charging controller, etc. If you want to join, get yourself a phone, serial cable, join the developer mailing list and introduce yourself! Happy Hacking Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel February 2010