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.
The ARM architecture seems to have a growing fan base. The Raspberry Pi and EOMA68 platforms are ARM based. There are even a few ARM based Arduinos floating around out there. The power, flexibility, and low cost of the ARM architecture, coupled with low energy dissipation, make it well suited to hacker/user friendly hardware platforms.
Several features of the Raspberry Pi especially, scream miniature BeBox. User programmable digital and analog I/O pins (think GeekPort,) and LED lights (das Blinkenlights) are a sure sign of this lineage.
The EOMA68 platform is a highly modular, open source hardware platform. It boasts an ecofriendly design concept where parts can be developed and 3d printed or otherwise made by users in the field. This opens up the possibility of locally recycled computers. Plastics can readily be reprocessed into injection molded parts and 3d printer filament by simple and inexpensive processes. This helps boost local economies while reducing our wastestream footprint.
These technologies are very in line with what I believe to be Haiku’s core principles that decended from Be Inc’s earlier philosophies that drew so many near and dear to the much beloved operating system. This is a sleek, efficient operating system that is both hacker and user friendly.
I’m not saying that the venerable x86 architecture should be abandoned just yet. I do think that supporting the ARM architecture would open up Haiku to the affordable hacker hardware of the future and present. This would help draw much needed development skills to Haiku.
I’m really not interested in that. What I like about Haiku is that it focuses on desktop computers. It is designed to be used efficiently with keyboard and mouse.
Look at what happened to GNOME when they tried to do both desktops and tablets. The result is clumsy on both.
If you are after a tablet oriented OS, I would say there is no use in carrying the BeOS legacy. But let’s see what Google is up to with Fuchsia/Magenta/Zircon, I suspect their plan is to go where Haiku doesn’t
I like the idea of Haiku desktop on tablet. Actually Haiku can be the only desktop OS on tablet. For this Haiku needs only some system of gestures to manage apps windows, workspaces and etc. Also there can be some app launcher like “BeFull”.
…there can be said that some system of gestures for managing apps windows and etc Haiku needs anyway.
This was a blog post from 2009. Just throwing that out there
We have a generic ARM image now and I have a tool (80% complete) to prepare images for any target board… we just need people to help out in the ARM port.
Rather confusing as one would not know that this was a “refresh” from 2009 unless reading the full blog post it-self from the link.
While a blog post from the past can be relevant and worthy of being brought back to the attention of the community, there should be a way to indicate that this is a refresh.
The same is felt when dealing with the Windows 10 user interface on a system without a touch screen! Even Google just created a wormholehack enabling Android Apps on ChromeOS rather than merging the two distinct user interface metaphors into one operating system.
Nevertheless, once the ARM port is finalized, it would not be surprising that some rogue/wild developers attempt to adapt Haiku to the virtual keyboard/mouse constraints of a tablet.
As I said, I doubt Haiku is the best choice to build such a thing. Our ARM port is still in the early days, we barely have any power management, the UI would need to be replaced,…
There are better alternatives out there for people willing to build a tablet OS.
I’m not interested in tablets either. My interest is in SBCs for creating small, portable, inexpensive computing devices with a desktop operating system. ARMs are cheap, multi-core chips that rival the average desktop/laptop power available in BeOS heyday. Haiku, theoretically is perfect for this. There isn’t much legacy software that I’m interested in. Except perhaps SoundPlay, but for these devices, I’m not interested in that. I’m getting back into coding. I’m glad to see an ARM port underway. Much has happened since WalterCon 1 in 2004.
I really don’t like the idea of Haiku tablets. I’m pretty sure tablets had something to do with Be Incorporated going belly up. Among other things.
I could envision a Haiku like system based on the Haiku API running on tablets. I’m thinking the system could be extended to support tablet UI stuff without changing the core system. I don’t think those extensions should be part of Haiku itself.
Most people think of the ARM processors as “tablet only”, or “embedded systems only” processors. This just is not true. It is a flexible chip architecture that now rivals what AMD and Intel were doing back when Be Inc. still had a future. Believe it or not, there is a whole lot you can do with it, especially when you get into an operating system that was designed from the ground up as a pervasively multi-threaded that ran great on RISC processors. Especially multi-core processors. Now if only such an operating system existed.
I wonder what would have been if ARM had been a bit more mature like the PowerPC was when Be got started.
Hi @kallisti5,
Good to see this, I happened to work on RPI sometime back, but due to other work i wasn’t able to work,
In my view if you can create a task list, i am happy to pick one of it and can try to fix it.
Because when i see the port from an angle it looks like a huge heap Better to break the tasks in modules and we can make Rpi to work with haiku.
@RahulAN I’m also definitely interested in a functioning ARM port too, though it appears that someone else has made some interesting improvements to the 32 bit ARM port and added initial AArch64 support with a newer GCC toolchain a while back in the mailing list and is still continuing the port on GitHub if you’re interested in his patches.
But do note that it cannot be upstreamed ‘as-is’, due to various changes listed here in his port however. I haven’t had the time to build his ARMv7/AArch64 port, but I’d argue that his patches might help fix some of the issues related to the RPi 2 booting past the kernel (MMU issues and the missing SDHCI MMC driver).
@return_0e I was trying to fix MMU in past. here
I will check with linked patch. And will try to come back on it
What is the status of @kallisti5 Arm port Rework?
i need it for a orange pi at least.
