The rest of the day is dedicated to hands-on work, discussions, and collaboration on areas like kernel mainlining, bootloaders ( #uboot ), packaging for mobile distributions, and preparation for upcoming community events such as #FOSDEM2026 .

Těšíme se na všechny!

2/2

So I followed up on one ofthe other, non-UEFI, suggestions, which is to create a Linux-format kernel image and boot with `booti`. This has a simple 64-byte header, followed by binary executable data.

So I do that, and #UBoot says it can't allocate the RAM for the image. Doesn't say *why* (like I've asked for too much, or the address range I want is already used or out of range). Just that it can't.

#OSDev

Some progress, I've ported those changes to the latest #uboot, will upload a working repo to gitlab soon.

Also finally worked out how to actually boot a kernel I've compiled. Ran I to an error when just using `bootm` - `FDT and ATAGS support not compiled in`, it took me a while to work out that I had to include the dtb as well.

I've now reached: `Starting kernel ...` but unsurprisingly it stops there, now need to make an actually functioning kernel. It's tricky as it's a balance of a working kernel and a working device tree, my plan was to use the one I have for u-boot as a starting point as it's very basic

#postmarketos
#linux #kernel
#mainlining

So I'm now told I'm holding it wrong, and I need to boot with UEFI. Which is *>2000* ages of specification, plus a load more reading on how to configure UEFI. And UEFI isn't even mentioned in the qemu docs for the machine I'm emulating (risc-v virt), so I don't even know if it's available.

How the hell is a human being meant to be able to understand all this stuff to actually use the hardware?

#OSDev #UBoot #Qemu #DeviceTree #UEFI