port

ARM progress!

Blog post by ithamar on Fri, 2012-11-09 19:04

The ARM is moving

After porting the basic VM code from X86 to our ARM port, it has been pretty much 2 years since I worked on it. Last weekend, BeGeistert 026, gave me a chance to work on it again, for a couple of days (nights?) in a row, and I tried to make the most of it.

Besides working on Haiku/ARM it was great to meet up with many of the people I already knew but had not seen for a long time, as well as finally meet the new people behind the names and posts I had followed over recent times.

Anyway, with much help from the people around me I was able to bring Haiku/ARM to the point where it now boots, lights up a couple of icons, and then fails to boot as the boot disk is not found. This means that scheduling, interrupts, and basic vm operations all work!

However, in the process of getting it that far in fairly limited time I had to make a couple of shortcuts that really need to be cleaned up before trying to bring up userland, and see Tracker/Deskbar appear ;)

Hardware Variation

One of the obvious ones is the problem that currently, the kernel will only run so far on the Verdex (Gumstick) target. This is due to the fact that things like timers and interrupts are handled differently between different System-On-Chips. This means that even at this very low level, we'll need to introduce some type of abstraction to be able to run on more then just the Verdex/PXA270 SoC.

As people reading the commit list might have noticed, Francois has commited basic code to support Flattened Device Tree (FDT). This is a way of describing full hardware layout, in a standardized format. This format has been used by OpenFirmware implementations, like the PowerPC machines from Apple, the DEC Alpha machines, and many more.

FDT is becoming mandatory for Linux support on ARM as well, which means there are more and more of these board description files available for hardware we want to run on. The intent therefore is to implement FDT support, making it (theoratically) possible to support newer hardware with only a new FDT file, but also being able to build a single kernel that can run on any ARM device, assuming the necessary drivers are available ofcourse.

If I can find the time, I'll write up a post about FDT, if Francois does not beat me to it ;) In docs/develop/ports/arm/urls.txt Francois was so kind to store an extensive list of URLs about FDT, so feel free to browse if you are interested in helping out.

Where's that page?

Another thing that needs work is the ARM VM implementation. Currently, all it really does, is the page table bookkeeping, but permissions are not handled, memory/caching types are not handled, not to mention that ARMv6 and ARMv7 support will need more work as well. My idea is to finish the VM for ARMv5 first, and then implement v6 and v7 support in a proper OO manner, by making subclasses of the base ARM VM classes.

ARMv5 has no builtin support of tracking page status bits that our VM expects (dirty/accessed), so we'll have to work around that. However, ARMv7 (and some ARMv6) do have that, so there's a fair amount of work to do.

Drivers and Busses

No I'm not talking of public transport here :P For a properly usable embedded ARM target, there's a lot of things besides the kernel proper that will need implementing. There's SPI and I2C controllers to support, there's storage like raw NAND, or MMC/SD to support, many things that aren't support as of yet in Haiku for other architectures.

Some of these will present new features for our non-ARM targets too (SD/MMC support will make Laptop users happy, I imagine), but quite few will not but will be critical to get a seriously usable system on ARM devices...

Where to go from here?

As the current target is a QEMU supported platform, anyone who wants to can join in and help out. I invite anyone interested in helping out with Haiku/ARM to follow the guide for compiling for ARM and start poking at the code. I tend to have very little time in general, payed work taking up the most of my time, so don't just wait for me to complete the port!

However, feel free to contact me with questions/flames/anything if you want, as I'll try and help out as much as I can, there's nothing I want more then for this port to reach completion!

Finally a Haiku ARM port update

Blog post by pfoetchen on Tue, 2009-08-18 13:46

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.

Helping on m68k

Blog post by mmu_man on Sun, 2008-08-03 22:17

As the m68k port is getting shape, maybe some of you want to give a hand, so here is how to set up the environment. After explaining the choice of the target platform we'll start with the build system, then the emulator to debug on the chosen platform.

getting to the kernel, 68k way

Blog post by mmu_man on Tue, 2008-07-22 00:50

Someday I should write about the start of the 68k port, there is plenty to talk about...
Today^Wnight^Wmornin erh, hmm well, now, I'll try to do a live report on the issue I left you with last time: getting the kernel to load correctly.

Updates on 68k port

Blog post by mmu_man on Mon, 2008-07-21 02:17

I've been getting further recently on the 68k port, as you may know already everything now compiles but the kernel is still largely stubbed, misses drivers, and the bootloader doesn't load it yet.
I've almost finished mmu setup, at least for the 040 ARAnyM emulates.

Git for Haiku (#1)

Blog post by nielx on Mon, 2008-04-21 14:25

I would like to announce the availability of the git revision control system. The git website describes it as:

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories; it is especially popular in the open source community, serving as a development platform for projects like the Linux Kernel, WINE or X.org.

Git falls in the category of distributed source code management tools, similar to e.g. Mercurial or Bazaar. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Still, Git stays extremely fast and space efficient.

This document describes how to install the git binary, and how to get the source.