porting

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. see: http://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...? ) 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.

I know I have been very quiet for a while in regards to my Haiku WebKit port, but that is because I've been in a long session of coding. I am happy to report that this weekend I finally got WebCore compiling for Haiku:

Link ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
Chmod1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetType1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
MimeSet1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetVersion1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 

So what does this mean? Does it mean the port is now complete? Unfortunately, no it doesn't.

There are still some "stubbed out" classes in the Haiku platform code in WebCore, which means they don't do anything and just exist to make the code compile. Fortunately I have coded a lot of the needed platform files, but the ones which are stubbed out are some of the more complicated ones.

But I am very eager to finally get a simple web launcher running on Haiku to test the port, so I plan to work on this project after work this next week. For those not aware my (self-assigned) deadline for the WebKit Port Bounty on Haikuware is November 15th, which is this next Thursday. I think this deadline was a good motivator so I am glad I have it, but I don't think the port will be rock solid and "complete" by then. Keep in mind that the Qt port of WebKit is also missing a lot and has been worked on by many developers for more than a year. In addition WebKit originally came from KHTML which was a Qt-based HTML engine, so they have another advantage in that the design is Qt-friendly. Even the Windows port which is done by Apple employees who are experts on WebKit is still missing things that the main Mac OS X port has.

I don't say all this as some big excuse. I just want people to realize this is quite a big project and involves my learning the design of WebKit as well as aspects of the Haiku API I am not aware of. Plus as I have discussed before I have had to set up a new cross-compiler environment, port and then build four external libraries WebKit needs (CURL, ICU, SQLite, and libxml2), and write new Jamfiles for JavaScriptCore and WebCore so they can be built with the Haiku build system. I have also added missing features to Haiku that WebKit needed. In the end I think I will be a much better developer after doing all this, but it does involve a lot of work. I expect that once I get over this first hump of the main work for the port, other people will be able (and hopefully willing) to help. I do know at least one Haiku developer who has interest in helping a bit.

So what do I plan to deliver to satisfy the bounty? Well I have started working on "HaikuLauncher", inspired by the QtLauncher, which will be a very basic browser shell to drive the WebKit engine. I would like this to be able to load a web page and render it properly. Beyond that I'm not guaranteeing anything, at least for another few months until I can write a full browser (which is outside the scope of the bounty.)

Given this I hope the folks who contributed to the bounty can feel satisfied that their money was well spent.

I have been documenting my progress on porting the WebKit project to Haiku on the Haikuware site, but decided to also post information here. You may want to read my previous blog article about this port and also the information at the WebKit bounty on Haikuware. Please consider donating to a bounty.

Before I started work on this port I asked in the #webkit IRC channel what the mimimum version of GCC that was required to compile WebKit. The general consensus was 4.0. So what does that mean?