Glofiish M800 GSM/UMTS Modem interface reverse engineered

During my seven hour stopover in Bangalore, I decided not to sleep and rather have a look about what I could do to find out more about the yet-unknown interface between the S3C2442B application processor and the 3.5G Modem in the E-TEN Glofiish M800.

Some initial poking in the WM6.1 registry led me to the (wrong) conclusion that UART0 might be used. It would have been a lot of data for a UART anyway...

So as it seems, they're using a SPI based interface. Not a bad choice, considering the various suboptimal alternatives. USB is way too heavyweight and power-consuming, and leads to inevitable problems when you want to resume the application processor from suspend (e.g. on incoming call). You just simply cannot afford the time to enumerate the USB, etc. Some shared memory / dual ported RAM interface like it is found in more integrated chipsets requires quite a bit of software work (synchronization of a shared memory region between two processors that have no common resources!) and requires a quite deep interface into the modem side. Something that E-TEN would unlikely get from Ericsson, I would say.

So SPI it is. Interestingly, the SPI master is in the modem, the S3C2442 acts as SPI slave. This adds the need for some kind of mechanism how the application processor can tell the modem that it actually wants to transmit an AT command. A simple GPIO line does that trick. The Modem responds by asserting the slave select line.

Interestingly, they even use DMA accelerated data transfers. So receiving data from the modem is less CPU intensive than reading data from NAND. What a crazy world.

Some more bits are found in the wiki.

I've already started to hack up a Linux driver. The SPI side is really simple. What is much harder is the fact that the Linux SPI core has no support for slave mode, and thus neither the in-kernel s3c24xx SPI driver. Furthermore, many of the traditional serial line analogies (baud rate, modem control lines, handshake, break, ...) no longer apply.

On top of the SPI, they seem to be running pretty standard AT commands. Nothing fancy at all. Thus, I'm optimistic that once the kernel driver is there, FSO or other userland can make use of it quite easily.