Yes. It can use HPKG, but it makes test cycle much longer because I need to fully rebuild haiku.hpkg on each change. Currently I compile only selected targets and upload it with a script that use bfs_shell.
2 Likes
Bash is currently not compiled and it is not present in Haiku source. HaikuPorts cross-compiling is needed.
It is funny that GUI is implemented before console. When making/porting OSes console is usually implemented first. But my first thing to do is setup and output something to framebuffer 
13 Likes
Thats so sweet
6 Likes
Most things are working, system is quite stable. Now applications crash show error dialog instead of KDL. Also after removing no more needed workarounds (fully allocate stack memory instead of allocating on demand by page fault handler) memory usage was reduced.
Maybe I release revision 2 soon that will be much more useable than revision 1.
What is still not working:
-
Terminal. Crashes because of “Failed to init pseudo tty”.Done. -
Write to file system and shutdown because of unimplemented page table API (Done. Shutdown and writing to file system is working.RISCV64VMTranslationMap::ClearFlags). -
plaintextlocale add-on. Probably needslibstdc++.sorebuild. -
Userland signal frames.Done. - Userland debugger.
-
SecondDone.launch_daemonis not starting. Probably problem withfork()call. It cause need of special hacks to start Tracker and Deskbar.
37 Likes
I think you broke discuss :D
1 Like
Even VirtIO network adapter is recognized. But network is not working because of missing API in host Haiku system required by TinyEMU. Network may work if compile and run TinyEMU on Linux.
26 Likes
I guess another question related to this port is whether this bare-metal approach would also be a faster way to get the ARM port working, but using QEMU rather than TinyEMU. I feel like a lot of the issues in this port might also apply to ARM.
I don’t know if all our apparent difficultly with the ARM port has been just taking the wrong approach and fighting with bootloaders and UEFI, or if X512 just happened to prepare himself better for this task (with the mini OS) and was more persistent in fixing issues, which obviously there were a lot.
I really like RISC-V, like many computer enthusiasts, but practically speaking right now Haiku would be more useful on ARM, especially on something like the Raspberry Pi 4.
But this work is still really exciting, and it shows that Haiku can indeed work on non-x86 platforms, and also sets the stage for Haiku to be a first class option on real RISC-V computers (with some more driver and bootloader work, of course.)
21 Likes
Not sure about RISC-V boards, but ARM boards can get quite weird with the booting process. For example, Raspberry Pi hardware is initialized by the GPU. Knowing that, perhaps it may indeed be better to get ARM ports working in emulators before moving on to bare metal; that is where adaptations regarding all of the different booting quirks are needed and where the ARM ports are seemingly stuck in.
Something else to consider is that there are people in the community capable of doing porting and those who have the hardware targeted for ports. Unfortunately, these groups are not always one and the same. Perhaps something can be done to get these folks working together? It’s far from ideal compared to a porter having hardware themselves, but it’s at least something.
1 Like
I don’t think ARM is that far off. The UEFI ARM code has the following problems:
- UEFI for 32 bit ARM doesn’t allow FPU, but all boot packages are compiled with hard float.
- 32 bit UEFI needs the same memory handling for loading ELF binaries, as we can’t map virtual addresses.
This is what 64 bit does. There are some more similar changes needed I think. - Setup MMU
- Drivers
For ARM 64, I’ve been working on building the boot packages, which I am still a bit stuck on. I don’t have any up to date info on what the failure was, so need to redo setup.
2 Likes
You have no choice if you want to run on real hardware. This approach of skipping the low level bootloader is reasonable on emulators, but not so much on real hardware because you end up having to do all the work of the bootloader yourself, super low level things such as configuring RAM timings, etc.
We are not fighting bootloaders, we are using them to get one part of the job done. In the past we have tried u-boot, we found out that it is not so great at doing this job, which is why, now we are going with EFI, which is the recommended way for 64bit ARM and getting quite popular even on 32bit ARM now.
The same work will have to be done for RISC-V as well eventually to run on any kind of real hardware.
2 Likes
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
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
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…)
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.
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
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.
19 Likes
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
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
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
- 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. 
5 Likes