Making an RISC-V OS (Part 3): Managing free memory (opens in new tab)

Part 1: https://traxys.me/riscv_os_setup.html

Part 2: https://traxys.me/riscv_os_2.html

Thanks for this, I enjoyed it. Just as a point of constructive criticism, I would say that you might want to go into some more detail on some of the pieces like how the linker script works, or how you are assembling your asm file. I took a look at the repo and figured it out pretty quickly, but I think a beginner would be pretty lost in some of those details.

Also, your buddy allocator fills me with shame. I didn't think of doing it that way when I wrote the physical memory allocator for my hobby OS, and my algorithm is way slow to initialize as a result of how I did it. I'm thinking I might have to go and revisit my allocator.

Very cool series! I've been working on the same kind of project, so I'm looking forward to the rest of the entries! I'd love to know more about why you opt for a higher-half kernel. Most hobby RISC-V kernels I've seen don't map kernel memory into a process' address space, and use a trampoline page to transition between kernelspace and userspace. Does this approach avoid the need to have a distinct address space for the kernel, and reload its 'satp' during traps? I found that one benefit of not mapping my kernel memory to the higher-half was that things that need physical addresses, like VirtIO or OpenSBI methods, were more straightforward to implement. Since my kernel heap was essentially identity mapped.

Also, cool static-site-generator! Your code syntax highlighting looks great too.

Wouldn't it be more accurate to call this "Making a RISC-V Bootloader"?

As nice as this was to read (and I read all three parts), it's basically all the functionality of grub (or similar).

For toy OSes on x86/x86_64 the best way to get started is to use grub to do all the setup and then launch the kernel.

For a moment there I thought this was referring to RISC OS[1].

[1]: https://en.wikipedia.org/wiki/RISC_OS