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

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

And the list of all parts is here:

https://traxys.me/

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.

I have not really thought too far ahead, I know quite a bit about Linux internals, so when in doubt I tend to follow what was done there. I have not though very far in how to handle most of syscalls, traps, drivers, ...

Thank you for the static site generator! The code highlighting should be very similar to the tokyonight nvim colorscheme, as it uses mostly the same colors & tree-sitter queries as it!

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.

I don't really understand what you mean. What is bootloader-like about this project? Any kernel, no matter what platform it targets, is going to look pretty similar to this project at this stage.

Well yes, but I the main idea of this series is to use no dependencies in order to have a deeper under standing of the entire stack, from boot to GUIs (that is a long term goal!)

Sure, the first three parts aren't exactly doing anything earth shattering. But it's an ongoing series, so I don't think one can judge it just yet.

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

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

Might as well be. Little to no RISC-V content here, and it's not even depending on the page table format, just blasting through physical RAM.

Well this part did not have much RISC-V in it, as it builds upon the abstractions of part 2, which had lots of assembly!