[PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Alexander Graf]

On 06.02.20 19:28, Atish Patra wrote:
> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt <xypron.glpk at 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.glpk at gmx.de>
>>> Reviewed-by: Atish Patra <atish.patra at 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