Now, that there are much fancier phones out there, like the Nexus One and Motorola Milestone, there must be a reason for people to buy them. The consequence about that is that they are holding back any updates to Android 2.0 or 2.1 for older phones. At least that’s my impression.

I also ever wanted to build and run my own Android since it is open source. At least that’s what Google says.
My first steps were quite disappointing since there was no device specific package for my G2 in the source tree. There was only one for the HTC Dream (G1).

Yesterday I wanted to give it another try and it was a success. I will post my steps here which are especially for the HTC Magic (or G2, HTC Sapphire, MyTouch 3G, Google IO – they are all the same) but it should be possible to do this with other phones as long as you have all the device specific blobs like the GSM Baseband layer or low level hardware drivers for your specific device.
Also keep in mind that this won’t be a normal guide like “How can I root this phone?” I assume that you more or less know what you are doing. So don’t blame me when you brick your phone: Shit happens and I’m not going to fix it.

Also, be careful what phone you have. There are 2 versions of the HTC Magic. One is the PVT32A and the other is PVT32B.
The A version has more RAM compared to B. The phone sold by HTC on their own is the A version. Almost all others are B versions. My phone is a B variant.
Check this site for any further information.

The SPL

The SPL is the Secondary Program Loader. The Initial Program Loader, which runs before the SPL is responsible for the basic bootstrapping of the processor inside the phone. Most of the time it is located on some on-die ROM and loads the SPL from flash.

The SPL itself is responsible for all kinds of boot services like booting from flash or receiving and handling data from the USB port with the fastboot protocol, which can be used for several maintenance tasks.

Usually, if you buy an OEM phone, you will get a shipment bootloader. Development phones will have an engineering bootloader.
The difference between those two is that with the shipment bootloader, you will not be able to write the flash directly from your computer over the fastboot protocol, which you definitely want if you compile/develop your own Android. So the first step is to install an engineering loader.
You can get several SPLs here. I installed the Crios  loader.
Just put the zip file on your SD-Card, boot a modified recovery image via fastboot and apply the zip file from your SD:

fastboot boot cm-recovery-1.4.img

The fastboot utility is available here or from your compiled Android in the out/host/<platform>/bin/ subdirectory.
To get your phone into fastboot mode, turn it off and hold the “back”-key while turning it on.

After flashing the new SPL you will have the engineering bootloader with security turned off.

Getting the Android sourcecode

If you want to build your own Android you obviously need to get the sourcecode. I did all the work on a Gentoo Linux. I don’t know how to do it under Windows or Mac OS.

First I thought to take the CyanogenMod repositories but they won’t check out completely because there seems to be missing at least one repository on github.

To get the official Google tree, just follow this guide.

Essentially you just install the required packages, get the repo client, do the repo init, repo sync and you should be done.

Get the binary blobs

For the Sapphire board package, you will need to get some binary blobs for the camera, WLAN, baseband and several other things.

You can download them on the HTC page for the Google IO. Just download the recovery image for Android 1.6 and put it into the root of your Android source tree.
After that you need to change the directory to vendor/htc/sapphire-open and execute the unzip-files.sh which extracts the blobs from the downloaded zipfile and puts them into the appropriate places.

Building it

After you prepared your environment, get back to the root of the source tree and do a

source build/envsetup.sh
lunch

to setup several environment variables and select the build target, which will be aosp_sapphire_eu-userdebug in our case.

After that you can just execute a

make -j3

to start the build. You can adjust the number behind the -j parameter to your machine. If you have n cores, the number you normally use is n+1. This is not essential for a successful build, but if you have 2 or more cores, you should use them for the build.
Now it’s time to ge some beautiful delicious black coffee or a cold bootle of Club-Mate, go for a walk or take a nap. This will take quite some time.

Common errors during the build

I ran into several erros while buildng. All of them were specific to my environment.

• no rule to make target `run-java-tool’ during build
  Solution: Just execute a export PATH=$(java-config -O)/bin:$PATH and the error you should be gone
• Java 1.6 is installed.
  Solution: Do an ACCEPT_LICENSE=”*” emerge =sun-jdk-1.5.0.22 and select the 1.5 JDK with eselect.
• Building the emulator fails with something like prebuilt/linux-x86/sdl/include/SDL/SDL_syswm.h:55:22: error: X11/Xlib.h: No such file or directory
  Solution: Do an emerge libX11

Installing the built images on your phone

After the build finished successful you will have everything in the out subdirectory.

Thanks to the engineering SPL, you can now install the built images using fastboot:

export ANDROID_PRODUCT_OUT="/path/to/android/root/out/target/product/sapphire-open"
fastboot flashall

Be sure your phone is in fastboot mode.

After you flashed the images you should boot the recovery image, mentioned in the SPL section, again and wipe the userdata partition.
This will cause a data loss. Anyway, you should have done a backup with nandroid in the modified recory image before messing around with your phone’s firmware

The result

Next steps

As you can see from the images above, all of the Google applications are missing. The next step would be to take them from an official Google image and put them on your phone. I think cyanogen already wrote a script for doing this for his builds. I haven’t checked this out yet.

Anyway, we have our very own Android 2.1 running.
If you want to use it on a daily basis you should consider building a stable branch and using this instead of the master branch.

If you’ve got any questions or problems, just leave them in the comments and we will try to figure them out.

Update: The cyanogenmod repositories do check out. I just used the wrong manifest repository.
If you want to give it a try, just do a

repo init -u git://github.com/cyanogen/android.git -b eclair
repo sync

instead of using the Google repository. Have a look here for more information.

General useful information, like adding your own target, creating keys for signing etc. can be found here.

Feel free to Flattr this post at flattr.com, if you like it.

Also… Es geht um KiCAD. KiCAD ist eine Suite, mit der man Schaltpläne und Platinen Zeichnen und Layouten kann. Von irgendsonem Franzosen an irgendsonem “Laboratoire des bla….” entwickelt. Im Prinzip wie EAGLE, nur mit dem kleinen aber feinen Unterschied, dass es komplett Open Source ist.

Die Bedienung ist etwas gewöhnungsbedürftig, aber verdammt schnell, wenn mans drauf hat. Es gibt einige verbesserungswürdige Punkte, aber die gibts immer. Mit einigen Buchstaben auf der Tastatur hat man sofort ein Bauteil unter Kontrolle. Nichtmal klicken muss man. Maus drüber, “m” drücken und Bauteil verschieben. Einmal klicken oder nochmal “m” drücken und fertig. Dasselbe gilt für “r” beim rotieren, “w” beim Wire verlegen usw.

Erste Ergebnisse nach 2 bis 3 Stunden Arbeit sieht man hier:

Eine geniale Anlaufstelle ist das Wiki mit seinem Schnelleinsteiger-Howto. Für Umsteiger von EAGLE gibts hier noch eine Sammlung konvertierter Libraries. Eigene EAGLE Libraries kann man wohl auch relativ easy importieren. Weiteres gibts hier im FAQ. Das ganze habe ich bisher aber noch nicht getestet.

Nachtrag: Die ULPs für EAGLE gibts alle hier: Sourceforge

Feel free to Flattr this post at flattr.com, if you like it.

[15:56:09][andy@geekbook:~/Desktop/oskrempel/kernel]
|-> ld -T linker.ld loader.o kernel.o kernel.bin
ld: unknown option: -T

Wieso? Klar… Apple hat einiges am GCC verändern müssen, um ihn Mac OS-Komptabibel zu bekommen. Aber wieso bitte gibt es keinen Support für Linker Scripte?

Selbst Google hat dazu nicht viel ausgespuckt, ausser die Empfehlung sich einfach einen vollwertigen GCC zu installieren. MacPorts sei dank geht das ja relativ einfach. Dauert nur ewig. Mein MacBook ist jetzt schon gut 3 Stunden damit beschäftigt.

Feel free to Flattr this post at flattr.com, if you like it.