Digging into the internals of WinCE / WinMobile

My E-TEN glofiish Linux porting efforts have made me investigate a lot of internals of the E-TEN ROM file format, WinMobile ROM files in general, XIP, Microsoft flash partition tables, imagefs and other bits and pieces.

I'm basically able to fully 'decompose' a ROM image into all its individual bits, including the pre-installed CAB's, the pre-linked DLLs in the XIP and the contents of the imagefs. And all of that on Linux, if it wasn't for the weird XPRS / SRPX compression in CE5.x imagefs. Allegedly it's the same Xpress algorithm as used e.g. in hibernation files and certain M$ network protocols, but I was trying that and didn't get anywhere. Luckily, the tools at least ran inside wine.

It's surprising how little information there is about those internals of the operating system. You can find bits and pieces in the 'ROM cooking' scene, but those are mostly HTC specific and don't always apply to E-TEN. And most of the tools that people tend to create in this community are not FOSS either :(

Anyway, once I find some time I'll probably pack/publish the stuff that I've done now. Obviously the coolest thing would be to do a GPL'd implementation of e.g. imagefs and get that into Linux. Would be fun (I've never ventured into filesystem land!), but then, it's not like I have any spare time at hands.

Last night I was trying to make sense of some of the M800 hardware drivers (sergsm.dll, keypad.dll, keybddr.dll, etc.) but it's actually quite a bit harder than I thought.

I also wrote some perl script that uses haret TRACE capability to reconstruct the I2C command/response stream. so you can basically perform any action on the device, like pushing one of the capacitive touch buttons, and see what kind of I2C communication the CPU initiates as a result. The problem with this, though: The I2C bus runs too fast, so it loses some bytes. I tried to work around it by increasing the I2C clock divider, but it seems the driver actually re-sets the divider with every transfer (rather than just once when bringing the I2C host controller up).

I'm trying to find other options (I could clock the entire system down, but then this affects things like the LCM refresh and other important clocks), since I believe a clean I2C tracer is the right thing to do.

I've also spent a bit of time on the Marvell 8686 driver, as there is already some (not entirely polished and thus not mainline yet) GSPI transport code for the libertas driver. However, I didn't finish this since it is not the biggest priority right now. Also, interestingly, the GPIO and other related bits regarding the wifi chip are all present in the winCE registry. Marvell apparently made the driver in a way that E-TEN and others don't need any access to its source code but can fully parameterize it through the registry.

So as a summary: I was spending basically every awake minute during the last days on this project, but there's no real visible progress yet. I've just learned a lot, and hope to use that information soon to further improve the Linux port.

Oh, and by the way: It seems like I'll be talking about some of this work (and actually showing how it was done) at FOSS.in 2008 next week. Stay tuned for some good old fun ;)

As with actual progress on the device itself: I've spent quite a bit today again with reverse engineering some drivers, thereby discovering two GPIO's that seem to be related to GSM modem power management. Maybe that's the reason why my own humble attempt at a Linux GSM driver has so far been unsuccessful. I also seem to find an awful lot of indication that UART0 is actually connected to the GSM modem, too. This might be some strange copy+paste artefact from older glofiish devices' linux driver, or actually they might have two independent communications channel to the modem - wouldn't be the first time to see this.

Some other bits have hinted at an externally-provided UART clock, but that is apparently just a workaround of a S3C2442 serial controller bug.

I', still having fun wading through tons of ARM disassembly. It's been a long time since I last had any good reason to use IDA (Interactive Dis-Assembler) that much. It's the only proprietary software that I've been willing to license (and thus pay for) in something like a decade.