I just thought that this code may be interesting to other people who did not attend this conference.

The demo code includes mainly x86 specific stuff and it is truly demo code, so don’t just copy it into another project. Even if it works at first sight, it it is highly likely to break sooner or later

The code contains samples for:

• A small “Hello World” bootsector in realmode
• A sample how to enable the A20 gate. This works at least in QEMU
• Loading a barebone-kernel written in C by GRUB
• Switching to protected mode and writing to the textmode framebuffer
• Handling interrupts in protected mode using the old PIC
• Configuring and using the old PIT (Timer)
• Switching to longmode (64 Bit)
• A multitasking demo how to do context switching

The first two samples are completely written in Assembly and are loaded directly by the BIOS from a floppy drive. All other samples are mainly written in C spiced with some Assembly and are loaded from a FAT formatted floppy disk by a GRUB bootloader.

For those of you who speak german, here are the slides of the conference:
Talk
Workshop

If you do anything with this demo code, I would appreciate to hear about your project or experiences. Also, If there are specific questions or problems about/with this code which are not easily resolvable by Googling and using your brain, feel free to ask in the comments.

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.

Es gibt einige Möglichkeiten Vorlesungen, Professoren, Dokumente, Termine etc. anzulegen, die Software ist aber lange nicht fertig und ich habe die Lust verloren weiter an ihr zu entwickeln.

Der Quellcode baut in der aktuellen Revision auch nicht, da ich mitten in einer Migration von SQL Compact Edition auf ein SQLite stecke. Einige Revisionen vorher sollten aber funktionieren.

Den Code findet man auf GitHub.

Screenshots:

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

Draufgegangen ist das unter anderem für dieses hübsche, aber leider teure FPGA-Board mit einem Xilinx Spartan 3 FPGA:

Wie man sieht, sieht man ein A auf dem LCD Display. Viel mehr habe ich damit noch nicht zustande gebracht. Besonders einfach wirds einem aber sowieso nicht gemacht. Das Ding ist halt kein Prozessor, mit dem man sequentielle Abläufe durch das Ausführen eines Programms abbilden kann, sondern pure Digitaltechnik.
Durch VHDL wird einem das Beschreiben etwas einfacher gemacht, die Vorgänge laufen aber alle parallel in diesem Chip ab. Signale warten nicht einfach so auf ein Ereignis.

Signalabläufe wie sie von einem Displaycontroller erwartet werden können auch nur über eine Statemachine modelliert werden. Man hüpft also von einem Zustand in den anderen und legt die passenden Signale an die Leitungen. Danach springt man meistens wieder in eine Warteschleife, weil der LCD-Controller üblicherweise langsamer ist als so ein FPGA.

Da man das ganze äußerst schlecht debuggen kann, simuliert man im Vorfeld die Abläufe. Man schreibt also erstmal sein Modul in VHDL und darf sich dann auch noch darum kümmern einen Sogenannten Testbench zu schreiben. Dieser Testbench ist dann dafür zuständig die passenden Signale, die normalerweise durch externe Quellen erzeugt werden, an das Modul zu legen, um das alles in Software abbilden zu können.

Nachdem man dann die Simulation für einige Milisekunden ausgeführt hat, sieht das so aus:

Auf diesem Bild sieht man die Simulation eines RS232 Moduls. Die Länge eines Bits ist hier 8,6µs, was eine Baudrate von 115200 pro Sekunde ergibt.
Als erstes wird in tx_data das Byte abgelegt, welches üertragen werden soll. Dann zieht man tx_start kurz auf High, was man hier nicht sieht, da es bereits 40ns nach dem Start passiert, und die Übertragung startet. Erst kommt das Startbit auf der TXD-Leitung, dann eine 0, dann eine 1 usw. bis das Stopbit kommt und die Leitung wieder auf “Standby” geht und somit 0xAA übertragen wurde. RS232 überträgt das niederwertigste Bit zuerst.

Analog läuft das mit dem Empfangen ab.

In VHDL sieht das ganze dann so aus:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity RS232 is
    Generic ( Clockrate : integer   := 50000000;  -- Hertz
              Baudrate  : integer   :=  9600      -- Bits/Sec
             );
    Port ( RXD      : in   STD_LOGIC;
           RX_Data  : out  STD_LOGIC_VECTOR (7 downto 0);
           RX_Busy  : out  STD_LOGIC;
           TXD      : out  STD_LOGIC;
           TX_Data  : in   STD_LOGIC_VECTOR (7 downto 0);
           TX_Start : in   STD_LOGIC;
           TX_Busy  : out  STD_LOGIC;
           CLK      : in   STD_LOGIC
           );
end RS232;

architecture Behavioral of RS232 is
signal txstart : std_logic := '0';
signal txsr    : std_logic_vector  (9 downto 0) := "1111111111";
signal txbitcnt : integer range 0 to 10 := 10;
signal txcnt    : integer range 0 to (Clockrate/Baudrate)-1;

signal rxd_sr  : std_logic_vector (3 downto 0) := "1111";
signal rxsr    : std_logic_vector (7 downto 0) := "00000000";
signal rxbitcnt : integer range 0 to 9 := 9;
signal rxcnt   : integer range 0 to (Clockrate/Baudrate)-1; 

begin
   send: process(CLK)
   begin
      if rising_edge(CLK) then
         txstart <= TX_Start;
         if (TX_Start = '1' and txstart = '0') then
            txcnt    <= 0;
            txbitcnt <= 0;
            txsr     <= '1' & TX_Data & '0';
         else
            if(txcnt<(Clockrate/Baudrate)-1) then
               txcnt <= txcnt + 1;
            else
               if (txbitcnt < 10) then
                  txcnt    <= 0;
                  txbitcnt <= txbitcnt + 1;
                  txsr     <= '1' & txsr(txsr'left downto 1);
               end if;
            end if;
         end if;
      end if;
   end process;
   TXD     <= txsr(0);
   TX_Busy <= '1' when (txbitcnt < 10) else '0';

   receive: process(CLK)
   begin
      if rising_edge(CLK) then
         rxd_sr <= rxd_sr(rxd_sr'left - 1 downto 0) & RXD;
         if (rxbitcnt < 9) then
            if(rxcnt < (Clockrate / Baudrate) - 1) then
               rxcnt    <= rxcnt + 1;
            else
               rxcnt    <= 0;
               rxbitcnt <= rxbitcnt + 1;
               rxsr     <= rxd_sr(rxd_sr'left - 1) & rxsr(rxsr'left downto 1);
            end if;
         else
            if (rxd_sr(3 downto 2) = "10") then
               rxcnt    <= ((Clockrate / Baudrate) - 1) / 2;
               rxbitcnt <= 0;
            end if;
         end if;
      end if;
   end process;
   RX_Data <= rxsr;
   RX_Busy <= '1' when (rxbitcnt < 9) else '0';

end Behavioral;

Mit einer “entity” beschreibt man, dass es irgendein Modul mit entsprechendem Namen gibt und welche Leitungen da rein und rausgehen.
Im “Behaviour” beschreibt man dann, wie sich das Modul verhält und welche internen Signale oder Variablen es gibt. Wir haben in diesem Fall 2 Prozesse. Einen zum Senden und einen zum Emmpfangen. Jeder dieser Prozesse kann gleichzeitig ausgeführt werden.

Der passende Testbench zu diesem RS232 Modul sieht dann so aus:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.ALL;

ENTITY rs232_tb IS
END rs232_tb;

ARCHITECTURE behavior OF rs232_tb IS 

    -- Component Declaration for the Unit Under Test (UUT)

    COMPONENT RS232
   GENERIC ( Clockrate : integer := 50000000;
             Baudrate : integer := 115200);
    PORT(
         RXD : IN  std_logic;
         RX_Data : OUT  std_logic_vector(7 downto 0);
         RX_Busy : OUT  std_logic;
         TXD : OUT  std_logic;
         TX_Data : IN  std_logic_vector(7 downto 0);
         TX_Start : IN  std_logic;
         TX_Busy : OUT  std_logic;
         CLK : IN  std_logic
        );
    END COMPONENT;

   --Inputs
   signal RXD : std_logic := '0';
   signal TX_Data : std_logic_vector(7 downto 0) := (others => '0');
   signal TX_Start : std_logic := '0';
   signal CLK : std_logic := '0';

   --Outputs
   signal RX_Data : std_logic_vector(7 downto 0);
   signal RX_Busy : std_logic;
   signal TXD : std_logic;
   signal TX_Busy : std_logic;

  constant clk_period : time := 20 ns;

BEGIN

  -- Instantiate the Unit Under Test (UUT)
   uut: RS232 PORT MAP (
          RXD => RXD,
          RX_Data => RX_Data,
          RX_Busy => RX_Busy,
          TXD => TXD,
          TX_Data => TX_Data,
          TX_Start => TX_Start,
          TX_Busy => TX_Busy,
          CLK => CLK
        );

   clk_process :process
   begin
      CLK <= '0';
      wait for clk_period/2;
      CLK <= '1';
      wait for clk_period/2;
   end process;

   -- Stimulus process
   stim_proc: process
   begin
      RXD <= '1';            --idle
      wait for clk_period*2;

      TX_Data <= "10101010";
      TX_Start <= '1';

      wait for clk_period*5;
      TX_Start <= '0';

      wait for clk_period*5000;

      --startbit
      RXD <= '0';
      --435 clock cycles by 20ns each = 8,7us = length of bit with 115200 baud
      wait for clk_period*435;

      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;
      RXD <= '0';
      wait for clk_period*435;
      RXD <= '1';
      wait for clk_period*435;

      --stopbit and idle
      RXD <= '1';

      wait;
   end process;

end;

Der Aufbau ist ähnlich wie vorhin. Die Entity hier enthält jedoch keine Ein- oder Ausgabesignale, da hier später nur die internen Signale dieses Testbenches im Simulator betrachtet werden. Natürlich kann man später in der Waveform noch weitere Signale hinzufügen. Zum Beispiel interne Signale aus dem getesteten Modul.
Im Behaviour wird dann als erses die Komponente RS232 definiert. Es gibt also irgendwo ein solches Modul, das später hier genutzt werden kann. Darauf folgend kommen wieder einige Signale, denen man später in Prozessen Werte zuweisen kann oder von denen man Werte auf den Leitungen abgreifen kann.
Danach wird ein RS232 Modul mit dem Namen uut (“unit under test”) instanziert und die Ports des Moduls werden mit den internen Signalen verknüpft.
Dann folgen wieder Prozesse. Der erste generiert das Clocksignal und der zweite ist für den eigentlichen Ablauf des Test verantwortlich. Das Senden ist hier relativ einfach: Wert in tx_data schreiben, für kurze Zeit an tx_start ziehen und dann beginnt die Übertragung.

Der Empfangstest ist dahingehend schwieriger, dass jedes Bit für eine bestimmte Zeit anliegen muss, wie es in Wirklichkeit auf einem Kabel auch der Fall wäre.
clk_period*435 entspricht hier exakt 8,7µs, was wiederrum ungefähr 115200 Baud/s entspricht: 20ns*435 = 8700ns = 8,7µs

Als nächstes werde ich mich mal an den VGA Ausgang setzen und probieren ein Bild zu zaubern. Danach ist allerdings auch schon der DDR2-Speichercontroller dran: Für ein 12 Bit VGA-Bild bei einer Auflösung von 640×480 Pixeln sind schon 450KB Video RAM nötig. Mit double buffering sind wir dann bei 900KB.

Update: Das RS232 Modul stammt im übrigen von hier. Lediglich den Testbench habe ich mir dann noch dazugeschrieben.

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.