I'm struggling to understand what U-Boot and/or Coreboot does that a RISC-V SBI (Supervisor Binary Interface) doesn't. I understand that the SBI's function in abstracting features, but I don't understand what things need initialising that an SBI doesn't do. I've seen a few examples (slide 9) of the types of boot processes you can have, but I don't understand why which one is necessary in each case.
Could the boot process be?: ZSBL (Zero-Stage bootloader) -> SBI -> Kernel
And if that's the case what is the point of having Coreboot or U-Boot at all? I understand that a First-Stage bootloader may need to be loaded into Static RAM first to initialise the Dynamic RAM and then move to an SBI, but what would be the point of having the SBI load into U-Boot after the SBI then? Just for the boot manager?
In the theoretical case that RISC-V gets to the PC market, what would be an ideally fast boot setup?
Could the boot process be?: ZSBL (Zero-Stage bootloader) -> SBI -> Kernel
Yes. It works perfectly fine on QEMU this way, but only because QEMU already loads the kernel into RAM. OpenSBI ("fw_jump") in this case just does some firmware setup and simply jumps to the kernel.
On normal devices, your kernel is likely located in a file system. OpenSBI has no drivers to read that file system and cannot load the kernel. Here you need something like U-Boot that comes with the needed drivers.
I think these slides are a good resource.