Fun with kernels on the Huawei U8150

For the hell of it, I’ve decided to play with the kernel that runs on my Huawei U8150. Like most other Android devices running Froyo, the U8150 comes with a kernel based on Linux version 2.6.32 (to be specific, it’s actually 2.6.32.9-perf). In traditional Linux version numbering, the farther the number is to the right, the less indicative it is of a major update, and more it represents a security or stability fix. Basically, something in the “9” slot isn’t introducing any new features or breaking backward compatibility. The “perf” is just some internal tag Huawei threw in there to make us feel like we have a fancy phone. Do you feel special now?

As Linux is open-source software, I have it in my power to download upstream patches to the 2.6.32 branch and play as much as I like with getting them to compile and run on my device. As of August 13, 2011 kernel.org shows that the 2.6.32 branch has patches all the way up to version 2.6.32.44. Just imagine all the zesty security flaws, performance regressions and general bugs that have been patched since the version of code which is running on our U8150 was released!

I downloaded a handful of incremental patches and furiously applied them to my kernel_huawei_u8150 repository on github, stopping every so often to compile and boot.

Hack hack hack… repeat.

bunzip2 -c patch-2.6.32.9-10.bz2 | patch -p1
bunzip2 -c patch-2.6.32.10-11.bz2 | patch -p1
bunzip2 -c patch-2.6.32.11-12.bz2 | patch -p1
./compile
adb reboot
fastboot boot release/noma_20110813v10_boot.img

Fruits…

Not all the patches apply cleanly, but I only saw a few hunks failing, and they didn’t seem to be in relation to anything very critical (remember, Linux runs on at least a dozen platforms, and all we need is ARM support!). Somewhere around 2.6.32.40 I started getting compilation errors, so I stopped at 2.6.32.39. And just so y’all know I ain’t messin’ with you, I have screen shots!

So I feel pretty sweet, but this whole exercise was basically pointless, as the Broadcom 4319 wireless hardware in this phone has closed-source drivers, and the pre-compiled kernel module expects kernel 2.6.32.9-perf. I tried fudging the EXTRAVERSION in the Makefile but it didn’t work; there must be some incompatibility introduced somewhere in that bunch of patches. Other than Wi-Fi, everything else worked fine (bluetooth, multi-touch gestures, phone calls, 3G data, etc).

Lessons learned…

Despite this being (practically) a complete waste of time, we have learned that git, patch, and friends are fun! It’s all for the lulz anyways, isn’t it?!

10 thoughts on “Fun with kernels on the Huawei U8150

  1. Hi, exist a kernel exactly the same as original (u8150) that make a over clocking to 690mhz? I don’t want to change rom. Thanks

    1. Yeah, there are several kernels which have overclocking steps up to 700+, but those become unstable for me. Every CPU is different, so not all can withstand the same levels of overclocking. Keep in mind the MSM7225 chip is actually 528MHz natively, so 650+ is already a big improvement!

  2. Hi, this is good work, but where did you get the linux kernel 2.6.32 incremental patches because the linux your gave does not have the the .32.x-y branch?

    NB: i though that the “perf” is to indicate that the kernel has performance analysis tools for linux.See /tools/perf/perf.txt

    Thanks

    1. Haha, like I said… the kernel.org server was hacked and the entire infrastructure was rebuilt. You’ll just have to poke around and see if they’ve restored them somewhere else. 🙂

      Either that, or make your own from git, for example:

      git diff v2.6.32..v2.6.33 | bzip2 -c > v2.6.32..v2.6.33.bz2

      But then you have to make sure you have a git tree which contains the tags you want. The mainline linux git tree doesn’t tag longterm releases… you have to get one like linux-stable.git from Greg KH which does (he’s the maintainer of the longterm kernels).

  3. Hi, asante sana, I’m aware of the kernel.org hack and i’ve being search for a doc about the new infrastructure, hopefully i’ll find one soon.

    i’ll check out the “gitt diff” method and generate my own patch. I was trying to avoid this, but now, this is a challenge, hopefully I will learn something new.

    Thanks.

Comments are closed.