LaForge's home page (Posts about osmocom-bb)

New OsmocomBB RSSI monitor firmware

Harald Welte — Fri, 27 Jan 2012 19:00:00 GMT

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

Initial mt6235 Linux and u-boot code available

Harald Welte — Thu, 18 Nov 2010 19:00:00 GMT

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

u-boot + Linux kernel port to Mediatek MT6235 baseband processor under way

Harald Welte — Fri, 29 Oct 2010 19:00:00 GMT

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.

Worlds first 20 minute voice call from a Free Software GSM stack on a phone

Harald Welte — Fri, 13 Aug 2010 19:00:00 GMT

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.

CECT C3100: Not a phone, but a flashlight with integrated phone

Harald Welte — Sat, 08 May 2010 19:00:00 GMT

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

OsmocomBB now performing location updating procedure against GSM cell

Harald Welte — Thu, 04 Mar 2010 19:00:00 GMT

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.

Restructuring OpenBSC and OsmocomBB code

Harald Welte — Fri, 19 Feb 2010 19:00:00 GMT

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