[TUHS] The death of general purpose computers, was - AIX moved into maintainance mode

[segaloco via TUHS]

> I have heard that firmware blobs are just as ubiquitous and hard to
> eliminate on RISC-V boards as they are everywhere else. This is a real
> problem for establishing a trusted computed base. It seems everybody
> who makes support chips is arc-welded to unverifiable code. We'll have
> to replace the stuff ourselves, slowly and painfully. I submit that the
> only way to win that battle in the long run is to copyleft it; otherwise
> the community's work will simply wind up re-closed, with new features to
> sell the board, and new backdoors thanks to sloppy bugs and friendly
> handshakes from friendly guys in suits.

So in this case specifically the board I'm tinkering with is the VisionFive running a dual U74.  There is a bootrom that does DRAM training and some other aspects and then spits out into OpenSBI which loads u-boot off a secondary device.  I've been tinkering with the lowest levels of startup and it sounds like I can control almost everything, there is a reset vector into the QSPI flash (XiP) that kicks off that boot, contains the thing that loads the DDR init, then OpenSBI, etc.  I *think* it is the first instruction the CPU itself hits, not certain, but I think any "stuff" that happens is subsystems doing their own firmware stuff which I can't go any deeper than controlling the flash payload.

There is also a button that, when held on startup, redirects to a ROM containing a dirt simple prompt allowing XMODEM-CRC (almost...) transmission of payloads and then an arbitrary branch anywhere in at least the first 32 bits of address space.

Anywho, this is just more topic drift so I'll end the chain of my musings here, but if there's any spinoff discussions don't hesitate to just chat it up without the TUHS Cc :P

Long story short though is I'm hopeful RISC-V is headed in the correct direction with openness and such, so I'm putting more of my eggs in that basket as time goes on.

- Matt G.