My Haiku RISC-V port progress

I managed to build fully operational Haiku for x86_64: Why MergeObjectFromObjects1 rule is needed? - #21 by X512. But Clang build is not yet officially supported and it require some patches to produce working system. Haiku buildtools are GCC-based, there are no Clang-based buildtools for now.

10 Likes

Very cool!
I figured about the buildtools at least.

1 Like

Hi @X512, @Coldfirex has suggested we add the RISC-V port to the Haiku port status page (Haiku port status | Haiku Project), so I’m working on that right now.

Could you have a look at the ports tables already present and let me know what values the RISC-V ports entries would have? For example, the x86 ports table has the different platforms listed, the different targets, the status and the status of work on critical components like the app_server, so what would the RISC-V table list as platforms, what would be the different targets and the status of work?

1 Like

All 3 items (Haiku Loader, Haiku Kernel, Application Server) are working. TinyEMU (raw platform), Qemu (raw platform, SBI/EFI) are supported. Real hardware is not yet tested. Remaining major problems are partially broken libstdc++ and many packages not yet compiled such as Mesa, WebKit.

Most of kernel code is not yet submitted to Haiku source tree because cleanup is needed (removing temporary workarounds, code style cleanup). Only raw platform boot loader code (haiku_loader.riscv) is already submitted, but it is a bit obsolete for now (machine-mode services and MMU page table initialization were recently added).

Official nightly builds are not yet operational, I provided my own builds if someone want to test it (it is also a bit obsolete for now).

14 Likes

@X512 Thanks for the info, I’ve added your port to the ports status page. You can view the commit on GitHub here:

1 Like

AHCI (SATA disks) are working. The problem was here in “packed” struct attribute that cause per-byte access to MMIO registers instead of 32 bit access.

Also PCI register allocator was improved to support proper alignment (register addresses should be aligned with reported register size). Some hardcoding was removed.

PCI bus related kernel serial output:

pci_controller_init()
  reg[0]: (0x30000000, 0x10000000)
  interrupt-map:
    bus: 0, dev: 0, fn: 0, childIrq: 1, parentIrq: (3, 32)
    bus: 0, dev: 0, fn: 0, childIrq: 2, parentIrq: (3, 33)
    bus: 0, dev: 0, fn: 0, childIrq: 3, parentIrq: (3, 34)
    bus: 0, dev: 0, fn: 0, childIrq: 4, parentIrq: (3, 35)

    bus: 0, dev: 1, fn: 0, childIrq: 1, parentIrq: (3, 33)
    bus: 0, dev: 1, fn: 0, childIrq: 2, parentIrq: (3, 34)
    bus: 0, dev: 1, fn: 0, childIrq: 3, parentIrq: (3, 35)
    bus: 0, dev: 1, fn: 0, childIrq: 4, parentIrq: (3, 32)

    bus: 0, dev: 2, fn: 0, childIrq: 1, parentIrq: (3, 34)
    bus: 0, dev: 2, fn: 0, childIrq: 2, parentIrq: (3, 35)
    bus: 0, dev: 2, fn: 0, childIrq: 3, parentIrq: (3, 32)
    bus: 0, dev: 2, fn: 0, childIrq: 4, parentIrq: (3, 33)

    bus: 0, dev: 3, fn: 0, childIrq: 1, parentIrq: (3, 35)
    bus: 0, dev: 3, fn: 0, childIrq: 2, parentIrq: (3, 32)
    bus: 0, dev: 3, fn: 0, childIrq: 3, parentIrq: (3, 33)
    bus: 0, dev: 3, fn: 0, childIrq: 4, parentIrq: (3, 34)
  ranges:
    IOPORT (0x01000000): child: 00000000, parent: 03000000, len: 10000
    MMIO32 (0x02000000): child: 40010000, parent: 40010000, len: 3f000000
    MMIO64 (0x03000000): child: 400000000, parent: 400000000, len: 400000000
AllocRegs()
AllocRegsForDevice(bus: 0, device: 0, function: 0)
  bar[0]: MMIO32, adr: 0x0, size: 0x0
  bar[1]: MMIO32, adr: 0x0, size: 0x0
  bar[2]: MMIO32, adr: 0x0, size: 0x0
  bar[3]: MMIO32, adr: 0x0, size: 0x0
  bar[4]: MMIO32, adr: 0x0, size: 0x0
  bar[5]: MMIO32, adr: 0x0, size: 0x0
  rom_bar: adr: 0x0, size: 0x0
  intLine: 32
  intPin: -
AllocRegsForDevice(bus: 0, device: 1, function: 0)
  bar[0]: MMIO32, adr: 0x0, size: 0x1000000 -> 0x41000000
  bar[1]: IOPORT, adr: 0x0, size: 0x100 -> 0x100
  bar[2]: MMIO32, adr: 0x0, size: 0x4000 -> 0x42000000
  bar[3]: MMIO32, adr: 0x0, size: 0x0
  bar[4]: MMIO32, adr: 0x0, size: 0x0
  bar[5]: MMIO32, adr: 0x0, size: 0x0
  rom_bar: adr: 0x0, size: 0x10000 -> 0x42010000
  intLine: 33
  intPin: INTA#
AllocRegsForDevice(bus: 0, device: 2, function: 0)
  bar[0]: MMIO64, adr: 0x0, size: 0x4000 -> 0x400000000
  bar[2]: MMIO32, adr: 0x0, size: 0x0
  bar[3]: MMIO32, adr: 0x0, size: 0x0
  bar[4]: MMIO32, adr: 0x0, size: 0x0
  bar[5]: MMIO32, adr: 0x0, size: 0x0
  rom_bar: adr: 0x0, size: 0x0
  intLine: 34
  intPin: INTA#
AllocRegsForDevice(bus: 0, device: 3, function: 0)
  bar[0]: MMIO64, adr: 0x0, size: 0x4000 -> 0x400004000
  bar[2]: MMIO32, adr: 0x0, size: 0x0
  bar[3]: MMIO32, adr: 0x0, size: 0x0
  bar[4]: MMIO32, adr: 0x0, size: 0x0
  bar[5]: MMIO32, adr: 0x0, size: 0x0
  rom_bar: adr: 0x0, size: 0x0
  intLine: 35
  intPin: INTA#
AllocRegsForDevice(bus: 0, device: 4, function: 0)
  bar[0]: MMIO32, adr: 0x0, size: 0x0
  bar[1]: MMIO32, adr: 0x0, size: 0x0
  bar[2]: MMIO32, adr: 0x0, size: 0x0
  bar[3]: MMIO32, adr: 0x0, size: 0x0
  bar[4]: IOPORT, adr: 0x0, size: 0x20 -> 0x200
  bar[5]: MMIO32, adr: 0x0, size: 0x1000 -> 0x42020000
  rom_bar: adr: 0x0, size: 0x0
  intLine: 32
  intPin: INTA#
PCI: [dom 0, bus  0] bus   0, device  0, function  0: vendor 1b36, device 0008, revision 00
PCI:   class_base 06, class_function 00, class_api 00
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI:   interrupt_line 20, interrupt_pin 00, min_grant 00, max_latency 00
PCI:   base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: (not supported)
PCI: [dom 0, bus  0] bus   0, device  1, function  0: vendor 1002, device 5046, revision 00
PCI:   class_base 03, class_function 00, class_api 00
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 42010000, pci 42010000, size 00010000
PCI:   cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI:   interrupt_line 21, interrupt_pin 01, min_grant 00, max_latency 00
PCI:   base reg 0: host 41000000, pci 41000000, size 01000000, flags 08
PCI:   base reg 1: host 00000100, pci 00000100, size 00000100, flags 01
PCI:   base reg 2: host 42000000, pci 42000000, size 00004000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: (not supported)
PCI: [dom 0, bus  0] bus   0, device  2, function  0: vendor 1033, device 0194, revision 03
PCI:   class_base 0c, class_function 03, class_api 30
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI:   interrupt_line 22, interrupt_pin 01, min_grant 00, max_latency 00
PCI:   base reg 0: host 00000000, pci 00000000, size 00004000, flags 04
PCI:   base reg 1: host 00000004, pci 00000004, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: MSI-X, PCIe, MSI
PCI:   Extended capabilities: (empty list)
PCI: [dom 0, bus  0] bus   0, device  3, function  0: vendor 1b36, device 0010, revision 02
PCI:   class_base 01, class_function 08, class_api 02
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI:   interrupt_line 23, interrupt_pin 01, min_grant 00, max_latency 00
PCI:   base reg 0: host 00004000, pci 00004000, size 00004000, flags 04
PCI:   base reg 1: host 00000004, pci 00000004, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   Capabilities: MSI-X, PCIe
PCI:   Extended capabilities: (empty list)
PCI: [dom 0, bus  0] bus   0, device  4, function  0: vendor 8086, device 2922, revision 02
PCI:   class_base 01, class_function 06, class_api 01
PCI:   line_size 00, latency 00, header_type 00, BIST 00
PCI:   ROM base host 00000000, pci 00000000, size 00000000
PCI:   cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI:   interrupt_line 20, interrupt_pin 01, min_grant 00, max_latency 00
PCI:   base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI:   base reg 4: host 00000200, pci 00000200, size 00000020, flags 01
PCI:   base reg 5: host 42020000, pci 42020000, size 00001000, flags 00
PCI:   Capabilities: MSI, SATA

screenshot87

32 Likes

I get swapped kernel and user address space ranges working. Now kernel can use high addresses and user can use low addresses as it usually done. Address ranges can be configured here (some address ranges hardcoding was removed), system still can be compiled and run with old address ranges. problem was addressed here and here.

It do not affect userland applications binary compatibility, but it affects kernel modules because of IS_USER_ADDRESS/IS_KERNEL_ADDRESS macro.

screenshot88

23 Likes

i get the feeling when you are done, many bugs from hardcoded structures will be fixed.

again, your work is inspiring and appreciated

5 Likes

IMO the RISC-V port status is misleading (everything is green), I would amend at least “Under development in a developer branch”, so that no one expects something buildable in the master branch.

2 Likes

Maybe. Someone can add this note.

You can checkout to hrev55144, apply patchset and compile operational RISC-V system.

8 Likes

I’ll edit that page on the website.

I made some video showing development and testing process:

23 Likes

Just a quick status update. After the relation chain in http://review.haiku-os.org/c/haiku/+/4435 is reviewed and merged, stock nightly images should boot on the SiFive Unmatched!

There will be bugs to hammer out… and SMP still needs completed, but this represents the first non-x86 architecture port which fully boots to a desktop!!!

Nice work @X512 !!!

48 Likes

Nice work to you too, and thanks for reviewing/cleaning/merging the patches and bringing it up to what it is now.

13 Likes

This is absolutely wonderful work.
Thank you to everyone involved at Haiku.
It was great to see X512’s fruits of labour on YouTube!!

Back in the day I ran BeOS on a twin Celeron Abit (I believe) motherboard and was thrilled by the fun factor and performance of BeOS. Haiku btw is now on my laptop.

Like others on this thread I to am waiting for the HighFive motherboard to arrive. The risk-v ISA is the future. BeOS should have been an overwhelming success all those years ago but failed on the x86 platform, Haiku developers can now take this rewritten OS to new levels, especially on risk-v architecture. The publicity for Haiku will be fantastic.

Kudos to you all

11 Likes

This is pretty cool! I would like to see the teapot spin :slight_smile:

2 Likes

Fixed running latest Haiku revision for riscv64 by downgrading to icu-57.2.2. Current haikuports.cross icu-67 riscv64 build seems broken.

screenshot230

31 Likes

icu67 is broken for all working architectures according to https://github.com/haikuports/haikuports/blob/master/dev-libs/icu/icu67-67.1.recipe

probably icu66 should be used for now (in both bootstrap and non-bootstrap).

4 Likes

Yet another RISC-V virtual machine that theoretically can be used with Haiku.

GitHub - LekKit/RVVM: The RISC-V Virtual Machine :

RVVM - The RISC-V Virtual Machine

RISC-V CPU & System software implementation written in С

TODO

  • Test FreeBSD, Haiku (FreeBSD generic kernel boots but i have no idea how to mount rootfs, too lazy to look at Haiku)
5 Likes

haiku_loader.riscv

17 Likes