My place to share some bits and bytes

The title says it all. I just released the first dfu-util release to the public. Please test it and package it for your distro. :)

We are making good progress towards a first release of dfu-util. Harald was kind enough to prepare a subdomain for it under gnumonks.org and I already setup a simple website, a git repo with the complete svn history imported and pushed out a release candidate for 0.1.

If no show-stopper crosses my way I will make the release Sunday 2010-05-23. Once this is done I will try to make sure that this release replaces the various svn snapshots distros have already packaged while waiting for a real release.

This is of course only the first step. On my agenda is better support for other hardware, more DFU 1.0 compliance and support for the changes from DFU 1.1. Next to this improvements I'm also thinking about the ecosystem around DFU on embedded linux systems. Getting the DFU u-boot patches fixed and merged would be a nice target as well. Be warned though that this will progress slowly as it is just one of my spare time projects and has to compete with others.

Until recently I had not much interest to play with the low-rate wireless personal area networks, thats what the formal description of 802.15.4 is. Often it is also referenced as ZigBee, but while Zigbee is based on it it adds some more layers on top which I'm not going to play with.

The main reason why I so far had not much interest in 802.15.4 is that it was almost always used in small micro-controller based systems. While I understand that for low power consumption products like sensor network nodes it is the right approach I never felt like I would enjoy to work on such systems.

In my study thesis I'm doing right now I have to get delay tolerant networking working over a 802.15.4 link. For this I'm using a setup with two iMote2 boards which are based on a powerful PXA27x SoC and are able to run linux. The linux port of the board was already in a really good shape and already included in the mainline kernel which gave me a good base to work from.

On the board is a Chipcon CC2420 802.15.4 RF transceiver which connected over SPI with some additional GPIO and IRQ lines. The linux kernel already is prepared with a 802.15.4 stack and luckily there was already posted a driver for the cc2420 which I had to bug fix it a bit over the last weeks. All my changes are already in, or on the way to, the linux zigbee tree which contains the mac802154 layer for the driver. This layer had not made its way upstream yet, but I hope that will happen within the next 2 or 3 release cycles. Next step on my agenda is to make it work with ibrdtn.

Last week I finished the contract work for the angular rate drivers I mentioned in my last post.

During the final meeting we also verified that the output of the sensors are what we expect them to be. While coding them I was able to check that I'm using the right registers, values are changing when I turn the device, but I had no test equipment to see if the measurement is really correct.

At the DLR we could use an angular rate table for this. The device itself was mounted on the rotating table with power and data connection on sliding contacts. Some pictures of the setup can be found here.

From the measurement point the MLX90609 and the SAR100 variant we used are quite different. The MLX is capable of 300 degree per second while the SAR100 was able to measure 1500. In our test we even had good results with 1800. During this testing we found a bit different offsets as described in the data sheets but still pretty close to what we expected.

I'm really looking forward to the launch of the rocket to hear about the results the sensors produced and how it compares to the big money equipment that it used for the flight control of the rocket. Once the rocket is back and the data is analyzed I also should be able to get a board back and do my part on getting the drivers into mainline. For now I have posted them as demo to the openmoko kernel list.

In May last year the Freerunner had its debut in outer space. The Mobile Rocket Base department of the German Aerospace Center launched a research rocket into the aerospace (140Km height). On board was the pictured Freerunner. Although the metal case you can see on the picture is new and was not used.

The mission of the rocket was to experiment with materials physics under conditions of weightlessness. The Freerunner had nothing to do with this experiments and was only on board to verify that it survives the launch, travel and landing. Battery, GSM and GPS antenna has been removed before launch. Everything survived. During the flight the accelerometers have been used to collect measurements.

In May this year it will enjoy its second trip into space. The case was designed and build to offer space for the Freerunner as well as an extension board connected to it. The board is connected to the debug board connector of the Freerunner which offers a SPI and an I2C bus. It was designed to hold different sensors the Freerunner does not offer and is equipped with a BMP085 pressure sensor and two gyroscopes. The Melexis MLX90609 and the Sensonor SAR100.

Over the next month I'll working on drivers for these two gyroscopes and after the flight we will see if the chips survived and if the data they had produced will show that they are good enough for further testing.

All in all this shows pretty nicely how an open device with available schematics, CAD files and hardware interfaces can serve together with an open software stack for vertical markets. Be it for research purpose like in this case or a crazy business idea on the other side. The fact that you have all resources to understand the electrical design as well as being able to make changes over the complete software stack brings you into the position to easily adapt it for your needs.

Some more picture with a higher resolution can be found here.

UPDATE: Fix typos and rewrite some parts so people have a chance to understand it.

Today I got informed that Palm has released the source code of the DSP bridge on the Palm Pre. This kernel module is used for communication with the DSP on the OMAP3 the Pre is based on.

It was written by TI and is available under the GPL elsewhere, but we heard that Palm did a lot modifications we would a) like to know about and b) having them available when recompiling the module to keep the original userspace working.

The only outstanding issue now from the kernel side is the wifi driver. The module itself states that it is licenced under the GPL, but Palm claims that they licenced it from Marvel under a proprietary licence and will change the module licence accordingly. If the module will still work then has to be seen. (Hint, it will not if the driver uses any EXPORT_SYMBOL_GPL() symbols).

Anyway, its nice to see that at least one part is done now. Greg KH, Simon Busch, Harald Welte and myself have been in contact with Palm for this quite some time already for this issue.

Over a year ago I wrote a mail to LKML asking about Linux support for the turbo memory controller. All I got was silence.

It really should not be more then a NAND flash controller with the flash attached to it. I wonder what the problem is here. Neither the really active kernel hackers form the Intel Open Source Labs are giving any comment on it nor is any kind of documentation available for it. At least none that I was able to find.

I'm well aware that it is marketed as Windows Vista, and now Windows 7, only, but to be frank, its hardware. There is no technical limitation to write a driver for it.

Given that I heard once that Intel has a great rule in place that there needs to be a good reason if no GPL driver is available for Intel hardware I wonder what is the blocker here. If it is no technical reason it must be something else. A completely wild guess would be that Microsoft is paying for the exclusive rights and active harm of other systems. I thought we were behind such things. Anyone knows more and wants to enlighten me?

FOSS.IN 2009 is over and I'm sitting on the airport waiting for the first flight on my way home. Time for a small wrap-up.

Both of my talks went ok I think, but its always hard to judge on your own talks. People were asking questions directly after and also over the next days. This kind of interest is all you can ask for as a speaker. :)

It was not only my first FOSS.IN but also my first visit in India at all. A new country, a new culture and a lot of things I need to think about is all I can say about it right now. I like it thats sure.

The format of not only advocating on FOSS, but understanding and embracing it as well as the technology around it is something I could not agree more with. It is this kind of understanding which makes innovation possible. Think about technology and products not only the way the company selling it likes you to. Open up your mind and think how else it can be used for something better.

Let me finish with a big thank you for the complete FOSS.IN team. They did a great job in getting a high-class conference going and bringing people together to collaborate and inspire. Their hospitality and energy needs to be seen somewhere else.

Tomorrow I'm leaving for FOSS.IN, Bengaluru. Oman Air decided to squeeze in another stop between Frankfurt and Muscat means I have a 2.5h longer trip. But back to the topic.

I'm going there to participate. In contrast to other conferences you are not going there to consume a show prepared for you. You are going there to really participate, hack some code in the hackcenter, enrich the workouts with your energy to get something done, give a talk to motivate people and work with them.

This year they are also integrating the hacker mindset a bit more. This always have been near to the FOSS mindset but still different. Personally I welcome this step. The game like nature of the hacker mindset playing with technology in ways they have not been designed for opens up a complete new horizon for the FOSS community.

The only pity is that I won't see much from Bengaluru due to the day and night participation.

I got myself a Palm Pre as they started selling them in Germany. Turns out that we already hacking nine days on it now.

From a FSO perspective we set ourself the challenge to get a GSM voice call working with FSO within a month. Since then we have done a lot of research on different topics of the system.

Since the third day I'm running my own kernel on the device. Build from a 2.6.24 vanilla kernel with the patch from Palm applied. They are using standard uImages in a /boot partition directly on the eMMC card. Changing which kernel will be booted by default is as easy as changing a symlink. And for recovery you always have the bootloader which you can enter by holding down the volume up key when putting in the USB cable into a powered off device.

After this we spent most of the time oin researching how the communication with UMTS/GSM modem is working and how we need to handle the audio routing for different scenarios. It turns out that the Qualcomm modem is offers his service over a high speed UART to the OMAP3430 as well as over USB. The USB ports show up as ttyACM0 and ttyACM1, but there are plenty of changes in the kernel usb-acm driver which have not been investigated yet. The second acm port is used for diagnose purpose and we ignored him for now. The first port is what pppd connects to for the WAN connection. It speaks plain AT, but sadly does not report +CRING on incoming calls. So we mostly concentrated on the UART port. No luck on plain AT here. Its an own protocol which seems to be based rfc1662 (with HDLC). The research here is ongoing but we are able to strace the telephony daemon on the palm system to gather all bytes that flow from and to the UART. So far we have the packet end signature, esacpinf sequences, CRC16 checksum working and also discovered different sequences which should be sync, sync response, config, etc.

On the audio soide we also had some progress today. I was always looking for an ASoC or pulseaudio way the would switch to an actual call, but it turned out they do it completely different. Pulseaudio is used for different sinks where applications can put there sounds in which then may have different priorities. The lower layer for voice calls is actually handled in the twl4030 audio driver part in an "interesting" way. Over a sysfs file you can create so called scripts which then are hold inside a list in the driver and get executed when called up with the right script name being written into another sysfs file. Among these scripts are call_started and call_ended and more.