haiku_loader.riscv was historically beginning of my Haiku RISC-V port and there will be no port without it.
(I will preface this explanation of the dispute at hand by noting that I am not an expert in these matters, and may get some things incorrect, etc.)
CPU architectures generally do not start in a mode where they are running standard instructions that they are documented with; instead, they usually start in some kind of “firmware” mode or something vaguely equivalent to it, and there is some program, embedded in the CPU or otherwise, that usually gets it out of this mode and into a more standard one, before invoking whatever the next boot step is.
On x86, this process is basically totally transparent to any OSes or even bootloaders; by the time any code an OS or bootloader developer has written is being run, the CPU is running in a regular and standard mode (when using MBR/BIOS booting on x86, this is usually … 16-bit real mode, emulating a good old 8088 or something close to it; it is the bootloader’s job to switch to 32-bit or 64-bit mode from there), and usually with some BIOS or other facility available to interact with hardware in a generic manner before you set up device drivers (e.g. IBM PC BIOS, EFI, U-Boot, etc.)
Generally, the layer that performs the truly early initialization and then provides the BIOS is CPU-specific, board-specific, and almost universally proprietary. Maybe it is technically reverse-engineer-able, or even documented, but modifying it is not trivial, and often not supported (“void your warranty”) and definitely not something OSes are ever in the business of doing. Such platforms are almost universally very machine-specific; on embedded platforms like RISC-V or ARM, they will often embed hardware addresses directly into the compiled loader, as there is no way of probing anything during this very early stage of booting.
On RISC-V, which is a truly open CPU platform, this lowest layer is actually officially documented (however, there are some major caveats even to this, it appears the specifications are deliberately looser about it, so this may not be such a strong guarantee), and so it is possible to write truly low-level boot platforms that do not rely on reverse engineering, at least in the abstract, instead of depending on a boot platform. X512 has written one of these, though it is limited to use in virtual machines (maybe just one virtual machine), and probably always will be; for any kind of real use on any bare metal device, either SBI, EFI, or some other like platform will have to be used as the bare metal device provides it.
So the question ultimately is, do we have a reason (if we are going to have to use SBI/EFI/etc. on bare metal, i.e. what Haiku is really geared at running on) to write, merge, and maintain a separate boot platform just for use in (maybe only one) virtual machine? That carries with it a lot of unknowns (for instance: developers that test on VMs may inadvertently break bare metal if they are using a totally different bootloader with different semantics) besides the added maintenance burden for unclear benefit. Hence why my own opinions, so far, side against this idea.
This is just a summary, I probably missed some things. But hopefully this makes the dispute more intelligible.
1 Like
haiku_loader.riscv runs on both TinyEMU and QEMU without modifications. Both virtual machines pass pointer to FDT in A1 register on CPU reset. It is used to detect virtual machine-specific hardware.
1 Like
OK, but that would still put us in the business for maintaining, on RISC-V, a level of bootloader we presently do not (or cannot) on any other architecture. That is no small thing, in my mind (especially if it is VM-specific, and there are alternatives available that are not VM-specific and that do not require us to maintain such a thing.)
1 Like
I agree. Haiku is different from Linux/BSD in many areas and I think that Haiku way is better. No need to bring Linux things and Linux way of thinking like u-boot. The only thing from u-boot we need is EFI.
For example Haiku boot loader is great that it can automatically scan and detect all discs containing Haiku kernel and allow user to select it in user-friendly interface. No configs at all! Unlike GRUB, Haiku loader can load kernel modules, configs and setup MMU so kernel is started with already prepared environment and kernel do not need to be recompiled for different boot drivers. No initramfs hack.
U-boot is a total disaster, it is major reason of ARM computer incompatibilities. It has terrible practice of compiling u-boot for specific combination with kernel. Linux has terrible practice of bringing very platform-dependent FDT table image with OS installation. On x86 such tables are usually located at BIOS ROM chip programmed by manufacturer.
For Haiku it is possible to just write image to USB and boot it on HiFive Unmatched board without any configs, FDT and SD card tricks.
In summary: Linux brings terrible importable and user-unfriendly practices that Haiku should not follow.
9 Likes
X512 has done amazing job and reached great achievements with his RISCV work. But his reluctance to the Jessica’s advice is hardly justified. You say, UEFI, uboot are bloated. but is it your concern? as a Haiku developer? would you deal with that? of course, no. In fact, no matter how “bloated” a UEFI implementation could seem to be, its interface provided to the OS Loader is super easy to understand and use. this is what an OS developer, creating the loader should and would care about. In this respect, using UEFI is the right way. Not to mention, all the future RISCV machines will be UEFI.
An I am happy with it, no more ugly u-boot. I use UEFI on HiFive Unmatched real hardware. But bare metal boot loader is more convenient to use on virtual machines especially when developing and testing kernel related parts. It is also nice that you aware of all code running on system, no unexpected behavior and easier testing.
7 Likes
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.
3 Likes
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).
4 Likes
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.
12 Likes
@waddlesplash put -2 on critical haiku_loader.riscv support code so I decided to stop updating Haiku patches on Gerrit for now.
https://review.haiku-os.org/c/haiku/+/4059/3#message-15df9b3aaa5645d8618a0a8932b585d356b8400d
3 Likes
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.
2 Likes
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!!
18 Likes
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.
16 Likes
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.
5 Likes