My Haiku RISC-V port progress

Development OS
#156

I see no major problems to add more boot loader platforms when system is already working on virtual machine. “Bare metal” boot loader has a huge advantage that it is starting fast (less than second from starting emulator to boot splash), have no 3rd party dependencies (it may be hard to configure and build on Haiku) and provide big freedom to control hardware.

RISC-V seems to use OpenSBI, that is yet another platform. I don’t know how UEFI can manage RISC-V machine mode stuff (timers, SMP etc.).

2 Likes
#157

Guys I’d say stick with RISC-V! It’s totally open, SiFive and BeagleBoard have them, and unlike arm there aren’t a ton of boards to try to support — it’d be the best path for getting R1 to something outside x86/64! And what @X512 has done is super crazy amazing!

4 Likes
#158

I hate to rain on your parade but with GPU support being up soon on the agenda, do the RISC-V boards you want to target have open-source drivers without binary blobs? (I would like to hope so but without checking, you never know…)

#159

SiFive HiFive Unmatched can use PCI-E 3.0 devices, so that would mean prolly AMD discrete GPUs being the best possible options in the long term unless the upcoming Xe cards from Intel prove to be easier to support.

The other boards don’t have GPUs, can’t support GPUs, or have video encoders/decoders at most.

The main issues with RISC-V SBCs will prolly be supporting the various specialized chips in them, such as AI or deep learning chips. The only RISC-V board that does support proper GPUs (AFAICT) is the HiFive Unmatched via PCI-E 3.0, so it shouldn’t hopefully be too difficult to bring over support from x86/x86_64 which also uses that standard.

#160

It have, but DRM port is still needed as in x86. Personally I don’t play games with heavy 3D graphics so I don’t get trouble a lot without hardware 3D acceleration. I hope that setting framebuffer on real hardware will be not so difficult.

3 Likes
#161

After implemening fork() and fixing problems with page table (stupid mistake in RISCV64VMTranslationMap::Protect(), it only added new protection flags but never removed, causing broken copy on write) Terminal is now working. But I currently use Lua as shell instead of Bash because it is easier to compile.

screenshot56

19 Likes
#162

After implementing fork() regular Haiku startup sequence with 2 launch_daemon is working. But one of launch_daemon crashes because it can’t run /bin/sh (it don’t exist yet). It can be a bug in launch_daemon so it don’t properly handle errors when launching processes.

Now desktop launch hacks can be removed. Before that Tracker and Deskbar were launched directly from kernel like launch_daemon. Also waiting for app_server was implemented.

vm_soft_fault: va 0x0 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x0, ip 0x0, write 0, user 1, thread 0x134
STrap(exception execPageFault)
  sstatus: (ie: {u}, pie: {s}, spp: u, fs: 3, sum: 1)
  sepc: <commpage> 0x0
  sie: {sTimer, sExtern}
  sip: {}
  sscratch: 0x97, 0x81292a00
  tp: 0x81292680(main worker)
Stack:
FP: 0x8077fb60
FP: 0x8077fc50, PC: <kernel_riscv64> vm_page_fault + 319
FP: 0x8077fd30, PC: <kernel_riscv64> STrap + 247
FP: 0x8077fe30, PC: <kernel_riscv64> SVecU + 109
FP: 0xffffffe0744a2ea0, PC: 0xffffffffffffffff
FP: 0xffffffe0744a2ee0, PC: <libbe.so> _ZN11BSupportKit8BPrivate8JobQueue9JobFailedEPNS_4BJobE + 59
FP: 0xffffffe0744a2f30, PC: <libbe.so> _ZN11BSupportKit4BJob20NotifyStateListenersEv + 153
FP: 0xffffffe0744a2f50, PC: <libbe.so> _ZN11BSupportKit4BJob3RunEv + 79
FP: 0xffffffe0744a2f70, PC: <_APP_> _ZN3Job3RunEv + 17
FP: 0xffffffe0744a2fc0, PC: <_APP_> _ZN6Worker7ProcessEv + 79
FP: 0xffffffe0744a2fe0, PC: <_APP_> _ZN6Worker8_ProcessEPv + 19
FP: 0xffffffe0744a3000, PC: <libroot.so> _thread_do_exit_work + 107
FP: 0x8077fe60, PC: <kernel_riscv64> arch_thread_enter_userspace + 189
FP: 0x8077ff90, PC: <kernel_riscv64> _ZL15enter_userspacePN7BKernel6ThreadEP24UserThreadEntryArguments + 67
FP: 0x8077ffb0, PC: <kernel_riscv64> _ZL19common_thread_entryPv + 77
FP: 0x0, PC: <kernel_riscv64> arch_thread_entry + 3
8 Likes
#163

I published revision 2. Now it mostly usable, most things are working.

Note that TinyEMU is changed, new patch version is needed if running on non 32 bit x86.


14 Likes
#164

Can confirm that the patch works; filed a PR with it for TinyEMU along with a screenshot of your rev2 working in a x86-64 Haiku install:

2 Likes
#165
  1. AMD Radeon graphics:
    Note: Provide, utilize, and support the Mesa Radeon 3D driver graphic stack DRM/DRI implementation.

As for the 3D gaming comments as the only factor for video hardware acceleration let’s consider that more business-minded people are looking at data modeling, medical, academia, font rendering, engineering projects (using CAD/CAM), multimedia, simulations, etc. - not focused with the ‘gaming’ mindset as a primary reason of use or purpose. :wink:

5 Likes
#166

This is definitely a major niche Haiku can fill. I like x86_64 and RISC-V for Haiku’s user base, especially since RISC-V is the future!

1 Like
#167

100% Accurate. The reason I started to focus on EFI for ARM/RISC-V was that EFI gives us a cross-platform set of BIOS services which enables us to focus on getting Haiku running on an architecture vs focusing on Haiku running on a board. Previously we built 5-6 different Haiku ARM images for 5-6 different boards. Each came with all the needed “mini-drivers” (PL011 serial, VideoCore brand frame buffer, etc) embedded in our u-boot loader. That meant we needed to support “all the things” duplicated within the bootloader. Now all we have to do is call EFI’s printf, etc until our kernel is loaded. Then our standard add-on kernel drivers take over.

The funny thing is, even u-boot is moving away from their own bootloader process. u-boot offers EFI bios services now across all architectures (instead of boot haiku_loader.ub, you do bootefi haiku_loader.efi)

EFI is really Microsofty, but it also is a standard that expanded to cover all the architectures which is something that was badly needed.

No more “per-board” Haiku images. Everything now can be “generic”. (there are exceptions, for example ARM 32-bit images need customized with a custom u-boot loader per SoC and (sometimes) board-specific binary blobs… that’s what the rune tool is for)

4 Likes
#168

Why not just select single virtual machine configuration and make Haiku working on it? Why jump between 5-6 different platforms when even userland is not working? It makes sense to just select “virt” machine like here.

I agree that EFI is a great thing that allows unified boot process, but it is mostly useful on real hardware, not emulated. It is not required for early OS porting process. Starting EFI firmware is slow (EDK2 takes several seconds and a lot of debug output), haiku_loader.riscv finish in a less than second. Speed is important for trial and error.

It took few days for me to make haiku_loader working on bare virtual hardware, adding new boards is not that difficult.

Linux on virtual machines also rarely use EFI, it can boot form Qemu directly without boot loader by using -kernel and -initrd arguments.

5 Likes
#169

Of course long term EFI is needed but as X512 says, short term it seems like a lot more progress can be made by focusing on virt hardware and a simple bootloader. Obviously this thread shows it is viable for RISC-V, and I think it is viable for ARM too.

I don’t think currents efforts on a Haiku ARM port with EFI are wasted, but if that is removed as a bottleneck I think a lot could be done. Again, we don’t need to guess, we can see what happened here with RISC-V. Focusing on virt hardware means some device specific quirks are taken out of the picture and the fundamentals of the port can be handled.

Also it can provide some division of work: some people can focus on booting and EFI on real hardware while others work on the kernel and userland using virt.

Anyhow, I don’t think this thread should be seen as a “you have been doing it wrong” criticism, but more like “OK, nice, this different approach works, maybe we should give that a try for ARM too, and we can work out EFI later or in parallel.”

Personally I’m learning what I can about baremetal ARM development so maybe I can help out on this, but I want to learn the basics and maybe even have a little mini-OS like X512 did, before I jump into trying to make a more complex OS like Haiku work.

12 Likes
#170

I never disagreed with that… I’ve only been full of praise :wink:

2 Likes
#171

As you say yourself, there is no bottleneck. Work can be divided. If someone wants to work on ARM in a virtualized environment, they can. If someone wants to make our EFI loader working on ARM, they also can. Both things need to be done eventually, and both are helpful.

The main bottleneck here is clearly that we have not enough developers, as usual :slight_smile:

4 Likes
#172

Yeah, I even feel guilty even mentioning looking into this “shiny” new thing (shiny and new for me at least) when I already have many other things I have said I would work on which I am not. Though I am much more serious about getting a proper Haiku dev environment set up than I have been in the past. Sometimes the “shiny” helps in that.

#173

amazing, RiscV had huge potential, Haiku being a complete system, massive

#174

Sounds good. Than better the Haiku dev environlment, than better the dev experience to get more of them interested. I am not a programmer or dev but I see the importance of a great developer experience.

#175

My dev environment is Pe editor (with some patches) and Terminal. It is handy that you can click compiler errors in Terminal and it will be selected in Pe. Also Pe allows simple code navigation and blocks with //#pragma mark <block name>. Other tools are Tracker with multi-window mode and menu navigation, TextSearch, my disassembly and module analysis framework on Blackbox (works only on 32 bit so I use 32 bit Haiku).

6 Likes