Yesterday I played a bit with qemu and the VT-d/IOMMU extension. The Vt-d extension present in many modern processors allows you to forward a PCI-device directly to your virtual machine so you can access it from the virtual machine as if it were a real device. This can be very helpful to develop drivers for PCI-devices without having to reboot the whole computer all the time. For example in my PC I use my Intel-onboard graphic as my main graphics card but I also have a Radeon in the PCI-express slot so I tried to forward it to my Haiku VM and it was more or less successful ;).
After quite some time I finally update my blog ;). A lot has happened in the last few weeks... The Haiku loader that gets loaded by u-boot finally is able to load the kernel and start it and we even have minimal framebuffer support running.
haiku_loader
In the previous posts I said that we would use the U-Boot API to write the loader, the problem with that is, that the API is not accessible on most U-Boots so we could not use it on early boot and had to write our own functions for serial output etc. Because of that the kernel is now loaded from a ramdisk instead of directly loading it from the sd-card as planned (but that might change later...). It also has the disadvantage, that the loader code is not completely platform independent anymore so we would have to rewrite it to be used on a PPC board with U-Boot for example.
Since we still need to know where to find the ramdisk for example (unless we hardcode it..) we decided to use the U-Boot image format that allows packing the loader and the ramdisk in one image and tell the loader where everything is and what parameters to pass to the kernel etc.. For this task U-Boot has OS-specific code since there is no standardized way of doing this. Since there was no Haiku specific code we would either have to convince the U-Boot developers to add Haiku support or simply masquerade as an other operating system. We choose the second option and François Revol added support for the netbsd way of booting so that we get the position of the ramdisk and the kernel parameters and some other info that is not yet used. He also created an jamtarget to allow to build an image directly.
I got the kernel to boot “a bit” ;) but since u-boot does not pass the kernel arguments when loading with loadelf I had to fake some kernel arguments etc.. So it’s not realy a working system but serial out works ;) (input does not work yet :( ) and I can see some stuff on my screen.. The kernel runs on a emulated gumstix verdex since there is no emulator for the gumsitx overo we will use and the beagleboard emulator did not really work (no sd card support for example)
Personal Profile Johannes Wischert Brief bio - I'm a computer science student living in Germany. I'm 25 years old now. I wrote my first program with 8 or 9 years or so and never stopped since then... After my studies I want to work somewhere in the embedded systems development but by now I enjoy my studies and take my time to finish. Project idea information Project title - Port the Haiku Kernel to ARM-Architecture List of project goals - generic u-boot Bootloader using the u-boot apis as far as possible to ease porting to other platforms that use u-boot Kernel that runs on the arm-processor and supports all applicable features that the x86 kernel has Device driver for at least the SD-card and the Serial-Port Working system running on a Beagleboard or similar device Project description - To get the system running on an ARM-CPU we first need a working Haiku ARM toolchain to compile the code I already got the toolchain to run and produce working binaries (tested under qemu) so this part of the system already works more or less.
