Linux on HD2: the beginning

Ever since I owned my HD2, I wanted to hack it and try and get Linux on it. Just like I helped to get it started on the Raphael, even though I had to drop out early due to lack of time unfortunately. I tried to uphold my famous way of debugging using the flashlight led at the back of the device. Like, boot the linux kernel, and when the led goes on, I know it reached that specific code. Then I can recompile and see if I get any further. It's poor mans debugging, but I love it. I sorted out some of the code to do this and put it on the appropriate wiki page.

HaRET bootloader
Before being able to continue at all, the bootloader had to be updated with support for the QSD8x50 SoC. Luckily a patch for u-boot was already present at codeaurora which adds support for the QSD8x50, so that could be used. Also, the core of the QSD8x50 is a Cortex-A8, which is partially documented on the ARM website here. The patches I applied to HaRET can be found at the HaRET git repository.

QSD8x50 support in codeaurora git tree
After fixing HaRET I tried to use the kernel in the codeaurora git tree, but it didn't really cooperate that well. At first all attempts failed. I compiled a kernel and couldn't even get into the very first instruction which is executed by the kernel. The only thing before the entry point of the kernel, is the decompression routine which is prepended to zImage images. And there I won a price, as the using the uncompressed Image did execute my famous flashled code. The flashled turned on which indicated it got to the code in the kernel. After quite a while of searching and playing, I found that there is an instruction which is not ARMv7 compatible: "mcr p15, 0, r10, c7, c14, 0". It should be a perfectly sane operation (to clean and invalidate the D-cache on Cortex-A8 processors), but causes an invalid instruction exception on the processor in my HD2. After fixing this to ", 2" at the end (which isn't entirely the same, but gets the job done), the decompression routine worked as well.

The next problem was that the kernel didn't boot up to iomapping. Something went wrong before that. This is however a problem for my poor mans debugging. As soon as the MMU (memory mapping unit) is enabled, I cannot access the physical memory addresses to switch on my flashled. I have to wait until after the iomapping is done before I can use the virtual address to access the hardware for the led again. As it hang between these things, I tried really a lot of things (without going too deep, i.e. I still don't know how to iomap() phsyical => virtual memory using assembly) but eventually decided to wait until a better kernel tree was available for the QSD8x50.

Patching the Nexus One kernel
And soon after that, the Nexus One was announced by Google and its kernel was made available. Without making a really long story again like above, I had to patch a few things to get this to work:

• irq.c was patched to not enable the INT_DEBUG_TIMER_EXP (enabling this interrupt causes the device to hang)
• timer.c was modified not to use this timer (the first mdelay() called would hang the device as the interrupt gets enabled)
• board-mahimahi.c was used for testing purposes, stripped it from most drivers and init code and replaced it (the mahimahi = Nexus One)
• io.c and msm_iomap.h were modified to make MDP available for htc_fb_console (which I borrowed and modified from the Raphael linux project)
• htc_fb_console was added and modified to work on the HD2

Summing this up like this makes it sound like it was a piece of cake, but it took me quite some time. I'm not a seasoned linux kernel developer, but I like the challenge on this.

For now, this is where I'm at! Awesome, right?

To other developers! Don't worry, a git repository will be setup soon. When there's more info about that, I'll put it here too.