question about RISCV EFI stub support

Arnd Bergmann arnd at arndb.de
Thu Mar 4 13:16:49 GMT 2021


On Thu, Mar 4, 2021 at 3:25 AM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
> The reason we coupled C and EFI is really to avoid the existence of EFI-only
> kernels, which are a headache these days because EFI isn't widely supported or
> used on RISC-V.  The general assumption is that, since we recommend rv64gc for
> portable systems and EFI is mostly of interest to portable systems, we won't
> end up with non-C EFI systems and therefor don't need to worry about having
> incompatible kernels.  That said, if there's one thing I've learned from the
> whole RISC-V thing it's that whenever I say "we don't think hardware that does
> X will show up" it does.  Assuming that's the case and we end up with non-C
> systems that people want to run EFI on, we'll figure out a way to do that -- if
> someone has real hardware I'm inclined to support it, otherwise we just end up
> with a mess of vendor-specific forks.

I think it makes sense to require the EFI stub in addition to RV64GC in the
minimum set for a 'portable' kernel, along with an MMU and a well-defined
set of peripherals that need built-in drivers (irqchip, clocksource,
console, ...),

Any hardware platform that doesn't have the minimum portable set or that
requires additional kernel support for booting can still be supported by
custom kernel configurations, it just wouldn't work with random distro kernels.

I think you require that already per documentation, but it might be helpful to
have a Kconfig symbol in the kernel that enforces this by selecting the
required options (ARCH_RV64I, RISCV_ISA_C, MMU, EFI, SERIAL_SIFIVE,
SIFIVE_PLIC, ...) and hiding any incompatible ones (CMDLINE, BUILTIN_DTB,
...).

        Arnd



More information about the linux-riscv mailing list