A couple of days ago the FSFE has announced its new president, vice president and executive team. This marks a big milestone, since the former president, Georg Greve, has been the president for more than 8 years, ever since the FSFE was conceived.

As you can reed in Georgs blog, him stepping back as president has been announced at the assembly last year, giving the organization a full year to prepare and think about potential successors.

I want to thank Georg for his dedication and exceptional work during the last years. The FSFE has played a very vital role with regard to Free Software related issues on a political level in Europe during that time. Involvement with the WIPO, the Microsoft anti-trust trial, the software patent debate, just to mention a few highlights.

When the FSFE was started, I always hoped to find some time to get personally involved and to contribute to it - but it seems that my many technical projects as well as gpl-violations.org have been draining already more time than I had.

I wish the new team all the best and hope (and expect) the FSFE will continue to play an ever-increasing role in the political debate around Free Software related issues.

As you can see in this picture referenced by this blog post, somebody is having real fun using the BS-11 and OpenBSC for GSM wardriving.

Please note that the BS-11 is a 200W AC powered device, so you need the entire trunk full of lead batteries and a reasonably sized UPS to provide it with power.

There are much lighter setups using a laptop and a nanoBTS, but then those setups are likely a factor 10 more expensive (and provide less RF power).

But what this all tells us: GSM wardriving has started. More security researchers are looking into GSM security than a year ago, much due to the successful growth of a community around OpenBSC. Many people are only starting with GSM and mainly using/playing with the software, the number of actual contributers to the code is still small...

On a larger scale, you can see that GSM insecurity is finally going to become a much more popular topic, with more people able to demo the various long-known issues such as lack of mutual authentication and insufficient threat models/analysis during protocol design.

A number of people from the various community-based Linux mobile phone projects (OpenEZX, gnufiish, freesmartphone.org, openmoko, openembedded) are interested in adopting the Palm Pre into the portfolio of supported devices.

If anyone wants to support those communities with Palm Pre hardware, please let me know. Right now, all the people I know are in Europe. Yes, we don't have CDMA hare - but those hackers don't care. All they want is to make sure you can build a number of different distributions on the application processor, and to support everything _but_ the CDMA modem in preparation for the GSM variant that is to be released at some future point.

As you can see from this press release, ScummVM alleged Mistic Software and its distributors from infringing the GNU GPL in some proprietary games based on ScummVM.

As it seems, this case was now settled. The press release does not make any statement on how the actual GPL issues were solved (i.e. "where is the source code"), but I would assume they would not want to settle unless the conditions of the GPL are fulfilled...

If anyone has more information, I'm interested to learn about that.

On this page, Palm has started to release source code + patches for a number of FOSS programs that they use in the Pre. I suppose the page is only an interim solution, since the entire site (nor the page URL) doesn't yet really seem to consider the fact of OS updates, etc.

Of course I have no idea yet if those sources can be considered complete and corresponding, but at least an initial look seems quite promising.

I've spent about 10 minutes looking at their 9 MByte (!) kernel patch against vanilla 2.6.24. The modem interface seems to be a UART + USB. The UART is required for stuff like waking up the OMAP3 from the baseband, and then you use it to set up a USB connection to the modem, where a hacked/extended version of the cdc-acm driver appears to be used.

I don't have time to look further into it, but I'm sure somebody with actual device hardware will - now that the source is out there.

In recent days, we have finally merged a series of patches from Andreas Eversberg implementing what we call the MNCC [mobile network call control] API. Using this API, it is possible to glue existing PBX or other telephony applications to OpenBSC and thus add GSM extensions to your PBX.

So far, only Linux Call Router (LCR) has been extended to use this MNCC interface. Andreas reports that he has successfully established both mobile originating and mobile terminated calls to GSM extensions of his LCR PBX.

It's great to see this kind of contribution, especially in an area which I personally am not all that interested in... I still want to focus on the actual GSM side of things and implement more features as well as work on stability, the vty/telnet configuration interface, GPRS support and the recently-announced plans for implementing an actual A interface.

Right now, other projects require more time slices, but I'm still spending quite a bit of work on integrating better SMS support, with actual store-and-forward of messages in our SQL database.

I've just received one of the few precious XO 1.5 samples, since I'm supposed to be working with Chris Ball and others at OLPC to help them with getting the VIA hardware fully supported, e.g. integrating/testing support for the specific panel, etc.

It seems to be booting fine the current xo-1.5 branch of the OLPC git tree, and the basic operation of all major peripherals is fine. Stuff like power management and support for DCON are still requiring some work, of course.

Today I'm still busy with generic non-OLPC VIA driver related work, but tomorrow I can hopefully look into OLPC related issues.

Some of my friends already know it: I'll be spending some 6 weeks in the city of Hamburg starting from June 21st. I can't talk about details of the particular project that I'll be working on, but I'm extremely excited since it's related to what I've been most passionate about recently: GSM networks and their security. And no, it's not about any software development and it is completely unrelated to OpenBSC.

If you happen to be in Hamburg and want to meet at some time to hang out, feel free to drop me an e-mail.

At the LiSoG meeting on July 1st, I'll be presenting on GPL violations and their international enforcement.

The LiSoG meetings have been repeatedly pointed out to me as some of the best Linux meetings out there, with a lot of professionals from the Munich area being present. I'm happy to be invited to join and present, even if it means I'll have to escape for a day from my most exciting project in Hamburg.

So if you happen to be in the Munich area and interested in meeting with a crowd of Linux people and/or interested in hearing about GPL enforcement efforts, feel free join.. But you have to to register [for free], as per instructions on the page linked above.

As there are a number of confirmed bug reports with the viafb kernel driver, and I've been working on openchrome VX855 support, as well as OLPC XO1.5 support for viafb as well as openchrome, I've decided to write some better tool for debugging graphics problems.

The userspace tool will dump all the registers (currently only CRT / LVDS / DVI / Sequencer / Power management) and parse them into human-readable form. This way we can set a certain mode or display configuration, and verify what the respective driver[s] have actually done in the hardware.

The idea is to ssh into the respective system and run that tool, even if the actual monitor is no longer showing any userful output.

viafb still needs quite a bit of re-work, I'm not really happy with e.g. how it directly uses the I2C controllers rather than registering proper i2c client drivers. What's also sad is that it doesn't use the common kernel interface for modelines (modedb). Also, there are _way_ too many module parameters. I guess close to nobody but the original authors understand how to set all this correctly.

Since I actually have a CLE266 and CX700 system at home, I'll be able to test any new code or changes on those two as well as VX800 and VX855, which should cover all the major generations of VIA integrated graphics hardware out there.

You can see the early beginnings of that tool at svn.gnumonks.org/trunk/via-chrome-tool. Theres lots of uncommitted code not yet in that repository, will push it tomorrow after I'm back to Germany.

Today, I've submitted the latest version of the via-sdmmc driver to lkml and Pierre Ossman, the kernel sdmmc maintainer.

Since the last submissin in early april has not received many additional fedback, I hope we can make the 2.6.31 merge window. This has been once again taking way too long. VIA has to improve its turnaround time significantly in the future.

As it has been reported at many places online, the Palm Pre has started to ship as a CDMA model in the United States. However, as it seems, at this time it is not GPL compliant and thus a copyright infringement!

The Pre undoubtedly contains Linux and other GPL licensed software. So it ships with the GPL license text as well as a written offer indicating to obtain the source code. So far so good.

But if you contact the respective address, you get a response like this:

Hello Harald and thanks for your email.

We are in the process of preparing the packages and our modifications
to upload them to our open source web site - http://opensource.palm.com.
We expect to have all packages and modifications uploaded and available
to the public in about 2 weeks from today.

If you prefer to get the packages and our modifications on a CD/DVD,
please provide us with your mailing address and we will gladly ship it to
you as soon as they are available on our web site.

Please let us know if you have any further questions.

All the best,
Palm Open Source Team

I think it is a bad sign that they write they are in the process of preparing the packages and our modifications. This sounds suspiciously like "we didn't think about it early enough and now we need to reproduce the soruce code that was used for actually compiling the build that is installed on the devices".

Since when did the object code exist before the source code? If you compile e.g. the Linux kernel, you _have_ the source code before you generate the object code. So you should be easily able to make the source code available at the same time as the object code!

I would have expected much more from a company like Palm. If you as a commercial entity want to use GPL licensed software, you don't have to pay one cent in licensing or any royalties. All that you have to do is to make sure you have the complete corresponding source code that was used for compiling the actual binaries available at the time you start shipping the object code.

Providing a written offer and then delaying is not good GPL compliance practise and introduces legal [and thus business] risks that could have been easily avoided. Let's hope the source code is really complete and corresponding within those two weeks. And let's hope they never repeat this with another product, or with software/firmware updates for the Pre.

As you can read here, it seems that based on initial analysis the Palm Pre seems to be closer to what mainline Linux is doing that Android. That's not really surprising, but still definitely great to hear.

I can't wait to get my hands on the actual source code. If anyone has seen the written offer as provided by Palm, please forward me the contact information indicated in it so I can request the source code.

If anyone already has their complete corresponding source code (as per GPL), please upload to ftp://ftp.gpl-devices.org/incoming (write-only) and drop me an e-mail.

I've recently been hacking on adding cpu_debug support for VIA CPU's to the Linux kernel. The code has today been published in the via-cpudebug branch of my linux-2.6-via git tree, the relevant commit is available here as commitdiff.

cpu_debug allows you to read all existing MSR (machine specific registers) from userspace using a debugfs interface.

Let's hope this code will - among other things - help us to debug any power / thermal management related issuses. I'm now going to be working on a small perl script that can interpret the power/thermal management related MSR values into something human-readable.

Today I've hacked up (and posted) a hwmon driver that prints the current temperature of the digital on-die temperature sensor integrated in VIA's C7 and Nano CPU's.

You can get the code from the via-cputemp branch of my linux-2.6-via git tree. The code is also available as git commitdiff.

Let's hope this is another building stone in debugging any problems related to power management on VIA's CPUs.

There is more commercial interest in OpenBSC than I expected initially when I started the project as a 'just for fun playground for GSM hacking'. Now we have received an inquiry from a company who wants to fund the development of an actual A interface to OpenBSC. This basically means that somebody wants to hook up OpenBSC to an actual real-world MSC (Mobile Switching Center) of an actual real-world GSM network.

The A interface is the interface between the BSS (BSC + BTS) and the higher levels of the telephony network. The interface is based on SS7 and lives on top of SCCP. There's BSSMAP, DTAP and OMAP. Both connection-less and connection- oriented modes of SCCP are required.

What this means is that OpenBSC's software architecture will shift even further towards the traditional GSM network architecture. So far, we have a "full GSM network from BSC to MSC/HLR in a box" approach. This makes it easy to implement, but is quite restrictive. You cannot route/switch calls to a different network, e.g.

The recent patches posted by Andreas Eversberg already introduce a software interface called mncc into the OpenBSC codebase. While those patches are not merged yet, they are introducing a functional split between the call-control entity on one hand, and the RR and NM as well as Abis RSL/OML functionality on the other side.

When we introduce the A interface, the functional split in the software will be driven even further. We'll first introduce an API at the traditional BSC/MSC split, and then write a BSSMAP/DTAP/OMAP protocol interface to that API.

One thing is for sure: We'll always keep the 'run everything in one box' mode around. This is still the most useful case for small-scale experimentation with GSM.

I'm definitely looking forward to see this project grow. We still have no agenda for things like GPRS/EDGE support, or any kind of handover. But then, development one step at a time is more healthy than trying to do everything at the same time.

I'm really excited to play with the A interface, and to interact with an actual MSC on a protocol level. This sort-of completes my ventures into GSM protocol land, from the Um (on-air) over A-bis to the A interface, one iteration up the network hierarchy at a time.

In about 8 hours I'll depart for FreedomHEC Taipei 2009, an event where members of the Linux development community try to help Taiwanese hardware vendors understand the Linux development model.

I personally believe this kind of event could not be any more important. The traditional PC and embedded hardware industry still has a very, very limited understanding when it comes to properly supporting Linux, aiming at the universal solution for best end-user experience. In order to achieve this, the FOSS development model needs to be understood, as well as the value of going mainline with the drivers/ports.

Once that point is reached, there needs to be understanding _how_ to achieve that. Availability of documentation is another key issue. If you want to enable people to help you with development, bug fixing and maintenance, you need to release programming manuals for the hardware..

I'm happy to see that this year the organizers were able to get prominent speakers such as Jon Corbet from lwn.net, and Greg K-H who is doing marvelous work with his Linux Driver Project. Last, but not least, Peter Stuge will be presenting on coreboot as a FOSS alternative to legacy BIOS.

I'm also happy to see more native/local speakers, such as the presentations by jserv (aka Jim Huang) on Qi, the bootloader that was developed as part of Openmoko - or the presentation on VIA's experience of merging code mainline by Joseph Chan.

Hey kernel developers, more proposals related to networking submitted for the Linux Plumbers Conference. This is the chance to have in-person discussions about future proposals like receive packet steering, RCU netfilter optimization, unified flow cache, and all those other topics that need need more brainstorming and discussion.

The Netconf 2009 is also being planned to occur before LPC.

As the CEO of Openmoko Inc. (Sean Moss-Pultz) has announced yesterday, there have been layoffs last week and the further development of the Openmoko FreeRunner (GTA02) will be tunred over to the community.

Openmoko Inc. will continue to provide funding for operating the infrastructure such as wiki/git/mailinglists/etc. Furthermore, the community explicitly has permission to use the Openmoko brand/trademark for their efforts.

I'd like to thank Openmoko Inc. and specifically Sean for all their support over the last years. It makes me happy to see a friendly transition into a pure community-based project.

[jk@pingu ~]$ mkdir ~/sshfs
[jk@pingu ~]$ afuse -o mount_template="sshfs %r:/ %m" -o unmount_template="fusermount -u -z %m" ~/sshfs/
[jk@pingu ~]$ cat ~/sshfs/ozlabs.org/etc/hostname
ozlabs
[jk@pingu ~]$ 

Just as a quick note, I'm back to Germany. Besides catching up with various aspects of work, I'll be visiting what I think is the world's biggest Gothic / Dark Wave / EBM festival, known as Wave Gotik Treffen over the extended weekend, and in less than two weeks I'm heading back to Taiwan for FreedomHEC Taipei 2009.

From the second half of June on I'll spend quite a bit of time in Hamburg on a customer project. I'm looking forward to using this opportunity to get to know the city better...

My recent hobbies have included an intense study of New York City architecture, and in particular the facinating stories behind the city's two most prominent train stations. That being Grand Central Terminal and the arguably infamous Pennsylvania Station .

McKimm, Meade, and White's masterpiece at 42nd Street and 3rd Ave.

In the second half of the 19th century and on towards the first half of the 20th century, any American architect worth his salt studied at the Ecole des Beaux-Arts in Paris.

If you had a degree from that school, you were at the top of the pile for selection on all of the interesting commisions of the time. The school presented the student with a challenging and fast paced curriculum.

Firstly, for these American students attending in Paris, the first challenge was just getting in. The entrance exam (of course) required at least some proficiency in French. Several of the most notable American architects had the retake this entrace exam 5 or more times before being able to pass.

Once accepted, the student was pressed to solve problems. 12 hours were given to draft up a solution to a real architectual problem. Then once the draft was accepted, the student had 2 weeks to flesh out all of the details and present the final design. All the while the student's progress was critiqued by an established French architect who oversaw a group of students.

We really don't have that kind of training for computer science people. It's not even science I would say. This kind of training does exist for pure mathmatics, espcially in France.

Envision a school where you're asked to draft up the design of a compiler pass in 12 hours, then for two weeks you implement it, and meanwhile Alfred Aho critiques your work. This kind of place simply doesn't exist. (Yes I know Alfred teaches at Columbia currently, so maybe this specific place does exist :-) but I maintain that more generally such institutions do not exist)

Open source development and "throwing the masses of monkeys at the problem" seems to be a logical consequence of this, does it not?

A formally trained Beaux-arts architect and a room with a few drafters could design something as insanely complicated as a huge transportation hub in the middle of New York City. And it would work, as there would be no room for failure. To me it seems that someone similarly trained could do a complete operating system, compiler, or similar large software engineering task.

McKimm, Meade, and White were three architects and a couple drafters, and yet they were able to complete works such as Boston Public Library, Pennsylvania Station, and the James Farley Post Office. To just name a few.

So which is better, strict formal training and mentorship or open source monkeys? You decide!

Today I wrote a VX855 southbridge GPIO GPIOLIB driver, which is required by the OLPC DCON display controller.

I've also spammed a queue of 15 patches to linux-fbdev-devel, hoping that the majority of the viafb improvements/extensions can go mainline quite quickly.

What the XO1.5 DCON also needs, is a redesign of how viafb drives its multiple internal I2C busses, but this is not ready for submission yet.

Let's hope that this helps OLPC to get Linux up and running very quickly...

I've been working long hours to hunt the remaining bugs in the code, but it's finally working: this branch of my git tree now contains everything needed for having 2D accelerated kernel framebuffer, i.e. fast scrolling console text without much CPU usage :)

On the way to get there, there was a lot of viafb general cleanup - but I'm afraid it is just the tip of the iceberg. There are so many duplicated structure members in the code that it is hard to know which one is supposed to have the current bit of data. But right now I already have 14 pending patches that need to go mainline, I'd rather not start piling up more right now. Maybe after things have settled.

The other odd bit is that on all VX800/VX855 system that I've had access to in the last days, I cannot get the I2C / DDC to work. Not with the kernel code, not with VIA's Xorg driver, and neither with Openchrome. On the other hand, using custom hand-crafted userspace code, I can set (and read) the SDA and SCL lines on the VGA connector and take the correct voltage readings with a multimeter. So my thought was: Maybe it's working slowly, but at faster speeds there's some capacitance/termination problem? Well, even if I slow down the clock rate to 1kHz, I still don't get it working.

Since I'm playing with the kernel framebuffer and openchrome graphics drivers for the VIA integrated graphics chipsets right now, I have a somewhat of a de-ja-vue.

In order to access the GPIO ports that are used for I2C/DDC, you need to use 8-bit I/O read/write to an indexed VGA register. You write the register number to 0x3c4 and you can read/write the actual data from/to 0x3c5.

This remembers me of the 1991 to 1993 time frame, when I was a teenager peeking and poking the registers of my then brand-new VGA card from turbo pascal programs on DOS.

I cannot believe that this kind of legacy is still around, in hardware that is produced 2009 :)

So Intel has co-announced ofono.org. It's clearly a sign that they are preparing themselves for times where we will see x86 SoC based smartphones or other mobile connected devices, which is good.

However, it just looks like a complete not invented here syndrome. It would be great to understand why on earth Intel did not just base on freesmartphone.org (FSO). Even if you don't want to use FSO's [current] implementations, they have spent man-years designing the d-bus based telephony API's and gathering experience with actual use cases as well as a variety of different GSM modems.

Neither on the ophone.org website, nor in their announcement I can see an explanatin of "how this compares to FSO and why FSO doesn't work for us". There might be valid reasons, but they would probably do good at publicizing them. I could also not see them publicly participating at the FSO lists raising those concerns and trying to get a compromise worked out.

So rather than working with an existing community of experts in the Linux telephony field, Intel and Nokia chose to create their own project. Is it desire for control? I'm really surprised of it, and would have thought better of both companies :(

Today I've managed to work on bits and pieces on the minimal support for VX855 graphics such as ensuring the viafb driver works on x86_64 builds as well as a preliminary patch to get VX855 supported by viafb.

I've also played a bit with openchrome and got it to the point where it can display X11 at various resolutions on a CRT (analog VGA out) including hardware accelerated cursor support. The patch is not yet posted, but I hope I'll soon find time to complete this.

As it seems, Marvell has released the PXA310 and PXA320 developer manuals. They can now be downloaded and used by anyone, without a need for a NDA. This is great, as it removes one major obstacle for Free Software developers to write code (e.g. Linux kernel / driver code) for those System on a chip (SoC) devices. Marvell also re-released the PXA27x manuals, but this is of less significance considering that back when the PXA was still with Intel, Intel had the full manuals public.

Ti has done something similar, at least for the OMAP3530: Publicly releasing their Technical Reference Manual without any requirement for an NDA. Sure, it is only one of their many products. But I think they have been showing progress even on one of the older OMAP24xx product, as far as I remember.

Now the only major vendor of ARM SoC's for mobile handheld devices like smartphones that has currently no reference manuals public is Samsung. This is really sad, as their S3C2410/2440 manuals always used to be publicly available from their website. Now the S3C6400 and S3C6410 manuals are under NDA, effectively preventing anyone to develop Open Source (and specifically Linux) code for their systems. I sincirely hope they understand what a competitive disadvantage they are now facing in the Linux market.

During the last days, I have finished my tests with regard to the hardware crypto part (PadLock) of the VIA Nano CPU. Now my kernel supports hardware rng, aes and sha engines in both x86_64 and x86_32 modes, at least as far as tcrypt and dm-crypt go.

The performance is quite impressive. It seems that AES256 ECB encryption and decryption gets something like 1.3 gigabytes per second with the tcrypt tests. And this is an evaluation board with probably some slow memory and a chipset that is not in its final silicon yet.

I'm not sure what the typical software implementation gets on modern CPU's without hardware crypto, but I'll do some testing by myself soon.

I'm also planning to write some paper about the performance numbers I get, extended with some figures for actual IPsec and dm-crypt workloads.

I use libcwiid for my various hacks, and recently I wanted to connect to the GH4 drumkit (which has been documented thoroughly on wiibrew.org but I couldn't find any patches. After realizing that the libcwiid project is pretty much abandonware, I imported the SVN into mercurial and hacked in drum support.

The start was the patch for GH guitar identification (found here but it didn't properly implement the new detection scheme. So I cleaned that up first.

The code in general needs some love, and adding support for new devices breaks the ABI and API as it stands, yet that's fairly easy to fix. But I don't really want to adopt YA puppy right now...

So this patch should get you going on the drums! Send me mail if you want support for other devices (the GHWT guitar should be easy), or other patches. If there's enough interest I'll export the repository somewhere.

As you can see at the XO1.5 bring-up page, I've been invited to helping the various OLPC, Quanta and VIA folks with the bring-up of the XO1.5 board from OLPC.

I'm looking forward to doing some more x86 work. It is a welcome change after my predominantly ARM based work during the last years (Openmoko, OpenPCD, OpenBeacon, OpenEZX, gnufiish, ...).

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.

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

$ dig -t MX openmoko.com

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.

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!

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.

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.

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.

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.

I've recently been doing some performance analysis work on Linux, which requires profiling various applications to see how they perform under load. One of the handy tools for profiling this behaviour is oprofile, but the output can be a little difficult to interpret.

So, I've developed hiprofile, the HTML interactive profiler.

Hiprofile is a small python script to generate HTML reports for oprofile data. Output is broken down into per-program statistics:

The page for each program lists the top 20 (by default) symbols within that function:

Each of the most-hit functions are show with per-instruction profiling data, and each instruction is coloured according to how 'hot' it is. If the source code for the function is available, the output is annotated with the corresponding code:

More info and downloads are on the hiprofile project page.

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.

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.

In response to the LCA 2009 Dinner Auction which raised about A$40k to help save the Tasmanian Devil, Linus agreed to change the logo for the 2.6.29 release (making that patch was fun: who knew there was a PNM reader in the kernel source?) No surprise that Tuz has also been seen moonlighting around the IBM Linux Technology Center:

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

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

I did not want to blog about it due to my intricate knowledge of Openmoko internals and my own past within the organization. But the news has made it to the various mailing lists now anyway: Andy e.g. is now longer working for Openmoko. He has been the main Openmoko kernel and bootloader developer (and maintainer) ever since I left in November 2007.

This is really sad news. There used to be really great engineers at Openmoko some time ago, but at least a number of good, senior folks are no longer working there at this point in time, or are working on a much smaller scope for Openmoko Inc.

Sure, it is not the right way to discuss the details of every HR matter in a public way. But I would have at least expected Openmoko to use the power they have to publish a statement on what this means _before_ the news get released in an out-of-control way by rumors and hearsay. If you allow this to happen, then you subject yourself to somebody else presenting their [distorted?] view of what he believes as reality first, and you (Openmoko Inc.) get into a defensive position.

After returning from my holidays, I've spent the last couple of days hacking on improving the SMS support of OpenBSC. In order to facilitate the intended store-and-forward model, we now store all incoming SMS in a SQL table. Things like validity period or even more esoteric things like SMS compression as per GSM 03.42 is obviously still missing. I try to get it working fist, and leave the gaps to be filled later.

Next will be the code for sending a SMS from an entry in the SQL table, and invoking that code every so often, based on timers and/or events such as a phone registering to the network.

The trickiest part here is how to handle the paging code. We could have a phone call and a SMS, or even more events that all want to page a phone at the same time. There needs to be some kind of arbitration and a queue, deciding what kind of event will first get access to the SDCCH that we have after paging succeeded.

There have also been suggestions to split the SMS processing into a separate process, much like in a traditional GSM network. Sounds reasonable to me, but I am not very familiar with the existing protocols (like UCP) and implementations (like Kannel). So I'll probably leave that as a second step, making the OpenBSC internal SMS handling optional at some later point. UCP would obviously also ease the integration with existing SMS operators (vSMSC and the like).

Much earlier than in previous years, FOSS.in has announced the date + venue for the 2009 incarnation of the event.

The CfP is not out yet, but I hope it will also be out sooner rather than later, as scheduling long-distance travelling is something that most speakers prefer to do rather sooner than later. And you won't book your ticket before you know your paper has been accepted, etc.

I'm definitely looking forward to it. As the frequent follower of my blog will know, I've been there every year since 2003, which probably makes it the only conference (next to the Chaos Communication Congress) that I've been visiting that often in a row.

They were acting quick. TomTom and Microsoft have settled their patent dispute. Of course, it's business as usual. They have to protect the interest of their shareholders, and a lengthy patent lawsuit is probably creating too much uncertainty for business partners.

I don't particularly mind them settling their [sometimes ridiculously trivial] claims on car navigation systems. But the settlement also includes the long-filename-patent that e.g. has been dismissed by Germany's Federal Patent Court about one year ago on the grounds of being too trivial and ISO9660 RockRidge constituting prior art. So given that the highest patent court in Germany has already issued such a judgement, I would be quite surprised to see a completely different verdict in the US. Either ISO9660 is prior art or not. I doubt there's much to debate on it.

So well, MS will still uphold their implicit threat against anyone who uses Linux + VFAT filesystem in a commercial product. In the end, I hope, this will simply drive people away from using FAT or VFAT altogether. It's not that they are particularly great filesystems anyway... and vendors just want to make it convenient for _windows_ users to use their products by enabling them with VFAT.

For many years, especially ever since 9/11 in 2001, German governments have been pushing very hard for so-called security legislation, removing civil liberties and enhancing the surveillance capabilities of the various government agencies.

The only sensible response is not coming from _any_ political party in the opposition. Neither the self-proclaimed civil liberties friends of the FDP nor the Green party are cutting it.

This, by the way, extends beyond just security/surveillance related legislation, but also e.g. with regard to the use of voting machines in federal elections. Only recently the constitutional court decided that the legislation as well as the actual devices used in the last election were unconstitutional.

The only people involved in the public debate who show a lot of reason are the judges of the German constitutional court (Bundesverfassungsgericht). Particularly the president of the court, Hans-Juergen Papier is a true hero to me, constantly fighting for the values of our constitution - not irritated by the general mood of the day or any hectic political activism by the government.

What is even more surprising: Mr. Papier is himself from a conservative political background: The Bavarian CSU party.

In recent times, there is an actual fight between Mr. Papier and our ultra-conservative home minister (Schaeuble). Mr. Schaeuble is now going as far as to publicly stating things like ">Bundesverfassungsgericht

). Particularly the president of the court, Hans-Juergen Papier is a true hero to me, constantly fighting for the values of our constitution - not irritated by the general mood of the day or any hectic political activism by the government.

What is even more surprising: Mr. Papier is himself from a conservative political background: The Bavarian CSU party.

In recent times, there is an actual fight between Mr. Papier and our ultra-conservative home minister (Schaeuble). Mr. Schaeuble is now going as far as to publicly stating things like 'those who want to be part of legislation should aim for becoming of parliament' or 'i have doubts on how far it is constitutional what the constitutional court is doing'.

This is just unbelievable. How can the government afford to have a minister who openly doubts the legitimacy of the decisions of the highest body of justice in this country? If people really cared about justice and our constitution, it should be immediate grounds to dismiss this minister.

I've been offline for an entire week, something that rarely happens to me as long as I can think back. It has been great. I took the time to read Cryptonomicon again, and it was just as great as the first time. I also found sufficient time to continue my (still embarrassingly little) chinese studies, and had even more time to think and reflect about my life.

So all in all it is a holiday like it should be. Don't expect any news from me in the blog or by e-mail before March 26th.

So, C has a preprocessor, and it can be used for evil: particularly function-style macros (#define func(arg)) are generally considered suspect. Old-timers used to insist all macros were SHOUTED, but it can make innocent (but macro-heavy) code damn ugly.

Remember, it's only a problem when it's Easy to Misuse, and if you've written something that's easy to misuse, maybe a rethink is better than an ALL CAPS warning.

There is one genuine and unescapable use for macros:

Macros which deal with types, or take any type

The classic here is

#define new(type) ((type *)malloc(sizeof(type)))

But consider also the Linux kernel's min() implementation:

 #define min(x,y) ({ \
	typeof(x) _x = (x);	\
	typeof(y) _y = (y);	\
	(void) (&_x == &_y);		\
	_x  _y ? _x : _y; })

which uses two GCC extensions to produce a warning if x and y are not exactly the same type.

And there are several justifiable but more arguable cases:

Const-correct wrappers

If you need to wrap a struct member access, it's annoying to do it as an inline function. To be general a function needs to take a const pointer argument, then cast away the const (see strchr). Const exists for a reason, and stealing it from your callers is a bad idea. A macro

#define tsk_foo(tsk) ((tsk)->foo)

maintains const correctness, at the slight cost of type safety (you could hand anything with a foo member there, though it's unlikely to cause problems and can be fixed with a more complex macro.

Debugging macros

Generally just add __FILE__ and __LINE__ to a function call. The non-debug versions are generally real functions.

Genuinely fancy tricks

There's no good way around a macro for things like ARRAY_SIZE and BUILD_BUG_ON (these taken from CCAN):

#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + _array_size_chk(arr))
#define BUILD_ASSERT(cond) do { (void) sizeof(char [1 - 2*!(cond)]); } while(0)

More questionable still:

Macros which declare things

This is for things which need initialization, eg. LIST_HEAD in the kernel (or ccan/list) expects an "empty" list to be pointing to itself. While this is convenient, nothing else in C self-initializes so it's arguably better to provide an "EMPTY_LIST(name)" macro. You get a nice crash if you forget (except on stack vars).

Macros which iterate

list_for_each() (ccan/list.h version of the kernel's list_for_each_entry):

#define list_for_each(h, i, member)					\
	for (i = container_of_var(debug_list(h)->n.next, i, member);	\
	     &i->member != &(h)->n;					\
	     i = container_of_var(i->member.next, i, member))

It's less explicit, but much shorter than having three macros and using them to loop:

for (i = list_start(&list, member); i != list_end(&list, member); i = list_next(&list, member, i))

If we sacrifice a little efficiency for convenience, we can make list_start() and list_next() evaluate to NULL at the end of the list, and I prefer it over the list_for_each() macro:

 for (i = list_start(&list, member); i; i = list_next(&list, member, i))

Of course, it wouldn't be a complete post on macros without mentioning things you should never do:

Modify your arguments.

C coders don't expect magic changes to parameters. From kernel.h:

#define swap(a, b) \
	do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0)

Embed control statements to places outside the macro.

Putting 'return' in macros is only ok if the macro is called, say, COMPLAIN_AND_RETURN. And then it's probably still a bad idea.

The classics: use too few brackets, or allow multi-evaluation.

The former is unforgivable; it cost be 1/2 a day of my life once when I was younger and using another coder's RAD2DEG() macro. The latter can be avoided with gcc extensions (see min() above), or sometimes using sizeof().

Since I'm currently at the BOSSA conference and thus basically on a break in my Brazil holidays, I decided I might as well get some work done and imported the zebra/quagga VTY code into OpenBSC. I used a fork of that code that I used some time ago for a never-announced (but in my public svn) 'cardshell' project.

What this means is that we now have a quite nice shell interface into OpenBSC, where you can interactively explore the data structures with commands like 'show bts 0', 'show e1_line' or 'show timeslot'. Over time, I hope we can easily add also interactive commands for [re]configuration, i.e. reconfigure the BTS on the fly, change administrative state via OML, or set TEI/timeslot configurations or the like.

Importing those bits from zebra/quagga has the advantage the we have things like a history and tab-completion without having to spend much time on it. Also, we can use the same codebase for saving/restoring the current configuration from/to a text file.

To give you an idea, it looks like this:

ideapad.de.gnumonks.org> show bts
BTS 0 is of nanobts900 type, has LAC 1, TSC 7 and 1 TRX
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Site Mgr NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Paging: FIXME pending requests, 100 free slots
  E1 Signalling Link:
    E1 Line 0, Timeslot 1, Type OML
    E1 TEI 0, SAPI 255

ideapad.de.gnumonks.org> show trx
TRX 0 of BTS 0 is on ARFCN 123
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Baseband Transceiver NM State: Oper 'RFU', Admin 0, Avail 'In test'
  E1 Signalling Link:
    E1 Line 0, Timeslot 2, Type RSL
    E1 TEI 0, SAPI 0

ideapad.de.gnumonks.org> show timeslot 0 0 0
Timeslot 0 of TRX 0 in BTS 0, phys cfg CCCH+SDCCH4
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Bound IP: 0.0.0.0 Port 0 FC=0 F8=0

This year's BOSSA incarnation has once again turned out as an excellent event. It was good to meet and talk again with a number of people like Marcel Holtmann or Rasterman.

This year it seems the organizers went out of their way to please every speaker. Since their conference shirts were available in three colors (but not black), they actually prepared a special edition of a black t-shirt for me.

It will be important to see how many other conferences can live up to that standard ;)

I've arrived in Brazil for 2.5 days of Rio de Janeiro before heading to Recife and Porto de Galinhas for BOSSA 2009.

Rio actually was a much more pleasant experience than anticipated, and as far as I can tell after that short of a visit, I seem to like the city - at least much more than Sao Paulo which I felt was a big disappointment while visiting it last year for a similarly short period of time.

Being in Brazil always fills me with some kind of strange sentimentality. I've spent most of the year 2001 in this country, it was my first long-term experience in a foreign country. It was a great work environment at Conectiva, and times without a lot of the sorrows and worries that I am having today, working with hardware companies who often still not have noticed even remotely what was happening in the Linux world eight to ten years ago.

And I'm always surprised how well I can manage with those few bits of Portuguese that I learned during my 2001 stay. It's actually more than just barely managing, but being able to grasp at least the key aspects of most conversations, etc. And this despite not having had the slightest bit of practice between 2002 and 2007.

If only I could ever get my Mandarin to that level. Well, this is also the reason why I've brought my Chinese language books with me and I'm planning to study quite a bit in them during the two weeks of holidays following after BOSSA. With some luck I can also find some time in May or June to take up my language classes in Taipei again.

I recently got DRM working on sparc64, and this means I had to of course test it :-)

I played around with ioquake3 and it worked just fine. This was in a way exciting since I have devoured many hours of my life into this game on x86.

One aspect of quake3 is that it has a virtual machine. You can write a MOD for quake3 and replace pretty much any aspect of the game outside of the rendering engine. But to keep MOD authors from eating people's home directories, sending your password out to some rogue collection system, and things of that nature the interfaces are tightly controlled and the MOD code runs in a JIT'd VM.

The only way you can get into the JIT is to make a "system call". And the only way to get out is to either return or make such a system call into another module. The system call is the main entrypoint into the module, it takes an integer command and 0 or more integer arguments.

All memory accesses done by the JIT'd code are masked so that it is impossible for the JIT to touch memory outside of that allocated explicitly for it by the VM.

Ben H. kiddingly said to me that I should write the Sparc JIT since there is one for x86 and PowerPC already. One should never kid about such things...

It's pretty neat stuff, although the stack machine VM code output by the LCC compiler they used is horribly inefficient. Some code for a function might look like:

OPCODE[  OP_ENTER] IMM4[0x0000001c]	! ENTER function, 0x1c of stack
OPCODE[  OP_LOCAL] IMM4[0x00000024]	! PUSH stack offset 0x24 (first arg)
OPCODE[  OP_LOAD4] 			! LOAD from "stack + 0x24"
OPCODE[  OP_LEAVE] IMM4[0x0000001c]	! LEAVE function, return LOAD result

Operations push entries onto the "register stack", and consume entries on the top of that stack. This might emit some sparc code like:

	save	%sp, -64, %sp		! OP_ENTER
	sub	%g3, 0x1c, %g3
	add	%g3, 0x24, %l0		! OP_LOCAL
	and	%l0, %g5, %l0		! OP_LOAD4
	ld	[%g4 + %l0], %l0
	add	%g3, 0x1c, %g3		! OP_LEAVE
	ret
	restore	%l0, %g0, %o0

We use several fixed registers, "%g3" is the stack pointer, "%g5" is the VM data segment offset mask, "%g4" is the data segment base address. So every load or store address formation is "mask with %g5 and add to %g4".

It's there in the ioquake3 repo right now and will be in the next release. There are lots of things that can be improved but it works very well and most of the quake3 MODS I've tried (CPMA, UrbanTerror, etc.) work. I've also been playing the base game online extensively, you know, for stress testing.

As expected, it seems that the various different GSM cellphones expose quite big differences in their behavior towards the GSM network. In part this is due to the evolving GSM standard, where features were added over time in a backward- compatible manner, so old phones still work on modern network. The biggest part is probably due to implementation differences in the GSM stack or the particular hardware drivers that glue the stack to the given digital + analog baseband circuitry in the phone.

I have started to collect a number of different phones to test them with OpenBSC, you can see my current collection here: In addition, at the Berlin CCC we also have an old 8W Siemens P1 for testing against Phase 1 GSM phones.

The old Nokia DCT3 phones seem to be the most tolerant ones when it comes to violations of the protocol. I had a number of bugs, such as using the wrong training sequence in the CHANNEL MODE MODIFY as well as ASSIGNMENT COMMAND messages, but they simply ignored it and used the TSC from the SYSTEM INFORMATION. The various Siemens and Motorola phones are way less tolerant, which is good since it enabled me to actually find the respective bug in OpenBSC.

Also, Phase1 support in OpenBSC hasn't really been there so far. We kept asking the phones for their IMEISV, and apparently Phase1 only have IMEI but no IMEISV, leading to us rejecting the LOCATION UPDATING REQUEST. This is also fixed now. The remaining Phase1 problems are:

• correctly dealing with FR (as opposed to EFR) codec
• figure out why they send a MOBILE IDENTITY TYPE 5 instead of an IMSI on establishing a mobile-originated (MO) call

Finally, it has happened in a public manner: Microsoft sues TomTom over patent violations in the Linux kernel [V]FAT implementation. Sooner or later something like this was bound to happen.

For a number of years, I have heard rumors by various companies producing Large-quantity embedded Linux products that Microsoft is claiming the Linux kernel infringes upon their software patents, and they should sign extensive patent licensing agreements with MS.

The underlying strategy is very obvious: Make those patent licenses high enough to reduce the cost advantage of a Linux based OS over Windows CE and thereby demotivate companies from using Linux in the embedded world.

This has so far happened behind closed doors, but if you google you can find a couple of strange press releases of Asian companies buying into those MS patent deals for Linux.

Now finally, one company, TomTom, has had the guts to stand up against Microsoft and fight their ridiculous claims.

The VFAT patent in question has been invalidated in some jurisdictions, since it has clear prior art: the ISO9660 Rock Ridge Extensions in 1994. Also, in light of the new software patent evaluation rules emanating from the Bilski case in the US, it seems Microsoft has a quite bad stand.

I myself, as well as numerous other people in the Free and Open Source world are asking themselves how this legal action fits into the Microsoft-proclaimed Free Software friendly strategy. As you can see now, that was nothing but vapor.

And MS goes even further. They claim that this lawsuit has no relation whatsoever to Linux, and they're only targeting TomTom's specific implementation of Linux. I have actually reviewed the TomTom kernel sources a number of times during the last couple of years as part of gpl-compliance reviews. I can tell you, there is nothing "TomTom specific" in their FAT FS code. It is the plain fat/msdos/vfat file system like in every kernel.org kernel.

I seriously hope that TomTom will keep up their spirit and be strong enough to fight this attack by Microsoft. We need to see more companies who stand up like TomTom.

Finally, close to 5am after a long day of hacking, I was able to make the first actual voice calls through OpenBSC. This has been _much_ harder than anticipated, with bugs spread all over various places of the code (my code!) as well as some conceptual shortcomings in my understanding of how the exact interaction between GSM 12.21, 08.58 and 04.08 happens.

Initially I was working with the ip.access BTS, but was stuck and didn't see any progress so I decided to try the BS-11, since that one is at least according to spec as A-bis over E1 is publicly documented. Some six hours of problems in my E1 sub-channel multiplexer and TRAU decode/recode later, I actually had a working voice call. To my big surprise, the delay between two phones at the same BTS is incredibly long. Feels like VoIP between two continents.

I then tried whether the fixes have changed anything for the ip.access situation. And yes, they did! It was working straight away, and the delay is non-existent. Isn't it ironic that the traditional E1 system is much worse than the fancy new IP based system? I really need to hunt down where the delay is introduced in the E1 TRAU frame handling, this is not really acceptable right now.

Some further experimentation discovered that my Motorola EZX phones somehow refuse to work, while all the Nokia ones do. Well, some more bugs to fix down the road. At least conceptually everything is working now.