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

[Heinrich Schuchardt]

On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
>
>
>> -----Original Message-----
>> From: Atish Patra [mailto:atishp at atishpatra.org]
>> Sent: Friday, February 7, 2020 6:56 AM
>> To: Ard Biesheuvel <ard.biesheuvel at linaro.org>; Chang, Abner (HPS SW/FW
>> Technologist) <abner.chang at hpe.com>
>> Cc: Alexander Graf <agraf at csgraf.de>; Heinrich Schuchardt
>> <xypron.glpk at gmx.de>; U-Boot Mailing List <u-boot at lists.denx.de>; Atish
>> Patra <atish.patra at wdc.com>; leif at nuviainc.com
>> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
>>
>> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> wrote:
>>>
>>> On Thu, 6 Feb 2020 at 21:06, Atish Patra <atishp at atishpatra.org> wrote:
>>>>
>>>> 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.a
>>>>>>>> doc
>>>>>>>>
>>>>>>>> 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 ?
>>>>
>>>
>>> Configuration tables are preferred over variables, but putting it in
>>> the DT makes even more sense, since in that case, nothing that runs in
>>> the UEFI context has to care about any of this.
>>>
>>>>>>
>>>>>>
>>>>>>> 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 :).
>>>>>
>>>
>>> Indeed. DT has a /chosen node that is set aside for this purpose. It
>>> does depend on how early you need the value (i.e., before or after you
>>> can run C code), but since you are passing the DT address to the core
>>> kernel, it makes way more sense to drop any additional information
>>> that you need to pass in there.
>>
>> We don't need boot hart id until real kernel boots and parse DT. So that
>> should be okay.
>> I just looked at the efi stub code once more and realized that it is already
>> parsing the DT to setup uefi memory maps from /chosen node. Adding boot
>> hart id to the chosen node does seem much cleaner to me :). Thanks for all
>> the explanations.
>>
>> I have not looked at EDK2 code. But I am assuming modifying the DT just
>> before jumping to the payload won't be too hard for EDK2 as well.
> We don’t use DT in edk2 RISC-V port and we pass boot HART ID in SMBIOS type 44h as it is spec out in below link,
> https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md

Thanks for the link.

For 'RISC-V SMBIOS Type 44 Processor Additional Information' I find
entry 0x13h 1: This is boot hart to boot system .

But is '44' a hexadecimal number? The document does not indicate this.

Best regards

Heinrich

>
> Abner
>
>>
>> Added Leif and Abner for the opinion.
>>
>>
>>
>> --
>> Regards,
>> Atish