RaspberryPi's to port Haiku to

Is anyone interested in porting Haiku to go onto a raspberry pi board http://www.raspberrypi.org/
I can see that there has been a bit of talk about it and I believe parts work with Qemu (not sure which core)
as I see it the best thing to do first is get an initial port to 1136 versatile board as the raspberry pi is an 1176ZF (thats like the 1136 with trustzone and a VFPU)
I’m trying to gather up an the info and working scripts (please don’t just post “it would be great” please post some useful links [like how to get Qemu booting a simple arm compiled image etc) so if you have tried or have some good info on getting Qemu/Arm images build or had success with getting the Haiku kernal crosscompiled PLEASE HELP ME :wink:
as an incentive I’m willing to buy a few (5) raspberry pi boards when the become available to donate to the cause

jpelczar is working on a port that would probably cross compile to ARM.


Just because Pi is cheap does not mean that porting Haiku to ARM is easy…

I saw, I have contacted him directly as I hope that his work will save me (and others) time.

I agree, but as it’s cheap other are more likely to buy one to run Haiku than they are if I port to Panda board which is about 8 times the price (8 times faster too)
and RaspberryPi, Beagle Board and Panda board all have the same issue with propitiatory GPU’s (unless you are a closed source vendor with deep pockets),
and ARM port will not be easy bu once there is an 1136 kernel, that will run on 1176 and A8 (or Sheeva (AinR) ) then its only a case of porting the GPU and io devices specific to each board.
if it was easy I would have done it by now I own a few arm boards and have gcc cross compiler and native compilers (I’ve developed apps on my panda board and may well use that or my Sheeva plug to build a kernel)

Datasheet posted today:


Actually Allwinner A10 or Xynos based tablets are probably the best thing to port to at the moment they are cheap and are real devices unlike a Pandaboard or Rasberrypi the former I have used myself and it was full of bugs in the design… the whole device is FSF compatible as there is a GPU driver being released And it will eventually be reworked into a Mesa/gallium driver.


Count me in as another keen on seeing a ARM port of Haiku! I understand the need to get the x86 version stable first but Haiku and ARM seem like they were made for one another to me.

I ordered a Pandaboard myself in December that still hasn’t arrived yet so I’m obviously keen on seeing some focus on that platform but at the same time I must agree with cb88 in that boards featuring the Mali GPU would be the most logical ARM platform to port to first being the most FOSS friendly.

I personally have no need for a tablet - I would buy a snowball or origen SBC or a netbook/laptop with a similar chipset in pref. to the Pandaboard but they’re both twice the price of the Pandaboard (and 10x the price of the Pi!) currently.

Just be aware that you can’t use large SD cards on the Pandaboard unless you use a USB adapter.

If you intend to do any heavy IO for instance compiling get a USB hard drive (not a flash drive) or do it over NFS.

I ram gentoo on a flash drive compiling on the device… thats just asking for trouble really.

Calling ARM itself today a platform really isn’t accurate… as each separate device is a separate platform little to no standardization :confused: which is why there isn’t an sucessful ARM port yet.


Which version of which model Panda do you have?

I should have mine within the next week. I’ve been on the mailing list for months already so I’ve read of the various probs I am to expect but I can also clearly see a significant number of people have bought the Panda who admit they are total Linux noobs and not ex-Commodore and ex-Zaurus, Linux user since '96 types like me! :wink:

Having read up on this subject more, I am now of the opinion that these Mali GPU devices like Snowball and Origen are no better free-software wise than the Panda as the open source Lima Mali driver is having to be reverse engineered as its official drivers are every bit as closed as the official drivers for the Panda’s SGX GPU.

There have been rumours of an upcoming, official open source SGX driver and should that never occur then an open source SGX driver could likely utilise code from OpenFIMG:

I would be very interested in seeing a port and I would love to help - I just have too many projects and no free time to do so :confused:

Just a heads up. Alexander von Gluck has recently made a couple of commits including “Add board definition for Raspberry Pi” but he adds “don’t get too excited, or expect any Haiku love for it anytime soon.” So I guess anybody with the skills, the time and an example of the hardware to work on this could get in touch with Alexander.


It was either an A1 or A2 not 100% sure and don’t have access to it anymore as it was for my senior design project.

I do have an N800 which has a released MBX driver but the display output for it is broken and its a binary driver on top of that so they are like “good luck with that” heh. I still use the n800 quite alot Opera Mobile is awesome.

In anycase … software for are should definitely enable hardfp support…so thats is something to keep in mind.

I got my A4 a few days ago so I’ve not got to play with it much and so far I’ve only run stuff from a 32GB class 10 SD card but considering it is running off an SD I’ve been impressed so far- I’ve seem to have all the hardware working (not tested bluetooth or mic input yet) under ICS and 11.10. It really light years apart from how things were on my Zaurus C3000 a few years ago! Now I just need a power efficient USB HD or SSD and a SGX (PVR-omap4) driver for 12.04 armhf (coming soon I’m told) before I can see what this hardware can really do!

Mic and Analog audio out on our pandaboard were a bit of a pain when I was using it in the fall… all the bits to make it work were there though… you just had to poke them just right :slight_smile:

I think we had issues with overheating on long compiles as well I think it was a kernel issue we weren’t aware of at the time that I found out about after the fact… so at least monitor the temps or put a heatsink on it.

Just got a rPi board in yesterday, let me know if anyone needs any extra help… or if you are in the dallas area and want to borrow it.

Well supposedly it would be possible to port the API easily to other OSes however… its not Mesa therefore it wouldn’t get you far on any other hardware at all. And its also unsupportable which is basically David Arlie’s stance on it.

Great news, Broadcom releases fully open source drivers for their BCM2835 ARM SOC which is used in Raspberry Pi.

So now all the necessary information is available to make Haiku a first class citizen on the Pi.


Its not a driver see here:

In short it merely allows you to talk to the firmware and not directly to the hardware since the driver is acutally built into the firmware (aka the blob that has to be loaded even before booting).

I see, I got my hopes up for nothing it seems. :confused:

The released code is just what’s needed to get a driver for Haiku working with full hardware acceleration.
The chip that the RPi uses is designed so the OpenGL stack is not running on the ARM CPU, but instead on the GPU side. This means it’s possible to feed the hardware almost directly with OpenGL function calls. The driver is just converting C calls to something suitable for the hardware/firmware side.

Most guy from the Linux sides are ranting about it because they expected to learn about the GPU structure and ways to hack into it, possibly reusing part of the information to improve Mesa and other linux related graphics stuff. This driver doesn’t help them at all.

However, on Haiku, it makes it quite easy to build a libGL.so around it. We don’t need Mesa and Gallium3D at all, just this small thing to transfer the calls to the GPU firmware. And we’ll get accelerated OpenGL.

There are some things to keep in mind however :

  • Haiku does not run on the Pi, yet. This will need a lot of kernel hacking, endianness fixes, etc.
  • The released driver can only do OpenGL. Which doesn't help much for the framebuffer-based app_server. We'll need a driver for that before even thinking about OpenGL.
  • The provided driver is OpenGLES only. This is a subset of OpenGL that removes a lot of "legacy" stuff from it. This means some apps that currently run fine with sofware rendering, will not run on this. The solution is adding back the missing parts of "full" OpenGL, redoing them by calling newer functions. Fortunately, apps are switching to OpenGL ES anyway, as all smartphones/tablets are using this one now.

So, yes, Haiku can become a first-class citizen on the Pi. But there is still quite a lot of work to do.

They also said that the firmware driver isn’t that great… so your opengl code has to work around the fact that the firmware doesn’t implement opengl well and its impossible to fix any real issues.

In any case its essentially a binary driver…however you look at it and should be considerd as such similar to if Haiku implemented interfaces to supprt say running the Nvidia blob. Which isn’t all that bad an idea since it works fast/well then again it isn’t open at all.

So to each his own.