My place to share some bits and bytes

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.

Matthew Garret is blogging about the Linux based Palm Pre system.

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.

Yesterday I got my order from ipmart. Two PCB of the Motorola A1200 Ming device.

I was quite surprised as I have seen them the first time on ipmart, but thinking about it a second time and taking the device copy scene from china into account it was not surprising anymore. :)

One usecase could be to measure some connections you are not able to with all the ICs mounted. Given the knowledge, 2.4 source code and our patches for 2.6 we already have for this device it will be more of an collector's item.

It was interesting and exhausting. Zecke joined Harald and meon saturday and sunday. I must say it is a real pleasure to work with them. Harald already blogged about it and I send a mail to the mailling list, subscribe now!, with some more infos.

I really hoped for modem communication during the weekend. That did not happen, but we start to get a real good understanding how the system works. We documented all the dirty details in the wiki.

Wish us look, or better help us, to get get the modem working soon. Then it is finally time to poke the rest of the FSO team to support it as a target device.

Waiting at the train station for my train to Berlin. I'm going to stay at Harald's place over the weekend to work together on the gnuffish project.

The main focus is to get the modem communication working. We are pretty sure that we understand how the modem is connected and how it is supposed to get driven. Even better Harald already wrote a driver for it. SPI slave part, linux tty layer integration, state machine it is all there. Still after nights and days debugging it we still not have it working.

This turns out into a major blocker now. Without the modem communication we can't start serious FSO integration and if the progress on this stalls to long it will be doomed as yet another project that may still make fun, but would not get the momentum it deserves, hardware is no longer available and so forth.

So we hope to get some progress with a high motivated face-to-face meeting over the weekend. We will send out a status afterwards. Stay tuned.

That's a question which is coming into my mind not that seldom. Today it came to me while I'm playing with a G1 in a local t-mobile store. Snappy user interface, all hardware features I want and feeling like a real product.

It's the user in me screaming for one of this fancy new smartphones. Get one and be happy. It's the 'I want to believe' [1] factor that let me think that Apple's iPhone or Google's G1 are exactly the phone I need.

Starting to get into a rush buying this new toy my other alter ego shows up. The tinkerer. These guy that ask inconvenient questions like what to do when I reach the end of the supported features? Neither the iPhone nor the G1 seem to support dial up or network connection via bluetooth. Damn tinkerer, life could be that easy. Still he has a valid point. Not having such a thing on the product spec is fine with me. There is always something that you have to scratch for a polished product.

But things like this are showing me the trouble I always get when trying to use these non-open devices. I step back then and think that my Freerunner, main phone since FSO MS4, may not be my taste in ID and needs a lot more work from the software side, but it gives me the freedom I want.

The Android dev phone 1 (aka unlocked G1) could be an option to work with FSO on it as it allows to flash unsigned images unlike the G1 from t-mobile. But a quick research turns up 600USD as cost for it. (400 the device, 180 shipping to germany and 25 developer registration fee. lol). Not an amount I'm willing to pay and then also invest time in working on it.

[1] Book recommendation: Neal Stephenson, In the beginning was the commandline http://nealstephenson.com/command/