Restructuring OpenBSC and OsmocomBB code
I've spent the better part of the day with , renaming files/functions/include paths, Makefiles, autotools and the
The result of this is a new sub-project called libosmocore that
gathers all the shared code between the network-side GSM implementation
OpenBSC and the phone-side implementation OsmocomBB. The library is
portable enough that it can run on a proper OS (like GNU/Linux) but
also be cross-compiled to work on the actual phone without any OS.
On the other hand we now have a master Makefile in OsmocomBB to build
libosmocore for host PC and target (phone), as well as the osmocon
and layer2 host programs and the phone firmware itself.
Let's hope I can now return to writing actual code...
Announcing OsmocomBB: Free Software / Open Source GSM Baseband firmware
Last, but not least, I am proud to announce the OsmocomBB project publicly. During the last
7 weeks, a small group of skilled developers has been working on this
It has now reached a point where we can
- scan the spectrum for the strongest signal GSM channels
- lock onto them and performing AFC (automatic frequency control)
- decode the SCH burst to obtain BSIC and GSM frame time
- decode the BCCH of the cell, pass it over to the host PC and feed it into
Since this in itself is a valuable and useful milestone of the project,
it was the ideal opportunity to take this project public.
There's still a lot of work to be done in many areas. Most of them are not
even related to the GSM air interface. So if you're familiar with C
development on an ARM7TDMI based microcontroller, know your way around
I2C and SPI, are familiar with the GNU toolchain for ARM and want to
help us out: Please join the baseband-devel mailing
list right away!
In six weeks from bare hardware to receiving BCCHs
After six weeks of full-time hacking, with the help of a few friends, we have
made it to receiving actual BCCH data from a GSM cell.
So what does this mean? As I have indicated publicly at the 26C3 conference:
Now, that we have managed to create a working GSM network-side implementation
(OpenBSC) during the last year, we will proceed to do the same with the phone side.
Initially we spent quite a bit of thinking on building our own custom hardware.
But while planning for the first prototype, we realized that it would simply
distract us too much from what we actually wanted to do. We don't want to take
care of component sourcing, prototype generations, quality assurance in
production, production testing, etc. -- All we want is to write a Free Software
GSM protocol implementation for a phone.
Unfortunately (as usually in the industry), the silicon and device makers do
not publish sufficient documentation about their devices to enable third-party
developers to go ahead and write their own software: The never ending
problem of Free Software in many areas beyond more-or-less standardized
hardware like in the PC industry.
So, if you want to write Free Software for such a device, you have two options:
- Reverse engineering the existing hardware and writing your code based on
- Building your own hardware and then writing the software you wanted
I've been involved in both approaches multiple times while looking only at the
application processor (the PDA side) of mobile phones: OpenEZX and gnufiish are
two more or less abandoned projects aimed at reverse engineering. Openmoko was
the project that had to build its own hardware as a dependency to be fulfilled
before writing software.
If you're not a company and don't want to sell anything, the reverse
engineering approach looks more promising. You can piggy-back on existing
hardware, don't need to take care of sourcing/production/certification/shipping
and other tedious bits.
If you are a company and want to generate revenue, then of course you want
to build the hardware and ship it, as it is what you derive your profits
So, just to be clear on this: Neither OpenEZX, nor gnufiish nor Openmoko were
ever about writing Free Software for the GSM baseband processor, i.e. the beast
that exchanges messages with the actual GSM operator network. But this is what
we're working on right now.
It's about time, don't you agree? after 19 years of only proprietary software
on the baseband chips in billions of phones, it is more than time for bringing
the shining light of Freedom into this area of computing.
To me personally, it is the holy grail of Free Software: Driving it beyond the
PC, beyond operating systems and application programs. Driving it into the
billions of embedded devices where everyone is stuck with proprietary software
without an alternative. Everybody takes it for granted to run megabytes of
proprietary object code, without any memory protection, attached to an
insecure public network (GSM). Who would do that with his PC on the Internet,
without a packet filter, application level gateways and a constant flow
of security updates of the software? Yet billions of people do that with
their phones all the time.
I hope with our work there will be a time where the people who paid for their
phones will be able to actually own and control what it does. If I have paid
for it, I determine what software it runs and when it send which message or
Oh, getting back to what our work: It will be published as soon as it is
sufficiently stable and fit for public consumption. You won't be able
to make phone calls yet, but we'll get there at some later point this
Symbian is Open Soruce - Really?
In recent news, the Symbian Foundation announced that "All 108 packages
containing the source code of the Symbian platform can now be downloaded from
Symbian's developer web site". This is great news!
This morning I tried to look at the parts most interesting to me: phonesrv
(implementing call engine, cell broadcast and SIM toolkit APIs) and poc
(implementing push-to-talk). Their pages don't have the usual "source code"
tab at the bottom right which links to mercurial and tarball download pages!
Either I'm too stupid, or I am unable to find any source code for those two
components. I'm quite sure something essential like the API's for making phone
calls are considered part of the Symbian platform. So how does that match
with the statement that all packages containing the Symbian platform can now