21 Jan
2023
21 Jan
'23
12:33 a.m.
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.