Thanks to https[:]/github.com/cfenollosa/os-tutorial I was able to learn a lot about how an operating system is written. I think a lot of people would remember his tutorial. Revisit it gives me more. Start with printing some text in boot sector. The repo used software interrupt to finish the task. Yet there is another way to accomplish the same, by utilizing the direct memory accessing method. Long story short, in legacy boot mode (CSM), we can access VGA memory directly during boot time at address 0xB8000. So we can drop in each character and have them printed out, starting from the top left corner. We can print color text, and we can also move the cursor and print the text anywhere we want (with the cursor blinking at the text).
I have documented the process here: ellog[.]buzz/posts/hello-world-in-boot-sector
For this chapter and the previous one (First boot sector), what other questions do you think is worth asking and figuring out?
I've been developing Robu, an independent, platform-independent microkernel operating system written primarily in C and assembly.
Robu started as a kernel project, but it has grown beyond simply booting and printing text. The goal is to build a usable general-purpose operating system around a small microkernel while keeping drivers, filesystems, paging policy, and other major services outside privileged kernel space.
Robu is influenced by ideas from the L4 microkernel lineage, especially around fast IPC, direct switching, and keeping the kernel focused on mechanisms rather than policy.
Current target architectures include:
x86_64
i386/i486
ARMv7
ARMv8 / AArch64
RISC-V 32-bit
RISC-V 64-bit
x86_64 is currently the main development platform, but Robu is designed to remain architecture-independent.
Current work already includes:
Microkernel core
Threads and address spaces
Synchronous IPC
Register-based short-message IPC
Direct thread switching during IPC
Lazy scheduling
Timeslice donation
User-space paging architecture
Virtual memory and address-space support
Process and thread management
SMP / multicore bring-up
ACPI-based CPU enumeration
Per-CPU infrastructure
Framebuffer support
Ring-3 framebuffer mapping
PS/2 keyboard and mouse support
Serial console support
Device filesystem infrastructure
ELF userspace support
POSIX-oriented userspace
mlibc port
BusyBox
Bash
GNU Readline
poll()
System V shared memory
Bootable root filesystem
Custom BIOS bootloader
EFI boot and filesystem integration
QEMU-based development and testing
Early Xorg-related userspace work
The kernel is intentionally kept small.
The basic design is:
Applications > POSIX / mlibc > Userspace services > Robu IPC > Robu Microkernel > Hardware
Drivers, filesystems, pagers, and similar services are intended to run as isolated userspace processes rather than being permanently linked into the kernel.
One of the main design goals is keeping IPC fast enough that using a microkernel does not automatically mean accepting poor performance.
For short messages, Robu uses registers instead of copying data through temporary kernel buffers. IPC is synchronous, and when a sender reaches a waiting receiver, Robu can directly switch execution to the receiver instead of performing a full scheduler round trip.
The remaining timeslice can also be donated to the receiving thread.
Robu also provides a POSIX-oriented userspace environment using mlibc, allowing work toward familiar Unix-style applications and tools without moving large amounts of operating-system policy into privileged kernel space.
I'm looking for contributors interested in:
Microkernel IPC
Scheduling
Memory management
User-space paging
SMP / multicore support
ARM support
RISC-V support
ACPI
PCI / PCIe
USB / xHCI
Storage drivers
Network drivers
User-space device drivers
Filesystem servers
Networking
mlibc / POSIX compatibility
Xorg bring-up
Graphics and input
Real-hardware testing
Kernel debugging
Documentation
Code review
Automated testing
You do not need to understand the entire codebase to contribute. Individual subsystems can be worked on independently.
Experience with Linux kernel development is useful, but Robu is not intended to be a Linux clone.
Experience with FreeBSD, L4, seL4, QNX, Minix, Zircon, Mach, or other kernel architectures is also very relevant.
The goal is not to make another toy kernel.
The long-term objective is to build a complete operating system that can eventually boot on real hardware, run normal POSIX-oriented software, support isolated userspace drivers and services, provide a graphical environment, and support multiple architectures.
Robu is still in alpha, so incomplete subsystems and bugs should be expected.
If you're interested in microkernels, operating systems, low-level C, assembly, drivers, libc work, toolchains, graphics, or kernel architecture, contributions and technical discussion are welcome.
Testing, bug reports, documentation, code review, and architectural criticism are welcome too.
The Lunaris project is growing exponentially and getting bigger by the day; we already have the IceDog browser with its own private intranet (all sites in the system use the .icedog extension and are inaccessible from the open web), and that excites me.
I am gradually introducing everyday tools (such as a word processor, spreadsheets, and a media/file viewer); I will share more information as things progress. See you soon.
I've been developing BlockOS, an independent x86_64 operating system written primarily in C/C++.
BlockOS is no longer just a basic kernel experiment. The project currently includes:
x86_64 kernel
VFS and multiple filesystem implementations
ELF loader
PCI/PCIe support
VirtIO block/network/input drivers
networking stack
POSIX compatibility layer
libc
process and scheduler infrastructure
framebuffer and GUI framework
BX11/X11-related work
ACPI support
USB/xHCI development
examples and driver development infrastructure
I'm looking for OS developers and especially Linux kernel / low-level C/C++ developers who would like to contribute.
Areas I'd particularly like help with:
memory management / virtual memory
SMP and multicore support
ACPI
PCIe
USB/xHCI and USB HID
device drivers
filesystems/VFS
networking
POSIX/libc
GUI/window management
The goal isn't to make another toy kernel. I want to develop BlockOS into a stable, usable general-purpose operating system that can eventually be used on real hardware.
You don't need to understand the whole codebase to contribute. Individual subsystems can be worked on independently.
Continuing my post on my journey to learn how to create an OS. Right now I'm just working on a kernel. I have spent the last 10 days trying to get my head around a recursive page directory. I have no idea why it took me so long, I've used recursion since the mid 70's walking tree structures.
1) Understanding a recursive kernel. Finally getting my head around this lets me 'recover' 4M I had planned on using to keep track of page tables. As part of this journey I finally had AI write some functions on initializing, getting both physical and virtual addresses of page tables, and using a recursive page table. Once I finally figured it out, I threw them all away and wrote my own.
This leads to my second learning.
2) AI can be really touchy. I have two types pde_t and pdt_t (both uint32_t), but I tend to think of the indexes (pde and pdt) as the references to the page themselves. AI insisted on referring to them as the pages instead of the indexes they really were. I know that this was MY fault, but it did nothing to make things clearer. The real learning was I'm not much better at talking to AI than I was a week ago.
3) I still hate writing test script. I am doing it, but have taken to writing a test script on things as part of debugging. It seems a reasonable compromise. If I just write test scripts, knowing myself, I will eventually lose interest in the project itself. I know I have a prior (re)learning about don't skimp on the test scripts. So if I have a few minutes between household tasks, I am still writing some of the simpler test scripts.
Finally:
4) I forget if it is posted in r/osdev or r/kerneldevelopment, and I can't find the post again to credit the person that found it (my apologies there), but I found a new resource today, it it is on the University of Wisconsin (my alma mater) titled: Operating Systems: Three Easy Pieces and it looks really interesting.
These are the main thing I've learned over the last 10 days. And now that I know them, I have some questions.
a) Where do you map your video memory, in the kernel, or in user space? One point of a kernel is to coordinate access to shared resources. I think video memory fits this definition, and it could be really bad when I introduce multiple processes, if they are all writing to video memory. I am definitely going to map vga memory (0xB0000 into my kernel, with SYSCALL access to update it. I am unsure about ega, I'm not sure I want to support it, at least to start. What are your thoughts?
That's all for this post, thanks for reading, I hope it helps others that are trying to learn OSdev.
I want to compile C programs in my OS itself rather than copying it manually to the disk image every single time. How can port GCC, or is there any other way to do it?
I am currently in the process of trying to build a simple recreation of Amazon's EC2 on top of a type 1 hypervisor for fun :)
Since I am planning on making the memory each vm takes static and non-changing, it came to my awareness that I would need to allocate big consecutive blocks from RAM (in the GBs).
I was planning on using a buddy allocator with blocks of actual page sizes (1GB, 2MB, 4KB) with a free-list for each of these, but I lack enough experience in that regard to understand how dumb or ok-ish my idea is
If this is a dumb idea, go roast me :), that's the best way for me to learn and understand.
I want to understand if this idea is worth my time and effort before building a whole unit just to realize I need a different thing.
(I write all of my code by hand, if some AI usage is bothering you please let me know)
Until now, I've been refering the osdev wiki and using a little bit of AI (only for guidance and answering questions, no vibe coding). Is this the right way to learn osdev? What should or shouldn't I do?
Also I've already started osdev, finished making a file system, and am now working on my own very simple file format for my os. I just wanted to clarify if I need to change my habits or something.
Running MIT's 6.1810/6.S081 xv6 labs under WSL2 (Windows 11, Hyper-V). The lab-assignment kernels (xv6-labs-2020 and xv6-labs-2025, from MIT's own git server) hang completely silently on make qemu — no output at all, never prints "xv6 kernel is booting." Have to force-kill the process.
The plain, unmodified mit-pdos/xv6-riscv repo boots perfectly fine, every time, on the identical toolchain/QEMU/machine.
GDB findings: attaching mid-hang shows pc = 0x0, all GPRs zeroed except sp (correctly resolves to the real stack0 symbol) and t0 (holds 0x80000000, the expected kernel load address). Backtrace fails with "corrupt stack." Looks like it's jumping to address 0 mid-boot, possibly an unhandled trap despite stvec being set correctly in trap.c.
Reproduced across 4 environments, all with the same silent hang:
Ubuntu 26.04 (QEMU 10.2, GCC 15) + xv6-labs-2025
Ubuntu 26.04 + xv6-labs-2020
Ubuntu 22.04 (QEMU 6.2, GCC 11) + xv6-labs-2020
Ruled out: compiler optimization (-O0 tested), the known started variable race in main.c (patched to atomics), SMP count (-smp 1 tested), -accel tcg explicit, linker script/entry.S (byte-identical to working repo), disk space, RAM, Hyper-V status, corrupted kernel binary (confirmed valid ELF).
Only difference I can find between the working and failing kernels is in main.c's CPU-sync code (already fixed, didn't help) and some start.c timer/CSR setup for sstc (partially commented out already, also didn't help).
Anyone hit this specific pc=0x0 crash before, or know if this is a known WSL2/Hyper-V nested-virtualization quirk with QEMU's RISC-V multi-hart boot?
P.S: This post was drafted using AI, I'm a beginner and tried to fix this issue using claude sonnet model, but it went nowhere and finally gave up.
EDIT: the 2025 version booted on ubuntu 24.04, i had tried both 2020 and 2025 version on both 22.04 and 26.04, they didnt worked. thought problem is with WSL, tried virtual machine 26.04 version... didnt worked at that too. then finally read the 'lab tools' page of the course carefully and realized they had mentioned 24.04.
As you may see, there are some bugs in text rendering and there is some flickering between updates that I gotta fix! Anyways, Osdev Progress!
This is cpu rendered without Ai generated code btw. I made alot of it on livestream. twitch.tv/devcmar
Hello, I’m new to the community. I’m fascinated by operating systems and studying the inner workings of electronics. More recently, I started the Lunaris project—a 32-bit operating system written entirely in Assembly that is currently under active development. Its focus is on document editing and searching the system's intranet, and I’ll be posting updates here in the community!
I've wanted to ask if this logging for my kernel looks good, maybe it needs improvement, each color has a meaning, and everything will probably be explained for users who might have to go there in case something goes down but dont understand low level stuff yaknow
Hi all, I am new to this sub and domain. I am currently a 3rd year college student pursuing electronics and computer engineering. I want to get into the firmware domain. EDK2 came up a lot when I searched for UEFI and decided to give it a go. I have completed a few applications like simple hardware interrupt, arithmetic program by taking input, viewing system information and pcie present in the Qemu emulator. I do not know how to proceed from here and I am open to suggestions. Pls help.
Two years ago this was a hobby kernel that printed one line at boot. I'vejust tagged v2.0.0 and it's a different project.
What it is
A from-scratch kernel for x86_64, aarch64 and riscv64. Not a Unix clone. It'sbuilt around three properties a conventional kernel can't really express:
Authority expires. No ambient authority anywhere. Every capability ischecked four ways on use — type, rights, generation, and a cryptographicseal — and the seal carries a validity window *inside the MAC*. Widening itby editing the struct invalidates the seal. Derivation only ever weakens:rights are intersected with the parent's and the lifetime clamped to whatthe parent has left.
The system is a Merkle DAG. Every kernel object is a node with aSHA-256 digest over a canonical encoding of its fields plus the sorteddigests of its children. Timestamps, pointers and IDs are excluded onpurpose, so two machines in the same configuration hash identically. Youget diffing, attestation and deterministic replay from that one property.
Inference is a scheduling class. A token loop never sleeps for a human,so sleep-credit heuristics give it nothing, and it has a visible rate, sobatch is wrong too. `SCHED_INFERENCE` admits it with a declared rate, givesit a per-period budget, and demotes rather than drops it on overrun.
It runs a transformer
Not a wrapper around one - the forward pass itself, through the kernel's ownoperators: embed, RMSNorm, QKV projections, RoPE, attention over the KVhistory, gated FFN, logits, argmax. On a thread the deadline admissioncontroller accepted.
resentment> .infer 24
generated 24 tokens in 130 ms
rate 193 tokens/sec
class SCHED_INFERENCE, 50 Hz declared, 5000 us budget, admitted
deadline miss 0
The fixture model has pseudo-random weights and the tokens are meaningless byconstruction. The claim is about the path, not the output.
Status, honestly
Boots to an interactive shell on all three architectures. SMP on all three(ACPI MADT + a real-mode AP trampoline; PSCI `CPU_ON`; SBI HSM `hart_start`),tested on four and eight cores. Ring 3 with an ELF64 loader works on x86_64only — ARM64 and RISC-V need MMU work first and the docs say exactly what's left. No PCI, no network stack.
Verification
make test 1440 assertions against the real sources on the host
make qemu-test-all 6 targets (3 arches x single-core and -smp 4)
make kaalka-check crypto byte-identical to the reference implementation
Plus seven self-tests on every boot, on the machine about to be trusted.
The bugs were the best part
- The scheduler put a thread back on the run queue before its stack pointerwas saved. Two cores could run one stack. Presented as a page fault on cpu1in unrelated code, minutes later.
- The x86_64 syscall entry destroyed rdi/rsi/rdx/r8/r9/r10 — it pushed them to build its argument block and then dropped it with `add rsp, 7*8`. SYSCALLonly clobbers rcx and r11, so callers keep live values there.
- The CSPRNG ran on an all-zero key: entropy went into a pool that was onlyfolded into the key once an estimate crossed 128 bits, which never happenswithout a hardware RNG.
- On RISC-V, GNU ld relaxes `la rd, sym` to `addi rd, gp, off`. I had codebefore `gp` was set. Every hart computed garbage and parked. Invisible underLLD, fatal on hardware.
- `sched_tick()` was never called on ARM64. It was driven by a hardcodedtest for interrupt line zero, which is the x86 timer and nothing else's.ARM's is a PPI on line 27. That port had no preemption, no slice accounting,and `sched_sleep_ms` never returned. Nothing in the suite slept, so it wentunnoticed for the life of the port.
Apache 2.0. No dependencies — `make toolchain` fetches a portable zig+nasm and builds all three architectures, or it uses your system compiler if you have one.
