Doing this with real hardware is kinda risky and complex.
But what about virtual machines like VMware? They have a BIOS, but how can we get our hands on it?
As I’m using Mac OS X for all my daily work, I’m using VMware Fusion as a virtualization program.

The BIOS seems to be hidden inside the virtual machine monitor executable itself.
To make our lifes easier, we are going to extract only the x86_64 part out of the universal binary with the following command:

lipo /Libary/Application\ Support/VMware\ Fusion/vmware-vmx -thin x86_64 -output /Users/user/Desktop/vm64

Now, we have a Mach-O file with only one architecture, which is x86_64.
It doesn’t matter if you are dumping the BIOS out of the i386 or x86_64 version of the binary. It should be the same for both architectures.

After that, we can extract the appropriate section in the Mach-O file which contains the BIOS itself:

segedit /Users/user/Desktop/vm64 -extract __VMWARE bios440 /Users/user/Desktop/bios440.rom

And here, you go: bios440.rom contains your VMware BIOS.

After you modified it to your wishes, you can use a handy VMware feature which lets you specify a custom BIOS for a virtual machine inside its vmx-file.
Just add this line to the vmx-file of the machine you want a custom BIOS for and place the rom file in the proper folder:

bios440.filename = "bios.rom"

Happy BIOS modding!

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

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.

Nachdem ich dann auch irgendwann mal raushatte, wie ich das vierstufige (!) Paging mit 4KB großen Pages beim Booten zusammenbauen konnte, um so einen Prozessor in den Long Mode zu bekommen, hab ich mich mal an die Virtualisierung machen wollen.
Zu diesem Zeitpunkt saß ich allerdings schon im Hackcenter.

Wie ich dann, mal wieder, feststellen musste, hat so ein Low Level Zeug einen unglaublichen Rattenschwanz, den man immer wieder hinter sich herzieht. In diesem konrekten Fall brauchte ich also ein vernünftiges Interrupthandling. Ist ja schnell implementiert, dachte ich mir und kopier mir meinen Code aus meinen anderen Projekten fröhlich zusammen.

Interrupts konnte ich dann handlen. Problem war jetzt nur, dass 2 Instruktionen nach dem Aktivieren der Interrupts sofort der Interrupt #8 auftrat, was nach Dokumentation ein Double Fault gewesen sein müsste. Dieser tritt aber nur nach einer fatalen, vorhergegangenen Exception auf, wovon ich aber nichts mitbekommen habe. Wieso fliegt da also ein Double Fault? Nichtmal die 2 Instruktionen, die nach dem setzen des Interrupt Enable Flags ausgeführt wurden konnten einen solchen Interrupt auslösen, weil es Sprünge zu sich selbst waren, um die CPU in einer Endlosschleife zu halten.

Kommen wir zurück zum Rattenschwanz: Nachdem ich dann die Interrupt Handler und die Verwaltung der IDT hatte, habe ich noch Routinen zur Verwaltung der GDT implementiert. Es funktionierte immernoch nicht, was allerdings zu erwarten war, da es mehr eine Verzweifelungstat war als ein richtiger Lösungsansatz. Wir sind zu diesem Zeitpunkt bei Tag 3 des Kongresses.
Allerdings war das ja auch nicht das Einzige, was ich da gemacht habe. Gab ja noch Vorträge.

Danach gings ans Debuggen. Ich habe VMware probiert, um zu sehen, was das Ding sagt. Wie erwartet: nichts. Es fehlen einfach die Debuggingmöglichkeiten unter Mac OS mit VMware.
Dann gibts noch Qemu, an den man einen GDB klemmen kann. Gesagt getan. Nach wie vor nichts gefunden.
Als letztes bin ich mit dem integrierten Debugger in Bochs dem Kram zu Leibe gerückt, mit dem man seinen Code auf Assemblerebene Debuggen konnte. Auch hier habe ich wieder nichts gefunden.

Was war das Ende vom Lied? Es gibt einen extra Chip auf x86 Systemem, der externe Interrupts handlet. Früher war das der PIC (Programmable Interrupt Controller) und heute ist es der APIC (Advanced Programmable Interrupt Controller), der auch Mehrprozessorsysteme ohne Gefrickel unterstützt.
Diese Chips kann man so konfigurieren, dass jeder externe Interrupt (Tastatur, Floppy, Timer etc) auf einen der 256 Interrupts der CPU gemappt werden kann.

Irgendein Stück Software vor meinem Kernel hat genau das anscheinend mit dem Timerinterrupt gemacht und ihn auf Interrupt #8 gelegt.
Das würde dann auch erklären, warum bei einem Double Fault eigentlich ein Errorcode auf den Stack gepusht werden sollte, was bei mir aber nie passiert ist. Es war schlicht und ergreifend kein Double Fault.

Also hab ich dann doch, entgegen meiner vorherigen “Brauchste eh nich”-Meinung, auch noch Code hinzugefügt, der den PIC (eigentlich sind es 2 PICs) entsprechend konfiguriert und die 16 Interrupts, die er verwalten kann, hinter die Exceptions mappt.

Was ist? Es funktioniert endlich.

Und so kann man sich wunderschön auf die Fresse legen und Zeit verbraten.
Ich will nicht sagen ich hab nichts gelernt, genervt hat es aber doch schon ziemlich. Gedauert hat der ganze Prozess jetzt 6 Tage. Und ich hab immernoch keinen virtualisierten Code laufen.

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

Wer jetzt schon heiß auf Code ist, kann ihn hier bekommen: github

Die Architektur, die dieser Kernel haben soll, ist ein Mikrokernel. Bisher ist davon allerdings nicht viel implementiert, da ich mir seit ein paar Monaten versuche Gedanken über die Speicherverwaltung im Kernel zu machen und sowieso nicht immer Lust habe an diesem Projekt weiterzuarbeiten.

Aktuell Implementierte Features:

• Ein-/Ausgabe von Text über einen 80×25 Zeichen Textmodus auf dem Monitor
• Ein-/Ausgabe von Text über eine serielle Schnittstelle
• Bootstrapping eines x86 Prozessors und Umgebung (Protected Mode, Interrupts, PIC, PIT)
• Interrupthandling, welches bisher noch sehr Plattformabhängig ist
• Ansätze eines HALs
• Paging
• Timer
• Das Buildsystem, basierend auf GNU make

Im master-Branch auf GitHub findet man noch einen implementierten Heap, den ich mitlerweile aber wieder weggeworfen habe, da ich ihn durch einen SLAB-Allocator mit etwas besserem Virtuellem Speichermanagement im Hintergrund ersetzen möchte.
Eine weitere Designentscheidung, die ich im Züge des neuen Speichermanagements getroffen habe, ist das der Kernel auf einem 32 Bit System die vollen 32 Bit an virtuellem Speicher bekommen wird und nicht in den virtuellen Speicher eines jeden Prozesses eingeblendet wird. Dies geht zwar mit einem Performanceverlust einher, da ich bei jedem Systemaufruf oder Interrupt das Page Directory wechseln muss und somit der TLB (Translation Lookaside Buffer) geleert werden muss. Wie hoch dieser Verlust sein wird, weiß ich allerdings nicht. Mac OS X macht das auch so und das ist auch noch schnell.

Alle diese Änderungen befinden sich momentan im Branch 4gbKernel auf github.

Weitere geplante Features sind:

• Ein Scheduler mit Interprozesskommunikation über Shared Memory
• Dieser Shared Memory kann auch auf anderen Rechnern liegen und das System kann somit verteilt werden
• Einige Userspace System-Daemons, die Sachen wie das Prozessmanagement, Userspace Speicherverwaltung, Netzwerk, Dateisysteme etc. übernehmen
• Einige Userspace Libs, die Posix implementieren, um GNU-Software ausführen zu können
• Evtl. einen DOS-Kompatiblitätslayer

Bis diese Sachen wirklich alle implementiert sind wird allerdings noch einiges an Zeit vergehen.

Screenshot des Aktuellen 4gbKernel-Branches in einem Qemu.

Screenshot mit kleinem Scheduler, der Kontextwechsel zwischen 2 Threads ausführt.

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