What’s wrong with the Raspberry Pi – Own your bits https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/
the GPU running the show and the crappy peripherals definitely turned me off to the Pi. i only did low level stuff with the 1st gen model but there were these issues:
- the GPU boots the CPU and can control it. it runs a proprietary firmware.
- no reliable documented timers: the CPU's clock was dynamic but it also went to all the CPU's peripherals, so one has to use an undocumented GPU timer and hope its binary blob firmware doesn't touch it.
@enkiv2 (3/2) 😅
- barely an interrupt controller: no vecotrs! so an interrupt handler needs to test flag bits to see what threw the interrupt, then jump to the appropriate routine. i wrote a soft-vic to work around this 😒.
@enkiv2 oh, and lack of an RGB LCD interface was a big minus since those are cheap and relatively easy to understand.
tangent: SPI LCDs for gaming are grooooooooosssssss. holy tearing, low framerates, and resource wastage...
Personally, I prefer reading a mask of pending interrupts and software-vectoring based on those. It adds latency, but lets the software determine what has priority.
But, in the modern age of distributed processing on a single motherboard, message-signalled interrupts largely renders this technique obsolete anyway.
@vertigo @enkiv2 @ddipaola
Presumably kestrel has something like a GDT, right? A bitfield that configures whatever global-level processor behavior is configurable? Being able to vectorize or unvectorize interrupts globally makes sense if you expect OSes to be written by folks with different preferences. (Another possibility is a pseudo-PIC where you swap interrupt numbers to control priority for vectorized interrupts).
@enkiv2 @vertigo @ddipaola
(A pseudo-PIC would also let you map interrupt numbers together which might be useful -- you know, instead of flow-through. But, programming the PIC to get IRQ lines right was a huge pain in the ass last I did it so maybe it's not good to reinvent that particular square wheel unless you've got good reason to believe you can make it round.)
@enkiv2 @ddipaola The RISC-V ecosystem currently supports two standard PIC definitions: PLIC and CLIC. The latter is a proper subset of the former from what I understand. However, both are sufficiently complex enough that I stay away from them.
I think I'll need to support them eventually when I want to support Linux; however, for now, I'm going to avoid adopting them.
@enkiv2 @ddipaola There is no equivalent to a GDT on the RISC-V privilege-mode specifications. The closest that you get is the *optional* feature (it's fully standards compliant to *not* support this) to dispatch interrupts by source (not priority). The algorithm defined is to branch to (vector table base + interrupt_number * 4). The reason for the *4 is because RISC-V opcodes are 32-bits wide.
It's intended that the programmer simulate a vector table by declaring a list (of sufficient length for your hardware) of JAL instructions, the targets of which handle their respective interrupts.
Also, interrupt source 0 is shared with non-interrupt exceptional cases as well (e.g., illegal instruction traps, page faults, etc.), so the interrupt handler for IRQ 0 still needs to dispatch based on some flags in the mcause register.
@bamfic @technomancy @enkiv2
Yeah. It's a shame. I don't think it's *just* capitalism, but capitalism boosted by speculation: early movers can build undeserved hype that allows them to stay afloat long after whatever merit they once had has been exhausted & then turn around and use that accumulated capital to out-market, starve, or acquire-and-fire anybody who spent that early period doing good design instead of self-promoting.
Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelque soit votre langue.