My place to share some bits and bytes

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 EXPORTSYMBOLGPL() 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 callstarted and callended and more.

Interested piece of information we just stumpled over is that the pulseaudio patch for the Palm Pre does contain a resampler module using the NEON support of the OMAP device. Strange to read, but should give them a good performance:

+#ifdef __ARM_NEON__
+
+#include 
+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 just did a test compile of the Palm Pre kernel using the released sources. Worked out fine. At least the patching and compiling, no real tests without the hardware.

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

Next week I will spent the better part of the week at the LinuxTag. I did not submit a talk this year and I will try to spent my time on hacking and relaxing. :)

There will be a table for linux on smartphone people in the dev center. People from various projects are planning to hang out there and do some hacking. I for my part will bring my phone collection and will hopefully spent most of these four days on getting something more working on them.

As the LinuxTag is an international event a thought jumped into my mind. I'm interested in the new Palm Pre. Especially in the hardware and the lower level parts. Anybody coming to the event who has such a device? If yes, please make sure you grab me and we can have a talk. I would like to see the device and maybe gather some informations on the device itself via a root shell. :)

Due to some money constraints I will not be able to buy one right now. (Yeah, I know it's CDMA and I'm not able to use it here in germany as a phone, still I believe that if we want to work with this device we should do so as early as possible and there is enough to do before the GSM version will get released). Anyway, LinuxTag may be an event where people with such a device are around. :)

Yesterday night I discovered that Palm had released the open source packages used in the WebOS for the current Palm Pre device. The table shows the used open source packages, a link to the original tarball and a tarball or compressed single patch with the changes Palm made, if any.

Most interesting for me was of course the changes to the kernel. (Being more interested in the actual device running linux already then in the WebOS software, even if I like a lot what I have seen and read so far.)

The kernel, version 2.6.24, is one of the packages where only one big patch is available against the original source package. Tiny 9.5 MB in size.

Next to the code they need for their hardware they also have things like KGDB and as it seems a big OMAP patchset from TI inside. Makes sense as the OMAP3 in .24 would have not been that good. It improved a lot over the last months, but I have no idea if Palm favours a kernel upgrade for newer WebOS releases.

The defconfig given in the patch matches the /proc/config.gz on the device. Only two variables for OE build tracking, CONFIGOEBUILDINFO and CONFIGOEBUILDINFOSTRING, are added on the device. The device was codenamed sirloin it seems. Defconfig is available as omapsirloin3430defconfig.

As the hardware is already known for the device I will not go into the details here. On thing I hoped for was that the MSM modem may be connected to a dual port ram so it matches the setup I have on the Samsung Omnia here. Sadly it turned out they use a combination of UART and USB.

I continue my work on different phones and phone platforms. Last monday I received a Samsung SGH-i900 Omnia device for some initial Linux hacking and especially trying to figure out how the modem interface is working.

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.