On 06.02.20 19:28, Atish Patra wrote:
On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
<ard.biesheu...@linaro.org> wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
RISC-V booting currently is based on a per boot stage lottery to determine
the active CPU. The Hart State Management (HSM) SBI extension replaces
this lottery by using a dedicated primary CPU.
Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
In this scenario the id of the active hart has to be passed from boot stage
to boot stage. Using a UEFI variable would provide an easy implementation.
This patch provides a weak function that is called at the end of the setup
of U-Boot's UEFI sub-system. By overriding this function architecture
specific UEFI variables or configuration tables can be created.
Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
Reviewed-by: Atish Patra <atish.pa...@wdc.com>
OK, so I have a couple of questions:
- does RISC-V use device tree? if so, why are you not passing the
active hart via a property in the /chosen node?
Yes. RISC-V uses device tree. Technically, we can pass the active hart
by a DT property
but that means we have to modify the DT in OpenSBI (RISC-V specific
run time service provider).
We have been trying to avoid that if possible so that DT is not
bounced around. This also limits
U-Boot to have its own device tree.
I don't understand how this is different from the UEFI variable scheme
proposed here? If you want to create an SBI interface to propagate the
active HART that U-Boot then uses to populate the /chosen property,
that's probably fine as well.
We already have hooks that allow you to modify the DT right before it
gets delivered to the payload. Just add it there?
I'd assume the EFI stub would not care at all about this information, and it
would give
you a Linux/RISC-V specific way to convey this information that is
independent of EFI.
Yes. EFI stub doesn't care about this information. However, it needs
to save the information somewhere
so that it can pass to the real kernel after exiting boot time services.
DT sounds like a pretty natural choice for that to me :).
Alex
