FOSS.out 2008

FOSS.in 2008 is over. The grand finale was Kalyan Varma's closing keynote on how he thinks fundamental FOSS principles are present in all aspects of his work and life, even in areas completely unrelated to FOSS such as photography and wildlife conversation.

I could not agree more to what he said. Fundamentally it is about being curious, learning how things work, cooperating with other people with mutual benefit, etc. - as I have to some extent outlined in one of my previous blog posts about reverse engineering.

One particular spin was also on Security. Having an IT security background like him, with a pretty similar FOSS culture background, I can perfectly understand and support his point of view.

As for FOSS.in, I think it could also not have been much better. Biggest constraints were probably the conference venue itself. Its lecture halls inevitably create a big divide between a small number of entertainers on the stage and a big auditorium. There also was a constant and severe lack of power outlets at any given time or place - to some extent again a problem with the venue.

Thanks to the Organizers, Team FOSS.in and the Volunteers. Well Done.

Update from FOSS.in

First of all, many people have asked for the slides of my presentations. You can get the keynote slides and the glofiish reverse engineering slides from the FOSS.in website now.

Giving the latter talk, I was really surprised that nobody in the audience raised their hands when I was asking who had ever done reverse engineering of any sort. I cannot really imagine any of my work, both in the FOSS community as well as professionally without using whatever means to discover how things (devices, drivers, software) work. Isn't it a most natural human trait? You discover something new, and you want to learn how it works. So you take it apart, learn about its components and understand how the individual parts play together.

I've been doing this with about everything I ever got, even as a kid. Stereo system, reel-to-reel tape recorder, my first 286 based PC, my first motorbike, car, etc. It's simply not acceptable to be in possession of some technical device without understanding how _exactly_ it works.

So anyway, I hope the talk was at least a bit inspirational and makes some people try. It is not so much important that you actually fully manage to reach the goal (like in my case getting a full-blown Linux implementation of all the drivers done, etc.). The importance is the process, and what you learn while doing it.

So today I was mostly busy preparing and holding that talk, later at night I was back to working on gsm-tvoid. I'll cover this in a separate post.

The first two days of FOSS.in over

I've been having the pleasure of holding the opening keynote at FOSS.in, where I've been (again) using the opportunity to point out the sad situation of Linux in the Embedded space. I think it was good to get this message not only to the CE Linux Conference Europe attendees, but also to the various FOSS interested Indian developers. Many of those work for companies involved in chipsets for Embedded devices, Embedded Systems development or even BSP development.

Despite that very sad/depressing conference opener, the feedback was overall very positive. Some people mentioned "it was like if you were talking to me personally". So let's see if this kind of grass-roots FOSS lobbying can help to make a bit of a change in those Embedded Linux companies.

After the keynote I was more or less immediately starting my WorkOut on improving Free Software based GSM protocol analysis. Basically we're looking at GSM-tvoid, gssm, gsmdecode, the wireshark patch of gssm, etc. and coming up with a much improved solution.

So far we've added the tun-device support from gssm to gsm-tvoid, but that's only a kludge and a temporary solution. Adding fake Ethernet headers to a GSM Um frame and using a non-registered Ethernet protocol type is not really the kind of "implementation quality" that I'd like to see.

So now I've come up with a 'gsmtap header' similar to what 802.11 solves by the radiotap header. gsm frames including radiotap header can be stored directly as a new linktype in PCAP files, or they can be sent via UDP packets through the regular IP and networking stack, where wireshark can just grab them using the normal network devices.

We've continued to work on those issues on the second day of FOSS.in, and we'll also continue to work on it today. Tomorrow I'll be presenting on my gnufiish project, i.e. the reverse engineering and Linux port plus driver development for the E-TEN glofiish X800/M800 devices.

I personally can't really say yet how well the concept of WorkOuts has worked-out in practise. I really need to learn more about the progress that the other workouts have been making. I think at least for the GSM workout, there were not many people who had the skills or knowledge about the protocols and/or the tools involved - which is not a big surprise. But I'd hope that some of the attendees at least got interested in the subject and will contribute to the respective projects. There are many things to be done, including the somewhat tedious exercise of adding dozens and dozens of new dissector code to wireshark. If anyone else (preferably with some generic understanding about network protocols and wireshark dissectors) wants to help with that, please contact me.

From FreedomHEC Taipei to FOSS.in / Linux and the Taiwanese Hardware Industry

I'm on my way from Taipei to Bangalore, from FreedomHEC Taipei to FOSS.in. Two very different events in two very different countries with a quite different IT industry.

I was really happy about FreedomHEC. It is really about time that the Linux world and the Taiwan-based chipset vendors and system integrators start much more interaction. It is a simple economic fact that A lot of hardware development, both in the PC mainboard, Laptop as well as the embedded device space happens in Taiwan. It is also very true, that for whatever reason the gradual Linux revolution in the server and desktop market in the EU, the US and other markets such as Southern America has not really reached Taiwan. At least from all the various contacts that I've made in Taiwan, there are almost no Linux users, and particularly not in a corporate environment.

My experience in Germany shows that many small and medium sized companies, as well as a noteworthy part of public administration is using Linux, at least on the server side, and to an increasing amount on the desktop side. Many end users have dual-booting machines. Plus, the universities and particularly the computer science departments have a long UNIX-related tradition - and most SunOS and Solaris workstations have since been replaced by Linux based systems, or at least systems with dual-boot configurations.

If my completely non-representative assessment of the Situation in Taiwan is true, then we just don't see this level of adoption there. And this has a quite big impact:

• Managers and Engineers underestimate the amount of Linux adoptions in their target markets, since they don't see that much adoption in their domestic market
• Even if there is a [customer] demand for Linux, the Taiwanese hardware industry has a hard time to properly respond to this demand due to the lack of know-how about Linux and FOSS - both technology-wise, but also regarding the development model
• There are very few system administrators or software developers with a profound Linux user experience. How are you supposed to administrate or develop for a system that you haven't at least used for a couple of years?

So as a result of this, I argue that Linux hardware support world wide suffers from the lack of recognition of Linux in Taiwan.

This needs to change. Recent developments like the Asus eeePC or Linux-based Netbooks in general are not a solution either. They don't mean that Asus suddenly cares about how well e.g. the Linux ACPI implementation interacts with the ACPI BIOS of their non-eeePC Laptops.

I think any system integrator who understands those facts will likely gain a lot of trust and customer satisfaction. We yet have to see _any_ laptop or mainboard manufacturer who goes public and says "we will test our systems with Linux like we test them with Windows".

Non-Taiwanese system integrators like Dell or HP have a competitive advantage here. They do understand much better what Linux is, and how to work with it - even though mostly still on the Server side. You will find Linux-based BIOS update tools. You will see ACPI BIOSes that actually work properly and don't just contain random bytes in those parts that Windows doesn't currently use.

Why not Acer? Why not Asus? Why not MSI? Why not Foxconn? How much of a R&D investment is it really to do even the most minimal testing like booting some Linux Live Distribution from CD and checking if the major features are working? I would assume in the total Laptop R&D cost, it's less than 1%. So if only 1% of the customers will install Linux, it should already be justified.

Especially right now, nobody has really made the first step. Anyone who starts with the right strategy can be the first one on the market. The opportunity is there. Don't wait until the competition uses it.

VIA and Openchrome; Graphics Programming Manuals

Coinciding with FreedomHEC in Taipei, VIA has announced its cooperation with OpenChrome and releases Graphics Programming Manuals.

This definitely marks a big milestone in VIA's new, much more FOSS friendly Linux support. Not only releasing the source code to VIA's own graphics driver, but actually interoperating with OpenChrome to help to create one future driver base and fight against the fragmentation of the developer and user base.

After all, there's probably no other family of GPU's where there are so many different Linux/Xorg drivers like VIA's. What a terrible waste of R&D resources to reinvent the wheel over and over again. One reason for doing that (VIA's driver being closed source) has disappeared when it was made open source a couple of months ago.

So let's hope that this cooperation will be as successful as possible, and we can have one unified driver codebase with the cumulative features of both individual drivers right now. Once that has been done, we can start to think about helping the result to get into mainline X.org and put the entire history to rest.

I also appreciate and welcome the release of the graphics programming manuals for the two most recent generations of integrated graphics chips. Sure, they are by no means as exhaustive as documentation of major competitors in the GPU market - but then, VIA is a small company and they cannot release documentation which never even existed in the first place. So please accept that VIA is working on releasing the documentation it has, but is unlikely to be able to work on creating additional documentation that doesn't even exist.

There are still some things to be done, though. We still cannot include MPEG/H.263/H.264 hardware acceleration support in the driver due to unresolved legal issues (working on that, don't worry) and there is still no open source 3D support for the Chrome9 core (VX800 chipset). But then, life would be simple if all of those problems would disappear overnight. In any case, I think VIA can now legitimately claim that it is moving in the right direction, that it is not only trying to become a much better 'Free and Open Source Citizen'.

There will be more manuals and code up for release at some point, but please excuse that I simply don't want to speak about the tentative schedule of things that haven't happened yet.

E-TEN glofiish M800 Linux tree now has public git tree and a name

You can find the git tree here and clone it from git://git.gnufiish.org/gnufiish.git. Thanks to Stefan for setting up the tree and doing the initial push (ssh+git from Taipei is so slow that it cannot finish the initial commit of a kernel Tree before the DSL modem reconnects 12 hours later).

I've called the project "gnufiish" just for the fun of it. It's quite close to the original name, and therefore a 'language hack'. Though it's obvious that there is no real official connection to the GNU project, since Linux is not part of that.

FreedomHEC Taipei 2008

As I think I've mentioned before elsewhere in this blog, in a few days there is the FreedomHEC Taipei 2008. If you're in Taiwan and are doing some Linux kernel/driver related development, you should come and meet up at this event.

Looking forward to meeting lots of [new?] Taiwanese Linux developers :)

Digging into the internals of WinCE / WinMobile

My E-TEN glofiish Linux porting efforts have made me investigate a lot of internals of the E-TEN ROM file format, WinMobile ROM files in general, XIP, Microsoft flash partition tables, imagefs and other bits and pieces.

I'm basically able to fully 'decompose' a ROM image into all its individual bits, including the pre-installed CAB's, the pre-linked DLLs in the XIP and the contents of the imagefs. And all of that on Linux, if it wasn't for the weird XPRS / SRPX compression in CE5.x imagefs. Allegedly it's the same Xpress algorithm as used e.g. in hibernation files and certain M$ network protocols, but I was trying that and didn't get anywhere. Luckily, the tools at least ran inside wine.

It's surprising how little information there is about those internals of the operating system. You can find bits and pieces in the 'ROM cooking' scene, but those are mostly HTC specific and don't always apply to E-TEN. And most of the tools that people tend to create in this community are not FOSS either :(

Anyway, once I find some time I'll probably pack/publish the stuff that I've done now. Obviously the coolest thing would be to do a GPL'd implementation of e.g. imagefs and get that into Linux. Would be fun (I've never ventured into filesystem land!), but then, it's not like I have any spare time at hands.

Last night I was trying to make sense of some of the M800 hardware drivers (sergsm.dll, keypad.dll, keybddr.dll, etc.) but it's actually quite a bit harder than I thought.

I also wrote some perl script that uses haret TRACE capability to reconstruct the I2C command/response stream. so you can basically perform any action on the device, like pushing one of the capacitive touch buttons, and see what kind of I2C communication the CPU initiates as a result. The problem with this, though: The I2C bus runs too fast, so it loses some bytes. I tried to work around it by increasing the I2C clock divider, but it seems the driver actually re-sets the divider with every transfer (rather than just once when bringing the I2C host controller up).

I'm trying to find other options (I could clock the entire system down, but then this affects things like the LCM refresh and other important clocks), since I believe a clean I2C tracer is the right thing to do.

I've also spent a bit of time on the Marvell 8686 driver, as there is already some (not entirely polished and thus not mainline yet) GSPI transport code for the libertas driver. However, I didn't finish this since it is not the biggest priority right now. Also, interestingly, the GPIO and other related bits regarding the wifi chip are all present in the winCE registry. Marvell apparently made the driver in a way that E-TEN and others don't need any access to its source code but can fully parameterize it through the registry.

So as a summary: I was spending basically every awake minute during the last days on this project, but there's no real visible progress yet. I've just learned a lot, and hope to use that information soon to further improve the Linux port.

Oh, and by the way: It seems like I'll be talking about some of this work (and actually showing how it was done) at FOSS.in 2008 next week. Stay tuned for some good old fun ;)

As with actual progress on the device itself: I've spent quite a bit today again with reverse engineering some drivers, thereby discovering two GPIO's that seem to be related to GSM modem power management. Maybe that's the reason why my own humble attempt at a Linux GSM driver has so far been unsuccessful. I also seem to find an awful lot of indication that UART0 is actually connected to the GSM modem, too. This might be some strange copy+paste artefact from older glofiish devices' linux driver, or actually they might have two independent communications channel to the modem - wouldn't be the first time to see this.

Some other bits have hinted at an externally-provided UART clock, but that is apparently just a workaround of a S3C2442 serial controller bug.

I', still having fun wading through tons of ARM disassembly. It's been a long time since I last had any good reason to use IDA (Interactive Dis-Assembler) that much. It's the only proprietary software that I've been willing to license (and thus pay for) in something like a decade.

TXL-CDG-BLR-DLH-TPE

This was the route that I was taking to Taipei this time: Berlin, Paris, Bangalore, Delhi, Taipei... with 7 hours in Bangalore and 4 hours in Delhi, resulting in a total travel time of about 38 hours.

Everything went surprisingly well and I did a lot of work. However, my day/night rhythm is basically completely gone by now. Need to try to synchronize with local time.

Oh, and if you're asking yourself "why"? Because airline ticket pricing is the most ridiculous thing on this planet, even worse than stock exchange. Any more 'direct' asymmetric Germany->Taiwan->India->Germany flight would have been about three times as expensive as both a Germany->India->Germany and a India->Taiwan->India round trip ticket together.

Glofiish M800 GSM/UMTS Modem interface reverse engineered

During my seven hour stopover in Bangalore, I decided not to sleep and rather have a look about what I could do to find out more about the yet-unknown interface between the S3C2442B application processor and the 3.5G Modem in the E-TEN Glofiish M800.

Some initial poking in the WM6.1 registry led me to the (wrong) conclusion that UART0 might be used. It would have been a lot of data for a UART anyway...

So as it seems, they're using a SPI based interface. Not a bad choice, considering the various suboptimal alternatives. USB is way too heavyweight and power-consuming, and leads to inevitable problems when you want to resume the application processor from suspend (e.g. on incoming call). You just simply cannot afford the time to enumerate the USB, etc. Some shared memory / dual ported RAM interface like it is found in more integrated chipsets requires quite a bit of software work (synchronization of a shared memory region between two processors that have no common resources!) and requires a quite deep interface into the modem side. Something that E-TEN would unlikely get from Ericsson, I would say.

So SPI it is. Interestingly, the SPI master is in the modem, the S3C2442 acts as SPI slave. This adds the need for some kind of mechanism how the application processor can tell the modem that it actually wants to transmit an AT command. A simple GPIO line does that trick. The Modem responds by asserting the slave select line.

Interestingly, they even use DMA accelerated data transfers. So receiving data from the modem is less CPU intensive than reading data from NAND. What a crazy world.

Some more bits are found in the wiki.

I've already started to hack up a Linux driver. The SPI side is really simple. What is much harder is the fact that the Linux SPI core has no support for slave mode, and thus neither the in-kernel s3c24xx SPI driver. Furthermore, many of the traditional serial line analogies (baud rate, modem control lines, handshake, break, ...) no longer apply.

On top of the SPI, they seem to be running pretty standard AT commands. Nothing fancy at all. Thus, I'm optimistic that once the kernel driver is there, FSO or other userland can make use of it quite easily.

Running Linux on E-TEN glofiish M800

Ever since my blog post about certain E-TEN glofiish devices in late August, it might have been obvious that I've been up to something.

In fact, I didn't have much time, as usual. Finally, after something like about two full days of work, I can present some preliminary results:

root@glofiish-m800:/proc# cat /proc/cpuinfo 
Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 176.53

[...]

Hardware        : Glofiish M800
Revision        : 0000
Serial          : 0000000000000000
root@glofiish-m800:/proc# 

You can also find a preliminary wiki page about the current status of hardware reverse engineering in the OpenEZX wiki. It doesn't really related to EZX or OpenEZX at all, but it somehow is related to the same thing: Bringing kernel+rootfs based 100% on open source to phones without vendor support. It also doesn't really fit into the Openmoko wiki, since as you can assume, this is by no means a project of Openmoko, Inc.

So far, it was pretty easy. I was taking the 'stable' branch of the Openmoko kernel git tree, adding minimal platform support to it (to get framebuffer, microSD and USB device working), and using haret to boot into a fso-terminal-image located on a microSD card.

Of course the really hard work now starts, getting all the hardware properly supported, especially the communication with the GSM Modem, as well as the power management related bits. Nonetheless, a foundation is laid, and I expect it to be not too hard to continue from here.

So maybe, if I can find sufficient time, we will see FSO on a 3G phone at some not-too-distant point in the future.

Now some of you might be asking: Why am I not working on improving the code for the Openmoko, Inc. handsets GTA01 and GTA02? Isn't it bad to support a non-open hardware manufacturer, plus pay the Windows Mobile license tax on a device, ...? After all, Openmoko, Inc. current business model is centered around the sales of their own hardware to support for the software development!

I don't think that this is much of a competition to Openmoko. Obviously, everyone wants truly open hardware, such as what Openmoko, Inc. is trying to do. Nonetheless, people (especially geeks/nerds/hackers) want devices with 3.5G or at least 3G, they want devices with real keyboards, higher capacity batteries, better mechanical design, camera, etc. This is just something that Openmoko Inc. has not been able to provide so far. There's probably not many people on this planet who feel as sad about this fact as I do.

Next generation of OpenPICC in the works

Yesterday at a brief visit to the Chaos Computer Club Berlin, Henryk introduced me to the prototype to the next-generation OpenPICC. After co-initiating the project with Milosch and Brita some years ago, I unfortunately had to drop out of it due to time constraints. I've heard rumours about plans for a next generation OpenPICC, but now it seems like Milosch actually found some time to get it done.

The result is really the über-OpenPICC. No shortage of anything. I don't want to reveal any information that's not out in the public already. Nonetheless, I can say: Stay tuned, stay excited. It rocks!

Open source SIM card emulation, SIM card proxying: BLADOX

I've been extremely positively surprised as I recently discovered bladox, a company specializing in providing development tools and custom hardware to simulate, proxy and extend SIM cards. And not only that, they are completely based on gcc + binutils as well as their own open source software. There couldn't be any better playground to play with the SIM interface of any mobile phone.

The general idea is to put an ATMega128 in between your real SIM card and the actual SIM card slot of the GSM mobile phone. On that ATMega128, you can then do whatever you want, e.g. forward only certain commands, such as "perform GSM algorithm" to the actual SIM, and implement the rest in your microcontroller. You can obviously also implement STK applications yourself for demonstration, or you can even block all STK commands and suppress the phone from ever knowing that the SIM actually supports STK.

This is an excellent playground. And it's even sold at a very affordable price. Now if I only had more time to look into all of its exciting possibilities while not forgetting about my other tasks (and paid work) :)

Maybe there are some readers of this blog who are just as interested but didn't even know that such products (and all the example code) did actually exist. Now you know :)

German Post paper form shows HTML font tag

Something fun for a change: This morning I had one of those "you were not present when we tried to deliver something to you, please come to the post office to pick it up" cards in my mailbox.

However, as the scan of this very card shows (check for the red arrow), they inadvertently show half of a HTML FONT tag for the font "HELVETICA" on the actual printed card. I wonder how nobody could notice ;)