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.

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.

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.

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.

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?

+#ifdef __ARM_NEON__
+
+int16_t fir_simd(int16_t *x, int16_t *h, unsigned taps)
+{
+       int32_t sum;
+       int16x4_t h_vec, x_vec;
+       int32x4_t result_vec;
+   unsigned i;
+   
+   /* Clear the scalar and vector sums */
+    result_vec = vdupq_n_s32(0);
+
+    h_vec = vld1_s16(h);
+    x_vec = vld1_s16(x);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);
+      
+    h_vec = vld1_s16(h + 4);
+    x_vec = vld1_s16(x + 4);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 8);
+    x_vec = vld1_s16(x + 8);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 12);
+    x_vec = vld1_s16(x + 12);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+      
+    h_vec = vld1_s16(h + 16);
+    x_vec = vld1_s16(x + 16);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 20);
+    x_vec = vld1_s16(x + 20);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+   /* Reduction operation - add each vector lane result to the sum */
+    sum = vgetq_lane_s32(result_vec, 0);
+    sum += vgetq_lane_s32(result_vec, 1);
+    sum += vgetq_lane_s32(result_vec, 2);
+    sum += vgetq_lane_s32(result_vec, 3);
+      
+   /* consume the last few data using scalar operations */
+   if(i > 24) {
+       h += 24;
+       x += 24;
+       sum += *h++ * *x++;
+       sum += *h++ * *x++;
+       sum += *h++ * *x++;
+       sum += *h * *x;
+   }
.....

I took the kernel package and patch from the Palm open source website and used a toolchain built by OpenEmbedded for the beagleboard. Using OMAP3 and armv7a should match here.

The 2.6.24 kernel package itself while renamed has the same MD5 and SHA1 sum as the original tarball from kernel.org (tar.gz, plain 2.6.24 no stable version).

The 9.5 MB patch applied fine and using the omap_sirloin_3430_defconfig as config let me compile a zImage without problems. Another developer seem to have tested a selfcompiled kernel, should match mine, already. Hopefully we can expect some updates here.

It was an interesting adventure so far. :)

I updated Harald's initial findings with some new facts and corrections. In a nutshell the device looks like this:

• Application Processor: 624MHz Marvell PXA312, probably a PXA310 with NAND
• (256MB) + DDR (128MB) in one package
• GSM/UMTS Modem: Qualcomm MSM6281, interfaced via dual-ported RAM
• Wifi: Marvell 8686 (SDIO on mmc2)
• Bluetooth: CSR 41814
• 8/16 GB external SD flash (on mmc1)
• Audio Codec / Touchscreen: Wolfson WM9713
• Screen: 240x400 pixels, 3.2"
• 5MP Sony IMX034 camera with LED flash
• Bosch Sensortec BMA020 Accelerometer
• Ambient light sensor

We have linux mainline support for the PXA312, Marvell 8686 wifi, CSR bluetooth and the WM9713 audio codec and touchscreen combination. That's a nice start. Given the fact that the device seems to be pretty near to what the Marvell zylonite reference design is doing an initial linux port should be pretty straight forward. I gave it a shot and it really worked out pretty smooth for the initial bits. Patch for inclusion just sent. I can boot into a rootfs on the microSD card with this, including working framebuffer. :)

To get more informations about a windows mobile based system Haret is the tool of choice. Naturally I used it to gather some more informations about which GPIOs are connected to what, power up and down sequences of different chips, etc. On the other hand Haret had PXA support up to PXA27x so far. That works not that bad, but the IRQ and clock register have changed a lot. Thanks to Marvell the PXA3xx data-sheet are public available. Based on that I started some initial PXA3xx support for Haret. Not finished, but helped me already a bit on understanding the Omnia system.

I also started to investigate the modem interface, which is still the primary goal here. The MSM6xxx modem chips are used in other Samsung devices and the A (for CDMA) variant is also used in the new Palm Pre. Getting support for this modem into linux would help a lot on the open phone front.

The modem is connected to one side of a dual port ram chip. The other side interfaces to the PXA SoC. Next to this we have at least one GPIO connected for power up and down. I should have found that one with haret watching GPIO changes when powering the modem on and off in windows mobile. What I don't know yet is if there are other GPIOs for out of band signaling when the ram buffers are filed, etc. Future will tell.

What blocks my work on the modem is the non-functional USB device controller. Without is I can't get a shell on the device, which makes the testing and debugging pretty hard. Getting this blocker out of my way the next big item on my list. I may also get a connector that features JTAG and serial console for the device. That would of course also helps a lot.

I like a lot what I read there. Linux Kernel, OpenEmbedded, dbus based IPC, OMAP SoC, root on SD and more. I would design it mostly the same way. Wait, I'm missing 300 develoeprs and 300 Millions vanture capital here. To bad.

Really waiting for the kernel sources. It is using a MSM6xxx based modem for CDMA and I would bet just the brother, perhaps MSM6281 like the Samsung Omnia, for the GSM variant. As I'm hacking on the Omnia right know I would of cours be interested in a kernel driver to drive the modem. On the Omnia it is connected via a dual port ram chip that interfaces to the PXA312 on the other side.

This also is kinda similar to the MSM7k SoC's that are used in the available Android phones. Just that AP, ram and BP are in the same chip here.

And the driver for the CDMA modem should also be pretty similar to the GSM variant. That gives me a little hope that maybe a driver for such a dual port ram setup will be in the Palm Pre kernel sources. Let me know if you have details here.

One feature that I wanted to have in my new notebook was a built-in 3G data card. What I got was the Ericsson F3507g. It does not only have HSPA, with 7,2 MBit down and 2,0MBit up, but also a GPS reciever on the same MiniPCIe card.

The control of the GPS is done via AT commands. For this the card offer three serial channels. Once you enabled GPS on one it will only act as NMEA channel after this. Given you have three channels the logical way was to have one for the HSPA data transfers, one for the GPS and the last one as control channel.

The basic commands for configuration and enabling the GPS can be found here. Sadly there seem to be no public documentation from Ericson on the proprietary AT commands for the GPS. Ericson, can you please offer a description or even better a datasheet for the chip it?

Anyone else can help out with more informations on this card? I'm interested in all kind of details about configuration options for the GPS.

For now I'm using the following script to handle the gps and hspa enable and disable. Not nice but working. FSO support is on the way and will get finished when I find a spare cycle for it.

#!/bin/sh

# We have /dev/ttyACM{0,1,2}
# 0 is used from wvdial for the HSPA connection
NMEADEVICE=/dev/ttyACM1
CONTROLDEVICE=/dev/ttyACM2

## Check we have appropriate permissions
if [ `whoami` != "root" ]; then
    echo Run this script as root
    exit 0
fi

init_modem() {
    echo -n "Powering up WWAN device .."
    echo 1 > /sys/devices/platform/thinkpad_acpi/wwan_enable
    while [ ! -c $CONTROLDEVICE ]; do sleep 0.5; echo -n "."; done
    echo " OK"

echo -n "Initialising WWAN modem ..."
    /usr/sbin/chat -v "" "AT+CFUN=1" "+PACSP0" "AT" "OK" > $CONTROLDEVICE < $CONTROLDEVICE
    echo " OK"
}

exit_modem() {
    echo -n "Shutting down WWAN modem ..."
    /usr/sbin/chat -v "" "AT+CFUN=4" "OK" > $CONTROLDEVICE < $CONTROLDEVICE
    echo " OK"

## Disable the WWAN hardware, save power
    echo -n "Powering down WWAN device .."
    echo 0 > /sys/devices/platform/thinkpad_acpi/wwan_enable
    while [ -c $CONTROLDEVICE ]; do sleep 0.5; echo -n "."; done
    echo " OK"
}

start_hspa() {
    echo "Starting PPP -- hit Ctrl+C when finished"
    /usr/bin/wvdial 3G
    #/usr/bin/wvdial Vodafone
}

start_gps() {
    # Enable NMEA, every 3 seconds, enable DGPS
    echo -n "Configure GPS ..."
    /usr/sbin/chat -v "" "AT*E2GPSCTL=1,3,1" "OK" > $CONTROLDEVICE < $CONTROLDEVICE
    echo " OK"

echo "Starting GPS -- hit Ctrl+C when finished"

# Fire up NMEA stream
    #/usr/sbin/chat -v "" "AT*E2GPSNPD" "FOOBAR" > $CONTROLDEVICE < $CONTROLDEVICE
    echo -en 'AT*E2GPSNPD\r\n' > $NMEADEVICE

/etc/init.d/gpsd stop
    /etc/init.d/gpsd start
}

stop_gps() {
    echo -n "Shutting down GPS..."
    /usr/sbin/chat -v "" "AT*E2GPSCTL=0,3,1" "OK" > $CONTROLDEVICE < $CONTROLDEVICE
    echo " OK"
}

case "$1" in
    hspa)
        init_modem
        start_hspa
        exit_modem
        ;;
    gps)
        init_modem
        start_gps
        # A bit hacky to wait for a ^C
        sleep 7d
        stop_gps
        exit_modem
        ;;
    both)
        init_modem
        start_gps
        start_hspa
        stop_gps
        exit_modem
        ;;
    *)
        echo "Use hspa, gps or both as param" >&2
        exit 1
        ;;
esac

exit 0