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 ;). To do that under Linux you have to detach the card from its real driver (probably the radeon kernel module under linux) and give it to the pci-stub module (you might have to load it first). To get the PCI-IDs and all the other information use lspci.
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)
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. see: https://dev.haiku-os.org/ticket/3633
After that done the next step is the boot loader. Since the beagleboard I want to target already has "Das U-boot" bootloader installed I decided to use it to get the kernel loaded. Using the u-boot loader has some advantages since it already provides all the important data and functions for loading the kernel like builtin serial drivers and drivers for all kind of memory to boot from (including a TFTP client) these functions are exposed by a simple platform independent API. By using this API an architecture independent kernel loader could be build, so that porting to other architectures that use u-boot would be much easier.
The loader would run as a standalone application on top of u-boot to use it's features and then switch to direct access to the hardware to run the kernel.
To allow u-boot to boot the kernel I could either include bfs in u-boot or implement the bfs in the loader programm. If the bfs code is in the loader no change to u-boot is needed so I will probably take this way since changing the u-boot always has the risk to brick a device.
I know that this is not everything and I will probably have to ask a lot of questions to get everything right ;)
I must admit that I don't know to much about the ARM internals, yet so I can't give much details about how I will port the MMU dependent stuff etc.
The device drivers for the serial-port and the sd-card are quite straight forward to implement, since they are interfaced directly by the processor (at least on the beagleboard) and there are a lot of existing open source drivers (of course we would have to pay close attention to the licenses etc...)
Since the beagleboard does not have an isa or pci bus it could use code similar to the m68k port to put the onboard devices in the pci bus. Even better would be to write a sort of bus system for the onchip devices this would also help to port to other devices that do not realy have a bus system like many other embedded devices.
The next steps would be to write a driver for the onchip usb-controler and a Framebuffer driver if the porting goes much faster than I think ;)
Why do you want to work on this project?
I love the whole concept of Haiku and would love to see it run on embedded hardware like all these planned linux+arm netbooks. Since ARM-CPUs are used in so many different devices and most of these devices are multimedia devices like netbooks/mediaplayers/smartphones it would make sense to port Haik as an multimedia OS to these devices.
I already have experience in embedded programing for example I ported an OS from the MSP430 to the SuperH Architecture for university (it was a nano kernel OS called SmartOS there is a wiki about this project but for whatever reason they have the interesting parts hidden http://www5.informatik.uni-wuerzburg.de/snow5xoops/modules/dokuwiki/doku.php? ) so I know a bit about all the problems that could arise.
I know porting such a complex project is quite difficult but I have the time to concentrate on this project and it's not the first embedded project I work on (but probably the biggest ).
Other projects I worked on were a device driver for the r4ds flash card to use it under DSLinux on the Nintendo DS and some other smaller stuff like a stepper motor controler board that was controlled by an MSP430.
I know that this project is not really helpful to get closer to the first alpha release of haiku but I think an ARM port would be a interresting addition to the Haiku project and perhapse attract some more developpers.
