TS2Overlay - Teamspeak 2 Overlay

I'm playing a lot of EVE Online recently and am currently in an alliance that uses the older Teamspeak 2 client to talk with eachother. As there don't seem to be any Teamspeak 2 overlay applications that work for Windows 7, I've created one of my own.

Head over to the TS2Overlay page on my blog for the details. Comments go there as well.

Overclocking the MSM7200 / MSM7201a

After writing an overclocking tool for the HTC HD2 (Leo), I had a request from someone challenging me to overclock the HTC Touch Pro 2 (Rhodium). As I still have an HTC Touch Pro (Raphael) myself, with the same processor in it, I decided to give it a go. I quickly learned someone (bzo) managed to overclock the same processor on Linux already while working on their Android port to the MSM7k device series. Being able to use that code as some sort of limited documentation I've also written an overclock tool for a number of HTC MSM7k based devices, such as the Raphael, Rhodium, Diamond, Topaz, Blackstone and Whitestone. It's not working perfectly yet, though. For now it's only possible to overclock on AC power, except for the Rhodium which seems to overclock on battery as well. Read all about it in the thread on XDA.

Btw, the MSM7201a is a 528MHz processor. Some have reported to be able to clock it at 787MHz before it hangs. That's a pretty insane overclock if you tell me. For me it's stable at 710MHz. I can push it to 750MHz, but it'll lock up as soon as I do something heavier on the device, like watching a movie.

CPU speed control for the HD2, including overclock!

Today I've released a new app for the HD2 to control the CPU speed of the device. You can scale the speed anywhere between 128MHz and 998MHz and lock it by disabling the autoscaling feature that HTC put in. Having the CPU at 998MHz all the time (as opposed to the 768MHz default idle speed), you don't notice the battery increase. I didn't at least.

I've also ported some of the code from the Nexus One linux kernel to allow overclocking. Unfortunately it's not possible (or I haven't found a way yet) to increase core voltage, so you can't overclock too far. You should be fine overclocking to 1.1ghz. Overclocking to 1.2ghz is tricky already and I've never been able to clock it at 1.228ghz or higher without it instantly locking up.

Also one other major limitation is that overclocking currently only works on AC power, as on battery the phone somehow enforces the cpu speed at 998mhz (or more specifically, last used performance level) every 500 milliseconds. I'm still trying to figure out how to fix this. :-)

Head over to the thread on XDA for more details.

Irssi tips for newbies

A colleague of mine recently installed irssi and I thought it'd be nice to give him some hints on scripts and some handy commands etc. After writing that up I thought it couldn't hurt sharing it with the world as well. Even though this is written for irssi newbies, it's not written for linux newbies :-)

1. Install scriptassist

Scriptassist is a script that will make your life within irssi a bit easier. It will help you install new scripts and add them to autorun.

# mkdir ~/.irssi/scripts/autorun
# cd ~/.irssi/scripts

# wget http://scripts.irssi.org/scripts/scriptassist.pl

# cd autorun

# ln -s ../scriptassist.pl

In irssi just type: /script load scriptassist
It may fail to load due to missing perl dependencies. Resolve these by installing the missing dependencies and try again.
When it loads correctly, you'll get info on how to use it with: /scriptassist help

2. Some nice scripts

Here's a few scripts that I'm using within irssi myself.

• autowhois: when someone queries you, it does a whois and displays it in the query.
• autocycle: autorejoin after kick (not always appreciated in all channels and can result in ban)
• binary: encode/decode for fun (01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100)
• kenny: same (mfpmpppmfpmfppf fppppfpffpmfmpm)
• nickcolor: gives each nick a seperate color (edit nickcolor.pl --> "my @colors = qw/3 7 9 10 11 12 13/;" for my recommended color set to prevent your eyes from pinching)
• queryresume: gives the last 10 lines of the previous time you had a query with that person
• splitlong: if your text doesn't fit on one line, it splits it over multiple ("/set splitlong_max_length 460" to be on the safe side)

These are just some suggestions. You can find all irssi scripts on their scripts site.

3. Some handy commands

• Make irssi remember what channel is in what window: /layout save
• Current people in channel: /n (or /names)
• Current topic: /t
• Close window (& part if chan): /wc (/window close)
• Search through current window: /last mysearch
• Scroll up 10 lines via command: /sb goto -10
• Scroll back all the way down: /sb end

4. Aliases that can be useful

Some aliases just make life easier. Especially when working on a mobile device in which you cannot use the alt key to change channels :-)

/alias 1 /window goto 1

/alias 2 /window goto 2

/alias 3 /window goto 3

/alias 4 /window goto 4

/alias 5 /window goto 5

/alias 6 /window goto 6

/alias 7 /window goto 7

/alias 8 /window goto 8

/alias 9 /window goto 9

/alias 10 /window goto 10

/alias 11 /window goto 11

/alias 12 /window goto 12

/alias 13 /window goto 13

/alias 14 /window goto 14

/alias 15 /window goto 15

/alias 16 /window goto 16

/alias 17 /window goto 17

/alias 18 /window goto 18

/alias 19 /window goto 19

/alias 20 /window goto 20

/alias c /window close

/alias dns /exec host $-
/alias figlet /exec -o figlet -s $-

5. Configuration settings

• Logging (only logs queries, add "pub" after "msgs" seperated by a space to also log channels)
  /set autolog ON
  /set autolog_level msgs
  /set autolog_path ~/irclogs/$tag/$0.log
• Away log
  /set awaylog_colors ON
  /set awaylog_level msgs hilight
  /set awaylog_file ~/.irssi/away.log

Hope this info is useful to someone! :-)

Linux on HD2: IRQ problem solved!

Just an update. Last few weeks we've been working on something we named "the irq problem". After registering some interrupts, whenever the first one fired, it would cause an infinite amount of "bad IRQs". Finally after a bit of coincidence that we read along some of the problems randomblame was having, we saw some interesting code in the entry-macro.S file, patched by vladone. This was the solution to the irq problem.

It's typical. You do really a lot of research on something, and it turns out to be something so small (only three lines of assembly code). As you can see on the git repo, getting rid of this blocking issues allows us to finally do some other work.

Modded HTC Flashlight app

Some time ago a flashlight application got released by HTC. It's being used in many ROMs already. However, one thing that is annoying, is that when you start the app, you get this demo of how to use the application. It rotates a few times and ends up in the center again with the LED on. Even though I have my own baby (TorchButton), I thought this behavior was pretty annoying and I read a few times on the forum already about other people being annoyed as well.

It was fun to figure out how to fix the exe to skip the demo, so I took on the challenge and fixed it. Check out the thread over at xda-developers ([MOD] HTC Flashlight, no demo at startup).

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