Nothing about the Raspberry Pi at all is "normal," and it's a very useful filter for people who have read about the various deep weeds of firmware/OS development and those who have actually gotten their hands dirty on a Pi - because the first group will express admiration about the "open and well documented hardware," and the second group will laugh at the first group and start cursing the various non-and-poorly-documented nonsense that's in the Pis.
They're nice devices, and work well enough, but they are architecturally insane and unlike anything else except the previous Raspberry Pis that were hacked to to make the new ones.
The Pi1/2/3 are more or less an (undocumented) GPU with an ARM core bolted on the side. The GPU boots the system, allows the ARM core some access to the DRAM (not at the same addresses as the GPU sees things, so be sure which version of memory addresses you're looking at), and most of the hardware control is done by asking the GPU to please do this thing for you through the mailbox interfaces. In the same way that userland applications make syscalls into the kernel, the kernel running on a Pi makes syscall-like requests into the GPU to do just about anything.
The reason you see things like "All the interrupts are only ever on a single core" is because the interrupt controllers simply don't allow anything else. The Pi2 BCM2836 interrupt controller feels a little bit like an intern's project, using the BCM2835 bolted on the front as an input for the rest of the hardware. At least the Pi4 finally gets a GIC...
They're fine, sort of... as long as you're OK with the only documentation for some of the hardware being "This Linux driver works with it" and "Well, people have reverse engineered most of it." But they're absolutely insane, architecturally, they're poorly documented, and this doesn't seem widely known.
Very similar to previous-gen game consoles, e.g. the Wii U’s “Broadway”
https://github.com/librerpi/ https://gwolf.org/2022/04/how-is-the-free-firmware-for-the-r...
Is the Pi4 any different/better?
Raspberry Pis were initially just a way for the Pi foundation to help Broadcom sell SoCs nobody wants anymore but they still had lots of stock/tooling for. Sort of like "hybrid" bicycles are how bike manufacturers milk more money out of hardtail (non-suspension) MTB frames.
> Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
It's funny, I just posted a comment about being afraid to dig into KMS code for fear a wizard would show up and tell me I'm looking in a wrong or irrelevant place. Luckily, your comment preempts that process.
And also luckily, I've only thrown flags at Chromium provided by other wizards so far. So my ignorance about KMS remains pure. :)
> The non-fake driver has been all sorts of problematic but it’s getting better.
So... are there like two different teams, one Pi-specific 'f', one general 'not f', racing to see whose module will become stable first?
Do both teams stream on Twitch? If not they should.
Basically, disregard everything you’ve learned about KMS from the world of Raspberry Pi. It’s only relevant to the quirkiness of the Raspberry Pi’s half-closed ecosystem.
The F in fkms stands for “fake” because they created a quirky abstraction to fake KMS compatibility. The non-fake driver has been all sorts of problematic but it’s getting better.
But none of this Raspberry Pi specific weirdness should be extrapolated to the KMS/DRM subsystem in general.