←back to thread

309 points LorenDB | 1 comments | | HN request time: 0s | source
Show context
Santosh83 ◴[] No.42637177[source]
Read somewhere that it is relatively easy to adapt NetBSD's drivers into a custom kernel... maybe Serenity folks can go that way? Device drivers are huge obstacle for any fledgling OS.
replies(6): >>42637487 #>>42638178 #>>42638309 #>>42639168 #>>42642231 #>>42665209 #
mysterydip ◴[] No.42637487[source]
> 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.

replies(6): >>42637523 #>>42638258 #>>42639203 #>>42639284 #>>42639368 #>>42646433 #
HankB99 ◴[] No.42646433[source]
> A mostly fixed set of hardware

But it's not. Over time they've revised the SOC (processor) and gone from 32 to 64 bit capability. The latest - Pi 5 - has totally re-architected the I/O subsystem, putting most I/O functions on their RP1 chip and connecting that to the SOC using PCIE.

And as already mentioned, the unusual boot sequence: The GPU takes control on power up and loads the initial code for the CPU.

All of the OSs I'm aware of that run on the Pi depend on "firmware" from the Raspberry Pi folk. Looking at the files in the folder that holds this stuff, it's pretty clear that every variant of the Pi has a file that somehow characterizes it.

replies(1): >>42648737 #
cesarb ◴[] No.42648737[source]
> All of the OSs I'm aware of that run on the Pi depend on "firmware" from the Raspberry Pi folk. Looking at the files in the folder that holds this stuff, it's pretty clear that every variant of the Pi has a file that somehow characterizes it.

That's not very different from depending on the BIOS/UEFI firmware on a PC; the main difference is that older Raspberry Pi didn't have a persistent flash ROM chip, and loaded its firmware from the SD card instead. Newer Raspberry Pi do have a persistent flash ROM chip, and no longer need to load the firmware from the SD card (you can still do it the old way for recovery).

> And as already mentioned, the unusual boot sequence: The GPU takes control on power up and loads the initial code for the CPU.

Even this is not that unusual; AFAIK, in recent AMD x86 processors, a separate built-in ARM core takes control on power up, initializes the memory controller, and loads the initial code for the CPU. The unusual thing on Raspberry Pi is only that this separate "bootstrap core" is also used as the GPU.

replies(1): >>42661641 #
1. HankB99 ◴[] No.42661641{3}[source]
> Even this is not that unusual; AFAIK, in recent AMD x86 processors, a separate built-in ARM core takes control on power up,

Good point. I think most modern motherboards (and all server boards) have a "management engine" that prepares the board on power up and even serves some functions during operation. I believe that that's what supports IPMI/iDRAC even when the host is running.

I don't think that changes the situation WRT the variety of H/W for the Pis through their history and even at present.