It seems like there was a critical bug sleeping inside my memory manager. It appeared since I started using the PMM in my AHCI driver, but I think the problem is in the virtual memory manager. For this reason I am working currently on the memory manager instead of the AHCI driver.
As soon as I fix the MM, I will continue on the AHCI driver. It probably won’t be finished until the end of stardance.
I am jumping a little bit fast form PCI to AHCI, but I think the PCI driver is as good as I need it right now, and if I learn that it isn’t, I will fix it. Anyway, I am starting to work on AHCI! This is really cool, as this allows me to communicate to storage devices! At the moment the kernel just lists connected devices, but that’s just the beginning!
The AHCI driver is in a very early stage, and it will take me a lot of time to finish, as AHCI is relatively complicated and the documentation isn’t written for beginners like me ;-)
I am starting to write a PCI driver, which opens a new world to me! As you can see, the kernel is already able to print some information on boot about connected PCI devices. I also added a function that can search for a specific PCI device by it’s class, which will help me to implement drivers for specific PCI devices.
The real reason I am implementing PCI is that I need it to find the AHCI controller. The AHCI controller can be used to access connected storage devices, which is my long-term goal.
I have released the next version of my own kernel! The biggest feature I added is multitasking. While it doesn’t look that special, it was actually very difficult to make my kernel switch between different tasks!
Here are some notes on how to try the project:
If you don’t want/can’t run it, you can look at the video in the readme.
If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller
I moved the status bar from the bottom to the top and removed the borders, in my opinion it looks better this way.
I am already working on a new command which will make it possible to see the borders of the framebuffer in QEMU. This will be useful for debugging while keeping the UI simple.
There are still some obvious bugs: My printf() implementation seems to break with invalid format strings and I have a bug in my memory manager which prevents me from merging the command showing the screen borders into main.
I will try to fix the bugs, but the features are now complete. I want to release the new version tomorrow.
I added a status bar which show the current time. It is very basic, but makes the OS look way more friendlier in my opinion. Sorry for the weird messages in the main window, I am currently debugging my printf implementation.
I still have a problem with printing dates: The year 2006 would be printed as 206, because the RTC has seperate registers for year and century, so if century is 20 and year is 6 it prints 206.
I am making it possible to split the framebuffer into multiple views. This should make it more easy to have a more advanced UI than a CLI already inside the kernel. Hopefully there will be user processes at some point, but I want to have a nice looking OS before that.
I still have to fix some things (as visible on the screenshot). After that, I can try to make use of it and add a status bar or a separate command window.
The kernel can now read the current time from the Computer’s RTC! At the moment, you can’t select the time zone, so the time is probably in UTC, depending on how the computer is configured.
I am planning to improve the use experience, for example by using multiple “windows”, to maybe even have a status bar.
I added GCC support, which should (hopefully) make debugging easier for me. I can’t show it really on the screenshot, trust me, it is compiled with gcc!
I have still bugs in my multitasking system. Currently I get a page fault when compiling with optimization >-O2 with clang, the next step is to test it with GCC.
I implemented a simple mutex (which isn’t perfect yet, but it works). As visible on the screenshot, I used it to make it impossible for the test tasks to print at the same time. One problem with it is that it currently runs hlt after releasing a mutex so that a different task has a chance to acquire it, which doesn’t seem like the best solution to me.
I am making the terminal position atomic, so that I don’t need mutexes for output, which I can not use in interrupt handlers
I fixed the last bug (that I could find) and multitasking works now! On the screenshot you can see two tasks trying to print the numbers 0-19 at the same time. The CLI even waits until the tasks are finished!
The output is still a little bit broken, so I want to implement output buffering and mutexes, so that multiple threads can’t print at the same time.
I am still working on multitasking, but I am stuck currently. I am trying to modify the stack frame so that asm_switch_task is called after iretq, but it doesn’t work. As you can see on the screenshot, I get a page fault as soon as it tries to switch tasks (in the debugging process I had it switch 2-3 times before it crashes, which is not really better)
My highest priority is to get task switching to work consistently. After that, I will see what I can polish.
The kernel will now switch the SSE register state lazily, but I still have two problems:
I think it is time to write a version of malloc() which can guarantee a specified alignment. After that, I can try to actually switch tasks automatically with a simple scheduler! I will probably use the PIT interrupt to switch to the next task in a list.
It probably doesn’t sound special, but it is as important as everything else:
SSE is an extension of the CPU which has 16 128-bit registers, but is rarely used. This means, that saving all of these registers every time a task switch occurs would cost some performance. For this reason, the CPU has a bit that can be set to indicate that a task switch occurred. In most cases, nothing happens and the registers are kept in their original state. But if a task needs to use SSE instructions, the CPU generates an interrupt, which manually saves the SSE registers. This is what I am working on currently.
All interrupt handlers use now my custom wrappers, which made possible that I can work on SSE support.
I now actually optimized the dynamic array type, which means that it allocates memory in bigger chunks instead of every time an element is added / removed. In the process I added some debug logging, so typing is now very difficult if you don’t know how it works with log level LOG_DEBUG.
I finally decided to implement my own wrapper for ISRs instead of relying on __attribute__((interrupt)). This should allow me to use floating point math with the FPU in the future. Also, I can now read more registers on interrupt (screenshot).
I am currently working on making all ISRs compatible with my wrapper. Then I will continue trying to get multitasking to work.
I decided to try to implement multitasking! The kernel can now switch tasks, but only one time. This is the first step in direction of real multitasking, but I still have much to do. It is interesting to see, How I realize how bad my implementations I did earlier are, because I don’t fully understand them. But now I can improve them!
I made a quick implementation of dynamic arrays for the keyboard driver, but as I realized that I need them to store a list of tasks, I decided to implement one optimized implementation I can use everywhere. I have implemented a very simple version and use it in the keyboard driver, but it isn’t optimized yet. In fact, it’s even worse than the one I had earlier in the keyboard driver, because every modification now requires a reallocation.
I am going to optimize dynamic arrays, and then continue with multitasking.
I quickly wrote a simple PIT (Programmable Interval Timer) driver, so that I have a basic sleep function.
It isn’t really useful at the moment and not thread safe, but as it was very simple I thought why not?
I realized that MADT I/O APIC overrides also override the flags of entries, so I am using these now unless it’s overridden by the user.
As I have now a simple keyboard driver, I want to work on something new. Some things I am considering:
All of this topics are completely new to me, so I will pick the one that looks the most simple and probably fail anyway.
I added a CLI the kernel, which was possible, because I finally have a keyboard driver! It only took so long, because it was actually difficult to write it: I thought I have to program the PIC, but it was already disabled so I had to learn the more complicated APIC.
There is a demo video in the README if you don’t want to run the kernel.
If you want to run it on macOS with UTM, you have to force a PS/2 controller: https://docs.getutm.app/settings-qemu/qemu/#force-ps2-controller
