[junon]

That implies AArch64 support which many hobby OSes don't have, usually because the introductory osdev material is written largely for x86.

But yes, raspi is a good platform if you are targeting arm.

As I'm also designing an OS, my biggest piece of advice for anyone seriously considering it is to target two archs at once, in parallel. Then adding a third becomes much easier.

[kelnos]

Raspberry Pi has a bizarre boot sequence and bringup process, much of it which is not open and not implemented in open source code. I think it's probably not a great platform for this sort of thing, despite it being decently well-documented.

(And even then, its USB controller, for example, has no publicly-available datasheet. If you want to write your own driver for it, you have to read the Linux driver source and adapt it for your needs.)

[jazzyjackson]

For anyone that hasn't fallen into this rabbit hole yet it's a good one: raspberry pi started out as a kind of digital billboard appliance, so they chose a GPU with efficient 1080p decoding and strapped a CPU to the die. On power up the (proprietary) GPU boots first and then brings up the CPU.

That's as far as I got before discovering the Armbian project could handle all that for me. Coincidentally that's also when I discovered QEMU because 512MB was no longer enough to pip install pycrypto once they switched to Rust and cargo. My pip install that worked fine with earlier versions suddenly started crashing due to running out of memory, so I got to use Armbians faculties for creating a disk image by building everything on the target architecture via QEMU. Pretty slick. This was for an Orange Pi.

[officeplant]

>GPU boots first and then brings up the CPU.

IS that the reason for the full screen of colors before you see the boot sequence? Never thought about that.

[jazzyjackson]

Yep.

The "color gamut" display, as you call it, is a GPU test pattern, created by start.elf (or start4.elf, or one of the other start*.elf files, depending on what is booting). That 3rd stage bootloader is run by the GPU which configures other hardware (like the ARM cores and RAM split).

https://forums.raspberrypi.com/viewtopic.php?t=336516

[rollcat]

You could probably skip some of the difficult parts if you bring in an existing bootloader that can provide a UEFI environment (it's how Linux & the BSDs boot on ARM Macs). But Serenity is all about DIY/NIH

[Aaron2222]

openSUSE does the same to boot on Raspberry Pi as well. Probably a few other distros as well.

[LeFantome]

It seems like a lot of the OS dev momentum is shifting to RISC-V. Lots of recent tutorials and courses going that way. Any links to your OS?

[junon]

RISC-V is the new hotness but it has limited usefulness in general purpose osdev at the moment due to slower chips (for now) and the fact not a lot of ready-to-go boards use them. I definitely think that's changing and I plan to target RISC-V; I have just always had an x86 machine, and I have built some electronics that use aarch64, so I went with those to start.

Kernel is still in early stages but progress is steady - it's "quietly public". https://github.com/oro-os