OpenBSC: Support for multiple BTS / ipaccess-config

Today I've been working on adding support for multiple BTS to OpenBSC. This means, using the [still uncommitted] new code, we can now connect multiple BTS and route voice calls between them. The actual data structures and the bulk of the code were already designed in that way, but the 'input driver' still had a lot of assumptions about talking only to one BTS at any given time.

This feature is currently only available for ip.access nanoBTS, as there is no special need for switching the RTP streams of the actual voice data. The BTS send that data directly between themselves. Dealing with E1/A-bis based BS-11 is slightly more difficult, since the TRAU frames with the voice data need to be

Still, even with two BTS at the same BSC, there is still no support for actual handover. So a handset is either registered to one BTS or the other. This matches a situation where you might have multiple different locations (let's say two branch offices) with one BTS in each location and the ability to make voice calls between mobile phones registered to either one of the branch office BTS's.

Actual handover between adjacent cells is not something that I'm personally interested in, so I'll probably leave this up to some contributor who finds it interesting (or a company who wants to fund me for that particular work). Right now we have more important missing features anyway (like proper SMS store-and-forward).

One other small bit that I implemented today is the ipaccess-config command line tool, serving as a tool to perform the most important initial NVRAM configuration of a new nanoBTS. You can use it to set the IP address of the primary OML Link as well as the Unit ID. From that point on, the BTS connects to the BSC and all further configuration can be done from the BSC.

The best linux kernel commit message ever

As you can see at this patch, Stephen Hemminger has submitted what I would call the best Linux Kernel commit message ever:

In days of old in 2.6.29, netfilter did locketh using a 
lock of the reader kind when doing its table business, and do
a writer when with pen in hand like a overworked accountant
did replace the tables. This sucketh and caused the single
lock to fly back and forth like a poor errant boy.

But then netfilter was blessed with RCU and the performance
was divine, but alas there were those that suffered for
trying to replace their many rules one at a time.

So now RCU must be vanquished from the scene, and better
chastity belts be placed upon this valuable asset most dear.
The locks that were but one are now replaced by one per suitor.

The repair was made after much discussion involving
Eric the wise, and Linus the foul. With flowers springing
up amid the thorns some peace has finally prevailed and
all is soothed. This patch and purple prose was penned by
in honor of "Talk like Shakespeare" day.

Signed-off-by: Stephen Hemminger 

---
What hath changed over the last two setting suns:
  * more words, mostly correct...

  * no need to locketh for writeh on current cpu tis 
    always so

  * the locking of all cpu's on replace is always done as
    part of the get_counters cycle, so the sychronize swip
    in replace tables is gone with only a comment remaing

 include/linux/netfilter/x_tables.h |   55 ++++++++++++++--
 net/ipv4/netfilter/arp_tables.c    |  125 ++++++++++--------------------------
 net/ipv4/netfilter/ip_tables.c     |  126 ++++++++++---------------------------
 net/ipv6/netfilter/ip6_tables.c    |  123 ++++++++++--------------------------
 net/netfilter/x_tables.c           |   55 ++++++++--------
 5 files changed, 188 insertions(+), 296 deletions(-)

Thanks Stephen, you made my day :)

Without words

$ dig -t MX openmoko.com

OLPC 1.5 to be using VIA C7-M CPU and chipset / VIA reference documentation

To many of you this might not be new. About a week ago, OLPC announced that they have selected a VIA CPU and integrated graphics chipset for their OLPC 1.5 hardware version.

I was expecting this to happen, not because I am working part-time for VIA or because I had any kind of insider information. As usual, I speak for myself and not for VIA. But for anyone who understands the x86 marketplace it would have been pretty clear. AMD's Geode is aged and slow, and there are not really any successors. Intel's product portfolio has recently become great for small mobile devices, but I would imagine the pricing is probably a bit too high for an extremely-low-cost product like the OLPC. Going for an embedded MIPS or ARM processor would rule out running a [un]popular OS from Redmond, and whether we like it or not OLPC is apparently looking at supporting such a OS, too.

Intel would obviously have been the perfect choice from the FOSS point of view, a lot of open documentation as well as GPL licensed and stable drivers in mainline Linux and X.org. VIA is not quite there yet, but I can assure you the changes are still ongoing.

Some people, most prominently John Gilmore have raised concerns about the lack of any public documentation for neither the C7-M nor the VX855 chipset. This is unfortunately still the case. The CPU data sheets should have been public for quite some time but haven't been due to resource constraints. And the VX855 manual is not yet public, as the silicon is still being verified. But as you can see from the publicly available manuals for the VX800/820 as well as the chrome9 2D and 3D graphics reference manuals (all linked from the OLPC wiki page now), the immediate predecessor of the VX855 already has open documentation, and this will not change for the VX855 either.

So rest assured that the documentation for the VIA chips to be used in the OLPC1.5 will be publicly available. I'll also try to get personally involved in the VIA/OLPC discussions and see what I can do to help both on the technical side, as well as helping with the interaction and mutual understanding of both sides.

Podcast about OpenBSC at Chaosradio Express

About a week ago, I had the pleasure of recording a Chaosradio Express (CRE) podcast about the OpenBSC project, as well as briefly addressing other GSM related FOSS projects such as OpenBTS and airprobe.org

As always with CRE, it was a most pleasant experience talking with the host Tim Pritlove and explaining the scope of the project as well as the overall how and why.

Unfortunately, unlike my blog (and most of its readers), the podcast is not in English language. But if you understand German and want to hear more about OpenBSC, I obviously recommend to check it out!

Some notes about the FSFE FTF Legal Workshop

I'm currently on the train heading back home from Amsterdam, where the last two days I've been attending the 2009 Legal Workshop of the Legal Network of the Free Software Foundation Europe.

I have to admit that it was a big surprise to me that the constructive atmosphere and the quality of the presentations, panels and hallway discussions has even improved beyond the already exceptional level last year.

So even if some of the more technical readers of this blog would find it hard to agree: It can actually be a lot of fun to spend two days locked up in a conference room full of 40 lawyers :)

It was very clear that the Free Software license compliance has moved ahead quite a bit since its early days. We have had a number of independent lawyers as well as corporate legal counsels from various backgrounds, as well as some folks like myself with a very technical background but a vested interest in legal aspects of FOSS.

Let me report on some of the most exciting parts of the workshop, at least from my perspective:

• An official representative of WIPO reporting on their recent considerations regarding collaborative creative work such as FOSS and the creative commons projects
• Very insightful talks about software patents and the various new projects like the Open Innovation Network, LinuxDefenders, Peer-to-Patent, etc. I believe the significance of this work for the future of FOSS cannot be underestimated, no matter of which jurisdiction you are in.
• This year, two legal experts from Taiwan were attending and received considerable attention given the many problems that FOSS has both legally and technically with products from the Taiwanese industry
• Last, but not least, I have made some very interesting new contacts from people involved in Linux on mobile phones

Thanks a lot to the FSFE and particularly Shane's excellent work in putting the Legal Network and the conference together. Thanks also to the sponsors of the workshop, including Canonical and Black Duck.

Departing for the FSF Europe Legal and Licensing Workshop 2009

In about six hours I'll be travelling to the Second Free Software Foundation European Licensing and Legal Workshop in Amsterdam. I've been to the fist workshop last year, and it was an excellent event, with all the important stakeholders present. Corporate legal departments of companies that already had their fair share of GPL incompliance, independent lawyers and legal experts, as well as folks with a Free Software community background such as myself.

The FSFE Freedom Task Force has done quite a bit of work during the last year, and their Legal Network has been growing. So there are a lot of signs indicating that this years workshop will be at least as good as the previous one.

I'm especially happy that this year we have a legal expert from Taiwan among the participants. Somebody who understands both the Free Software culture but also has had contact with the Taiwanese Embedded Industry: Florence (Tung-Mei) Ko. Given the many GPL problems that we see in embedded gear that was developed in Taiwan, I think many people at the workshop will be interested in the experience and insight that she can share with us.

So for the next two days, I will once again have to put my glofiish reverse engineering, OpenBSC and VIA related work aside and put my gpl-violations.org hat on. Not really pleasant for the engineer that I am - but a necessity to help bring more GPL compliance into the industry.

Some updates on the gnufiish project

Over the last weekend, Stefan, Zecke and myself have been focusing on getting some work done for the gnufiish project. As usual with this kind of reverse engineering project, you never really know how long you need until you've cracked all the major difficulties.

The biggest issue with gnufiish is the lack of working support for the 3.5G modem in the device. Obviously, without such support the device is nothing else but a nice PDA. Disconnected from the rest of the world.

We still don't have a working 3.5G modem under Linux, but we have made the following progress:

• confirmed that the modem is attached over UART in addition to SPI
• learned that the modem uses some kind of binary protocol on the UART at least for firmware updates
• discovered the meaning of quite a number of additional pins on the debug connector, including the serial console. Almost all pins should be known by now.
• a preliminary u-boot port has been produced. It can be loaded via OpenOCD/JTAG and accessed over serial console or USB serial emulation. It doesn't yet have the full feature set as people are used from Openmoko GTA01/GTA02, but NAND and SD card access are working
• ported Werners Linux userspace s3c24xx-gpio tool into u-boot. This makes it much more convenient to play with the GPIO's without computing boolean bit masking operators in your head. And since booting into Linux userspace takes way too long right now, having this in u-boot really is the right thing.
• learned more about the various programs installed in the E-TEN ROM image, i.e. their initial loader, usb downloader as well as the Empire/Knight test environment.
• we discovered some bug in OpenOCD leading to problems with breakpoints, Zecke cooked up a patch for this.

If you're interested in the intermediate results / notes, feel free to check the M800 as well as 3.5G modem related pages in the wiki.

Will be in Taipei in May after all

Despite the cancellation of OpenTechSummit, I will be spending three weeks in Taipei soon (May 05 through May 25). I am looking forward to both the business side of this trip, as well as actually enjoying the life in this vibrant Asian metropolis.

I'll be doing some work for VIA, as well as some of my other customers and also be doing some gpl-violations.org related meetings.

Samsung Omnia: A phone suitable for (Linux) hacking?

Samsung is currently shipping a phone called Omnia, or more precisely, the SGH-i900. It is a touch screen only phone shipping with Windows Mobile. Recently at Mobile World Congress, Samsung has shown that there is a LiMo port to the Omnia. Obviously, this port is not available publicly, so there's no easy way to just re-flash any other Omnia.

However, as it seems some folks at xda-developers.com have booted a generic PXA3xx kernel on the device, which shows us two things: One, there appears to be no cryptographic lockdown, i.e. we can execute what we want on the CPU. Second, that at least a core kernel with framebuffer is already working.

I did some more research today, and put most of the findings at this page in the gnufiish wiki. Among other things, apparently a service manual has leaked, containing schematics excerpts, component placement and similar useful information. I've linked various data sheets of components that are used in the device.

As it seems, the big unknown part is the GSM Modem interface. It uses dual-ported RAM to communicate with a Qualcomm MSM6281 3.5G modem. Now maybe the shared memory protocol is similar or even the same to what Android/HTC/Google G1 uses. At least typically, if you roll out an architecture of a chipset like the 3.5G chipset, then all members of that architecture are likely to speak more or less the same protocol. Of course this is just guesswork, it yet remains to be confirmed.

With some luck I should receive one of those devices soon to do my share of reverse engineering.

Meanwhile, I'm looking forward to the upcoming weekend, where Stefan Schmidt and myself will try to finally get the SPI based 3G/3.5G modem interface of the E-TEN glofiish devices implemented on Linux.

OpenTechSummit Taiwan 2009 cancelled

I was very sad to hear that OpenTechSummit Taiwan 2009 had been cancelled by its organizers.

I was really looking forward to this event as an opportunity to provide some more information to Taiwanese hardware makers about properly supporting Linux and other Free and Open Source Software. On a more personal note, I was also really looking forward to spending some time in Taiwan again. It's currently questionable whether that will now happen in may, as originally planned.

New "linux/mobile" section

This is where I will write about stuff that happens with regard to Linux mobile devices after closing the linux/opemoko section.

Cancellation of GTA03 / thoughts on OM Inc.

As you can see at lwn and h-online, as well as slashdot: Openmoko Inc. has discontinued smartphone related development.

It's good that there is now some official statement from the company. They way this came about was less than pleasant, though. There would have been a number of ways to avoid the need for discontinuation.

For me, things now finally come to an end. I still very much believe in the idea of having more open mobile phones, both on the software stack as well as on the hardware side. I also believe that there used to be a number of very good people inside Openmoko who could drive the development to create such open products. But over time, I have started to have severe doubts whether Openmoko Inc. is really the most productive and/or best environment to do this kind of development. Priorities and directions changed a lot.

So as of now, even though Openmoko Inc. states it wants to re-start smartphone development at some later point, I am happy that I can finally let go. I do no longer have to hope that Openmoko Inc. gets their act together to actually get an (to my standards) acceptable product out into the market.

The pain and suffering is over. The engineers behind the 'open smartphone project' are all "free" now, and they are more than ever interested in continuing the mission that they once set out to get done. Very much like me some time ago. I've never stopped believing in the idea of building more open mobile phones. I just started to doubt if Openmoko Inc can do that, which is one of the key reasons why I left a very key position at the end of 2007. Now my doubts are "complete". People can move on and try to find a way to get what they were fighting for - probably with less interference and no side-tracking and constantly changing priorities.

Now some people might argue that I'm trying to do Openmoko-Inc-bashing here. That is not the point. I, as an individual, have just expressed my doubts and my assessment of the situation. I've held back a lot of grief for a long time, trying to not interfere with the business of Openmoko Inc. But since the Openmoko project is an open source project, and it is developed and supported by a much larger community, I feel more connected to that community than to the company. I feel obliged to let them know my opinion, since I have more insight into the project than most other people have. It's a personal opinion, I don't claim that it is "the one and only truth (TM)".

Closing the "Openmoko" section of this blog

I have decided to quit blogging in this section. I have left Openmoko Inc. quite some time ago. Openmoko Inc. has announced to discontinue Linux smartphones, and I'm not interested in any Project "B".

For those who want to follow what I have to say about Linux on mobile devices, I have created a new section linux/mobile in this blog.