Dependency of essential Linux bluetooth features on dbus

Apparently I'm not the only one with outspoken criticism of the BlueZ dependencies on dbus.

I do not want to debate the merits of a message bus system on any system (desktop or non-desktop) and neither do I want to start a debate on how efficient dbus is trying to solve that problem.

However, what I'm fundamentally opposed to is when basic interaction in a network or between a computing device and its peripherals depends on extensive userspace dependencies. Now you might argue that ipsec needs a userspace keying daemon, that routing protocols need a routing daemon, and 802.1x or WPA need a userspace daemon, too. This is not the point. There are very valid technical reasons for doing so, and nobody really proposes that such things should move into the kernel. Also, none of the above-mentioned programs have requirements on other userspace components aside from glibc or maybe some netlink specific library.

Bluetooth however now requires dbus. At least it is almost impossible to do without. I have tried for neverending hours and didn't make it work. Others apparently have similar problems.

If people want to [d]bus-enable their kernel-related tools, let them do it. But please make it optional and don't depend on it. This is just not how things are done in the Linux kernel world until now, and I don't think there has been any debate on whether we really want such a paradigm change yet..

proprietary MiFARE [in]security finally falling

At a presentation entitled "Mifare - Little security, despite obscurity" at the 24C3, Henryk Ploetz and Karsten Nohl presented about their revelations of the proprietary Philips MiFARE classic RFID system.

As everyone in the IT industry suspected, the level of security provided by such a cheap, low-gate and completely undisclosed system is in fact very limited.

I'm particularly proud that this security research is exactly what Milosch and me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put easier accessible and open, documented tools for low-level access to 13.56MHz RFID systems.

With a bit of luck, at some point in 2008, it should once again become clear that security by obscurity doesn't work. This lesson seems to be well-understood in the Internet world, but apparently has little penetration into the RFID sphere so far. There are still many proprietary systems whose security relies solely on the secrecy. Once a single person reveals that secret, the system is broken.

I can only hardly imagine the amount of economic damage imposed by the perpetrators of such systems. There are a couple of hundred million MiFARE classic tags on this planet, particularly in public transport ticketing and access control. The vendors of such systems should be blamed for their false claims. And anyone who bought it should be blamed for their blind belief in the claims of profit-oriented corporations without any independent validation or verification.

Personal reflection on the 24th annual Chaos Communication Congress

It's great to be at 24C3, the 24th incarnation of the Chaos Computer Clubs annual congress in Berlin.

In fact, this is my 10th anniversary at this congress, i.e. the first one I visited was 15C3. I ended up at 15C3 as somewhat of a coincidence by just following a fellow Linux hacker from the Linux User Group Nuernberg to whom I've since lost all contact.

What's actually worth mentioning is that this is the first CCC congress that I visit as a pure guest. I have no lecture, and I am not actively involved with any of the things I have been involved before, such as the video recording/streaming team or the Sputnik RFID location system.

Interestingly, I felt the first day much more tiring than usually, despite having slept more than in any of the previous years. Apparently the lack of constant adrenaline caused by last-minute-problem-solving has its impact..

The congress is a lot of fun, I've been talking to many old friends, colleagues and fellow hackers from all over the world, involved in all of the projects and/or companies that I've remotely had any contact throughout that ten year time period.

It's a very nice feeling. I doubt there is any other event or occasion where I would feel more at home than at this annual congress. This is my culture. This is where I belong. Here are people who understand, or rather: understood.

HTC TyTN II / Kaiser doesn't look like a GPL violation!

There have been numerous rumors floating around the net that the HTC TyTN II (aka Kaiser) might be a GPL violation due to a number of strings in the firmware image referring to Linux and vmlinux.

I've done some analysis on this subject, and posted my preliminary results in this posting to lkml earlier today.

So as indicated, I do not see any reason to believe there is a GPL violation with regard to the Linux kernel in the MSM7200 modem side as used in the abovementioned device.

So please stop those rumors now. I'm obviously not opposed to people being watchful and report/investigate potential GPL violations. But before you call it an actual violation, please rather make sure that you have some evidence!

Final cleanup of OpenMoko Neo1973 kernel patches

I'm doing one final review+cleanup iteration for the OpenMoko Neo1973 GTA01 related kernel patches before pushing them for review later tonight or at some point tomorrow.

The cleanups are mostly dead code removal, avoiding compile-time warnings as well as cosmetic cleanups such as adding MODULE_DESCRIPTION to all modules, and using consistent naming for files and driver names.

GTA02 will have to wait a bit more. On the one hand, changes that the kernel developers want me to do on PCF50606 will likely appear in the PCF50633 driver, too. On the other hand, the entire Smedia Glamo driver core has not been polished yet.

Playing around with the HTC TyTN II / Kaiser

For reasons that I cannot yet disclose, I have obtained a HTC TyTN II (aka Kaiser). This is my first (and hopefully last) Windows Mobile based device.

So far I've taken the device fully apart, unmounted all the shielding covers and took high-resolution photographs of each and every part of the phone. The resulting information is now that I'm aware of all the major components in the device, and I've started to do some data mining on those components.

As everyone knows, HTC used a Qualcomm MSM7200 based chipset in this device. The MSM integrates both the GSM baseband (DSP+ARM9) as well as the application processor (ARM11) and many other things. What's less known is the further peripheral configuration.

• The Bluetooth and WiFi chips are from Ti (BRF6300 and WL125, respectively).
• The power management unit is a Qualcomm PM7500
• NAND+DRAM are in a multi-chip module (1.8V, 2GBit NAND x8, 1GBbit DRAM x32) from Samsung
• The 3G/GSM RF part consists of Qualcomm's RFR6500 (receive with integrated GPS) and RTR6275 (transmit) as well as AWT6280, AWT6273 and AWT6273 amplifiers
• There furthermore is a CPLD: Xilinx XC2C128 (3000 system gates, 128 macrocells).

For those interested, I'll go through my PCB photographs and will edit and publish them soon.

I am now digging through all the various XDA/WM6 hacker information out there and trying to understand the various tools that can be used for further taking apart the software side. I've already managed to get into the bootloader, which apparently offers a standard USB serial emulation that can be accessed even from a Linux PC.

Unfortunately the MSM7200 is a highly proprietary/closed chipset, and there is very limited public information available. I've already ran into this while evaluating potential hardware for OpenMoko at some point in the past. I became curious about this MSM7xxx chipset family when they were first added to the ARM-Linux machine type registry many months ago.

Anyway, meanwhile Google seems to be doing a lot using this chipset, as they have recently announced the availability of a linux-msm.git tree. The source code should document many things such as GPIO assignments, IRQ's and contain drivers for most of the hardware (on the application processor side).

Now if some of you ask yourselves if I have turned my back on OpenEZX and OpenMoko: No, that's not true. I'm just looking at this for a very peculiar reason. Hopefully I'm able to reveal more soon.

Merging OpenMoko patches with u-boot and kernel mainline trees

Those following the OpenMoko commitlog will have noticed quite a bit of activity in the areas of u-boot and kernel patchset. For u-boot we always tried to track mainline git. For the kernel, there is now a patchset against the current Linus git tree (2.6.24-rc4 should also work) at http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches.

I'm intending to do some level of testing after the merge, and then submit the majority of the stuff. For kernel, I don't expect many issues. For u-boot, it will be a quite painful process.

So if you now think this means that I'm back working for OpenMoko, this is wrong. I'm doing this for a personal reason: I merely want to make sure that the code I wrote throughout the last 18 months will not bit rot somewhere but is actively merged into mainline.

Day one of FOSS.in

It was a great first day at FOSS.in 2007. It's been surprisingly quiet at the venue today, compared with the previous incarnations of the event. This is due to the changed structure, in which the first two days are focused "project days" and the main conference only starts on day three.

This does by no means imply that the project days are less important, or that the lower number of people is bad. Quality matters, not quantity. And since the event is about contributions, project days are a very important addition to FOSS.in

I spent most of the day talking to Rusty and James. It has been quite nice and I now have learned about Rustys new exciting CCAN project. As a long-time perl developer (I have leanred Perl before C!), I definitely understand the beauty of something like CPAN. With C however, the hardest issue will be resolving the namespace problem. Unfortunately I am currently not in the mood of adding even more unfinished things to my task list.

incommunicado for a while

It seems like my main mail server, ganesha.gnumonks.org, is facing some severe problems (ext3 corruption on a 3ware hardware RAID-1, i.e. something that clearly should not happen.

As per Murphy's law, this had to happen exactly while I was in-flight on my trip to Bangalore for FOSS.in 2007 :( Had it happened 2 days earlier, i would have actually within physical reach of the machine in question.

Luckily, all my hosted servers have remote consoles and actually even remote access to the BIOS setup. So I'm trying to recover what's to recover. The exim mail spool is on the affected /var partition. The much more important cyrus IMAPD spool is not affected. What a relief.

Still, everyone who tried to contact me: Please expect some delays in email based communication through the next few days. Sorry for the inconvenience.

Looking forward to FOSS.in

In a few days FOSS.in 2007 will start. I'm departing from Germany on Monday next week. I have a ton of things to do until then, including a trip to my family in Nuernberg on Friday,, visiting a industrial festival in Chemnitz on Saturday and packing my suitcases on Sunday ;)

So this will be the fifth year in a row that I visit Bangalore in late November/early December for the event formerly known as Linux Bangalore. What once started like a crazy reason for visiting India the first time (after enjoying Indian food and bollywood music from Germany for a couple of years), has turned into a regular mark in every years' calendar for me.

I've been told that FOSS.in this year will be very different from all the previous events. The focus has been shifted from doing just another round of 'this is free software and this is how to use it' event, the focus is now entirely on the community developer.

India still has, to my deep regret, shown relatively few significant contributors to Free Software - especially if you relate it to the size of the IT industry and the number of people working as software engineers in that country. Thus, I very much welcome any effort to nurture and foster the active, contributing part of the FOSS community there.

Meanwhile, the Schedule has been published by the organizers. Looking at the speakers and topics covered, it definitely looks more than promising!

Also: My openmoko-induced absence to the major Linux events in Europe and Canada have resulted in a way too long time since I've last met Rusty and James, my former fellow netfilter/iptables hackers :) Make sure you don't miss any of Rusty's talk. It's going to be fun :) And be prepared to switch your brain's English parser into high-speed mode :)

As a final side note: I'm happy to learn today that my application for a five year visa to India has been granted. During the last five years, I had to obtain a total of seven 6months visas - sufficient evidence to support my argument in favor of a 5 year visa.

Slowly getting back to my normal life

For the last couple of days I finally felt like in the "good old" (pre-openmoko) days. Suddenly things that have been piling up to higher and higher stacks are getting resolved. Tax related issues, various other administrative things like housing, insurance related, etc. I even find time for regular medical checkups like dentist's visit again.

I'm also slowly browsing through the various lists like netdev, which I haven't had time to read throughout the last year or so. Finally I get the feeling of being "in sync" again with what's happening in the rest of the Linux world.

I'm also making quick progress on gpl-violations.org (just ordered two new test purchases of allegedly infringing devices). And I even have time for the occasional homepage update of my various rotting (and rotten) websites.

I'm also almost finished with Ulrich Dreppers excellent paper "What Every Programmer Should Know About Memory". Being a kernel hacker, most of the issues have been known to me more or less, but it's good to read about all of them in a concisive paper, together with benchmarking on current hardware.

There ares still hundreds of pending issues here and there, and I yet have to find some time to e.g. finally do a ulogd2 release, work on integrating all the pending patches in librfid, work on ISO15693 support for it, and last but not least work on getting a lot of the work I did for openmoko on u-boot and kernel finally merged mainline. But if I'm able to continue getting things done at this pace, I'm very optimistic

It seems like all the time with OpenMoko has actually made me forget how easy and fast things have been moving all the time before ;)

Leaving OpenMoko "Lead System Architect" position

The regular reader of this blog will have noticed a distinct lack of any OpenMoko related news. This is not a coincidence. As Mickey wrote in a blog entry, there has been quite a bit of internal friction lately.

Adding that to the enormous amount of stress over the last 18 months has made me feel quite a bit demotivated over time. I've tried to cut down on the amount of work I do, but it hasn't helped much. So now I'm at a point where I feel unable to work in any active/leading role inside the project and/or company. My deep apologies to the the project and its community.

But don't worry. OpenMoko is a team, and I'll do everything to help smoothen the transition. I'm more than willing to assist those who will take care of my various tasks.

From today on, I'm nothing more than a volunteer to the project. I'll likely continue a bit of hacking in my areas of personal interest. Just like in many of the other FOSS projects that I have been (or still am) involved.

All the best to the OpenMoko project, the OpenMoko company, FIC Mobility. The last 18 months was an intense experience. Thanks to everyone who has helped the project both inside FIC/OpenMoko and outside. Thanks to FIC for funding and supporting the project. I wish everyone the best, and I'll be the most happy person (next to Sean) at each and every milestone the project achieves in the future.

My last netfilter training

Since I've been doing no netfilter/iptables related work recently, I've announced that the three day training is going to be the last one, at least for the time being.

Though stressful as usual (have you ever talked/presented straight 8 hours on three consecutive days?) it was a quite joyful experience. Apart from the netfilter/iptables workshop earlier this year, the only contact with my former much-beloved project in 2007.

However, the training made me realize how outdated all the existing documentation (and even my own training material) is. Basically everything was written in the early 2.4.x days - and much has changed ever since.

There's all the nf_conntrack / nf_nat related changes, as well as the x_tables transition, which can cause many subtle errors due to old scripts expecting different kernel module names, etc.

None of the HOWTO's or similar documents talk about the conntrack userspace program yet, there's no documentation (and no release) for ulogd2, etc.

So I'll really try to sit down and find some time to improve some of those areas. It yet remains to be seen if I can actually make it. But I feel there's a real gap to be filled...

Slowly getting back to work on gpl-violations.org

Today I've finally started to pro-actively work on gpl-violations.org again. I haven't been able to do any work on it for almost 1.5 years due to my intense involvement with OpenMoko.

Among my first tasks was to update the ssl certificate for our internal Request Tracker, which apparently expired quite some time ago. After that, I went through all RT tickets and deleted tons of spam from it. Now it finally looks like I can start working with it again :)

I'm also trying to catch up with all the gpl-violations.org related email, but please give me a couple of weeks, there's just way too much of it :(

Heading back to Germany

So, after roughly two weeks of OpenMoko Taipei headquarters, I'm now heading back to my Home+Office in Berlin. And I'm really looking forward to it. During the last couple of months I've tried my best to help the transition from OpenMoko a a project inside a FIC business unit to OpenMoko, Inc. the independent company inside the FIC Group. I've helped with tons of things that are definitely by no means related to kernel/bootloader development, or even the hardware architectural planning that I've been heavily getting involved starting with GTA02.

So now it is a good time to finally focus again on what my actual and original task is: Software development. This can be done much better remotely, so I'll expect to be able to work way more from Berlin. Which makes me happy, since it always was and still is my favorite city. And I definitely missed it a lot during the last year of intensive OpenMoko work. Now I'm on my way back, and I'm looking forward to spending more time with my friends, the CCC Berlin. Being able to go to concerts and clubs that play music I actually like. Being able to work on finally improving (or rather: finishing) home improvement in my apartment, and many other things.

So don't get this wrong. I'm very much continuing my technical work for OpenMoko, and as the first developer on this entire project and a OpenMoko core team member, I'm always going to maintain an influential role in the project. But finally, I can go home, feel better, work more focused and efficiently, and improve the technical quality of our products even more :)

Since OpenMoko now actually has three full-time paid project members in Berlin, It's also going to be nice to closer cooperate with them. (or co-work, like the Chinese English speaking would say)

Seeing netfilter/iptables boot-up messages in an airplane

I've read a couple of blog posts about the suspicion (or even confirmation) that some of the in-flight entertainment systems are using Linux. It's completely understandable that if you have to put 400+ such systems into a plane, you'd rather use free software for the economics of licensing costs.. imagine 400+ windows licenses :)

Now in any case, during my Taipei-Singapore flight enroute my trip back from OpenMoko headquarters to Berlin, I was amazed by the new big-screen entertainment systems that Singapore airlines is apparently using in some of their planes. This particular plane was a Boeing 777-300R. The screens are not the usual 4" or similar, but actually something like 10" - and that in economy class. Also, they're really high-res, and seem to be entirely controlled digital, i.e. no blurry PAL/NTSC or VGA resolution, but actually something on the order of (guessing) XGA.

The second unusual bit was the three connectors on the right hand side of the screen. Ethernet (!), USB host and composite video-in. I've never seen something similar in an airplane before.

Now unfortunately the system on my seat was stuck. I called the flight attendant, who then issued a remote system reset. To much of my surprise, I could soon see the BIOS boot screens of a VIA based embedded system. Afterwards, it executed RedBoot, followed by a Linux kernel, to be followed later by an X server (you could see the grey background pattern with the X cursor for quite some time), and then some custom X11 applications.

As the RedBoot message suggests, the system was implemented by Panasonic Avionics.

The first thing worth mentioning was the incredibly slow boot progress. They must be running those systems at low clock speed, and boot them over the network, even though the rootfs was ext2. I didn't see the details since I was too busy grabbing my camera to take this photograph.

The amazing thing about this system is that it has 512MB RAM per seat, dissipates a dangerous amount of heat (you can feel it getting very uncomfortably warm under that screen, where probably the entire system is located, similar to a "tablet PC" form-factor). Still, it is very slow. And then look at the details. Why on earth do you need a wifi stack and netfilter/iptables, including ip_conntrack on such a system inside the airplane? I severely doubt that they use packet filtering to prevent a hacker to get from one seat to another - and thus connection tracking adds anything aside a performance hit.

So what's it with those connectors? I couldn't get the Ethernet part. And for whatever reason, I didn't have a patch cable in my carry-on luggage either. Maybe the entertainment system might have been even more entertaining that way, who knows :(

The USB connector is meant for a user-provided USB memory stick, where you can then watch your own pictures, or use a word processor or spreadsheet to view / create / edit documents. The software used for this is - unsurprisingly - a customized version of StarWriter/StarCalc, based on OpenOffice.org. I've played a bit around with it. Using the controller, you can actually resize the window from full-screen to something smaller, but there's nothing interesting in the background. I've tried to see if one can somehow change the print command to "/bin/sh" and then print a document - but the printing functionality had been removed altogether, so no luck here.

I decided to sleep for the rest of the flight, rather than trying different attack vectors. If I run into such a system again, I'm probably quite tempted to do so again. Would be fund to get an entire plane full of Linux hackers (let's say: OLS attendees) and have them play around with it to see how well is is done from a security point of view. I guess the worst-case scenario is something like people connecting their USB hard drives (or laptops via Ethernet) and then ripping the entire entertainment library during the duration of a 12 hour intercontinental flight. I'd suppose they actually should have looked a fair bit at the security of such a system. But then, the same is true for many systems, and developers still neglect that aspect way too often.

Back to Taipei

Today I got back to Taipei, almost three weeks later than originally anticipated. More news after at least one night of full sleep and the first day at the office...

FOSS.in 2007 Call for Participation

The Call for Participation of this years incarnation [it's in India, after all] of FOSS.in has just been released.

This is great news. I've cut down on all other events this year: I haven't visited at OLS, LinuxConf Europe, linux.conf.au, ... Only FOSS.in I really cannot miss ;)

I haven't yet decided on the exact title of the lecture that I'm interested to submit, but it seems like I'll have to decide soon. It will be OpenMoko related, that's for sure ;)

If you have worked on something exciting in the FOSS world, please don't hesitate and submit it to the FOSS.in/2007 CfP. It's a great event with a very technical audience. And an ideal opportunity to catch a glimpse of India :)

Overwhelming participation at Demonstration against Germany's new surveillance laws

On Saturday, I attended the Freiheit statt Angst demonstration in Berlin, which aimed at protesting against the various new laws and regulations increasing the surveillance of the German government on its citizens. I assumed it would be again one of those niche events like the demonstrations against software patents, with some 200 people. To the contrary! The organizers counted 15,000 demonstrators, and even the police's initial estimate at the beginning of the demonstration was 8,000.

This really is a big step forward. Apparently it's not only the "generation Internet" that is sick of the ever increasing cut down on civil liberties, data protection and privacy. That being said, 15,000 is still a too small number for a topic that effects everyone in this country. But even a demonstration of that size doesn't happen every day in Berlin, so it's not that easy to completely ignore either...

Don't miss the photos of the demonstration

netfilter developer workshop 2007 is over

The days of the netfilter workshop passed quite fast, and I'm finally back to my home in Berlin now. In case you're interested, here is a link to the group photo.

Among other things, we've had the following major decisions at the workshop:

• Patrick McHardy finally officially head of the coreteam
• ulogd2 will see an official release candidate soon
• we want to merge ipset soon
• we will try to shift future developments in the direction of libnl and slowly deprecate libnetfilter_*
• we will move the netfilter and netfilter-devel lists to vger.kernel.org since we don't have to care about spam filtering there. Other, lower-traffic lists remain on lists.netfilter.org
• we will switch to git even for userspace code, at least for the iptables source code

Finally, I'd like to use this opportunity to thank all our Workshop sponsors, particularly Astaro for their continuous and generous support of netfilter/iptables throughout the last five years.

Enjoying the netfilter workshop 2007

I've returned to Germany in order to attend the 5th netfilter development workshop in Karlsruhe. It's sponsored by Astaro, whose continuing support of netfilter/iptables is really outstanding. Even after I took my "leave" to work on OpenMoko, they continue their funding by paying for Patricks maintenance of the netfilter/iptables codebase, and things like hosting the netfilter workshop.

It's really great to meet with the old colleagues with whom I've co-worked for a number of years on netfilter/iptables. I really miss those days, basically spending most of my day working together and communicating with cool people hacking on similar problems. Quite a bit different from what I'm doing right now.

So while I'm here, I'm actually trying to spend most of my time related to netfilter/iptables, which is really refreshing.

I now own two motorbikes

Besides my BMW F650ST in Berlin, I now (since 10 days ago) own a Yamaha TW200 in Taipei. To me, this is sort of a joke of a motorbike. A toy bike. 200cc feels like a bicycle with ancillary motor. No acceleration, no torque...

But then, Taiwan is an incredible strange country when it comes to motorbikes. And that TW is definitely better than one of those 2-stroke plastics scooters (I had one when I was 16: 3 jammed pistons in two years, plastics above the exhaust completely melted up to a point where I had to add custom-made aluminum pieces for it not to loose its structural integrity).

So it somehow fits the overall Taiwan experience: A never-ending compromise....

Two days of intense u-boot hacking

After finishing most of the basic device support for GTA02v2 in both kernel and u-boot during the last week, I've finally turned back to implementing one of the longest standing issues in u-boot: GSM passthrough.

GSM passthrough allows you to basically ignore the smartphone part of the device and connect the GSM modem more or less directly to a host PC. The feature has been long known by various smartphone hacker projects such as e.g. OpenEZX (which as a side note has made quite some progress recently, much appreciated by me as retired project founder).

So GSM passthrough is mainly useful for rapid development (developing gsmd more efficiently by running it on the developers workstation, without cross-compiling and ipkg installs), but also if you want to use some legacy application that was written at a time where a phone really only was a phone (e.g. sim card managers, ...)

Now the GSM passthrough was always pushed back on the TODO list, since our usbtty code in u-boot was never very reliable and caused lots of data corruption such as bogus and/or missing characters. Quite useful for the human operator, but definitely not acceptable for getting a program with AT command parser to work. So that had to be fixed first (and it is now fixed).

As I pointed out in my announcement, the generic way of implementing this feature has actually quite interesting but much more obscure use cases such as dialling from a landline via GSM (CSD call) into your Neo, manually accepting the incoming call and then attaching the u-boot command line to it. That's sort of the feature you have on hosted/colocated servers, when you use a boot-loader with serial console support and attach a modem or terminal server to it.

So does this mean the Neo1973 is now ready for the enterprise? Not quite. Even though it has a built-in UPS (called battery), and GTA02 will even allow you to change the battery without shutting down the device, resulting in higher availability ;)

But then, the expectations / requirements for mobile communications devices are quite a bit different from that world. But the hackers community likes those kind of strange features. Have you ever heard of another smartphone with that capability?

Oh, and before I get any complaints about the security: This "feature" has to be explicitly enabled and every call manually accepted by typing a sequence of commands into the u-boot command line. So unless the attack involves tons of social engineering (getting the device owner to do all those things) there's not that much of a big deal. But maybe we should start to think of some kind of user authentication for u-boot now *rotfl*.

OpenMoko Taipei office network setup

For the last three days I've been busy setting up the network in the new OpenMoko office. Finally something that just works, without any major flaws. That's probably because the involvement of external entities is fairly small. But looking at it closer, actually exactly there the problems start. FIC purchasing e.g. only bought 50% of the switch equipment that I asked for, something that I still don't yet have received any details about, neither some kind of apology.

In any case, the network is up and running. We now have a pretty uncommon heterogeneous combination of Cisco, Dell and even some D-Link switches, with the core switch being a pretty impressive Dell 6248. The 10GBit transceivers are still missing, so the backbone is just running 1GBit for the time being.

There's a total of about 190 Ethernet access ports throughout this new office, and we have various different broadcast domains, safely separating guest network, office network, r&d network, ... from each other.

The server room also looks quite nice now, with five 19" full-height 19" racks, 2 layers of UPS (building-wide and extra small UPS in front of servers), with three fairly big servers in operation, and eight more pending to be used soon.

The Internet uplink is a 100MBit capable physical layer (fiber optics), of which we only subscribed to 8MBit initially. But one phone call (plus additional transfer of money) later, we can bump the speed to any rate below that 100MBit physical layer limit.

The operation of our own (netfilter/iptables based, what did you think?) firewall now also brings us back the long-missed basic fundamental networking needs of any free software hackers (called luxury around here) of all our developers being able to

• access the web without restrictions and blocked sites
• finally use IRC!
• access external IMAP4 servers
• have SSH and other interactive sessions not time out every couple of minutes

Progress with the new OpenMoko and FIC Mobility office

The final 24 hours of my current Taipei trip have started. This is a good time to reflect on what has happened in those last weeks since July 9.

As with the overall status of the project, I'm still extremely dissatisfied. The frequent reader of this blog will have noticed the last postings on this subject, full of discontent.

So the further we are into this project, the more time we put into it - the further I expect it to produce anything that I would consider reasonable results. Please don't confuse this with the commercial success, or the ability to produce working products. This is an entirely different matter.

To me, it is extremely important to do things systematically, with lots of planning, safeguards, checks, verifiable and reproducible processes, as much automatization as possible, little room for human error, etc. So as long as not everything from hardware to software development, mass production, production testing, distribution/logistics/sales, etc. follow a well-thought-through process, I will not be happy with the results. Because any such "results" are more or less the mere product of luck or randomness, and not a trustworthy basis upon which we can rely on.

So reflecting on those past weeks, I think the following things have made humble and moderate progress:

• GTA02v2, the second prototype generation of GTA02 was finalized after many issues including unavailability of key components. I'm more than looking forward to see how it turns out
• DebugBoard v3, the third version of the Neo1973 Debug Board was finalized and is actually also verified and can go in mass production
• Our internal software team finally has proper leadership and guidance from somebody who is both Taiwanese and has a thorough understanding of Free Software: jserv
• The new, second (intermediate) generation user interface was implemented and released. It's implemented mainly by O-Hand, since embarrassing as it is, we still don't yet have managed to build a proper internal software development team.
• The first batch of Neo1973 GTA01 was sold, though with a entirely last-minute, error-prone and way-too manual process for order, payment and logistics.
• We have found a capable sysadmin for our hosted, publicly-accessible servers. More news about that in September.
• We have managed to find a extremely valuable senior technical person for our graphics driver and low-level UI work. This, too, will make big news in September.
• The FiWin (FIC wireless networks) company, home to the team working on the it-exists-but-nobody-publicly-knows-what-it-is HXD8, was merged into OpenMoko and FIC Mobility
• We have finalized the specification for the workstations of our software developers. It's incredibly complex to find something that's compliant with our requirements (mainboard with Intel 945/965 on-board graphics, Ethernet chip != attansic/realtek, dual core CPU with 2x2048kByte cache) in Taiwan. So now our developers will all get a Q6600 CPU (what nonsense!). I've tested it, and it compiles the GTA01 kernel in 1.59minutes. Guess they'll be happy about that.
• Realize how many things really are fundamentally wrong internally. What we knew so far about our inheritance was just the beginning ;)

One major thing that finally started to move forward, with something like four to six weeks of completely unnecessary delays, is the new office. After it was decided that we will split FIC MCBU into the independent OpenMoko, Inc. and FIC Mobility (aka Mobile Communications), we also decided to move into bigger, scalable and independent offices.

To our big luck, two thirds of the 7th floor in the FIC headquarters were currently unused, and they're now undergoing quite a bit of renovation and reconstruction. Walls have been removed and brought in, floors have been properly removed and new ones laid - after days of fighting by Sean and myself.

The networking and phone cables get a major overhaul and will be tested. I've also seen the AC for the new OpenMoko server room being brought in. The contract for our own Internet plink has been finalized. The fiber will be put in place within the next week. The core switches have been configured, but we're still fighting very hard to get those damn 10Bit XFP transceivers from Dell.

So the current schedule is to move on August 17, one day after I'll be back from Germany. If that works out, I could spend the weekend 18/19 for doing the final network/server/router/firewall/... configuration.

Obviously, all of this causes quite significant resource drainage for everyone involved. But it's a more than necessary step forward to building an environment that we can actually work in. An environment where our developers have real Internet access, can join IRC channels, and can get in touch with the OpenMoko community without the obstacle of strange corporate policies. An environment where we can have a 'clean start', even in the most literal meaning of the word :)

So all in all, bear with us, have patience. The revolution might take significantly longer than anticipated. But we're still busy doing whatever it takes to get us to the product that the OpenMoko core team set out to build.

Looking forward to the Chaos Camp 2007

In about 24 hours I'll be on my flight 'back' to Germany. In fact it's not really a flight back to Germany, but more like a temporary break of my extended stay in Taipei for the sake of OpenMoko.

The main reason for this trip is to attend the Chaos Camp 2007 of the CCC. I've so far dropped every conference or other technical event this year to concentrate on my work for OpenMoko, but I'm not able to compromise on the camp.

On the one hand, I'm looking forward to finally not having any official function at a CCC event. More than one year after vacating my task as leader of the video documentation effort, and after my somewhat minor involvement with the sputnik RFID tracking project at the congress last December, this is not really the first CCC event which I'll visit as a pure visitor. I haven't even submitted any paper.

So the camp will be holiday. Time to relax, talk with fellow hackers. Sure, lots of the German OpenMoko guys (roh, stefan, alphaone, and our newcomer gismo) will be there. So there will definitely be some kind of productive outcome for the OpenMoko project, too. But in a very different setting. Doing thighs that are fun, rather than all the things that have to be done :)

I'm single again

And this time actually looking forward to it. What kind of strange feeling.

Always in motion, the future is.

Sick but not insane (yet)

Some people were troubled by my last posting about 'insanity'. And I have to admit it is justified. It isn't nice to pull internal issues of some company out into the public that way. But I just couldn't do differently anymore. FIC should think about providing a free corporate psychiatrist for us. ;-) I think I have a fairly big tolerance when it comes to mishaps, incompetence and cluelessness, but some of the things we're experiencing here are just not bearable. Especially not if they lack any kind of rational explanation.

So my latest outburst was mainly related to the fact that despite being with flu and fever in bed, I had to personally hack that embarrassing little online shop we now have at https://direct.openmoko.com/ [my first perl CGI code in about ten years!!]. Can you believe it, we just did not have (and still don't have) anyone in this project who has ever done some real work on CGI's or 'technical web things' at all. And if this was not enough yet, the requirements kept constantly changing all the time, up to this day, more than one week after the webshop opened.

So for gods sake, how many months have we been knowing that at some point we need to ship? And then you have plenty of people who produce over many months three entirely different concepts on how to shop and distribute those devices. And in the end, you have something with a Chinese-only credit card processing page, no proper setup with regard to the carrier (UPS in our case), tons of people talking vapor, but from what I've heard drawing nice diagrams. And no working solution.

Some people might wonder why those shipping rates in the shop are so high. Shouldn't a large company like FIC get huge discounts? Yes, they do. But believe it or not, FIC does up to this day not know in advance how much a shipping costs. Only after it was made. UPS has something like a Rates and Service Selection API. UPS has also a nice and detailed manual on how this XML API reports those rebated 'negotiated rates' in addition to the standard rates.

But then till this very day, UPS keeps claiming that such an API does not exist. Despite the fact that off-the-shelf e-commerce applications _support_ this API, and despite the fact that UPS' very own API documentation goes into every detail describing how that information is XML-encoded. What comes to my mind is the O'Really: Distributing Clue to users in a slightly modified version: Distributing clue to UPS' own sales representatives. How on earth can you get or keep a job there if you haven't even read the company's own documentation on their products?

Then you have companies like WorldPay, who very broadly advertise the many different payment variants they accept, not only all the credit cards known to man, but even things like direct debit (Lastschrift) in Germany. But do you believe they are able to process American Express for us? No, obviously not. Customers located in Taiwan (like FIC/OpenMoko) cannot process AmEx. No explanation given. So much for the word WORLD in WorldPay.

Or would you believe that some large bank like Citibank (Taiwan) was able to charge credit cards (VISA/MasterCard) in USD? No, obviously, being in Taiwan they can only charge in NT$ (New Taiwan Dollars). WTF? It's the 21st century, and there are dozens of online credit card acceptance partners that allow you to bill in about any currency you want. But not a world-class bank like Citibank.

And now you might think that we're actually no longer working on development. That is wrong. Yet another funny story from the MokoUniverse is that one of the worlds largest semiconductor distributors just had a long meeting yesterday, with FAE's and tons of FIC hardware engineers to crack their heads about the question whether or not we can use a "new" silicon revision of a certain component, and where exactly the differences between the old and new revision might be. I refused to participate in such a meeting, indicating that I just want a document describing those differences. In writing. Soon after that, I find out that we have always been using that supposedly-new revision, for the better part of one year. Nobody actually bothered to look at a unit of hardware, or at all the high-res photographs of GTA01 that I posted on people.openmoko.org ages ago.

Then lets get to another of my favorites. Purchasing. I wrote an extensive list of networking gear that we desperately need in order to crate the internal IT environment for our fast growing new OpenMoko company. After many delays, today I finally got our two core switches. And what did they do? They "forgot" to order the transceivers, even though they were explicitly listed in the requirements/order list. God knows what happens in the heads of such people. So I'm now back to once again just mail-ordering things from Germany and then billing FIC for the expenses.

And to not bring up more embarrassing facts, and to at least preserve some level of confidentiality, I'm now going to stop. But believe me, there are _much_ more insane stories to be told. With some luck, at some distant point in the future, I'll get permission to publish them in my memoirs.

But that's basically the kind of thing that drives me close to insanity. Whether for that cause, or completely unrelated: My health is actually quite bad recently. Maybe the lack of regular sleeping hours, let aside regular intake of food and the tons of stress have contributed to the flu that lead to a severe fever attack today. You know there's something wrong if at 33 centigrade in the sun, you're shivering more than when riding your motorbike at -13 centigrade in German winter.

So I'm going to take it slowly for the time being, working much from what has now become my 2nd home (apartment in Taipei, provided gratuitously by FIC for people like Werner and myself, who are spending so much time over here).

My sincere apologies in advance. But given my multitude of roles/hats and functions in the OpenMoko project, I bet my health issues will now contribute to some further delays in about any area of the project. But there's little I can do. One day, we will get there. Let's hope you're still interested in our products at that point.

Insanity

If you want a status update on OpenMoko: I'm at a point where I won't go to the office again because I know the agression inside myself will turn into physically hurting someone there.

An update from the OpenMoko world

As Sean has now made his latest OpenMoko Announcement last night, this is a good point in time for me to write some more bits. Up to this announcement it was hard for me to publicly state anything, since the whole internal restructuring process has been underway, but not yet publicly announced.

I can only join Sean in his assessment about the superb support of FIC's senior management. They are providing us with the kind of resources we wanted.

But being the realist (well, Sean as optimist would call me pessimist, you know that old story), I also see severe challenges both right now, and ahead.

Whatever you might think: I bet that none of you has not the slightest idea about how many problems the OpenMoko team is fighting all day long. If you're thinking "what's the problem with a purely technical task, i.e. designing hardware and software for an Open phone"? Then my reply would be: It's not that big of a technical problem.

However, the really big issues start as soon as you leave the R&D world. On the one hand, there is the actual hardware production. Many components have incredible lead times (3 months or more), and our yet sort-of-unknown-but-initially-very-low quantities are not particularly helpful either. Any .tw OEM/ODM thinks in different terminology. The kind of production processes, shipping infrastructure, ... is just not meant for low-volume and direct shipment. We obviously knew this from the beginning, but everyone just happily works in their usual mode of operation, ignoring our concerns for many months.

Then think about the various customs / legal / trade issues. If you ship components from Taiwan to mainland china and use them to manufacture a product there, you need a special import license in order to get those products back into Taiwan. This license costs money (and, most of all: Time).

Or another example is the lack of double-tax agreements between Taiwan and the rest of the world. So payments to all our various external consultants all over Europe are taxed twice: Once in Taiwan, a second time in the respective country of residence.

For the last two weeks I have been working on finalizing the floor plan and infrastructure planning for the new FIC Mobile Communications and OpenMoko software groups offices in Taipei. And believe it or not, it is a very long and time consuming fight to ever get what you actually want. We know exactly what kind of servers, switches and routers we want. We know to which height we want to reduce the cubicles. We know what kind of Internet uplink we want. Still, it's close to impossible to get anything done. People will just outright refuse to do what they are asked (and paid!) to do.

Take our new servers as one minor example. You would assume that it is no problem at all to configure high-end servers around here. When doing this in Germany, I usually consult one of the many mailorder stores, go through their extensive list of mainboards and other components, select products based on their availability, price and features, and within 24hours I have everything delivered to my doorstep. 99% of those components are from Taiwanese companies.

Now enter Taiwan. First of all, you will discover that the concept of mailorder or extensive online product lists doesn't exist. "Taiwanese people don't trust e-commerce", is what they tell me. Secondly, you can't just call those places and ask them if they have a certain product, since apparently they would always say yes, only to get you into their store.

If you actually get into the various stores, you will see that almost all of the products you want are not available locally. "Not sold into the Taiwan market" is something that you hear very often. So e.g. the choice of Socket 478 mainboards from ASUS goes down from 52 (German online store) to something like 15-20.

So in the end we were really unable to find anything remotely decent (good performance, chipsets with excellent free software support) locally and I ended up importing Asus and Tyan mainboards from Germany into Taiwan, while buying the other components in Taiwan.

Now I could continue and name dozens of examples like this. If this project was just about _developing_ hardware and software, I would be a happy man, and we could look ahead to complete one device after the other. But it's all the other issues, administrative, political, cultural, sales, finance, accounting, shipping, ... which make people like Sean and me run at something like 20-25% of their usual efficiency, despite putting in at least 180% of regular working hours. And there is nobody who can help this, because nobody non-technical really understands what we're doing here, and why we need to do it different than whatever they might have done it before.

Visiting FIC's factory for GTA01 mass production in Suzhou

Yesterday I was on a ten-hour trip from Taipei to Suzhou in mainland China. It took about ten hours for something like a 300km line-of-sight distance, since the Taiwan/China political dispute over The Three Links doesn't allow any direct flights. So we had to go from Taipei to Hong-Kong, transfer onto a different flight to Shanghai, and then start for a couple of hours car ride to Suzhou.

The trip was quite impressive, especially since I have seen a lot more of Shanghai then during my summer 2006 trip to the FIC Shanghai branch. In fact, the sight of so many [strangely-looking] dense, high-rise apartment buildings with 25, 30 or more floors in the suburbs reminded me quite a lot of the classic 1927 Metropolis movie. This impression was probably further enhanced by the thick clouds of smog covering all of the sky, resulting in even non-grey objects look grey, giving the impression of a more-or-less gray-scale world...

In any case, let's not deliberate more about my general thoughts about China, Shanghai or Suzhou at this point, but get to the actual work: Today I spent at the FIC Suzhou factory, mainly doing final QA/Testing of the first 300 Neo1973 GTA01 phones. While I was doing this, another 192 phones went through assembly, resulting in a total of 492 units available at this time. We have another 500 units pending throughout the next two weeks.

The overall quality of my QA checks was quite good. The factory is doing a good job, and we could not detect any production-introduced bugs. The tools provided to the factory for programming/testing of the hardware leave quite a bit of room for optimization though. Will have to start this optimization process next week, after my return to Taipei.

This also means that we can finally make another announcement about the overall project status very shortly. And it means that as soon as the web-shop is up and running, developers will finally be able to purchase Neo1973 GTA01. 8 months too late. Sorry for that. Too much politics and too little actual technical work. All fixed now. Bright future ahead :)

Everyone is busy at OpenMoko

A number of people keep asking me what's going on with regard to openomko. I've even virtually stopped to update this blog quite some time ago. As much as I regret the lack of updates: Be assure they're just a sign of how busy everyone involved is.

I have, in fact, even cancelled my already-accepted paper and corresponding presentation at OLS this year :( I'm also not speaking at any other 'traditiona' event this year, not at Linuxtag, Linux-Kongress, CLUC, LTC, 0sec. Sorry, guys, maybe next year again.

I can't publicly state what's going on with regard to OpenMoko internally, but let me assure you: Good things are happening. We're working on a lot of internal changes that should enable us to approach the project with way more bandwidth.

The first couple of hundred GTA01Bv4 phnes have been produced by the FIC's mass production factory in mainland china. I'll personally do QA on 10% of those phones throughout the second week of June. We want to make sure we don't have any mishaps with our first customers, do we?

The first generation GTA02 prototypes have also showed up at FIC in Taiwan. More news on that at some later point :)

becoming a self-proclaimed election observer

Today I will leave to the German state of Sachsen-Anhalt, as part of a CCC group that will observe the use of electronic voting machines (rather: voting computers) at the elections there.

Our main focus is to witness and collect evidence of the many shortcomings in even the current (by no means sufficient) rules and laws on the security of those devices.

As a Dutch hacker group in cooperation with the Berlin CCC has demonstrated before, the voting computers in question are by no means safe against manipulations - neither are the corresponding safety procedures and measures.

Short update

The last couple of weeks have again been so busy that I didn't find the time to update this blog. After returning from the Taipei trip, as usual, there were tons of things to be done for OpenMoko. Later I spent about one week on a business trip to Bangalore, from which I've returned monday afternoon.

Now I'm only home until thursday next week. Next friday, I'll once again depart for Taipei to speed up and coordinate OpenMoko/FIC development.

Introducing patchwork to the openmoko mailinglists

Some time ago, Jeremy Kerr wrote patchwork, a tool to semi-automatically keep track of patches submitted to mailinglists.

So far, it was mainly being used for the linuxppc and netfilter project with mixed results. I guess in both projects, in the end, nobody raelly maintained the patch status and stuff just ended up to get stale.

Now I've started an patchwork installation for OpenMoko, at least for the most common public mailinglists. So why do I think patchwork will be used more productively and receive better maintenance? Well, firstly, the number of patches on those lists is still quite small. Secondly, the number of people looking into reviewing those patches, within their primary paid-for working time, is relatively large.

I really believe that patchwork can provide an enormous benefit to a project. Let's hope we manage to use it correctly :)

Returning from FIC HQ / Taipei

Just returning from one of the probably busiest weeks in my life. The entire week was spent with meeting lots of FIC staff. Finally I'm able to connect faces to the members of the hardware and production testing team located in Taipei.

Significant time was spent talking to vendors of WiFi chipsets over the last week. The choice seems to have boiled down to designs around Atheros AR6K or Marvell 8686. The AR6K driver code is completely public for quite some time, even though it (and the mvista SDIO code it depends on) might need a bit of cleanup. From Marvell we yet have to find/receive the GPL licensed driver source code - at least from our [high level official] marvel contacts we have received positive confirmation. So actually, for now, only AR6K is a 'known possible' choice, whereas Marvell might become a choice, once we see the source :)

The other big task was sitting down with Werner Almesberger and doing the system level design for the next major hardware revision, and discussing this design with the hardware team. A lot of things are still in flux. But at least the potential of it is _really_ promising. Details are to be revealed at their appropriate time.

I've also had the chance to briefly meet with senior management such as the head of the mobile communications business unit, as well as the CEO and the chairman of the board of FIC. Everybody seems to be really excited and looking forward to the time ahead, now that we have identified many of the problems in the hardware design, production quality and internal processes and are heading to a much brighter future.

Another interesting opportunity was to present at Taiwan NTU University on the 'correct' way of doing Linux development, both technically and from the GPL / policy point of view. Let's hope we now have a couple of more software developers who will know these things before entering the industry :)

In retrospective, I should have done this trip way earlier on. But then, many things have changed over the last nine months, and it might have been an entirely different experience.

Taiwan/Taipei really seems to be an incredibly interesting place. A world of never-ending possibilities in the field of computer hardware. An industry that can produce about any device of your dream - but doesn't since it seems to be locked too much into either the master/slave role of traditional OEM/ODM business - or into producing the same things like all of their competitors, without really trying too much new/exceptional things.

So it seems, after all, my good intentions about travelling less in 2007 seem to be vaporizing sooner than I would have liked. I guess the productivity gain of me being in Taipei at least from time to time is worth it...

One-week trip to Taipeh, visiting FIC.

On rather short notice I am now on my way to Taipeh, Taiwan. As the interested reader of this journal will have noticed, OpenMoko and the Neo1973 are the seemingly endless story of delays and mishaps throughout the last nine months.

So the purpose of this trip is to discuss various options on how to make sure that we all learn the neccessary lessons out of this past experience, and ensure that OpenMoko eventually can at least keep up to some of its schedule promises.

So this will be a week full of meetings and discussions mostly with various managers and particularly the hardware team at FIC, our generous sponsor.

What is at least equally exciting are the planned meetings with various WiFi chipset vendors to discuss our requirements of a mobile-phone compatible low-size, low-power WiFi chipset with a fully GPL licensed Linux kernel driver.

The downside of all this is that I'm once again held back from writing some of the most important infrastructure code that OpenMoko still needs. Anyway, this compromise has to be made - after all, of what use is software without a high-quality, reliable, performant and available handset hardware :)

Since Werner doesn't have a blog, old-fashioned as he is, let me mention that he'll be there for the whole week, too. I think it's a 34-hour trip for him to get from Buenos Aires to Taipeh. I wonder how well he'll survive that...

Dor

On my China Airways flight from Frankfurt to Taipeh, I have continued my tradition of watching the [usually] only Bollywood movie that the in-flight entertainment system offers. In this particular case, it was Dor

I had not yet heared/read anything about that movie, and not even the name sounded familiar. So I was a bit skeptically if this was one of those cheap superficial "B-class" movies that I try to avoid.

To the contrary. What seems like a low-budget production without any major actors [that I would recognize], is actually a masterpiece. Very unlike the cliche Bollyowood, it is not "overdone". Nothing is exaggerrated into self-irony. Everything feels real, down-to-earth. No princess-like costumes, no palaces and no super-rich Indians in their mega-cities. This impression is further substantiated by the somewhat simplistic editing. Scenes end abruptly, and the audio track does not spawn such 'hard cuts' smoothly either.

Dor is a sincere and honest movie about two women who have nothing in common, and come from completely different cultural backgrounds of Indias diversity. However, both of their husbands go abroad to work in Saudi Arabia very soon after marriage. A terrible accident involving those two Indian workers sets the stage for the remainder of the plot.

The whole movie is shot at various locations on the country side. The only remnescent of modern india is a cell phone with SIM card, and the mainstream bollywood songs that are sometimes playing on some squeaky radio.

It seems like this is the next DVD on my 'to-buy' list. Let's see if I manage to pick it up during my trip to Bangalore in early April.

Apple can't even properly translate their SPAM

I just received SPAM from apple: "Mit dem Mac ist Codieren immer und überall möglich." and further down "Codieren. Kompilieren. Berechnen."

Seems like a multi-billion multi-national company cannot even afford some native speaker to proof-read their advertisements. Quite embarrassing.

Phase 0 software build

Whenever you think something is bad, it will come worse. We've had another hardware outage of one of our buildhosts during the creation of the images that were to be prepared for the "Phase 0" devices. Luckily, the build system is easy to set up on various machines, and we actually now have the build system on four hosts :)

It was a lot of stress to resolve the most important issues just before flashing those 50 phones. All kinds of last-minute problems showed up, such as a certain kernel module missing in the rootfs, etc.

Anyway, we managed to finalize it early Friday morning, and Friday + Saturday engineers in Taiwan used Werners fabulous devirginator to install u-boot, environment, splash screen, kernel and rootfs.

Unfortunately, due to all the delays we have been suffering, all those initial recipients will receive is a very basic Linux distribution:
We have hardware support for all the components in the boot loader and kernel. The device now has a boot menu that allows you to switch to serial or USB=tty console. It will happily boot into Linux, where it starts the X11 (kdrive) server and starts matchbox and looks like a pretty standard GPE desktop.

Suspend/Resume is now working from the software side, i.e. you can suspend the Linus system into RAM and get back from it, all drivers are coming back into operation nicely. You can access back light brightness, battery charger state, Bluetooth, etc. The easiest way to work on the device is currently by using USB Ethernet emulation and then ssh'ing into dropbear that gets started during bootup.

So you might think ok, I'll get a fully open source Linux PDA with super-bright display. But I wanted a phone!
We still have lots of stability issues with our native OpenMoko applications currently, so there will not be a working/stable "dialer" application yet. Instead, if you really want to try it, you can either manually use GSM, or use to

So yes, we are delayed. Still, we have decided to ship those units to allow more people to hack on it as early as possible. The foundation is there, and it so far appears to be quite stable, too.

Also, software can always be updated, especially now that we have USB DFU support.

And now, finally, after a long time, I am looking forward to touch the GSM code again. Let's hope there are not too many urgent issues interrupting me next week. After all, we want SMS and GPRS support rather sooner than later :)

G5 Quad broken one month after warranty: The big bang

Last night, I was once again annoyed by the slow build time of our dual AMD64 2.4GHz build server, and I wanted to use my Apple G5 quad again as a build/compile system.

So I pressed the power button, and immediately in that instance there was an extremely loud BANG!. No smoke, no smell, just that bang. Standby/trickle power was still there, the LED's kept shining.

I quickly opened the case, too off the covers, etc. There is no visible component that has suffered any damage. No leaked/exploded capacitors, no residue from some electrical spark, nothing.

And then I found out: The machine arrived on February the 2nd, and now it's exactly one month after the 1 year warranty has expired. I wonder how they can time their system failures that well :(

A little bit later I found out about the Apple Power Mac G5 Repair Extension Program for Power Supply Issues. It seems like this is a common bug, especially when you see things like this lengthy list of people who report a similar effect.

Seems like I'll have to call some local Apple dealers the first thing Monday morning....

A day full of new hardware problems

It wasn't sufficient enough that our main build server had memory corruption yesterday (in which case no RAID1 will help, because the buffer cache data is corrupt and gets written to both disks corrupt).

Today, I had the pleasant experience of finding something like three more or less independent severe hardware design bugs in the Neo1973. I know this is really sad news for those of you who are eagerly waiting for their "Phase 0" devices. But firstly, you have to understand how sad _we_ are about all this. Even more so, specifically, how sad I am, personally... [now working 14hours straight on this issue].

I was not involved in the early hardware design of the Neo1973, and was hired as a pure systems level software guy. Over the progress of this project, I've been involved more and more in hardware fixes / reviews / redesign. And it's been only now that I've had a more detailed look at the suspend/resume/wakeup related bits. Given the previous series of hardware bugs I should have probably been more cautious and thoroughly review the whole design from the beginning, but then: It is complex, time consuming, and I'm no hardware engineer either, just joe random hacker.

The good news is that we are able to fix all this in the next version (GTA01Bv4), and that there are likely-to-be-working hot-fixes for the already-produced Phase-0 devices.

Originally USB DFU support for u-boot was supposed to be finished yesterday. Now with those two days full of most serious hardware problems (server, prototype), I wonder what's going to prevent me from working on DFU tomorrow.

OpenMoko now runs 2.6.20

Despite the much-feared genirq and workqueue changes, it turned out to be way easier to merge our patches to 2.6.20 maintain than reviewing and back-porting all the relevant bug fixes from 2.6.20 down to our old 2.6.17.14 based system.

We probably wouldn't have been able to do this if Phase-0 wasn't held back due to Bluetooth hardware problems. So everything seems to have its positive side, too :)

Ben Dooks (S3C2410 Kernel Port Maintainer) has already picked some of our patches and is merging them, which is good. He also fixed a s3c2410fb bug in vanilla 2.6.20 which I discovered [and just worked around by porting s3c2410fb from 2.6.17.14. into 2.6.20, lazy as I am]

Today, I spent much time on restructuring our u-boot patches (getting them ready for submission) and actually submitting the first nine patches to the u-boot-users mailing list.

I also spent some time on proprietary software, after a _long_ time. I'm trying to get TI's GSM Modem Firmware updater ported from Windows to Linux. Eventually I want to be able to re-flash the GSM firmware from the S3C2410 side, not involving any PC and especially not any proprietary operating system ;)

I would love to see the firmware updater going public, too - but given the nature of the GSM business, that chance is close to zero. Which is ridiculous, since it doesn't reveal anything important at all. The GSM Modem will verify the cryptographic signature of the firmware image anyway, no matter what the downloader does. But well, we have different problems to solve than to engage in endless discussions anyway...

The first peak of load on openmoko.org servers

For the last seven hours I've been trying to organize the openmoko.org server setup into providing more efficiency / performance. It was really amazing. We were not on slashdot, not on any of the major news sites, but we were already having something like 40MBps aggregate outbound traffic peaks on our servers.

The two major performance bottlenecks were ViewCVS and Mediawiki. Quickly I installed memcached on one of our more idle boxes, and put two squid instances on two separate machines in front of the mediawiki, which then seemed to do mostly fine.

The ViewCVS apparently cannot be helped at all. What I found on the web is that it's apparently just very inefficient code, and there's little one can do without rewriting the code. I don't know whether that's still the current situation, but when the next peak comes, I'll probably just disable ViewCVS to save some CPU cycles.

In case you're interested: Our setup is currently running on four physical boxes, running a total of ten OpenVZinstances. One of the machines is dedicated to the GForge installation on projects.openmoko.org, the other one a (at least intended to be) dedicated buildhost where we do our OE builds.

While this obviously has been quite enough for the last half year, we now have different performance requirements. For Phase-0 this installation is probably still quite sufficient, since this first-couple-of-days peak is bound to cease at some point.

However, When Phase-1 starts (public availability of phones to developers by means of direct order), we will definitely need a more sophisticated infrastructure for our downloads.openmoko.org site, from where we will make available the full source code that our OE builds need, plus the full source and object code of every binary release we make. The idea is to have a round-robin DNS setup of geographically distributed machines.

So as of now, we're soliciting mirrors with large disk capacity. If you want to help us by providing a mirror (expected capacity requirement for 2007: something like 300GB) and bandwidth, please contact me at laforge@openmoko.org. We're particularly interested in the US and Asia regions.

Apart from that, a couple of secondary DNS servers would also help improving our availability. If you already have a bind installation somewhere and want to become a secondary DNS for openmoko.{org,com,net}, please contact me, too.

Finally, the good news is: We're down to 2..4MBps for now. Until the news appears on major news sites, I guess.

After having discovered that mailman doesn't use templates for its listinfo_overview page (the one you get when calling /mailman/listinfo without a list name), I quickly hard-coded our openmoko header into the python code. If somebody feels motivated to add proper templating support to all mailman pages (such as the 'options password prompt' and the before-mentioned listinfo_overview), you could help us out even with something like that.

Now I'll finally turn back to actual moko code. We have frame buffer support in u-boot since two days ago (splash screens are important for marketing), I'll now look into getting the CPU clock to 266MHz (we've had some issues with this) and finally, after all, TS07.10 multiplex and gsmd infrastructure, for which I consistently haven't found time until now.

openmoko.org goes public

Today, We have added public access to

• openmoko.org
• wiki.openmoko.org
• lists.openmoko.org
• svn.openmoko.org
• svnweb.openmoko.org
• bugzilla.openmoko.org
• projects.openmoko.org

OpenMoko / Neo1973 delayed, once again

As you can read in this announcement, there will be another [slight] delay in the release schedule for OpenMoko and the Neo1973 phone.

I'm really sad and sorry about this, since the core team has been working _very_ hard for the last couple of months to get this project somewhere. However, a combination of Murphy's law, our high demands on quality at every level, communication problems and a lack of FOSS-experienced developers have made progress quite a bit slower than expected. I won't even tell you how far we are behind the original internal schedule [It's an internal schedule, after all].

For somebody like me, who has primarily worked with and in the FOSS community, even in his day by day professional career for the last decade, there have been many cultural problems in this project.

I've originally been hired to take care of the low-level aspects of the system, i.e. boot loader+kernel porting, driver development, and last but not least the GSM communication infrastructure, as well as general consulting with regard to FOSS matters.

In the end (up to now) I have been doing tons of more things. I've been doing hardware related debugging, hot-fixing and consulting, providing lots of support for our internal development team, doing all the system administration, configuration and maintenance of our four physical and about 15 virtual machines (wiki, lists, gforge, svn, build server, etc.). Today I even spent a lot of time on web related issues [hey, I haven't done much web stuff since HTML4 and CSS1 came out], since we have committed to go public with our web sites public at some point.

We've had to teach people how to use request tracker, bugzilla, subversion, mailing lists, IRC. Those basic means of communication, natural for everyone ever involved in a FOSS project are all things that we had to bootstrap here.

Many of the things that are a complete given for me (and even us, the rest of the core team consisting of Sean, Werner, Mickey and myself) are not at all known, valued and/or respected [yet] by the various people and entities we had to relate in this project.

To give you a short outline about some of the issues we have been fighting to create our vision of a truly open device, targeted by developers for developers:

So e.g. for web designers, it's hard to cope with the demand that web pages should fully scale, not have any fixed-pixel width graphics/style, not contain flash, only make careful use of javascript, and should always pass XHTML / CSS validation. We don't want 'hacks', but clean themes/styles/templates in the native drop-in format that the respective applications (mediawiki, mailman, bugzilla, gforge, etc.) support.

For source code, people who have always worked in closed-source environment, and even with a concentration on embedded 'one time throw away' devices, it is a cultural change that the source code has to be maintainable, that it has to follow coding style rules, and that it has to be "pretty", since people will read it, and it will make a bad impression if the code quality sucks.

Our code is not OK if it builds once on some system, but the applications need to use autotools or similar mechanisms, be packaged for OE use, the package description needs to be verified and debugged, and the resulting builds need to be reproducible one everyone's system.

We do not use a vendor-supplied toolchain, but rather build our own. And yes, that toolchain also needs to be built 100% from scratch, and that process has to be solid and reproducible, just like the packaging.

For the hardware, we have to provide the interfaces that usually nobody wants to give people access to (serial console, JTAG, ..). We have to make it easy for people to update their firmware, rather than hard. We have to have safeguards in hardware, since we can't prevent people to reconfigure the battery charger algorithm in software. The battery should still survive this, no matter what happens.

Preferably using hardware components with open documentation (versus "the cheapest available that does the job") is a design criteria that almost nobody in the industry will be used to.

Also, whenever we use hardware with specs under NDA (which we tried to avoid in all place, the source code has), we have to submit that code to the vendor, and ask whether it is fine to release it.

All in all, this is a quite exciting thing. Making people think different, trying to get the values of Free Software into their mind set, even if only for this project. Most of the people (as in numbers of people) involved in the development so far have not had any relation to FOSS before. They might have done Linux based development, but only because somebody asked them to get something done, cheap and quickly. But that's now what we're after.

But this process takes time, and a lot of strength. And it's hard to scale if you only have three to four people who actually have a clue about all those things. So on the one hand, we have to learn how to scale better. We have to involve more people from the community, with the FOSS/hacker background, both as paid developers and the excited volunteers. So far Sean, Werner, Mickey, and myself have been powerful but 'lonesome' fighters in the corporate world with whom we had to interact.

I'd like to express my deepest thanks to FIC for funding this endeavor that must appear like strange little experiment to them. I'd like to thank for all the support we have received from the FIC hardware and software development teams. I know we've been always very critical, and probably still seem unsatisfied with many things. But it's nonetheless a unique chance to be able to do this at all.

I've suffered a lot during the last seven months, and I've never worked as hard in my entire life, spending at least 80 hours per week on this. Despite that, if you look at the actual results, both in software and hardware (in the upcoming days), you will probably see way more things that need to be done rather than have been done. You will probably think: What, you haven't written more code in that entire time frame? All I can do is ask you to read this mail to get a grasp about what has been going on.

From now on, I hope we can lead this project more into the community. Make it like any other FOSS project. Work will be way more fun. More creative people. More cool hacks. More freedom.

Please consider this as the beginning, not the end. We're just bootstrapping the world of as-open-as-possible mobile devices. There will be much cooler devices, and there will be much cooler software. I'm honoured to be given the chance to take a leading role in this.

USB serial support in Neo1973 boot loader (u-boot)

The last two days I was adding support for USB serial (cdc_acm compatible) to u-boot for the Neo1973 phone. This is definitely a nice way to give developers access to the boot loader prompt, without having to have any special cables, the debug board, hackers lunch box or else.

Obviously, it's not the same as a real serial port. But given that you have a working u-boot in flash, and given you don't want to do boot loader development and rather concentrate on kernel/user space issues, then this definitely is a nice option.

The basic cdc_acm patch came from the handhelds.org SX1 project, so I mainly had to add a s3c2410 USB device controller driver for u-boot. Usually this is not that much of a challenge. The lack of documentation by Samsung is compensated by the handhelds.org s3c2410_udc.c kernel driver, of which by now I know every single line.

However, this one was really hard. I couldn't even get the control pipe to do all the tasks to enumerate properly on the bus. And that after having implemented the control pipe handling for a different device (OpenPCD) only half a year ago, so I basically still knew quite detailed what had to be done.

I read, and re-read, and re-read the code. Looked and verified the assembler output. At some point, I was convinced the logic of my code is correct. It must be some auxiliary issue. PLL configured wrongly, GPIO settings not right, whatever. I still couldn't find it.

After two days (one of which had 16 hours straight) it turned out that the problem wasn't actually the logic of the code, but it was pure timing. The u-boot usbdcore.c EP0 implementation had done a memcpy of 18 bytes in a code-path that turned out to be extremely time critical. Just not copying the device descriptor (which is only done for on-the-fly patching the correct EP0 packet size) everything immediately worked.

What a relief. I can finally get back to work on GSM related stuff.

Federal "Express" - One month to get a customer account

Since sending hardware to Werner Almesberger in Argentina using DHL seems to be suboptimal, I decided to give FedEx a try. So I went to their web-site, and tried to register for a customer account / number.

What struck me first, is that they require you to enter both land-line AND mobile phone number. As if everyone had both these days. I know a lot of people who either only have land-line, or mobile. And obviously there are people like myself, who would never want FedEx to contact them via mobile at all.

Anyway. What I then got back was an automatic email (in German) indicating that the respective employee is "Out of Office till 21st of February", and that "e-mails to this address will not be processed during this time".

Whew, I thought. What kind of express. It takes only three weeks to get a customer number. Maybe I should resort to UPS next. *sigh*

Informing recipients of free OpenMoko developer phones

Today [depending on the timezone maybe even yesterday], we started to inform those developers whom we have selected for the 'Phase 0', i.e. those who will receive a Neo1973 free of cost (including shipping). Those phones are scheduled to leave Taiwan on Feb. 11.

So this heads-up mail two weeks in advance is mainly to obtain shipping address, and ask whether there are any special customs related issues that need to be taken care of.

Yes, it is somewhat elitist to hand-pick people and then send them free hardware. But I don't really see a viable alternative approach for a start. Those recipients are people who are really known to contribute to the FOSS world, and of whom we think they would really like to contribute to this project.

Now some FOSS critics (or people critical of businesses engaging with FOSS) might say: Yeah, now you think the rest of your phone is developed for free. This is completely wrong.

This project is ran by people who believe in Free Software. It is from the community for the community. It is an important chance for Free Software and user freedom in this otherwise completely controlled mobile phone market.

Basically we have a hardware vendor (FIC) providing us with phone hardware, for which they

• fund to hire selected developers within the community
• provide complete hardware documentation and hardware support, even the ability to feed back hardware wish list items
• give us complete freedom where we want to take this project

Now you might still think: "In the end, they will make the profit". This is only true to a certain degree. First of all, everything we develop is Free software. Everything but the hardware specific bits could easily be run on any other piece of hardware. So anyone who wants to either contribute code or hire capable developers could theoretically port the whole thing on different hardware.

Also, while we ourselves think that this product will rock, this is really a nice market. It's interesting for geeks, hackers and certain power users. Not unlike OpenWRT in the field of wireless routers - but with active support by the hardware manufacturer.

So I personally cannot believe any of those "they just want to get development for free" arguments and want to strongly encourage the interested community to join this effort and help us make Free Software a viable alternative in the mobile phone market.

Chaos Communication Camp 2007

The date and location for the 2007 Chaos Communication Camp have been announced, which is really good news.

An OpenMoko update

As the interested reader might have noticed, a couple of days ago, the OpenMoko project has officially announced a schedule for the upcoming months.

Behind the scenes, everybody is giving his best to be able to fulfill that schedule. Anybody who has been involved in a project of this size inevitably knows that there are many problems and bugs to be resolved.

Today, for example, I was happy to be able to play back MP3 (and politically correct: Ogg/Vorbis) files for the first time on the Neo1973 phone. Those speakers can really scream loud, I can tell you!

In my part of the project, the boot loader / kernel area, there are also many bugs to be fixed. The bugzilla indicates 11 blocker bugs and five major bugs in that key area of the project that need to be resolved. The quantity might seem low, but some of them are quite generic, such as some important mechanism not working yet.

By now, we've also come up with a quite complete list of names for the 'phase 0', i.e. those guys whom we will ship a free Neo1973 device on February 11 (actually 12, since 11th is a Sunday. Hey, we're working on Sundays, only the shipping company isn't *g*).

Oh, and yes. The planet.openmoko.org is finally public. Even though there's not a lot of activity yet, expect way more in the next weeks, especially after mid-february, when we've put 50 phones into the wild :)

Getting back into netfilter/iptables work

I've been gone for long enough. Even though neither my RFID projects nor OpenMoko are anywhere close to be finished, I'm determined to get back into netfilter work again.

Started to catch up with mailing lists. There has been amazing progress, most notably the implementation of NAT for nf_conntrack, which finally should get us rid of the old ip_conntrack code in one of the upcoming kernel releases. No more support of two versions in parallel. And the ability to do IPv4 NAT and IPv6 connection tracking on the same machine. Isn't that all that we wanted? Not quite...

So for now, I'm participating in the discussions again, and I'm now also working on getting IPv6 interpreter plug-ins into ulogd2. The nfnetlink_log mechanism can happily send IPv6 packets to user space, it's just that ulogd2 doesn't yet know what to do with them. That needs to be changed.

No time to blog

Just a short ping, I have been way too busy to do even the most important things of life, let aside writing blog entries.

I am not going to write about progress of any projects, because I absolutely don't even feel like talking about my work anymore. The workload is just too high, with no real end in sight. Things keep falling apart as fast as they come together...