If anyone is familiar with CoreBoot compatible flash firmware, what would it take to build a modern Haiku rig with most of the OS in the startup “BIOS” rather than UEFI or something similar?
It would be hard to do. Some boards have at most 32MB of flash while most only have 1-2MB meaning haiku won’t fit… The bare kernel might fit dunno but haiku’s base package is about 50ish mb
I’m considering getting a kgpe-d16 board and playing with that… Haiku will definitely be tested on coreboot!
I think this would make the machine more annoying to update and have no clear gain. Probably putting the haiku_loader there directly would be nice, however.
Yeah the auto update woudn’t handle it… you’d have to use flashrom to upload to the flash and it would be slower.
That said you might not be able to see the bootloader… depending on if coreboot inits your card correctly or not. In some cases it only comes up after the Linux driver gets a hold of it (which is why you want your whole kernel in rom).
My laptop that I use with Haiku on metal is a System 76 Oryx Pro 5, which just gained CoreBoot support! I’m wondering, has anyone been able to use CoreBoot with Haiku, or should I hold off on updating the firmware?
Considering we’re still in beta, holding off might be advisable.
I don’t think there is any logical reason CoreBoot would not be a fine firmware to use for a Haiku box, but it may require changes in both the CoreBoot and Haiku side to get it working well. I bet if done well it would mean a blazing fast boot time.
It is probably just a matter of a developer giving it a try. I have interest in learning more about firmware but cannot make any promises about this in relation to Haiku.
The System76 embedded controller is also interesting and I suspect it would not be too hard to add some Haiku drivers for that to control the devices it manages, like the fans and keyboard.
That’s good to hear! Recreating the fast boot times of the Amiga with its custom Kickstart ROM may be a possibility. In 2011 there was a Coreboot payload for the Broadway distribution of AROS and would boot in less than a second. Of course AROS ABI v0 lacked memory protection and other modern staples of computing (as did the Amiga which it was based on).
In the case of Haiku, the only phase that will be sped up is loading the bootloader. That’s the time spent before showing the splash screen. After that we still have to do all the kernel loading and startup.
This is because our kernel actually expects the bootloader to do a lot of the early hardware setup, in particular, setting up the MMU. This is not what is done, for example, in Linux, where all this code is in the kernel.
So, it’s not the (only) key to <1second booting. We have a lot more work to do there.
In my RISC-V port MMU is setup by kernel in
arch_vm_translation_map.cpp. haiku_loader.riscv don’t use MMU.
Since I posted my last message I have been doing research into coreboot. I may try to get one or two cheap devices (maybe ChromeOS devices) to experiment with in general to learn more low-level things but also of course in the context of Haiku.
IMO Haiku should try to be more like Linux and do as much as it can itself, though maybe setting up an MMU has device specific quirks that is easier to depend on the bootloader for. I’m sure getting a few specific devices to boot with a minimal coreboot payload is possible but maybe general support is more difficult
I will say that based on watching various Youtube videos many people outside the community think Haiku boots really fast and I think the only OS that comes even close is ChromeOS, which of course uses a super minimal coreboot. I’m not sure what others tricks they do, besides just being a stripped down Linux.
You will also need to tell coreboot how to find the kernel in an hpkg file that is itself in a bfs partition. Unless you extract the kernel from there and put it somewhere where coreboot can access it, but then you have to re-do this everytime you update the kernel.
It is simpler to have only the bootloader there, really.
Linux avoids this by having their “kernel” be an initramfs, that is, a whole filesystem loaded in RAM with the kernel plus all modules needed for booting. This allows the kernel to boot quite far without doing any disk access, and load all modules from there. In the end, our approach is a bit simpler, and it also allows us to provide a nice boot menu with debug options and other useful tools.
As a small update to this I have bought a HP Chromebox from eBay which I got today. All ChromeOS devices use coreboot. I plan to use some firmware from a site called MrChromebox to update the stock ChromeOS specific firmware with one that has UEFI, and then I will put Haiku on it.
I believe other people have done this already, at least @kallisti5 I think, so maybe this is not super innovative but this is the first time I have tried it. I guess if I am starting over on this drive I will need to set up the EFI partition myself, eh? I’ll try to read some documentation about that. Worse case maybe I use a Linux USB stick to set that up.
Anyhow I got this machine to maybe experiment with coreboot in general, though to start I just want to play with this cute little machine as a Haiku box. I also don’t know the state of firmware updating tools on Haiku. In fact I don’t know how they work in general, so I have some learning to do there too.
DriveSetup can create EFI ESP partition.
The MrChromebox firmware is rather picky when it comes to usb drives and I’ve only gotten 64-bit linux to work so far (no legacy boot possible). Haiku (hrev55117) kernel panics when it can’t find any boot partition.
The onboard SD/eMMC on the chromebook I’m using is even worse off and shows up in linux as:
[ 2.608964] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA [ 2.662889] mmc1: SDHCI controller on ACPI [80860F16:00] using ADMA [ 2.704542] mmc0: new HS200 MMC card at address 0001 [ 2.717883] mmcblk0: mmc0:0001 MAG2GC 14.6 GiB [ 2.721263] mmcblk0boot0: mmc0:0001 MAG2GC partition 1 4.00 MiB [ 2.725237] mmcblk0boot1: mmc0:0001 MAG2GC partition 2 4.00 MiB [ 2.733638] mmcblk0rpmb: mmc0:0001 MAG2GC partition 3 4.00 MiB, chardev (245:0)
Hardware list: https://files.catbox.moe/3fypda.txt
I finally got around to updating the firmware on the HP Chromebox I have. It was complicated by the fact that the device would not go into Recovery mode with my 4K monitor I was using. I also don’t think my keyboard was working. So I set it up with a 1080p monitor and a plain Dell keyboard and it finally got into Recovery and then Developer mode. I then installed the UEFI firmware.
Unfortunately the older Haiku hrev53839 USB stick I have won’t boot. The same stick will boot on my Ryzen desktop. It will show the Haiku boot screen for a second, then it reboots. Trying to get into the Haiku bootloader with Shift or Spacebar does not seem to work.
When I use a Windows 10 USB stick it booted fine.
I will try updating the Haiku USB stick to a newer revision and if that doesn’t work I’ll try another USB stick maybe. Beyond that I suppose I’ll have to get familiar with coreboot and Tianocore and maybe whatever customizations MrChromebox adds.
Sometimes VirtualBox is a godsend as I have no less than two (regular BIOS) PCs that refuse to boot Haiku from USB/CD unless it’s already installed. So I just do the installation virtually and move it over
I started this thread almost 3 years ago. Custom bootloaders are a source of optimization for a particular task that can make installation work on systems that are no longer supported by their manufacturers useful again.
I have several ARM based systems that don’t have a recent UEFI bootloader because their company doesn’t maintain them properly, such as the Cubox i4P. If I were to try to port Haiku to it without UBoot support, I’d have to first port UEFI to it then see if it works at all. Without that, I’d be up a creek.
The argument that it shifts the bootloader design to the manufacturer is often invalid. If the manufacturer still supported old hardware, I wouldn’t be trying to run a 3rd-party OS on it.