Porting Haiku to ARM architecture | Haiku Project


#21

The idea is solid, and the code mostly done. We generate a “generic” arm image which is tweaked by “a tool” to inject board-centric bootloaders, etc.

The tool not being ready shouldn’t prevent you from working on the arm port. You just have to tweak the boot partition by hand. All Haiku arm images should look like this:

  • MBR
  1. "Blank space for silly AllWinner boards looking for a bootloader at a fixed offset. (not required except on AllWinner boards)
  2. 1st partition - FAT + boot stuff.
  3. 2nd partition - BeFS / Haiku image

The files needed on the first partition:

  • Bootable stuff for your board per this manifest
  • haiku_loader compiled from our sources.
  • fist full of compiled FDT’s from our sources.

The second partition is literally our compiled filesystem.

I’ve done a lot of legwork and the manifest above gives you everything “non-haiku” you need to get going.

Currently, the native fat rust code needs improved more. I’ve been hacking and improving, but it kind of turned into a skunkworks. I’ve been busily trying to complete our server move which has sucked up most of my time lately.

Help welcome! I’ve said this before, but I chose Rust because I wanted the image tool to run on multiple platforms with minimal modification since end-users will be using it as well as developers.

The possibility of a native Rust FAT driver also means there are almost zero dependencies. (aka, end users don’t need a user to install a bunch of requirements like fat filesystem tools, etc)


#22

I started following behind him and working on building Haiku with GCC 7.3 with changes that’ll be easier to upstream.
Lots of issues though, i’m currently stuck on an issue that “Shouldn’t happen” Feel free to help out!


#23

Hi @kallisti5
I took the latest code today from haiku repo and then builded it for arm.
then tried the same qemu command to emulate, it is still hanged at same MMU memory mapping.

mmu_map_identity: [ 80000000 - 80800000]
get_next_page_table, sNextPageTableAddress 0x1104c00, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105000, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105400, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105800, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105c00, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106000, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106400, sPageTableRegionEnd 0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106800, sPageTableRegionEnd 0x1300000, type 0x1

I think this bug need a fix at first.
Any idea over this ?


#24

A port of Haiku to Raspberry Pis is a perfect match. There are millions of these sold. They are underpowered, so a perfect fit for a light system like Haiku.

Looking forward to try this port!