Harald Welte's blog


Harald's Web




Other Bloggers
David Burgess
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma


Ohloh profile for laforge
Linked in

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.



Sat, 28 Jan 2012
New OsmocomBB RSSI monitor firmware

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

[ /gsm/osmocom-bb | permanent link ]

Fri, 19 Nov 2010
Initial mt6235 Linux and u-boot code available

As Marcin announced yesterday on the OsmocomBB mailing list, his initial u-boot and Linux port to the MT6235 baseband processor has been pushed to the git.osmocom.org server. He has also provided some instructions and pre-compiled kernel and u-boot images.

He's now working on the NAND, SD/MMC, GPIO and LCD drivers. If you want to help out, feel free to contact Marcin about this.

Meanwhile, I've been doing a bit of theoretical analysis on the GSM baseband / RF interface of the MT6235, based on the limited documentation that is available to the general public. Seems like it's about time to start with practical experiments soon..

[ /gsm/osmocom-bb | permanent link ]

Sat, 30 Oct 2010
u-boot + Linux kernel port to Mediatek MT6235 baseband processor under way

I am really excited about some recent work by Marcin on starting a u-boot and Linux kernel port to the Mediatek MT6235 baseband processor.

Among GSM baseband processors, the MT6235 is a very unusual device. Unlike classic GSM baseband chips, it is not based on an MMU-less ARM7TDMI/ARM7EJS but on an ARM926EJS core. This is a full-blown ARMv5 core on which a standard Linux kernel could run.

The reason for the MT6235 to contain such an 'advanced' ARM core is simple: Mediatek is producing chipsets and reference designs for very inexpensive but feature-rich phones. Instead of going to a full-blown (and expensive) smart-phone design with separate ARM cores for the baseband and application processor, they simply make the base-band processor a bit stronger than needed for the GSM stack, and run the entire rich UI on the same cpu, including TCP/IP stack, touch-screen, web browser, e-mail client, H.264 playback / camera recording, etc.

The original firmware on the Mediatek chipsets is a Nucleus-kernel based software stack which is completely proprietary.

Now the mid-term vision for us is to have a Linux port to the MT6235, and run the OsmocomBB Layer1 (and possibly Layer2) code inside the kernel, while the Layer3 and a user interface program is running as application programs in userspace.

This would allow us to do a very rich user interface (imagine network monitoring modes, protocol tracing, manual cell selection, etc.) while still having to care only about one processor in the system. Furthermore, there are millions of MT6235 based devices, so there will be no shortage of inexpensive hardware to run this code on.

The MT6235 also has a built-in SD/MMC controller (for storing e.g. protocol traces that you take from the GSM network) and it has a fast, dual-mode USB2 high-speed USB controller for connecting it with a PC

Sure, porting our Layer1 to a completely different baseband chipset will be a lot of work, and I don't really have any idea how long it will take us. But I think the vision of such a powerful device (and finally bringing OsmocomBB and the Linux kernel together) should prove a very attractive motivational factor.

This also means: Even if you have no clue about the GSM protocols, you can now start to contribute to OsmocomBB: A lot of Linux kernel drivers for e.g. SD/MMC, USB, frame-buffer, SPI, I2C, PWM and other integrated controllers of the MT6235 need to be written.

Like all Mediatek data sheets, the MT6235 data sheet describing all those peripherals can be found on various places on the Web, including (but not limited to) Chinese developer forums.

It also seems there is at least one MT6235 based phone where JTAG and serial console have been identified (Sciphone Dream G2), which should make debugging and bootstrapping convenient.

[ /gsm/osmocom-bb | permanent link ]

Sat, 14 Aug 2010
Worlds first 20 minute voice call from a Free Software GSM stack on a phone

As Dieter Spaar has pointed out in a mailing list post on the OsmocomBB developer list, he has managed to get a first alpha version of TCH (Traffic Channel) code released, supporting the FR and EFR GSM codecs.

What this means in human readable language: He can actually make voice calls from a mobile phone that runs the Free Software OsmocomBB GSM stack on its baseband processor. This is a major milestone in the history of our project.

While Dieter has been working on the Layer1 TCH support and the setup of the voiceband path in the analog baseband chip (audio ADC/DAC), Andreas Eversberg has been quietly working on getting call control of Layer3 into a state where it can do all the signalling required for mobile-originated and mobile-terminated call.

Combining both of their work together, they have been able to make a 20 minute long voice call from a baseband processor running a Free Software GSM stack. For all we know, it is the first time anything remotely like this has been done using community-developed Free Software. Five years ago I would have thought it's impossible to pull this off with a small team of volunteers. I'm very happy to see that I was wrong, and we actually could do it. With less than half a dozen of developers, in less than nine months of unpaid, spare-time work.

Sure, the next weeks and months will be spent on bringing the code from alpha level to something more stable, fixing known issues and known bugs, etc. But I'm confident the biggest part of the work on the OsmocomBB stack is behind us. Big thanks to the developer team driving this project forward.

[ /gsm/osmocom-bb | permanent link ]

Sun, 09 May 2010
CECT C3100: Not a phone, but a flashlight with integrated phone

I've seen many [mobile] phones in my life, but nothing like the CECT C3100 so far. It's made of the cheapest hard plastic, like cheap kids toys. In addition to the phone keyboard, it has a mechanical switch on its side. If you slide that switch, five powerful bright white LEDs at the top of the phone will turn the entire device into a flashlight.

However, it is one of the most basic phones with one of the older/simpler MTK baseband chips inside (MT6223). Also, as we have determined by a PCB delamination analysis, the test pads next to the MT6223 really are its ARM JTAG pins.

JTAG is something not commonly found in MTK phone designs, but it is definitely a big win for bootstrapping any system-level software such as drivers on the unit.

Right now I don't have the time to work on MT6223, we still have many issues to fix in the current Ti Calypso code. But I can't wait to find time to see if we can extend our hardware support to MTK GSM chipsets...

[ /gsm/osmocom-bb | permanent link ]

Fri, 05 Mar 2010
OsmocomBB now performing location updating procedure against GSM cell

I haven't had much time for blogging recently, too much exciting work going on at OsmocomBB:

  • we now have simplistic support for Uplink (transmit) on SDCCH/4
  • we have a minimal Layer2 (LAPDm) implementation
  • we can send LOCATION UPDATING REQUEST to the network, and receive the respective response
  • there's wireshark integration, i.e. all packets on the L1-L2 interface can be sent into wireshark for protocol analysis

There are still many limitations, but this is a major milestone in the project: We have working bi-directional communication from the phone to the network!

The limitations include:

  • The cell has to use a combined CCCH (SDCCH/4 on timeslot 0)
  • The cell has to use no encryption/authentication
  • The layer2 is not finished, especially re-transmissions will not work yet
  • There's no power control loop yet
  • There's no timing advance correction
However, most of those are more or less simple we know what needs to be done, its just a matter of getting it done kind of tasks. There are no big unknowns involved, and particularly no further reverse-engineering of the hardware is required.

Also, the existence of a stable bi-directional communications channel between the network and the phone means that anyone interested in working on the higher layers can now actually do so. Completing and testing layer2 as well as RR/MM/CC on layer3 is a major task in itself, and it definitely requires the lower layers to be there.

The other good part is that development of layer2 and layer3 can happen entirely on the host PC, where debugging is much easier and there's no need for cross-compilation and we can use all the usual debugging options (gdb, valgrind, ...)

I'm now almost heading off for holidays (starting March 10), so don't expect any major progress from me anytime soon. I hope other interested developers will be able to take it from here and fill in some missing gaps until I'll get back.

[ /gsm/osmocom-bb | permanent link ]

Sat, 20 Feb 2010
Restructuring OpenBSC and OsmocomBB code

I've spent the better part of the day with , renaming files/functions/include paths, Makefiles, autotools and the like.

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

[ /gsm/osmocom-bb | permanent link ]