[RFC PATCH 0/1] Add boot hartid to a Device tree

[Ard Biesheuvel]

On Thu, 5 Mar 2020 at 04:28, Schaefer, Daniel (DualStudy)
<daniel.schaefer at hpe.com> wrote:
>
> Hi,
>
> I have started to implement the corresponding changes in EDK2: https://github.com/changab/edk2-staging-riscv/compare/5f63e9249751ccb9302514455b9a1a7038f34547...RISC-V-DT-fixup
> What happens is: The DTB is embedded in the FW image and passed to sbi_init in SEC phase. We initialize OpenSBI as early as possible and because it also wants to modify the device tree, I have to pass it the DTB as next_arg1.
> Then it's passed to PEI in the firmware context and further to DXE via a HOB. In DXE the boot-hartid is inserted and it's installed into the EFI system config table from where the EFISTUB reads it.
>
> Unfortunately I don't get any console output after the EFISTUB calls ExitBootServices, so my patch is still WIP.
> Atish, which platform file in OpenSBI did you use to test your changes? platform/qemu/virt/platform.c or platform/sifive/fu540/platform.c ?
> Maybe the failure is unrelated to the new patches - we've never booted Linux from EDKII yet.
>
>
> I'm a bit skeptical whether DT is the best way to pass the boothartid to the kernel. Ard has argued that it's good because it's independent from UEFI, but the proper kernel doesn't read the hartid from there - it gets it from a0. Only the EFISTUB reads the hartid from the device tree. Therefore the solution we need is EFI specific anyways, right?
> One of the design goals is that we don't want to force bootloaders, which load the EFISTUB (e.g. UEFI Shell, grub chainloading, systemd-boot), to change.
>
> If we let the firmware embed the hartid in the DT, the user cannot swap out the DT later for their custom one. They need to use the one given by the firmware.
> Of course we could add commands and config to bootloaders to load and fixup (embed hartid) the device tree... but, as mentioned earlier, we want to avoid that.
> Additionally from EDKII side we're also planning to run later stages, including the bootloader, in S-Mode, where they wouldn't even have access to mhartid and thus couldn't fixup the DT.
>
> If instead the firmware writes the hartid into the EFI system config table, the EFISTUB can read it from there, just like it does the device tree already. Then bootloaders can put a user supplied DT in the config table, too, like they always have.
>
> What do you all think - does that make sense?
>

It doesn't really matter from the EFI stub pov if the information
comes from the DT or from another config table. But the idea that
RISC-V is 'special', and that you have to pass *two* pieces of
information around instead of just one like on every other platform is
something that you should really think about carefully - there may be
other places where it will bite you down the road.

Also, the idea that a DT is a file that you ship with the kernel is
giving a *lot* of grief in the ARM world. The DT describes the
hardware, not the software, and so it is the responsibility of the
platform to provide it. If the platform gives you some way to drop in
another version of the DT in one way or the other, that is absolutely
fine, but in this case, the platform should know how to update
/chosen/boot-hartid (which it already can, in any case). But don't
make it part of the boot protocol, it really doesn't belong there.