re custom firmware > I've seen oreboot and thank you for contributing to it, but isn't modern firmware extremely difficult to write and modify? I would love to be educated on this topic (or I can educate myself - in time; no pressure). I believe for most users, it doesn't matter whether firmware is custom or vendor-provided - the only exception is the amount of bloat and bugs in typical vendor firmware, and the repairability of a firmware you can modify
It's not hard at all if you start from a clean slate. Working with existing frameworks such as U-Boot or coreboot can be powerful with some training. In the case of oreboot, I really just do the bare minimum and bring up the DRAM, essentially some thousand MMIO reads/writes with bits of logic, and I keep an optional runtime (on RISC-V based on RustSBI) for those who want it, but as I said earlier, you can start your OS in M-mode just fine and define your own interface. It's just another exception handler and an interrupt handler on another layer anyway. So the question remains where you want to start defining your OS. I personally find it sensible to tailor it for the effective hardware platform, such as, say, the Allwinner D1, StarFive JH7110, SpacemiT K1, Canaan Kendryte K230, or XuanTie/T-Head TH1520. I have all of those and find them pretty okay in their own right. YMMV. That is, AFAIK, Plan 9 does not have much portability across hardware platforms anyway - what NetBSD, U-Boot, Linux et al do via Device Trees, or what Allwinner does with FEX. Other than that, as I said, SBI would be the software abstraction. On Tue, 22 Sept 2026, 07:48 plat via 9fans, <[email protected]> wrote: > On Sunday, September 20, 2026, at 11:29 PM, mikethe1wheelnut wrote: > > ..from laptops to SoC's with attached monitors.. ..I'm effectively > throwing out my entire system for a near-blank slate, and I'll end up with > software that won't work on ~99% of computers.. ..LMAO.. yeeehawww! > > Calm down, please. Hardware support does relate to the simplicity and > openness of the board, but it also related to the popularity of the board > > On Sunday, September 20, 2026, at 11:58 PM, mikethe1wheelnut wrote: > > > ya. such an idea is, of course, as sexy and addictive as it is terrifying > and unrealistic. and, at least in my case, more about vertical integration > than knowing better. > > Making or modifying an SBC is very possible and companies pay very well > for it. Not sure where to start, but some other people in here are more > knowledgeable on this topic > > > All hardware has some amount of suck. > Hardware is an abstraction > > On Monday, September 21, 2026, at 4:00 PM, mikethe1wheelnut wrote: > > I have been exploring the rabbit-hole of higher-level languages, each one > clamoring for attention. c, rust, zig, haskell, etc, etc, ... > > Stick to one. Some are better than others. Some are better for certain > projects > > On Monday, September 21, 2026, at 5:23 PM, Jiji Freya Daniel Maslowski > wrote: > > You don't need to use the vendor firmware at all > > I've seen oreboot and thank you for contributing to it, but isn't modern > firmware extremely difficult to write and modify? I would love to be > educated on this topic (or I can educate myself - in time; no pressure). I > believe for most users, it doesn't matter whether firmware is custom or > vendor-provided - the only exception is the amount of bloat and bugs in > typical vendor firmware, and the repairability of a firmware you can modify > > On Monday, September 21, 2026, at 6:47 PM, ron minnich wrote: > > So, yes, you can ignore RISC-V for a while yet. But not for long. I choose > not to ignore it, even with its limits and flaws, > > I like that RISC-V is open, even though it doesn't guarantee anything. I > have worked with power, but it generally seems less popular than RISC-V at > this point, at least in the microcontroller world > > On Monday, September 21, 2026, at 6:47 PM, ron minnich wrote: > > Further, RISC-V comes with a few nice ideas that make new approaches to > old problems pretty easy. I'll be talking > about one such idea at supercomputing 2026. > > Sounds interesting, I may tune in ;) > > Also, on concerns on e-waste some people have voiced - I think that > computing e-waste that comes from people buying Raspberry Pis or similar > boards is minimal, if not zero. Raspberry Pis especially, but SBCs in > general have a pretty big market of people willing to buy second-hand > devices. Nobody in their right mind would just throw away a Pi. Using > second-hand x86 computers for Plan 9 is not only often painful, but you're > most likely to need an extra terminal or a very small CPU server rather > than a big CPU or a disk server, and a big loud machine that may not even > boot is the opposite of that. People use Raspberry Pis for Plan 9 because > they offer a nice, small, and silent terminal or a weak CPU server - not > because "I have one, might as well use it" - certainly some people like > this exist, but I believe they are in the minority. In general, using a > more efficient repairable computer seems more eco-friendly to me than > sticking to inefficient architectures > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Tbf390d3a51f65cdf-Mb8beb743a5ba97c83826a551> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbf390d3a51f65cdf-Mf10fab433966a1751a674476 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
