progress report

The ARM keeps moving...

Blog post by ithamar on Thu, 2012-11-22 20:58

The ARM keeps moving...

For people not watching the commit list closely, I've continued to find time to work on Haiku/ARM. So far, things look promising. No new screenshots of any kind though, but more investigation work done to get an idea of what I'm getting myself into. All in all, I'm actually quite pleased...

In my local repository (of which most is actually in the Haiku repository as well, bar some really nasty hacks that not even I dare to commit publicly) I've been able to get to the point where all content for a standard Haiku image is being built (the famous haiku-image target, for the devs reading this). Ofcourse, lots of architecture specific stuff is still stubbed out, but it means that at least there are no surprises lurking to get things to compile at least...

Since I've got a little more confidence in the amount of work needed to get Haiku/ARM up and running on at least a single target, I'll be writing up a proposal for a Haiku, Inc contract. This contract would enable me to focus more on Haiku/ARM for a longer stretch, reserve time in my schedule, with as a target getting some form of basic userland running on a single Haiku/ARM target. From start of next year I should be able to dedicate more time to Haiku/ARM if the contract proposal would get accepted.

Now, I'm not certain I'll commit to any specific target. For the moment, I'm considering to stick to QEMU/Verdex as my main target, but I might switch to some real hardware if needed. Also, some kind of userland could simply be a working "bash" shell, but ofcourse my real hope is to get far enough to see app_server up and running, with Tracker/Deskbar greeting us....

Anyway, short version is that I'm hoping to get Haiku/ARM far enough to make it very easy for other people to join in and port Haiku/ARM to their favorite device, with as little work as possible. It should become as easy as adding hardware support to Haiku/x86, if all goes well.

Time to get back to that source tree.... ;)

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!

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.

Sub-pixel antialiasing report #1 [GSoC]

Blog post by Andrej Spielmann on Thu, 2008-06-26 14:06

The first month of GSoC coding period is almost over and it's time for a summary.
This month wasn't particularly easy. I was working hard to distribute my effort between Haiku and my exams accordingly. I must confess, I was probably doing more schoolwork than Haiku :-)
Nevertheless, I did make some progress and now I am very happy to announce some of the first actual results of my project!