Free Software Foundation Europe elects new senior leaders

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.

GSM wardriving has started

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.

Palm Pre wanted for FOSS hackers

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.

ScummVM settles GPL duspute with Mistic software

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.

Palm has released sources for WebOS 1.0.1

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.

Soon I'll say hello to Hamburg

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.

I'll be talking about GPL violations at LiSoG on July 1st in Munich

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.

OpenBSC now has an API for integration with PBX systems

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.

OLPC XO1.5 samples has arrived for VIA driver related work

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.

Working on a new VIA graphic chip debug tool

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.

Updated via-sdmmc driver submitted to mainline

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.

Palm Pre is shipping GPL incompliant

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.

Palm Pre supposed to be closer to traditional Linux than Android

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.

Linux kernel cpu_debug support for VIA CPU's

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.

Linux kernel hwmon driver for on-die temperature sensor of VIA CPU

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.

OpenBSC on its way to get funded A-interface development

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.

On my way to FreedomHEC Taipei 2009

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.

Openmoko announces Freerunner transitions fully into the hands of the community

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.

Back to Germany, travel plans during next weeks and months

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

Some more VX855 work related to OLPC

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

VX800/VX855 accelerated kernel framebuffer

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.

VIA Integrated Graphics / VGA De-ja-vue!

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

Intel (and Nokia) announces not-invented-here-syndrome

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

Some VIA VX855 integrated graphics related work

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.

Marvell PXA310/PXA320 SoC manuals public

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.

Some more testing with the PadLock hardware on VIA Nano CPU

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.

Will have the honor to assist with OLPC XO1.5 bring-up

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

OpenBSC: Support for multiple BTS / ipaccess-config

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

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

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

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

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

The best linux kernel commit message ever

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

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

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

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

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

Signed-off-by: Stephen Hemminger 

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

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

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

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

Thanks Stephen, you made my day :)

Without words

$ dig -t MX openmoko.com

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

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

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

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

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

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

Podcast about OpenBSC at Chaosradio Express

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

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

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

Some notes about the FSFE FTF Legal Workshop

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

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

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

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

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

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

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

Departing for the FSF Europe Legal and Licensing Workshop 2009

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

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

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

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

Some updates on the gnufiish project

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

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

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

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

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

Will be in Taipei in May after all

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

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

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

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

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

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

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

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

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

OpenTechSummit Taiwan 2009 cancelled

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

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

New "linux/mobile" section

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

Cancellation of GTA03 / thoughts on OM Inc.

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

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

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

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

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

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