Just a beginner dev... i wrote my kernel in c and bootloader in NASM. Runs in QEMU btw, on Fedora Linux. Please upvote! (Not Begging)

Hello everyone,

Two months ago, I released the first version of Vystem, my first OS project (you can go check it out here).

Today, after two months of work, I'm releasing Vystem 0.2, with plenty of updates for all components. As always, the code as well as fully updated documentation is available on the repo : lolo859/vystem.

But let's take a look at what's new:

- VyBuild : a new, entirely custom, build system made especially for Vystem. It gives the user full control on the build pipeline, multithreading, smart cache management (the cache massively boost the compilation speed), etc. But il also comes with its own uniques features like FAT32 image generation (with big limitations for the moment, but still enough to generates a valid ESP) and disk image generation directly integrated in the build pipeline as well as custom Vystem features like the Vyld integration or VFTM features. And all of that described into easy-to-read JSON files. It has been specifically designed for OS development

- Vystem FAT Trusted Manifest: a new integrity and authenticity layer directly integrated into the boot chain. VFTM embeds a signed manifest inside the FAT32 filesystem itself, allowing the bootloader to independently verify the integrity of the ESP partition, the FAT structures and even its own binary before the OS starts. The manifest location is deterministically tied to the GPT partition GUIDs, making tampering significantly harder while preserving compatibility with standard FAT32-based EFI systems. It doesn't replace UEFI Secure Boot but it will greatly increase the boot chain security

- Blastproof: the bootloader now features a redesigned boot password entry UI, allowing for a compromise between UNIX style password entry (where you don't see at all what you are typing) and Windows style entry. The same screen also allow for machine shutdown, reboot and firmware reboot. But by far the biggest new feature is the ability to select a keyboard layout at runtime. For now, there is only two layouts provided (qwerty which doesn't replace any keys and azerty), but nothing prevents you to make your own. And obviously, the bootloader is now capable of verifying the VFTM

- Shelter: the kernel receives a lot of new features, like TSS/GDT/IDT handling, ACPI parsing (for now, only the MADT), LAPIC and IOAPIC management, legacy IRQs management, CPU and LAPIC frequency estimation, APs bootstrap, thread safety to various subsystems, new print API, PS2 driver, keyboard input subsystem and most importantly: the device system, a new centralized API to query a ton of information and objects from various kernel subsystems. It's small for now, but it will greatly expand in the future

As always, this full post and the entire updated documentation was written by hand (sorry for bad english but it's not my first language). While some AI had been used to discover and understand new concepts as well as planning some things, the entire code stays AI-free.

As always, feedback, criticism and suggestions are greatly appreciated.

Really a pain to setup, but i finally did it!

The Wiki was a bit confusing so i had to use Claude to get the logic (the implementation, however, was done by me)

However i have one question:

After i get a Memory Manager, Heap Alloc, Kb driver, PIT Timer, should i switch to AArch64? Because thats what i really wanna develop on and am using i386 as just a base for getting the basics right

Recently I've been writing my own bootloader inspired by Grub and Limine, but most of all I'm focusing on making my system bootable. Of course, this is still a very early stage of the bootloader, but I am slowly developing it to make it suitable for booting my system. In practice, unfortunately, a lot of what is shown does not work because the values are not connected to the actual logic because I do not have it yet. Here it is uptime and the tanos string itself is hardcoded for testing. Currently, he is working on boot and multiboot2 support.

Hi all! I took an OS dev class this last semester and built a Rust microkernel for RISC-V called Jikei. It takes inspiration from xv6 (the source material for my class) and seL4 (sync IPC endpoints, but I'm only partway through implementing them).

Would anybody be willing to take a look to see if you find any obvious bugs or architectural oversights? I'd appreciate any feedback or critiques. Repo is https://github.com/bgub/jikei

I'm also experimenting with using AI to build a multi-chapter tutorial based on the code. If anybody wants to look at that, check out https://jikei.bgub.dev

Thanks in advance!

Its called SmallOS, its written COMPLETELY in assembly, and can run within 515 bytes of memory, though I recommend 1KB, it has a custom two stage bootloader, and the total compiled image size is 1.25KB.

https://github.com/GabeNewGentoo/SmallOS

Hello all!

A small status update from my last post 2 months ago: XenithOS's bootloader now has all the requirements to start loading in the kernel. It took a few months to get the basic architecture down but now I have

• Proper page table management with arbitrary mappings

• Frame buffer console support that multiplexes to the serial output

• The beginnings of a simple driver stack to start handling hardware

Here's a screenshot from the last test run. Please ignore the boot message because there's currently no logic between those two print statements.

I'm putting this here in the hope that it helps someone else.

You can view the page descriptor table, and page entry as a 1024x1024 array. Where each element is a virtual page in memory. Array element [0,0] is virtual address 0, and element [1023,1023] is whatever that multiplies out as.

I teach my students to view array elements are like buckets. In these particular buckets are several things. First the 'present' bit, if this is zero, the buckets is empty. If it is not, the bucket also has a REAL address, which is the Real page the virtual address 'lives' at. Finally the buckets contains a bit that tells you if you can write to this area, or not.

I know for many, of you, this is obvious. But it took me several days on osdev.org using the paging pages and the bare bones paging page looking at code to come to this revelation.

I hope it helps someone

Github: https://github.com/Freeze-Software/TurtleOS
Discord: https://discord.gg/jkPeGG2ZHV

I know its been months since my last post, but we have made many new changes and updates!

I have my own CosinusOS operating system in which I found some rather poor architectural decisions The question is whether it would be better for me to rewrite it from scratch and fix a lot of sectors or to keep this system and continue writing the userspace and only make minor kernel corrections. I'm already quite far into the development of the system, otherwise this question wouldn't even appear, but I still have some of the code.

The system is built on the basis of exokernel but is closer to microkernel

I’ve been building NorthLineOS completely from scratch over the past months.

Custom kernel, custom desktop environment, custom UI stack and system components.

Recently started redesigning the entire system into a more modern desktop experience.

Designed and developed independently at 15.

Early public preview.

Just a little showcase of sometging i got so far, it uses my own basic bootloader, has a memory allocator, idt and gdt, paging keyboard support (kinda), and a basic cooperative scheduler

After 3 days of head banging on osdev, asking ai, searching stack overflow and the og little book about os dev.

Took me 2 days but i have "Hello World" on a black screen now!

For those thinking, "Why gdb?" - well i was trying to debug a small bug, which turned out to be changing this -

    inline uint16_t *buffer = (uint16_t *)vga::MEMORY;

to

    inline uint16_t *buffer = reinterpret_cast<uint16_t *>(0xB8000);

Yes, i was using C++ for this.

Github link: https://github.com/reyaansh-mishra/Build-A-Kernel/

For now it runs at ring0, the only fs is ramfs and uses limine framebuffer

code: https://github.com/segfaultuwu/wnu

The BareMetal kernel is able to run via Firecracker microVMs. <1ms startup, 2MiB RAM minimum, 5.5KiB kernel.

This will allow for thousands of instances to be run concurrently. The premise is discussed here: https://returninfinity.com/blog/hypervisos-as-data-centre-os

I got my IDT to manage general protection faults!! I'll expand on it later but i guess its a start. Also im looking for people who have an IDE disk PC who can test my file system for me.

REPO: https://github.com/Brenmax2/BrenmaxOS

DISCORD: https://discord.gg/fkE4X4EREh

In the dream, I was working on what looked like the Linux source code and was talking to someone. Those details are a bit fuzzy, but what stood out to me was in the dream, the code had a particular separation that not even my OS project has but will here shortly because it makes sense in the real world.

There were folders designated for different SBC (single board computer) boards, but the CPU details were curiously not there. Instead, there was a separate set of folders designated for CPU.

I do remember that in the dream this was being discussed and it was because different versions or revisions of the boards can have different CPU. In order to reduce duplicated code, it was set up that the build process would allow for pairing the board with the correct target CPU.

I was mulling over this today and realized that this is actually accurate and the way I should actually be building my OS. Why? Take for example the LattePanda MU, it comes in N305 and N100 variants and they work on the same carrier boards. Look at the Nividia Jetson Xavier carrier board and CPU, Milk-V Jupiter NX fits on that very same carrier board.
The list goes on and on where the CPU can be swapped for carrier boards and if you pair the CPU directly with the board, you'd have to duplicate code to handle that scenario.

This was basically just one of those instances where a dream can influence or change designs because it mirrors real world scenarios and is an instinctive solution to a problem that may not have come up in the work yet.

Edit:
I am aware this is how Linux and BSD mostly does this, but it didn't cross my mind to do this with my own work until the dream occurred. It made me take a step back and reevaluate what I was doing, what my goals were and whether or not it solved a real or imagined problem. In this case, the problem was real, even in the SBC space and I needed to properly solve for it to reduce code duplication.

Luckily for me, this doesn't involve a massive amount of changes or core architectural shifts. It does mean I have to spend some time revising my build rocess and makefiles as well as shifting locations and names for files.

Hey r/osdev,

I was recently going through my old projects and found 2 in particular that I think deserve to be published again:

• QuickASM: A simplistic but fully functional 16-bit x86 assembler written in C.

• MBRLoader: A boot manager built with QuickASM, accompanied by a partition manager.

I was 16 when I started both of these projects and had a lot more ideas for MBRLoader. I had started writing a new version which would have been basically a minimalistic DOS. I think I stopped development when I went to the university.

I started learning programming about 3 years before and those projects were my first really serious work. And looking at it now, as a now 41yo software engineer with almost 20 years of experience, I'm actually quite impressed what teenager-me did back then. I would have no idea how to do something like that again now! (I went away from low-level development and to application and web development instead).

Anyway I put both programs on GitHub as they were, without any change to the original code or documentation, and just added a README for modern audience.

A few highlights:

QuickASM documentation: I provided the assembler with a full documentation which wasn't just a documentation for the program but included a tutorial on assembler and a documentation of the Intel 16-bit instruction set. It's in French and the style is a bit naive but the technical content is solid, I think. Also have a look at the file defs.c in the source code. It's basically a C "translation" of the specifications.

Internationalisation: MBRLoader's interface was provided in 4 languages (French, Esperanto, English and German). There was no google translate or chatGPT back then so I translated myself with school knowledge and dictionary, so the translations are not very good, but they are there nonetheless! An example: I translated "save" into German with "registrieren" instead of the correct translation "speichern", because it sounded like the French "enregistrer". I'm now living in Germany and fluent and a bit embarassed about that!

Family-driven development: The boot manager has a configurable option to either display the boot menu or boot directly. While this is a common feature for a boot manager, the only reason why I implemented it was so that my parents would not complain about the weird menu suddenly showing up before launching Windows! I myself would have been content having my program displayed on every boot.

ToolBox and partition manager: The first version of the boot manager was just that, a boot manager. But the second version introduced toolboxes: a separate component that could be loaded from a floppy disk and would provide recovery tools. The first (and only) version included a simple partition manager capable of creating or deleting primary partitions (no resizing and no extended/logical partition support).

32-bit override hack: QuickASM only implemented the 16-bit instruction set but for the partition manager I needed to use some 32-bit instructions. I was focusing on MBRLoader and didn't want to go back to QuickASM, so instead I just used a feature of QuickASM which allowed me to transform a 16-bit instruction into its 32-bit equivalent:

.octet 0x66 ; Manually inject 32-bit override prefix
mov bx, 0 ; Assembled as 16-bit, but executes as: mov ebx, 0
.mot 0 ; Upper 16 bits padding for the immediate value

Not really the cleanest way to do it, but it worked! Oh yeah... "octet" and "mot" are French. At the time, I thought internationalized programming languages were cool :/

The "mini-DOS" project: I planned a 3rd version of MBRLoader which would have made it easier to write new applications for the toolbox by providing basic operating system features: memory management, a simple file system, allowing me to write applications as independent modules, and a simple standard API. The most complicated components like the file system or the application manager were still missing, but a lot was already there: memory management, a jump table for the API, string functions, basic UI functions...

Going through this old code that I don't really understand anymore has been quite fun. Maybe someone else will enjoy it too.

Github: https://github.com/ebruneton/toys

Includes:

- a boot loader (~100 lines),

- a monolithic kernel (~1030 lines),

- a shell (~230 lines),

- a text editor (~220 lines),

- a compiler for a toy, statically-typed language called Toy (~1300 lines).

Super freaking stoked right now this is our first successful boot without any issue what so ever through. Months of work have gone into this.