I finished the kboot.conf file and nixos boots automatically on petitboot. And I’ve also learned that now I don’t need to rely on u-boot custom image for each board I own, everything can be just booted, kinda like on x86. This is next-level for me in terms of usability.
For those not in the known, petitboot does something kinda like grub, it allows you to pick the OS you want to boot into (it’s a bootloader). U-boot is kinda like a pseudo-firmware and bootloader. It gets loaded by the ARM SoC’s startup sequence and it then looks for bootable OS files at certain locations on the storage mediums attached. U-boot can read legacy boot.scr’s and boot.ini’s, the later which look horrible, along with extlinux.conf files.
Now, the kboot.conf is not exactly easily readable, given its large lines, but it’s better than that egregious u-boot boot.ini config.
Take a look for yourself. And this is for multiple nixos generations / boot options!
# Change this to e.g. nixos-42 to temporarily boot to an older configuration.
default=nixos-default
nixos-default=vmlinuz initrd=initrd.img dtb=dtb init=/nix/stor/5fbhlfm4y8m9200xi802c083jg9bcdvb-nixos-system-hc4-23.05.1748.e11142026e2/init zfs.zfs_arc_max=2147483648 nohibernate loglevel=4 rootwait rw console=tty1 no_console_suspend max_freq_a55=1800 maxcpus=4 hdmimode=hdmi
nixos-7=nixos/k3bgrdk8v2l1rfmvxrn8ch9xyikd75wf-linux-6.1.37-Image initrd=nixos/5zavkvid31j06k9wpiblqxydkcvysrddinitrd-linux-6.1.37-initrd dtb=nixos/k3bgrdk8v2l1rfmvxrn8ch9xyikd75wf-linux-6.1.37-dtbs/amlogic/meson-sm1-odroid-hc4.dtb init=/nix/store/5fbhlfm4y8m9200xi802c083jg9bcdvb-nixos-system-hc4-23.05.1748.e11142026e2/init zfs.zfs_arc_max=2147483648 nohibernate loglevel=4 rootwait rw console=tty1 no_console_suspend max_freq_a55=1800 maxcpus=4 hdmimode=hdmi
The first boot option is just symlinks, just like u-boot does it. The second one is the full paths, like nixos does it with the extlinux.conf file. Unfortunately, there’s no way to split the config on multiple lines for readability, not even with \. But it’s a tradeoff I’m willing to make. The bad part of this is that I have to maintain the boot config myself. But on the other hand, on the boards that I run non-supported linux distros, I have to build the uInitrd and change the symlinks myself anyway - in all fairness, this makes it easier than those, because I can just copy paste some paths and file names and boom, bootable config (although not easier than having the OS deal with it, which is what nixos was doing).
U-boot is kinda like UEFI on modern systems, but using its own standard for booting. Just like UEFI can read the efi files your OS generates in your boot partition, u-boot can read its own files. U-boot to me feels clunky and a bit limited, the linux distro one uses, has to maintain u-boot firmware updates and the boot files / symlinks (correct me if I’m wrong and the later is somehow scriptable in other ways in some package managers or other tools, I want to learn to do that next).
The UEFI in a x86 motherboard is maintained by the manufacturers, but in ARMland, there’s no standard, because each SoC has different initialization sequences or something (the most offensive one being broadcom using the gpu to boot, most common boards using their chips being the raspberry pis).
U-boot is like a middle layer and SBC manufacturers like Pine64 and Radxa have to ship with their own. I can’t speak for Radxa, but unfortunately for Pine64, I haven’t seen a board that can just boot any OS you slap on a uSD card or eMMC drive out-of-the-box. This shifts the maintenance of boot firmware from board manufacturers like them over to the OS maintainers. It seems that many maintainers happily took the burden on that though.
All or most of the OS installs I’ve seen frequently come with their own version of u-boot for each board they support (unless the board is supported upstream by u-boot already). Here’s where petitboot comes into play. Hardkernel is shipping petitboot with most or some of their boards now. With just a simple config file, petitboot can boot any supported OS. By supported, it means both OS that support the linux kernel’s kexec method (which, besides linux, only FreeBSD does AFAIK) and OS that ship with the proper dtb files for the board in question. This shifts the burden back to the board / SBC manufacturers, freeing up resources on the OS side for things like dtb and drivers maintenance.
So what’s this kboot.conf thing that I kept talking about? I mentioned previously that petitboot is able to read and parse kboot.conf and u-boot boot.ini config files to know which kernel image, initramfs and dtb to load up
KBoot is another bootloader that uses kexec to boot linux and other os’es. Online I mainly found people using it to run linux on their ps3’s, but it seems like petitboot also kinda caught traction on the ps3. And bellow is how I found the default value thing to allow petitboot to boot automatically into one of the boot options specified in the config. This is really reminiscent of grub.
http://ftp.riken.go.jp/pub/Linux/kernel/people/geoff/cell/ps3-linux-docs/HowToUsePS3Linux.html
But it seems like petitboot is not without its faults. People on the armbian and dietpi forums hate it. I know in some systems, like armbian and nixos, it seems to disable USB support (attached keyboards don’t work, neither do usb storage). Other than that, everything seems to work. Some people seem to blame it on the old kernel used in petitboot. Some other people say that mmbclk0 and mmcblk1 get inverted when in petitboot and a booted newer linux versions. So is sda and sdb on the HC4 (you should always use UUIDs). For my system, despite having a keyboard attached to the hc4, I can’t see it or use it.
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
# dmesg |grep -i keyb
Some people suggest flashing u-boot into the SPI. Petitboot uses u-boot to boot up from the SoC to the minimal linux kernel, so it would make sense to remove the middleman. Also tested before, when booting straight with u-boot, the keyboard works, but reboot fails (again, suspecting that’s because of the SoC trying to read the empty spi and hanging there doing nothing).
The USB isn’t as important to me as being able to reboot, so at least on that front, it’s a sacrifice I’m willing to make. But I need to be mindful when upgrading the system to not delete the old nixos generations, otherwise, I’ll need to drop to a petitboot linux shell and edit the kboot.conf to match the fresh extlinux.conf (basically what I’d have to do after a nixos-rebuild anyway).
Now I can finally concentrate on putting the HC4 to good use. I’ll need some HDDs and some rubber vibration stoppers to make better contact with the toaster case…
