3 ms·
I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it and thus will be open-source "librebootable" from the start,
by shrubble 2y ago
I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it and thus will be open-source "librebootable" from the start, with no binary blobs.
- cesarb 2y ago> I am assuming (hope I am right!) that the RISC-V board doesn't have the equivalent of the IME on it Actually, it does! Check the block diagram on the first PDF linked to by this article, it has two RISC-V "monitor cores", a 32-bit one and a 64-bit one, besides the four 64-bit main cores. > and thus will be open-source "librebootable" from the start, with no binary blobs. There's always going to be a small bootstrap ROM, to configure everything to the point where code can be loaded from the external flash; but other than that, I agree with you: I also hope that the bootstrap code, and the code which runs on these "monitor cores", will be open-source from the start.
- snvzz 2y ago>open-source "librebootable" from the start Already is. There's a default flow with u-boot SPL, opensbi and u-boot. There's an alternative flow which includes TianoCore (UEFI). There's another alternative flow, oreboot. All the tiny ROM inside the SoC does is fetch the next stage from elsewhere, as per the state of some GPIOs. One of the options is XMODEM on the UART. DRAM setup and such happen in the next stage, which is e.g. u-boot SPL mentioned above. >doesn't have the equivalent of the IME There are some extra tiny cores in the SoC. They are available for you to use; you can implement an IME if you wanna. But by default they're doing nothing.