Linux on HD2 source code (so far)

Just a small update. I managed to get a git up a few days ago on linuxtogo.org and today I've managed to tidy up and commit the code that I have so far to this git.

I also planned on making a guide to build the kernel from scratch, but didn't get to that yet. You can take a look however at other guides for other phones, and just swap the git repository with the one linked above. Here is a guide for the Blackstone. I suggest you use the prebuilt toolchain by Google though. Otherwise you may run into compile issues regarding floating point instructions.

For a HaRET build you can check www.netripper.com/leo/

As default.txt you can use:

# MTYPE of the HTCLEO
set mtype 2524

# This is the physical location of the first memory bank
set ramaddr 0x20000000

# 224MB ram, just a guess though. Not sure how large
# the first bank is (or the second).
set ramsize 0x0E000000

# You must use "Image" instead of "zImage", as the
# decompression routine fails on the Leo!
set kernel Image

# The most important parameter is "lpj=8000000"
# here, without it, the kernel hangs during boot
# when it tries to calculate the loops per jiffie.
set cmdline "init=/init root=/dev/ram mem=64M lpj=8000000"

# Boot the image
bootlinux

Have fun!

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.

KeypadLedControl

On the forums I read a post where someone complained that the front keypad lights turn themselves off after about 10 seconds the device got out of standby. And that's correct. HTC built it with a timeout. Whenever you press a key, or the device comes out of standby, the driver turns off the keypad lights after 10 seconds. I had been used to this for ages, as HTC has always done this. However, it wasn't until this post that I thought it'd also be nice to have it always on (at least, whenever the LCD is on).

Luckily I found how to do it pretty fast. The keypad driver makes use of events to notify when the keypad light should go on. When the event is set, the keypad light stays on for 10 seconds. If the event has not been set again within that period, the light turns off.

On the HD2 the event is (by default) named "IconLedOnEvent". On any old HTC devices the event is called "IconLedEvent". When this event is created with CreateEvent(), you'll get a return message saying ERROR_ALREADY_EXISTS, which in fact isn't an error at all. In our case this means success, as someone else is using the event as well (the driver!). Calling SetEvent() on the handle effectively enables the light. I've made a small app that checks the power state of the LCD screen and calls SetEvent() every few seconds when it determines the LCD is turned on (i.e. out of standby).

On the HD2 default stock ROM, the light automatically turns off when the device goes into standby. The driver makes sure this happens. However, it seems that some versions of the stock ROM, and also some other HTC devices, don't have this behaviour. In this case we have to turn off the LED ourselves. I found that on all HTC devices, an event named "IconLedOffEvent" exists to turn off these keypad lights. So I simply check the LCD state, and when I detect it is off, I set this event to turn the keypad lights off.

Unfortunately, it wasn't this simple.

The problem is that when the device goes into standby, the application is "paused" right away as well. This causes it never to detect that the LCD is off. I've tried various way to "detect" when the device goes into standby, and run last-minute code. I couldn't easily find a way without having a dialog window (and a message queue).

With this in mind I tried another approach. Instead of detecting when the device goes into standby, I prevent it from going into standby. And only when I allow it, the device actually continues to go into standby (until that time, only the LCD is off). We can do this using the PowerPolicyNotify() function. This function works with a counter. For every time PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) is called, a similar call with FALSE must be called as well. As long as the counter is not back at zero, the device will stay in unattended mode. Using this method, we keep the device in unattended mode until the code detects that the LCD is turned off, it sets the keypad light off event, and then releases unattended mode. Overal the device would effectively be in standby a second longer than intended, but that's no problem.

If you're interested in the code, you can find links to it in the thread I made for this little app.

The photo included in this post is made by pocketnow.com (link to article).

TorchButton

About a year and half back I got my previous phone, the HTC Touch Pro (a.k.a. the HTC Raphael). On all the HTC phones I had before that, a utility existed to turn on the flashlight led on the back of the phone to allow the phone to be used as torchlight.

However, as the Raphael had just come out, and the old utility didn't work for that phone, I got itchy and wanted to get this feature done anyway. After reverse engineering the camera app and dll, I released TorchButton v1.x series. I added some features to the request of other uses of the XDA forum.

For the HTC HD2 (a.k.a. HTC Leo) I had the exact same problem. I added support for the Leo and released TorchButton v2.x series. Newer versions have new lovely icons and I also added support for the Samsung Omnia i9x0 devices. Check the thread for more info.

Although I won't add support for every phone in TorchButton, my next phone will certainly be supported as well. That's still a bit into the future though, as I'm still pleased with the HD2. :)

FiPo!

Yay, got the first post on my own blog. This is the first blog I've ever started. Let's see if I can keep it up.

Purpose of this blog is to keep people updated about some technical stuff I'm working on and a place I can put up some centralized information on my projects. This will include stuff like TorchButton, KeypadLedControl and my efforts to run Linux on the HTC HD2 (or HTC Leo), which I use as phone. Previously I've helped with getting Linux on the HTC Touch Pro (or HTC Raphael). Please do note that this is not just my effort behind those links! Lots of people are involved getting this to work.

Hope you'll enjoy this blog. :)

P.S. The blog itself is also a work in progress. Just experimenting with how I like things best, in case you notice the layout changing :D