My place to share some bits and bytes

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.