Heh. You could say I'm now among other things a professional hardware reverse engineer. This mostly started as a kid, where I always had to take everything apart. In more recent years, I've mostly been doing hardware reverse engineering as part of the gpl-violations.org effort, or projects like openezx.osmocom.org.
Now, I've actually been asked by a company to buy a device on their expense to disassemble and photograph it, to find out about the components it uses, etc. And no, before you start to wonder, I don't work for Openmoko anymore. So they are not that company ;)
The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find the pictures of the disassembly process and PCB photographs here.
As you can see, the device employs the following major components / chipsets:
- Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
- CSR4 based Bluetooth (same like Openmoko and many other devices)
- microSD slot, must be connected to S3C2442 SD/MMC controller
- WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)
- TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
- AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
- Two cameras of unknown type, must be using the S3C2442 camera interface
- Ericsson based quad-band GSM and tri-band 3.5G chipset centered around the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson has excellent public documentation on their AT-commandset for their phones. Since they are likely to use the same firmware base, the AT commandset should thus be known.
- A Xilinx CPLD
So now what does all this mean? Setting aside the CPLD and the unknown camera modules, this device (and its keyboard-enabled brother the M800) should be a very attractive target for porting Linux to it. Known SoC, wifi with driver already in mainline, GSM/3.5G modem with documented AT commands, etc.
Big question is the power management. It looks like they're using a lot of discrete regulators rather than an integrated PMU. Also, the CPLD is likely to cause a lot of trouble since neither the external connection nor the internal logic is known...