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)
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
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)
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
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)
