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

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.

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.

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.

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

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

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.

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