An Elf Odissey! #dreamos64 I recently added support for basic ELFs in my hobby #kernel but, it required me to dig into some very obscure issues caused by some changes in llvm and their linker.

Basically the introduction of large sections in #llvm broke the grub image, and caused more problems to my kernel.

I posted all the details of my debug process in my free #kofi post here: https://ko-fi.com/post/Finally-Dreamos64-is-officially-running-an-ELF-Exe-B0B41AYZW0

Dreamos64 Running on QEMU

https://makertube.net/videos/watch/4fe63165-9300-4060-a936-bdffa874c0ef

Today a new version of the printed version of "Osdev Notes" has been released! :)
More info in my free #kofi post: https://ko-fi.com/post/Osdev-Notes-New-printed-version-released-U7U5199LOA
The printed version is available here:
https://www.lulu.com/search?sortBy=RELEVANCE&page=1&q=osdev+notes

Major update is the replacement of the "Stivale 2" protocol with the "Limine Protocol".

The project as usual is on github:
https://github.com/dreamportdev/Osdev-Notes/releases/tag/v1.5
#programming
#operatingsystem
#kernel #assembly #x86_64 #operating_systems #selfpublishing #osdev #hobbyos #programmingbook

#Fiwix is an operating system written from scratch, based on the #UNIX architecture and fully focused on being #POSIX compatible. It's a #hobbyOS and, since it serves also for educational purposes, the #kernel code is kept as simple as possible for the benefit of students and OS enthusiasts.

It follows the #SystemV Application Binary Interface (ABI) and it also aims for #Linux 2.0 system call compatibility

Version 3.4 was released on November 15th: https://www.fiwix.org/news.html

Habemus ELFs! Not the fantasy creatures. But just a set of organized bit and bytes.
I managed to make my #kernel #dreamos64 launch its first ELF executable, although is just printing a message.
ELF support is still very limited, but, is still a great achievement for my toy project.
More info on my free #kofi post: https://ko-fi.com/post/Habemus-ELFs-Q5Q6160TJI
#osdev #operatingsystemdevelopment #programming #systemprogramming #kernelprogramming #osdever #operatingsystem #hobbyos #hobbykernel

After more than two months another Dreamos64 update. Not new features but fixes and improvements, full story on #ko-fi
https://ko-fi.com/post/Dreamos64-Status-update-U6U71340LC (free).
I found a nasty bug in a core memory function, where i was returning true instead of false and viceversa. Also some code refactor and documentation improvements.

okay. weird question. #kernel #hobbyOS

how do you make a seekable on-disk format? how do filesystems normally do seekable things?

e.g. - if you have a #btree larger than memory.

I guess does the file contain the physical disk locations, or just the inode names?

if you're a SQL DB, how do you "store" rows?

in such a way that you can efficiently seek in the DB files such that you read them?

#database

I've seen lots of writeups for trees and tries, but they're usually talking about the algorithm /in memory/, not the layout /on disk/.

Habemus #scrolling (nearly) :)

I'm working on adding framebuffer scrolling in #Dreamos64
Initially it will be just scrolling the text up, when it reach the last line.
#osdev #kernel #operatingsystemdevelopment #programming #framebuffer #systemprogramming #kernelprogramming #osdever #operatingsystem #hobbyos

I don't think it will interest anyone, but i'm happy to share it nevertheless! :D
My #operatingsystem system (the #kernel i'm writing) has moved its first steps into #userspace! Below a screenshot showing the logging of two #threads running a supervisor idle and a user idle.
#osdev #kernel #programming #dreamos64 #hobbyos #operatingsystemdevelopment #toykenel

More info about the project are here: https://github.com/dreamos82/Dreamos64

Update on my #hobbyos , #tyros . Feature-wise nothing has changed, as I'm still at the state of having detected a SATA disk, but haven't send any commands to it yet.

The code behind the scenes has changed a lot, though. As you may discern from the screenshot, I have some debugging prints in there from my memory mapping code. Mapping memory is much more dynamic and flexible now (and I can even dynamically allocate new memory from the free memory pools).

This is all necessary to get SATA working, which is the next step.

Tip for anyone else developing a hobby OS: if your kernel is compiled with debugging symbols, gdb can show you the line of code for a specific instruction pointer with the 'list' command (e.g., "list *0xf0a"). Very useful in conjunction with your page fault handler to quickly determine which pointer was not mapped properly.

Minor update to my #hobbyos , #tyros . Basic AHCI (SATA) configuration, setup, and probing is working. Actual SATA operations like reading or writing are still a ways off. That will involve memory allocation (still haven't finished my memory allocator), DMA, interrupts with locks....

Still very proud of myself!

This has really given me an appreciation for how fiddly it is writing hardware drivers. EVERY hardware specification you read is like "So set this bit to 1 to initialize. That's all that's required, but some devices may require a reset after that. Also you should check this bit to see if it's 1, but it will probably work anyway, unless your device is very old". And it goes on like that. Like how can anyone have any confidence that their code is going to work across all devices? It's an impossible problem. I thought specifications would be better by now, and I guess they are...a little bit...but still quite bad.

Another update on my #hobbyos #tyros . Last post, I said I was going to tackle AHCI (SATA controller) next. Which...I've started...kind of.

There was a bit of a domino effect here. In order to find the AHCI controller, I needed some PCI code, and in order to find the PCI code, I needed some ACPI code. And all of this is complicating my virtual memory mappings, so I'm in the middle of redoing virtual memory to be done properly. That means dynamically allocated page tables.

Fun stuff! I have made the decision to only support PCI Express. This excludes all (old) PCI 1.0 and PCI 2.0 systems. I can live with that since it makes my life easier, ha.

Hope to get into real AHCI code soon!

Obligatory screenshot.

Going to work on #tyros #hobbyos again today. Did some preliminary PS/2 keyboard work. I can type stuff! Next up is AHCI (hard drive support).

Doing this work on a hobby OS is, as always, granting a deeper appreciation for how hard it is working with hardware. I'm working with hardware specifications that have been published and examined and implemented for sometimes decades, and even then it's often hard to figure out exactly what to do.

To help keep myself from forgetting everything, I've done, I've started rewriting (so far just the boot code) in noweb (https://www.cs.tufts.edu/~nr/noweb/), a Literate Programming tool. I've always been a fan of Literate Programming and have found it helps a lot.

Obligatory screenshot of my keyboard doing stuff.

Update on #tyros #hobbyos that I'm foolishly making from scratch. My first time in a couple weeks getting to sit down with it. Fixed the crashing bug I had with handling IRQs. I can now properly get IRQs from the timer and keyboard (and then do nothing with them). Scrolling text even works now! Feeling somewhat accomplished.

Next up is dealing with scan codes from the keyboard.

Slow and steady progress on #tyros #hobbyos . This is not a real milestone because I clearly have a bug, but it's been about 3 days (and more than 5 hours of work I think) of trying to get the timer IRQ handler working.

So I'm showing off! Avec bug! I won't have time to fix it until next weekend anyway probably.

I got 3 pings from the PIT (hardware timer) before my kernel went tits up somehow. It really is nice to see SOMETHING. #request_reaction #topic_milestone

Major milestone for #tyros #hobbyos! Very proud of myself, especially since I only get an hour or so every few days.

What's done:
- Boot from GRUB (and have GRUB initiate the framebuffer via VESA/GOP)
- Init the serial port and print out debugging information
- Transition from 32-bit mode to 64-bit x86-64 "long mode". Long mode REQUIRES paging (virtual memory) and GRUB can't reasonably do that for you, so this step is required to be done by the kernel
- Set up the call stack to make the leap from asm into C (and probably Rust soon?)
- Render characters (only basic ASCII) onto the framebuffer

Up next:
- Interrupts (IDT) and reading input from the keyboard
- More sensible memory management (right now the framebuffer's virtual address is hardcoded)
- Access a disk, towards mounting a root filesystem

#tyros #hobbyos updated. Booting well with GRUB, and got it printing (text) to the screen. Got the stack set up for running 32-bit code. Need to get it into long mode for 64-bit code next.

It's still quite fun. I will reiterate that I think the PC architecture (both BIOS and UEFI) is unnecessarily cumbersome and frustrating to work with. I'm hoping I get over the rough patches just when I'm getting tired of it haha.

I'm going to skip doing an initrd architecture and just have the kernel mount the root filesystem directly. I don't know if that's a mistake.

A new #Unix-like OS is out there for all to try. #serenity #foss #floss #hobbyOS

https://www.osnews.com/story/129716/serenity-a-new-unix-like-operating-system/