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

[Alexander Graf]

> Am 06.02.2020 um 22:06 schrieb Atish Patra <atishp at atishpatra.org>:
> 
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf <agraf at csgraf.de> wrote:
>> 
>> 
>>> 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 don't want to create SBI interface to pass this information.
> 
>> We already have hooks that allow you to modify the DT right before it
>> gets delivered to the payload. Just add it there?
>> 
> 
> Hmm. I guess it is true if the DT is loaded from MMC or network as well.
> How about EDK2 ? If we go DT route, it also has to modify the DT to
> pass the boot hart.
> 
> As it requires DT modification in multiple projects, why not use efi
> configuration tables as
> suggested by Ard ?

How is assembling a configuration table better than modifying a DT?

Alex

> 
>>> 
>>> 
>>>> 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
>> 
>> 
> 
> 
> -- 
> Regards,
> Atish