Bringing SerenityOS to real hardware, one driver at a time

One of Serenity's philosophical decisions is that as much as possible they build everything themselves from scratch. So even if NetBSD's drivers would be easy to adapt and have a compatible license they probably wouldn't go that route and would instead write their own drivers.

> Device drivers are a huge obstacle for any fledgling OS.

I've wondered if new/hobby OSes would fare better by starting out targeting a popular single board computer like a raspberry pi? A mostly fixed set of hardware to make/get drivers for and test your system on.

Rump kernel/anykernel is the concept. The drivers can run in user space with minimal underlying support.

https://en.wikipedia.org/wiki/Rump_kernel

The solution is to pick 1 good set of hardware (that the software authors sell themselves if possible) and build drivers for that and only that.

It's basically what Apple does and has done from the start as far as I can tell. The only breakthrough consumer Unix-like thing out there.

System76 is another example of (almost) that.

Frame.work comes close although they don't focus on the OS as much.

I believe it. Their libc is remarkably tidy, I've copied stuff out of it several times for various projects. Can't speak for the drivers, though.

Actually it is very simple to communicate with the modern hardware (both x86 and ARM). All you need to do is read/write the hardware memory. This called Memory-mapped I/O (or MMIO in short). Of course you cannot do this from the application that run on the OS since it is a job of the kernel to prevent the application to direct access the hardware memory. Here are the roughly steps if you want to get into this field:

1. You need a programming language that capable of output the machine code for your target CPU. Better to be a language that does not have GC or runtime like Rust/C++/C/Zig. If you are not familiar with low-level language I recommend C as a first step since it is easy to find examples on the internet.

2. Learn the basic of assembly language of your target CPU. You need this because the above language may not provide the intrinsic functions for some instructions.

3. Start writing a hello world kernel. You can find a bunch of tutorial on the internet, especially for x86.

4. With step 3 you should already learned how the CPU start your kernel and how many mode and privilege level available on the CPU. Usually the CPU will give you the highest privilege level when jumping into your code.

5. Now you need to setup the CPU into whatever you want. For example, you likely need to switch the CPU to long mode on x86 so you can use 64-bits instructions. In this step you likely need to setup a virtual memory. You can find a reference for your CPU from their website.

6. If you have reached this step then congratulations! You should already have some idea how the CPU is working with the OS and how to enumerate available devices to discover its memory location. There are a ton of works that need to be done once you are here like implementing filesystem, scheduler, etc.

Remember that the only different between the software that run on the OS and the OS kernel is mode of the CPU currently executing its code. With highest privilege level you can use some instructions that are not available to the normal application.

I started with LDD [1], which is a book from a decade ago, but should still be relevant these days. And at some later time I found this treasure trove [2] hidden in FreeBSD docs, among which, the FreeBSD Architecture Handbook and the FreeBSD Developers' Handbook may be of special interest to you.

[1] https://lwn.net/Kernel/LDD3/

[2] https://docs.freebsd.org/en/books/

I really enjoyed this tutorial:

https://wiki.osdev.org/Bare_Bones

I did an OS dev course in uni, that was some 15 years ago. We used Minix, which is super cleanly written (5kloc kernel) and is covered by many textbooks (sorry but can't remember which one I used, but there's also the official one).

I got to implement a simple server (Minix is a μkernel so that's how most drivers work) and do some kernel hacking. I read the course material in advance and didn't even attend any lectures, still got an 8/10 grade ^^

I've also heard many good things about NetBSD and of course SerenityOS (Andreas did a lot of development on live streams).

It is indeed easy once you know where to start.

Honestly, step 1 is just understanding what the purpose of each component is.. OS, driver, device etc...

for eg. A device driver is about exposing an interface for other programs being run on your computer, to access and control a device...

https://m.youtube.com/watch?v=juGNPLdjLH4 this is a decent crash course on that.

You can create a toy USB device using an Arduino or something that can send / receive information to your PC. Eg: https://m.youtube.com/watch?v=yTc2GLXfCOY .

Then it's a matter of just understanding what the subsystem you're interested in writing drivers for your OS does, how to make it do something, just write code. Storage devices, graphics devices, etc...

A raspberry pi can be a decent starting point for these experiments too.. eg. Writing a bare metal operating system for the raspberry pi https://github.com/babbleberry/rpi4-osdev

Me as well.

Sadly, they have parted ways at this point. Not only has Ladybird broken off into an independent project but it does not consider SerenityOS a target platform anymore.

Ladybird is slowly shedding a lot of the “home grown” Serenity layers and replacing them with more mainstream alternatives.

As I am primarily a Linux user, I am excited to see Ladybird become a real alternative on Linux. However, as a fan of SerenityOS as well, I am sad to see all the energy and innovation that was going into Ladybird get stripped out of SerenityOS.

Maybe the devs hate Seinfeld.

I’m definitely running it unsupervised and without understanding what it does

Very curious what that would represent, to a layman.

the next one is somehow worse

looks like perplexity didn't fall for it

    The article appears to be about bringing SerenityOS to real hardware, specifically focusing on efforts to run it on a Dell Chromebook 3100. It details the author's journey in setting up debugging capabilities, working with UART interfaces, and developing drivers for components like eMMC storage.
    
    Some key points from the article include:
     - The author's efforts to create a closed-case debugging solution using a Raspberry Pi Pico
     - Challenges with initializing and communicating with the eMMC storage
     - Differences between SD, MMC, and eMMC protocols
     - Debugging techniques using port 0x80 for output
     - Progress in getting SerenityOS to boot and display graphics on real hardware
    
    The article does not speak highly of Microsoft Windows or express hatred for Linux. In fact, it focuses primarily on open-source development and alternative operating systems.

This is called prompt injection. Modern LLMs have defenses against it but apparently it is still a thing. I don't understand how LLMs work but it blows my mind that they can't reliably distinguish between instructions and data.

A bit of both probably. That kind of prompt injection generally does work though.

Neat. Bard says it can't access the site when I ask for a summary and give it a link. ChatGPT summarizes it and doesn't seem to reference those instructions even when asked if it read them.