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.

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.

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.