More A780 hacking

Today was a very exciting day of more A780 hacking. You know, from time to time it's quite good to do something else than stupid netfilter development or the like ;)

So what I've been able to do? Well, I analyzed most of the device drivers from userspace side. I now know the key-codes of every keypad or other button/wheel/dial on the device, I know the touch screen and framebuffer. I can control the three different backlights.

Then I've learned a bit more about the architecture of the phone. The Xscale processor (PXA270 Bulverde) actually uses USB to talk to the Neptune chip. Neptune is a DSP with a synthesized ARM7TDMI on-chip. The PXA270 runs in host mode, the Neptune in device mode.

Interestingly, the Motorola developers have debugging callbacks in the stock kernel. So by registering a simple kernel module with the USB rx/tx functions, I now have hexdumps of the USB traffic between those two chips (also called AP and BP).

Then I called the a780, and I immediately received some nice hexdumps in the kernel ring buffer. The first thing I could spot was "IP: "+4930xxxxxxxx",1\r\n". There it was, the incoming phone number :)

Some other nice guy at motorolafans.com has managed to replace the proprietary userspace Bluetooth code with the stock Linux BlueZ codebase. He's working on Bluetooth keyboard support... that would really be nice. Using a Bluetooth keyboard with the Qonsole terminal emulator (or even a framebuffer console) of your phone :)

I'm really confident that the AP<->BP protocol can be worked out fairly quickly. Once this is done, we can start developing our own "phone" programs, and get rid of all the bloated embeddedQT and Java crap that is running on the phone. It has 48MB of physical ram, and the database daemon has a resident size of 2.7MB, the address book 4.5MB, the "phone" program has 6.6MB. This is really ridiculous...

At the end of the road, I'm dreaming of something small and efficient, running uClibc, busybox, DirectFB, ...

The USB device port of the device is called "Extended Mini USB (EMU)", because it apparently can be switched in more than half a dozen of different modes (by assigning various pull-up/pull-down resistors). Apart from a USB device, it can for example run a UART on that port. However, since the USB host port is already used for Bulverde<->Neptune communication, I don't think it is possible to run the phone in USB host mode. This basically rules out attaching a stock 802.11 wifi USB adapter, which is very sad.