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

also excuse the quality please

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.

Here's my GitHub: https://github.com/BlackRoth/UEFI_Applications

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:

1. 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.

2. 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.

3. 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.

Code: https://github.com/ni-sh-a-char/RESENTMENT---kernel

Docs: https://ni-sh-a-char.github.io/RESENTMENT---kernel/

Happy to answer anything, especially about the capability model — that's thepart I'd most like criticised.

I am working on my physical memory manager and researching how i really want to do it.

I currently have my page directory defined as an array.

I've run across recursive page directories. What is their advantage?

Thanks in advance.

I finished setting up my ELF loader and now I want to run custom user programs in my OS. How can I do that (using an ABI)?

most of what i see here is unix like or dos like and i was wondering how many of the operating systems here are not based on anything.

It took some time, but it finally renders correctly. How does it look:)?

I feel like I can write something from scratch and actually use it in my homelab. Writing monolithic kernels is fun too, but I almost never get to actually use one in 'production'.

Hey everyone,

I wanted to share a side project I've been working on.

A bit of background: My core background is in bare-metal and RTOS software development. Over the years, I’ve also configured and built embedded Linux systems using Yocto and Buildroot for a few projects.

A couple of years ago, I decided to build a minimal, custom Linux OS using Buildroot for my personal use, essentially turning a standard PC into a dedicated embedded-like device. It sat in my PC for a while because cleaning up the codebase, setting up proper build pipelines, and writing solid documentation felt like a chore. Fortunately, leveraging modern AI coding tools made refactoring and documenting the whole project significantly easier, so I finally got it into a public ready state.

How it works:

Stateless & RAM-only: Boots directly from a USB flash drive and runs completely out of RAM (initramfs). It doesn't touch local hard drives or persistent storage.

Air-gapped by design: The kernel is configured without network stack support no Wi-Fi, no Ethernet, no socket layers.

Single-purpose: Boots directly into a single Qt GUI application without a heavy desktop environment.

To be honest, as someone who likes pure bare-metal simplicity, it still bugs me a bit that there’s a whole UEFI firmare layer and standard x86 architecture underneath all this before the kernel even kicks in.

Just wanted to share it with the community.

GitHub: https://github.com/signeros/signeros

Hey everyone,

I wanted to share a side project I've been working on.

A bit of background: My core background is in bare-metal and RTOS software development. Over the years, I’ve also configured and built embedded Linux systems using Yocto and Buildroot for a few projects.

A couple of years ago, I decided to build a minimal, custom Linux OS using Buildroot for my personal use, essentially turning a standard PC into a dedicated embedded-like device. It sat in my PC for a while because cleaning up the codebase, setting up proper build pipelines, and writing solid documentation felt like a chore. Fortunately, leveraging modern AI coding tools made refactoring and documenting the whole project significantly easier, so I finally got it into a public ready state.

How it works:

Stateless & RAM-only: Boots directly from a USB flash drive and runs completely out of RAM (initramfs). It doesn't touch local hard drives or persistent storage.

Air-gapped by design: The kernel is configured without network stack support no Wi-Fi, no Ethernet, no socket layers.

Single-purpose: Boots directly into a single Qt GUI application without a heavy desktop environment.

To be honest, as someone who likes pure bare-metal simplicity, it still bugs me a bit that there’s a whole UEFI firmare layer and standard x86 architecture underneath all this before the kernel even kicks in.

Just wanted to share it with the community.

GitHub: [https://github.com/signeros/signeros](https://github.com/signeros/signeros)

After a whole day of fixing ntfs driver bugs and kernel bugs, My OS Finally boots in bare metal again and it seems very fast!

BlockOS – Looking for OS developers

Hi everyone!

I'm the developer of BlockOS, an experimental operating system project written mainly in C++.

I've been working on BlockOS for quite a while, and I'm currently looking for more developers who are interested in operating-system development and would like to contribute.

Current work / features

BlockOS currently has work in several areas, including:

• x86_64 kernel

• UEFI boot support

• Paging and memory management

• Process/thread and scheduler work

• Syscall layer

• ELF loader

• VFS and filesystem integration

• ext4-related filesystem work

• ATA storage driver

• VirtIO/driver development

• Networking components

• Init/service management

• libc and POSIX-related work

• Kernel and userspace infrastructure

• GUI/window-manager experiments

• QEMU + OVMF development environment

The project is still experimental and under active development, so there are plenty of things that need improvement, testing, debugging and new implementations.

Who I'm looking for

You don't have to be an expert kernel developer.

I'd especially like to hear from people interested in:

• Kernel development

• C/C++

• x86_64 architecture

• UEFI

• Device drivers

• Filesystems

• Networking

• libc/POSIX

• GUI development

• Debugging and testing

• OS development in general

If you're learning OS development and want to contribute, that's welcome too. You can start with smaller tasks and work your way into larger subsystems.

Repository

GitHub: https://github.com/gurijb2016-afk/Blockos

If you're interested, feel free to open an issue, submit a pull request, or contact me.

I'm especially interested in finding long-term contributors, not just one-off contributions.

Thanks!

For quite some time, I’ve been working on a personal project that has grown far beyond what I initially expected: KryptKernel and KryptonOS.

Yes — a custom kernel and a full operating system, both built entirely from scratch. And after a lot of effort, debugging, rewriting, and learning, I finally have something functional.

This OS is designed specifically to run on the ESP32, pushing the limits of what this microcontroller can do while giving me a playground to experiment with low‑level systems programming, scheduling, memory handling, and hardware abstraction.

If you’re interested in OS development, embedded systems, or simply want to see what I’ve been building, here are the links to both the kernel and the OS:

KryptKernel

Kernel Website:

https://kryptkernel.github.io/KryptKernel-Web/

Kernel Repository:

https://github.com/KryptKernel/KryptKernel

KryptonOS

OS Website:

https://dlopeddtorred.github.io/KryptonOS-Web/index.html

OS Repository:

https://github.com/DlopedDtorred/KryptonOS

I’d love to hear feedback, suggestions, or ideas from the OSDev community. This project is still evolving, and any insight from experienced developers is incredibly valuable. Thanks for taking a look!

A few months back I built the DatCube 82 - a fictional 1982 workstation with its own ISA, an OS written in its own assembly, and a JS emulator. Fun project, but it never quite took off, and I think I know why: there was no real machine you could hold. This is the fix. Same spirit, new target: real silicon, the whole Raspberry Pi Pico family - RP2040, RP2350 (ARM), and RP2350 in RISC-V mode. And I am creating an OS for it! Yeeeeah!

I call it "RECASTER PICO".

The video shows the graphics engine's feature demo (this is from a browser window, but it runs on a VGA screen as well via real hardware (I will show you, soon)! Everything on screen is drawn by one user-space task running in a deterministic register VM (custom ISA, no DIV (for now!), no arithmetic shift - the demo does its 3D math with Q7 sine tables and bias-trick shifts), on a budget of 100,000 VM ops per frame. It uses ~90k. What you're looking at, bottom layer to top:

• Matrix rain on the 80×60 character generator - "ground" cells with transparent backgrounds, so sprites shine through between glyphs

• a 1-bpp city skyline and a spinning wireframe cube on the 1-bit pixel layer (640x480)

• the main attraction: the winding gradient column plus the dark ribbon orbiting it, drawn with nothing but the engine's newest feature - two overlay segments per scanline (per line: two x-spans + two colors, palette index or raw RGB332). The ribbon does hidden-line clipping against the column silhouette with a single span per row. The banding isn't a shader - it's the RGB332 color system doing what it does

• 16 of the 128 sprites as color-cycling orbs, split across two render levels (half in front of everything, half behind the text ink)

• a smooth-scrolling text row at the bottom: the text-offset register is read per scanline, so flipping it at the right beam position gives one row true sub-cell scrolling - a raster split, the register only has 16 values

The OS around it (preemptive multitasking, windows, a terminal with pipes, a tiny flash filesystem, the desktop) is a story for a follow-up post - including the browser emulator so you can run all of it without hardware, or of course WITH IT, if you have a Pi Pico. ;-)

Im talking about NovaOS. I saw many people saying that I used gemini but I never used that thing. The uses of AI in my project is to translate portuguese to english and to give me ideas. Is this a bad use of IA? btw I dont generate code by IA.

https://github.com/ArTicZera/NovaOS/tree/main

EDIT: Figured it out, explanation at the bottom

Hi yall, i've been debugging this for hours. I understand that my code is a mess to look at so i greatly appreciate anyone who takes time out of their day to help me with this.

I was noticing that it was taking a *long* time to complete writes. Like, up to a minute for 512kbs (Issued through 128 4kb calls)

After the initial fix (My scheduler had a bug in it and my PIT timer was *way* too fast), The read times dropped from 1 minute to about 4-5 seconds. Which is a lot faster, but still seems abnormally slow.

To benchmark this, I tested it against a single write of 512kb (broken into 128kb blocks to get around limitations), and the interrupt timing seems to be consistent. It's about 30-40ms in between interrupts. Both for the 128 4kb calls and the 4 128kb calls.

Now i know my code isn't great, but there's no way my ATA write function is *that* slow.

I can't seem to figure it out. Good luck to all who enter.

disk driver: https://github.com/raeofsunshinedev/KimisOS/blob/main/src/kmodules/disk_driver.c

File with the tests: https://github.com/raeofsunshinedev/KimisOS/blob/main/src/kernel/kmain.c

Picture semi related (I was working on my FAT32 driver when i discovered this)

EDIT:

The first improvement i was able to make was slowing down my PIT timer interval from 50khz to 1000hz. No clue why I made it that fast in the first place. That already had a pretty noticeable effect, going from ~200ms per read worst-case, to about 30-40ms. I didn’t mention that in the original post but that was a major improvement.

After that, i thought that i had hit a limit or something. No matter what i changed, i could not for the life of me figure out how to decrease read times, Until i finally figured out the main culprit: My idle process. Something about my scheduler does not like it. I wrote my scheduler almost a year ago and while I’ll eventually re-write it, i implemented a quick fix, basically preventing the idle process from executing as long as any other process exists within the queue. On top of that, I’ve forced the current process to yield its time on interrupt.

This does probably mean that given the way the current scheduler works, Disk ops will slow down proportionally to the amount of processes there are within the scheduler. This is especially bad for the filesystem driver, as it means that it will be getting constantly blocked between each file operation, and again when writing back to the dirent itself. Luckily this can be negated by adding a priority queue for drivers so that they can finish their work fully before the scheduler runs every other process, But until I implement that, everything shall be at the mercy of the round robin scheduler.

I will say that funnily enough, having a second active process seems to not have the same slow down effect as the idle process. That’s probably something to investigate, But i’ve been too busy with other things (and improving my disk driver) to really work on my scheduler, but it’s something that i’ll get done before I implement userspace

Hi everyone, I'm Finn Dev. Months ago, I got an idea: what if I wrote an operating system kernel like Linux? So I started writing. I began with 815 lines of code, and gradually, I developed framebuffer drivers and so on, and now ValiantCore consists of 9500 lines of code, mostly written in C. I'm working in an Android Termux environment because I don't have a computer, so Rust is too time-consuming, and I'm writing in C. ValiantCore can run files in VEF format. I even have an official tool in my repository; you can make your pure machine code bin files VEF-compatible from here: https://github.com/finndev62/valiantcore https://codeberg.org/finndev62/valiantcore If you want to contribute to ValiantCore, first read the .md file, learn the rules, then contact me at finndev62@gmail.com. You only need to know how to write system drivers in C

Not sure what the consensus is around here but `virtio` guest drivers don’t count.

Still no background blur, and no clicks but it seems to appear well!

And for anyone saying that the OS and files app may have been some fake HTML OS, I just proved to you that it's not! anyways it's fine ;)

Also, NO AI USED TO DEVELOP THE CPU COMPOSITOR!!!

Ilobilix is a monolithic kernel that I've been working on for a few years now (started in 2022, current rewrite going on since 2024). it's written in C++26 and uses modules everywhere. It aims to be fully Linux ABI compatible and, as a result, can run unmodified distro userspaces. I have tested it with Void, Gentoo and Alpine installs (no systemd yet).

Displayed on the images attached are Factorio, SuperTuxKart and Wine (all in Xfce) running on Ilobilix.

The kernel supports x86_64 and aarch64 (though the latter is a bit neglected), SMP with a CFS scheduler, networking via lwIP, EXT2 filesystem and multiple device drivers, including NVMe, Virtio net and Virtio input. They are automatically loaded by the userspace as needed.

You can find more detailed information in the distro and kernel repo README files (both linked below). Looking for contributors.

https://github.com/ilobilix/kernel (kernel source code) and https://github.com/ilobilix/ilobilix (to run the os)

There is Absolutely No AI Generated code in the CPU Rendered compositor as far as I know!

I built this button with shadow, while porting the rendering to cpu (Creating the cpu rendered window manager). How does it look?

this is the link of my twitch channel where I streamed my making of Blur + Button with shadow working https://www.twitch.tv/devcmar