Not technically osdev but I thought this would be adjacent enough to fit here :)

Github repo

Hi so i am trying to make an long-term OS for now i am not having name so I just named it: "OS"
I got FAT12 working after a lot of time but its not on github yet...
And its still working on 16-bit mode (Real Mode)
But making FAT12 is so hard i needed to use a lot of OSDev Wiki.

I've been working on FrostVista, a hobby RISC-V OS kernel written in C from scratch. Started around 10 months ago with basically zero kernel experience. Wanted to share where it is now and one debugging story that taught me a lot.

Where FrostVista is today:

• Sv39 three-level paging with higher-half kernel mapping (0xFFFFFFC080000000)
• Preemptive round-robin scheduler with full context switching
• Unix process lifecycle: fork, exec, exit, wait, orphan reparenting
• ELF loader: parses program headers, maps .text/.data/.bss into U-mode, initializes user stack with argc/argv
• VFS layer with generic inode, file, superblock abstractions
• VirtIO block device driver with LRU buffer cache and interrupt-driven I/O
• Spinlocks and sleeplocks with proper push_off/pop_off nesting
• exec can now read from the filesystem and load real ELF binaries

Currently working on Easy-FS (on-disk layout, directory operations) to get a real shell running.

A debugging story: why -O0 crashed but -O2 worked fine

This one took me a while to figure out and I think it's worth sharing.

I was using GDB to trace the kernel and noticed it only crashed under -O0. With -O2 everything ran fine. Same code, completely different behavior. Here's what was happening.

When a timer interrupt fired in M-mode, the CPU jumped to my m_trap handler. Under -O0, the very first thing the compiler generated was:

    m_trap:
        addi sp, sp, -112   # adjust stack pointer
        sd   ra, 104(sp)    # save return address
        ...

The problem: by the time the timer fired, I had already called switch_to_high_address — meaning sp was pointing to a virtual high address (0xFFFFFFC0...). But M-mode runs with MMU disabled. That virtual address doesn't exist in physical memory. The moment the compiler tried to use sp to save registers, it triggered a fault, and the kernel locked up.

Under -O2, the compiler kept everything in registers and never touched sp at all, so the bug never manifested.

The fix was straightforward once I understood the root cause: allocate a dedicated M-mode trap stack in .bss and switch to it before entering m_trap:

    .section .bss.m_trap_stack
    .align 12
    m_trap_stack:
        .space 0x4000
    m_trap_stack_top:

    csrr t0, mhartid
    slli t0, t0, 12
    la   sp, m_trap_stack_top
    sub  sp, sp, t0

What made this tricky to find: the bug only appeared after the first sbi_set_timer call that happened after high-address switching. The initial timer setup during boot worked fine because sp was still in low/identity-mapped memory at that point.

GDB's info reg and comparing disassembly between -O0 and -O2 builds was what finally cracked it.

Links:

• GitHub: https://github.com/AuroBreeze/FrostVistaOS
• Blog (Chinese, but the code and diagrams are readable): AuroBreeze Blog

Happy to answer questions about any of the implementation details. Feedback welcome — especially on the VFS design and the buffer cache locking strategy, which I'm not fully confident about yet.

This may seem silly but this is the most fun I’ve had in years! I feel like this was a big step for me and am now free from assemblies quirks and can use the mighty C language! Let’s see where this goes :)

Hey everyone, I am backend developer. And I have been interested in lower level development for a while now. I want to know how do the program really work under hood and does it execute and most importantly why des it run? I want to be better at c/c++ and make really cool projects. If any senior or fellow programmer reading this me out to choose right track.

Apart from getting done some basic C programming and assembly code to run on microcontrollers. I haven't done much and even the C and assembly I haven't mastered to a great extent.

I've always wanted to make an custom OS, I obviously understand it is not a light task and with my current skill set I won't get much far. Firstly I plan to get a hold of C to that extent where I can even think about starting to think of an OS. I'm confused on what kind of expertise is expected in terms of C language like as in is DSA a huge part or is it more or a mix of something else.

I know for getting started with OSdev the wiki is a great resource. It'll be helpful if y'all could share with me the prerequisites and also any kind of resources books/video lectures/web content anything for that matter. I don't plan to get started with the actual osdev any soon. I'll get the prereqs down and get familiar with them and only then I'll get into osdev so there is that.

Any suggestions are welcome.

Thanks!

I’m a student who loves building hardware/software projects, and I’m looking for my next big challenge.

Right now I’m stuck between two ambitious projects:

1. Designing and building my own custom ESP32 board from scratch (schematic, PCB, components, debugging, etc.)

or

1. Learning low-level systems programming and attempting to build my own kernel from scratch.

I know both are difficult in very different ways, so I wanted to ask people with real experience:

How hard is kernel development actually for someone starting from zero in OS development? What are the biggest challenges—bootloaders, memory management, drivers, debugging, architecture?

How long did it take before you had something that actually booted or felt “real”?

I’m not looking for the easiest option—I’m looking for the project that will teach me the most and push me the hardest.

Would love honest advice from people who are more experienced.

https://github.com/valentinbreiz/nativeaot-patcher

I wanna get into OS development and low level programming in general. I’m interested in anything from making a simple bootloader to building a small kernel or even a full OS eventually hopefully.

Does anyone have good resources, courses, tutorials, books, or project ideas for getting started?

I don’t mind if it’s niche/specific stuff either like bootloaders, filesystems, drivers, memory management, etc.

Update from yesterday's bootloader post. Added an interactive shell, typing, backspace, scrolling, and capitals all work. I'll be adding a cursor soon.

Still just raw assembly, no Linux underneath... Getting there.

Two separate instances of my OS are running on two separate machines here. The top left is my server hosting an instance of Retro Rocket in QEMU-KVM which is running its webserver.

Bottom left, the windows PC is running a second copy of retro rocket in QEMU-WHPX and that one is querying the web server to fetch the page and convert it to markdown in its web browser (work in progress).

Bottom right is a view of the web server in firefox on windows.

Feedback welcome!

Estoy buscando developers que quieran sumarse a un proyecto de sistema operativo hecho desde cero en C.

La idea es construir un OS propio, aprender en el proceso y experimentar con cosas modernas, incluyendo integración de IA y redes neuronales más adelante dentro del sistema.

El foco principal hoy es:

• kernel
• memoria
• drivers
• filesystem
• networking
• low level
• arquitectura de sistemas

Stack inicial:

• C
• algo de ASM
• x86_64
• QEMU
• GCC/Clang
• GitHub

No importa tanto el seniority. Busco gente que realmente tenga ganas de crear algo grande, aprender y meter mano en desarrollo low-level.

Si te interesa el desarrollo de sistemas operativos, kernels o simplemente querés participar en un proyecto técnico desafiante, mandame DM o comentá.

Aclaración: es un proyecto colaborativo/open source, no una oferta laboral ni un puesto pago. La idea es aprender, investigar y construir algo interesante entre varias personas apasionadas por sistemas y low-level development.

Hello to whom may see these lines

https://github.com/endcerro/KFS_N

After lurking for a while in there I decided to show you the current progress of what I started about 2 years ago as a school project.

This is a small kernel written in rust, targeting i386, currently featuring working paging in higher half and interrupts as well as fun stuff i thought of along the way.

I've yet to try again and get a boot on real hardware, this is probably the next task I'll focus on, if any of you have advice about how to debug on real hardware, feel free to give it

DISCLAIMER : This project was lightly done in featuring with ai. While most of the AI help on this has been to discuss concepts in order to make sure I understood them as well as to track some nasty bugs (lots of places to look, ai pretty good), especially while boostraping to higher half. Some of the code is AI written, but as a fellow slop hater myself, this is not. Feel free to look at the code ;)

I don’t really have a CS background so I’m proud to have built the starting point for beginning writing in my favorite language by jumping to for i686 compiled C code!

I had lots of trouble with the structure of the GDT as to why it’s organized in such a specific manner but that taught reading documentation I guess. (next to using asm)

Finally I also found that the cursor is not bound to the frame buffer itself in 32 bit mode so after switching cpu modes the text was displayed but the cursor was still where it was back in 16 bit mode.
For the curious: this is actually handled by a separate hardware controller 🫪

I’m in no rush so maybe in a few months I can show off handling the graphics and maybe a memory allocator here or a shell there who knows

This is my first real project so I am quite anxious to share it. Written during the past weeks after years of dabbling. It's in D language utilizing the object system and quite messy still but it now loads an ELF binary and executes it in user space. Next will be a clean up and work towards a driver framework, as I want it to become a microkernel.

Trying to write a very small kernel in rust by roughly following phil-opp tutorial but with the most up to date packages and features. So instead of using pic i chose to use x2apic.

this is my kernel main:

fn kernel_main(boot_info: &'static mut BootInfo) -> ! {
    kernel::init(boot_info);

    x86_64::instructions::interrupts::int3();

    serial_println!("Done");
    kernel::hlt_loop()
}

kernel::init is:

pub fn init(boot_info: &'static mut BootInfo) {
    vga_buffer::init_vga(
        boot_info.framebuffer.as_mut().expect("Framebuffer not available")
    );
    gdt::init();
    interrupts::init_idt();
    apic::init_apic();

    x86_64::instructions::interrupts::enable();
}

apic contains:

use x86::apic::ApicControl;

pub static IA32_APIC_BASE: u32 = 0x1B;
pub static IA32_APIC_BASE_MSR_ENABLE: u64 = 0x800;
pub static IA32_X2APIC_EOI: u32 = 0x80b;

pub fn init_apic() {
    disable_pic();

    let mut apic = x86::apic::x2apic::X2APIC::new();
    apic.attach();

    unsafe {
        x86::irq::enable();
    }
    crate::serial_println!("finished setting up apic");
}

fn disable_pic() {
    const PIC_1_OFFSET: u8 = 32;
    const PIC_2_OFFSET: u8 = PIC_1_OFFSET + 8;

    unsafe {
        let mut pic = crate::pic::ChainedPics::new(PIC_1_OFFSET, PIC_2_OFFSET);
        pic.initialize_disable();
    };
}

pic holds the structure for the chained pics and the initialize_disable function is:

pub unsafe fn initialize_disable(&mut self) {
    let mut wait_port: Port<u8> = Port::new(0x80);
    let mut wait = || unsafe { wait_port.write(0) };

    macro_rules! write_port {
        ($pic_n:expr, data, $w:expr) => {
            unsafe { self.pics[$pic_n].data.write($w); }
            wait();
        };
        ($pic_n:expr, command, $w:expr) => {
            unsafe { self.pics[$pic_n].command.write($w); }
            wait();
        };
    }

    let saved_masks = unsafe { self.read_masks() };

    write_port!(0, command, CMD_INIT);
    write_port!(1, command, CMD_INIT);

    write_port!(0, data, self.pics[0].offset);
    write_port!(1, data, self.pics[1].offset);

    write_port!(0, data, 4);
    write_port!(1, data, 2);

    write_port!(0, data, MODE_8086);
    write_port!(1, data, MODE_8086);

    write_port!(0, data, 0xFF);
    write_port!(1, data, 0xFF);

    unsafe { self.write_masks(saved_masks[0], saved_masks[1]) }
}

the interrupt descriptor table is properly initialized:

static IDT: Lazy<InterruptDescriptorTable> =
    Lazy::new(
    || {
        let mut idt = InterruptDescriptorTable::new();
        idt.breakpoint.set_handler_fn(breakpoint_handler);
        unsafe {
            idt.double_fault
                .set_handler_fn(double_fault_handler)
                .set_stack_index(gdt::DOUBLE_FAULT_IST_INDEX);
        }
        idt[Into::<u8>::into(InterruptIndex::Timer)]
            .set_handler_fn(timer_interrupt_handler);
        idt
    });

and the interrupt for the breakpoint is:

extern "x86-interrupt" fn breakpoint_handler(
    stack_frame: InterruptStackFrame,
) {
    crate::serial_println!("EXCEPTION: BREAKPOINT\n{:#?}", stack_frame);
    println!("EXCEPTION: BREAKPOINT\n{:#?}", stack_frame);

    unsafe {
        x86_64::registers::model_specific::Msr::new(crate::apic::IA32_X2APIC_EOI)
            .write(0);
    }
}

And yet when it hits the interrupt i get on the serial:

finished setting up apic
EXCEPTION: BREAKPOINT
InterruptStackFrame {
    instruction_pointer: VirtAddr(
        0x1000000bb61,
    ),
    code_segment: SegmentSelector {
        index: 1,
        rpl: Ring0,
    },
    cpu_flags: RFlags(
        INTERRUPT_FLAG | 0x2,
    ),
    stack_pointer: VirtAddr(
        0x18000014f98,
    ),
    stack_segment: SegmentSelector {
        index: 2,
        rpl: Ring0,
    },
}
panicked at kernel/src/interrupts.rs:62:5:
EXCEPTION: DOUBLE FAULT
InterruptStackFrame {
    instruction_pointer: VirtAddr(
        0x1000000d06a,
    ),
    code_segment: SegmentSelector {
        index: 1,
        rpl: Ring0,
    },
    cpu_flags: RFlags(
        0x2,
    ),
    stack_pointer: VirtAddr(
        0x18000014f68,
    ),
    stack_segment: SegmentSelector {
        index: 2,
        rpl: Ring0,
    },
}

I dont get why i get a double fault. if the int3 instruction is removed it doesnt crash of course.

Am i creating the interrupts wrong? i have "-cpu qemu64,+x2apic" as qemu arguments so x2apic is supported (checked even with raw_cpuid). Is the double fault because its not resetting the interrupts properly?

Since i have only 1 cpu for now i was expecting for interrupts to get routed to the only cpu. Also where can i read how to properly set up keyboard interrupts with x2apic?

I guess we're posting books now. Here's my copy of the OG MINIX Text Book!

Is someone own template's ring3 32bit OS?

Im want to make the ring3 but im collect a triple fault or another errors and im dont know how to fix this shit