My progress on real RISC-V hardware

Which you can never say about Linux. It is so bloated that nobody can know more than a tiny fraction of it.

But yeah, let’s do it like Linux! /s

Some people respect their freedom and select open solutions instead like CoreBoot. It it weird to claim open architecture, but force specific solutions. Open architecture means that you can do anything with it regardless of any opinion and you have access to all documentation and source code.

But of course it is unrelated to haiku_loader.riscv, it is currently pure virtual machine solution.


the argument was not about this. it was about not using a processor mode, intended to be used by only a very machine/platform specific (early) part of firmware and not intended for using by the OS loader. the main practical reason is not even "we don’t like doing like this), but the fact, this code surely will be very different on every SoC family, on every platform, vendor etc. it belongs to such deep FW guts, that for the OS loader, there is really no benefit to get into that. in other words, this code will be only relevant to this particular narrow target set (Qemu, TinyEmu virt). for other targets, the loader arrangement will be absolutely different (UEFI app). is this divergence good in the tree?

It is really small difference in kernel handling for “riscv” and “sbi” (values of “platform1” kernel args). I see no problems in maintaining it. Difference between x86 BIOS and UEFI is much bigger (even 8086 virtual machine is included for BIOS) and it is still maintained.

MSyscall interface currently has only one syscall for kernel usage to set timer interrupt (and it is better designed than SBI, SBI have no direct ability to disable timer).


I think the biggest problem here is that @X512 has done a huge amount of work to support a new architecture, and this seems like an unimportant argument not directly related to the core haiku codebase. Of course code committed to haiku has to meet haiku standards and pass review, but isn’t this particular issue something that could perhaps be addressed later if necessary? It does seem to me that the most likely person to be maintaining this code is @X512 in any case. Continuing the argument seems like a fast way to alienate a talented and highly motivated contributor.


@waddlesplash put -2 on critical haiku_loader.riscv support code so I decided to stop updating Haiku patches on Gerrit for now.


A -2 does not mean “this will never be merged”. It means “this should not be merged at present”; in this case, it means that I think the discussions at hand are significant enough that we need to resolve them and reach some kind of consensus before the change is merged. That’s all: no more and no less. It is just to ensure the change is not merged until that is taken care of.

I have previously placed -2s on my own patches, patches of other developers, etc. and of course the discussions are eventually resolved and the patches are merged (or resolved in favor of abandoning the patch for some other strategy.) I am not sure why you are seeing this any differently.


To me, I think this boils down to what @Munchausen said… and it is very clear to me, so I’m not sure what the argument that justifies all of this is…

On the left side we have - “code that an external developer is not happy with”, but that works and boots to a desktop. This is the first non x86/x86_64 port. This is the first time we have an alternative processor booting to a GUI and more or less working desktop. We have a motivated developer who actually can make the port work, and improve the port to being a first class Haiku platform.

On the right side we have pedantry, It is not the way someone wants it to be and this will block the commit. This will demotivate @X512, and might completely derail the RISKV port (something that actually got press and brought a few extra eyes on to the Haiku project.)

Is losing @X512 worth it? I have to ask both @waddlesplash and @PulkoMandy. Is it worth destroying the first port to another architecture that actiually had legs and didn’t stall because the dev was not able to make it boot? Is it worth it?

Accept the patches, agree to put in a schedule to review this alternate method, let RISCV mature and then worry about it. Seriously guys, WAKE UP CALL!!


Wow, yrs and yes I totally agree here…

I love @X512. Work!
What a pleasure to have BeOs like devs.
No fear go get it, make it work!

This work is extremely encouraging to develop
on Haiku!

How am I on that side of the argument now?

I said that I think the code should be merged as it is now because it is not getting in anyone way.

Also, it is not even needed to boot Haiku on real hardware, it’s just there for testing with TinyEmu and won’t be used for anything else, as QEMU and real hardware both come with firmware that allows us to boot Haiku in much simpler ways. So this is all a very minor detail that no one should care about.

What am I annoyed here is everyone who is going sentimental, threatening to leave the project, using authority arguments in the line of “that’s not how its done”, and also bringing this discussion in all places (it was on gerrit, now on the forum, and also on the IRC channels). I think everyone is behaving badly in some or all of these aspects.

Can everyone just stop discussing this for a few hours or days, take a breathe, and we can resule the discussion on a more calm mindset? Because otherwise this is just a useless flamewar over a single 10-line patch, and one that isn’t even planned to be used on real hardware. And frankly it’s not worth the emotional drag and energy that everyone puts into it.


No worries - It was a lot to take in and I might have mis remembered something a long the way.

I use haiku_loader.riscv on QEMU too as primary boot method. SBI/UEFI is used only on real hardware. I can’t silence that damn timeout counter in u-boot, it probably needs recompiling that currently fails on Haiku. Even without counter it is quite slower than haiku_loader.riscv.

Only haiku_loader.riscv allows to setup framebuffer and display Haiku kernel bootsplash both on TinyEMU (simple-framebuffer) and QEMU (fwcfg ramfb). u-boot can’t, it have no compatible video drivers. EDK2 will probably have QEMU-compatible GOP video drivers.


Ok. I’ll pick up work on them them, fix the style issues, and merge them.


Please don’t hurry. Some patches also change common kernel code that should be discussed (added generic kernel access to user memory handing to page fault handler). “Non-arch changes” contains a lot of hacks that can affect x86.


I’ll take my time working my way up from the bottom. Please feel free to ping me in matrix if you want me to hold on something.


At least compilation of riscv64 and x86 should be checked. Non-arch changes should take special attention. PCI driver will need more work. Feel free to ask why specific solutions are used in code.


I don’t have a horse in this race so I don’t have a strong opinion on this either way. My understanding is that once the riscv port is running on real hardware as opposed to a vm then a more traditional boot loader will be used, yet the haiku_loader.riscv will still be useful for testing in a vm. It is important to have thick skin and not allow a -2 or two to derail you and to try and keep your emotions in check.

I’m still waiting for BeagleV boards to become available. It seems that a few lucky/connected individuals have already received test units, but the general release has been delayed until November 2021. Anybody else interested in BeagleV once it becomes available? I’d be willing to donate a board or two to help the development effort.

Kallisti5 said that he’s already got the more expensive and available HiFi Unmatched board, so he’s good to go. But for the rest of us the BeagleV seems like a cheaper alternative to getting a riscv box.

Any interest in a BeagleV board X512?

1 Like

It is delayed. Production planned next year. Maybe Sipeed Nezha Allwinner D1 can be interested instead. It is actually produced, it have enough resource to run Haiku and it have GPU.


Interesting, then how was this possible (below), @kallisti5 ? sorry for bugging by this, but I really need to know. :smiley:

1 Like

Interesting. What QEMU and u-boot version are you using? How u-boot compiled?

Stop, I see scrolling on the right side, is this really framebuffer and not UART output? As far I remember, u-boot has only simple-framebuffer video driver that is not supported by QEMU, simple-framebuffer is supported only by TinyEMU. And it need to be enabled during u-boot compilation.