Over the time, I have made more and more progress with my operating system. Now I can even get keyboard presses (scan codes) in the kernel, which is a huge step!
But recently I decided to move that stuff from my old repo (https://codeberg.org/sfiedler/zig_os) to a new organization (https://codeberg.org/loup-os) and to “downgrade” the old repo to the state of my last post about it (see here).
Because then I could keep it up-to-date with the latest Zig master and explain all the code to help other people get started with operating system development.
I did some EFI development when I was at HP, I implemented “secure boot” where we would hash/verify our Windows CE kernel image at the time, but I wasn’t aware how all the pieces “fit together”. Excited to look more deeply into your project to learn more about it.
Mainly, it was the interface when I was completely new to the OS programming stuff.
So I found the std.os.uefi namespace and decided to try reading some EFI bootloaders. As far as I know, MBR works with the BIOS and I wanted to focus on the main thing (parsing the kernel executable) instead of having to bother with interrupts.
However, as my repo only contains the basic stuff, most of the code is around half a year old. In that time, I improved the kernel and learned really much about the architecture of processors and operating systems.
Now, I think I could program a MBR bootloader, but why touch a working piece of code?
Just joking. In the future I may support EFI and MBR using a bootloader “core” which parses the kernel executable and two bootloader “interfaces” that are wrappers to UEFI and BIOS.
I’m having considerable success with my nascent illumos distro using bootboot on everything from AMD Turion BIOS, to the latest HP and Dell PITA UEFIs, to Rockchip 5 and RISC-V… UEFI’s not the easiest spec to wrap one’s head around, but blimey, /EFI not /efi is literally the only MUST. Got no love pointing that out, so fixing BSD loader’s a nonstarter.
We boot partitions now, not devices. An ESP can have an MBR. A GPT partition containing an ISO-9660 file system, is an MBR partition. But there is no such thing anymore as an MBR device unless we’re on BIOS. Which I think means I can have one downloadable distro file as .img, which may be renamed to .iso and still be valid, covering all use cases I care about. No, really. Try it. I use rEFInd Plus to launch bootboot, except that isn’t a thing on the embeds, but it also doesn’t matter. It’s also easier said than done, but bootboot’s applet for generating such a bootable image is worth a look to anyone who reads this.
Which brings me to isaexec. In the spirit of cross-compiling, this is my change (note I don’t say proposed, illumos is a library where you must speak in reverent whispers and never suggest uppercasing EFI let alone changing the build system to, say, Zig). We don’t care about 32-bit, but what if instead of …/linking from /bin/amd64 we fall back to /bin/riscv or /bin/arm64 and qemu the executable? Looks like a nice little Zig project for this neophyte.
My hobby kernel ain’t much, HP15c Tk widget in framebuffer, but I’m no sudoer… RBAC/pfexec is why I’ve long used SunOS. What isn’t fun is an UEFI box with no CSM, that you need to use both iGPU and dGPU, when those aren’t using the same driver. Just because nobody anticipated this need and the assumption went the other way, doesn’t mean it isn’t possible, and my utter failure to prove this doesn’t mean nobody can do it. But yeah, where in the boot should we figure out that we aren’t really a TTY because workstation…? Loader or login?
Edit: Going with Sortix init. Can launch SMF as stage 2.
