HaRET and linux on HD2 update

It's been a week since the last update, which is a while in software land. It seemed appropriate to give you guys an update, even though there's not been much progress.

First things first. I've already mentioned I updated HaRET with support for the QSD8x50 SoC which can be found in our beloved HD2 devices. I've updated HaRET with two new commands, the SETBITP and SETBITV which makes it easier for me to play with GPIOs. There are probably other uses for it too. Let me know what you find it useful for. You can find the source in git and look here for the latest binary for HaRET.

Regarding Linux on the HD2, there's not been much progress. Besides having lots of other stuff to do, I first wanted to get the graphical driver to work, msm_fb. However I've been running into problems with the MDP driver, which is needed for the msm_fb. The interrupt handler causes a problem, which results in the device having to handle a bad interrupt. As the MDP interrupts are very frequent, this must be solved first. I've been given some ideas by cr2 to check out, one of which is that this caused problems on the Raphael as well. So I should be able to learn from that. Also codeaurora has some patches which could be useful to check out.

If this MDP stuff drags on for too long, I might skip it temporarily and check out usb, sdcard and other things first. I'm someone that loves to see progress, and not just get stuck on something.

Some of you have volunteered to test kernels. As of yet I don't see the neccessity for it yet. When there are proper kernel builds, which actually do something useful, there'll be test versions out.

That aside, if you're a developer, you can of course help by checking out the sources and giving it a go yourself and sharing your results. Once a git is up with my changes so far (I know, it's taking a while already), that'd be a nice starting point. Also you're welcome to join #htc-linux on freenode.

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.