These days, I find myself hacking, reverse engineering, whatever, several mobile devices that run Windows Mobile. A really great tool that I've started using is called
HaRET (Handset Reverse Engineering Tool). In most, it's necessary to get terminal access to them in order to perform low-level debugging. Sometimes, a mobile device will have Linux USB OTG support without any hassle, and I can use the g_ether kernel module to bring up usb0 as a network device at boot time, assigning a static IP address. Then, by using usbnet and other kernel modules on my workstation, I am able to communicate to the mobile device using telnet or ssh. Great!
However, in many cases, USB OTG does not work "out of the box". Furthermore, given that the LCD rarely ever works "out of the box", that leaves me with very few options for getting any type of feedback from the mobile device at all, aside from maybe generating morse code with the vibration unit - that's a joke... please believe me.
It's very necessary to have terminal access, or ICE access, to perform low-level debugging when porting Linux to a new mobile device. One option is to find unpopulated pads on the PCB, where a UART has possibly had pins brought out, and to solder some wires directly to those pads and create the appropriate level-shifter circuit, attaching an RS232 cable to the workstation. Another possibility is to use the JTAG port. In some cases, neither of those options will work because either a) the pins have not been brought out, or b) the JTAG port has been fused (See my previous opinions on
Fusing the JTAG port). In many cases, there is a debug port on the board, with an unpopulated header. Finding the appropriate header and FPC cable is sometimes possible, but in many cases it's like looking for a needle in a haystack. Luckily, I found that needle in my last reverse engineering project, and
fabricated a small PCB to bring out the pins of the
FFC connected to the UARTS of the embedded device.
When I don't find that needle, then I'm left having to do some very creative reverse engineering. My suggestion: Why not build a small daemon into the kernel that would actually bring up the system console over bluetooth? Most, if not all, mobile devices manufactured in the last decade have bluetooth hardware directly connected to one of the UARTS. I can't imagine that it would be terribly difficult to build something like this into the kernel. My only main concern would be missing valuable information that the Linux kernel spits out at boot time. To counter that, I would probably introduce a "consoledelay" boot parameter, that functioned much like the "rootdelay" boot parameter. Such a boot parameter would allow the underlying hardware of the console to initialize before performing any IO on it.
If anyone feels like funding me to build this into the kernel, I am very open to suggestions :)
So I wrote Motorola recently to see if they would like to cooperate in my effort to port Linux and Android to the Q9h, and although a couple of engineers on the motodev site seemed enthusiastic, I still haven't heard any kind of definitive reply.
