The funny thing is what literally started all of this is I wanted to update the firmware on my VisionFive, followed their instructions to a T, and it bricked the firmware. I found that the embedded recovery ROM still worked, so then tried to follow their processes to reflash the bootloader/SBI stuff. That likewise failed, so I gave up on trusting any of their documentation/advice and just started hacking on the thing with binaries sent over XMODEM on the serial line. Their XMODEM-CRC implementation is broken so I even had to write my own version of sx (they had a XMODEM send, likewise doesn't work stock...got it to work modified but then just wrote a simple stdio tool without all the cruft of their implementation.) Fast forward to today and the most I've put together for that is this: https://gitlab.com/segaloco/riscv-bits (src is "kernel" stuff, util is that XMODEM-CRC transfer thing I mentioned) I've got some process handling and VM stuff that hasn't gone up to the repo yet, but it's hanging around because it's incomplete anyway. I then realized with what I'd learned in the process I was poised to start hacking on other SBCs at that level, so ordered the Pico, Ox64, and an Onion Omega2 (ARM32, RV64, and MIPS32 respectively) and have slowly been building up development workflows for each (I'm eschewing vendor libraries and SDKs given my experiences with the VisionFive...) The boot matter itself is proving the most annoying part, since literally each one of those has a different mechanism to get an operational binary loaded up. VisionFive is an (broken) XMODEM-CRC transfer, Pico is a UF2 file over USB, Ox64 is some custom Bouffalo Lab tool (although I think it's just a wrapper on top of some standard XMODEM/Kermit/etc. type protocol), and then the Omega2 I haven't even really explored raw boot yet, it's got OpenWRT on it so I've just been hacking on the existing OS thus far, getting more familiar with the board, my hunch is it's probably a UF2-ish thing since it's main UART is over USB like the Pico. RISC-V presents some complications given the privilege model, what with the "master" mode vs the "supervisor" mode, as opposed to other chips where supervisor and master are essentially one in the same. Where I'm torn is if I want to have OpenSBI in the mix just to go with what is ubiquitous in RISC-V land, or even try to handle that matter with my own code. That wouldn't necessarily have an analog on all the other platforms. Then there's hypervisor stuff, what with RISC-V having the extension and other chips having something akin to this, but it not being universal. The simple answer is to just get everything, regardless of details into a "supervisor" state, ensure necessary interrupts are forwarded to this state if another, higher one exists, and enter into this supervisor state with MMU/VM turned off. Then theoretically each machine can start from here by setting up memory, then device inits, then FS and other subsystem init, and finally process init. Anywho, I'm kinda at a standstill on this project right now while I work on a few other things, namely a disassembly of Dragon Quest for the Famicom (embedded console games are a lot like operating systems) and manual page diffing stuff, but I'm hoping to carve out some time this summer, maybe even a little coding retreat from work for a few weeks, to hammer out a true project plan on paper so I can start working on more of this in earnest. I'm not sure yet if I'll be headed down the "get UNIX going" or "get my kernel going" route first when I get there, but either way, I'm sure we'll have plenty to talk about in the coming year. - Matt G. ------- Original Message ------- On Thursday, April 20th, 2023 at 8:57 AM, Paul Ruizendaal <pnr(a)planet.nl> wrote: