> ... the device tree blob could/would be embedded in the same package as this HFI firmware
Why "could/would"? It is part of the firmware, now. HFI BIOS is U-Boot + VideoBIOS + Set-Up program. Its job is to initialize your hardware (video controller included) and start your boot loader (EFI program), just like in a PC.
> ... even if the main NAND/emmc/SSD hosting the OS is wiped out
There is [almost] always the possibility of recovery. I have three RISC-V systems, and each of them cannot be "bricked":
* X-Modem for VF2;
* SD-card boot for Unmatched;
* fastboot (Android) protocol for the K3
> on PCs, there is usually a NOR flash that hosts the BIOS/UEFI.
Same on Unmatched, for example: you may store HFI BIOS in NOR (boots very fast!), or on your SD card (boots slow, only 81 KB/sec). What to boot from is selected by DIP switches. Similar mechanism on VF2 too.
Why "could/would"? It is part of the firmware, now. HFI BIOS is U-Boot + VideoBIOS + Set-Up program. Its job is to initialize your hardware (video controller included) and start your boot loader (EFI program), just like in a PC.
> ... even if the main NAND/emmc/SSD hosting the OS is wiped out
There is [almost] always the possibility of recovery. I have three RISC-V systems, and each of them cannot be "bricked": * X-Modem for VF2; * SD-card boot for Unmatched; * fastboot (Android) protocol for the K3
> on PCs, there is usually a NOR flash that hosts the BIOS/UEFI.
Same on Unmatched, for example: you may store HFI BIOS in NOR (boots very fast!), or on your SD card (boots slow, only 81 KB/sec). What to boot from is selected by DIP switches. Similar mechanism on VF2 too.