Question regarding "boot-hartid" DT node

[Heinrich Schuchardt]

On 12/2/21 17:58, Ard Biesheuvel wrote:
> On Thu, 2 Dec 2021 at 17:53, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
>>
>> On 12/2/21 17:20, Ard Biesheuvel wrote:
>>> On Thu, 2 Dec 2021 at 16:05, Sunil V L <sunilvl at ventanamicro.com> wrote:
>>>>
>>>> Hi All,
>>>>      I am starting this thread to discuss about the "boot-hartid" DT node
>>>>      that is being used in RISC-V Linux EFI stub.
>>>>
>>>>      As you know, the boot Hart ID is passed in a0 register to the kernel
>>>>      and hence there is actually no need to pass it via DT. However, since
>>>>      EFI stub follows EFI application calling conventions, it needs to
>>>>      know the boot Hart ID so that it can pass it to the proper kernel via
>>>>      a0. For this issue, the solution was to add "/chosen/boot-hartid" in
>>>>      DT. Both EDK2 and u-boot append this node in DT.
>>>>
>>>
>>> I think this was a mistake tbh
>>>
>>>>      But above approach causes issue for ACPI since ACPI initialization
>>>>      happens late in the proper kernel. Same is true even if we pass this
>>>>      information via SMBIOS.
>>>>
>>>
>>> It would be better to define a RISCV specific EFI protocol that the
>>> stub can call to discover the boot-hartid value. That wat, it can pass
>>> it directly, without having to rely on firmware tables.
>>
>> As discovering the current process' hartid is not a UEFI specific task
>> SBI would be a better fit.
>>
> 
> I disagree. The OS<->loader firmware interface is UEFI not SBI. So if
> the EFI stub needs to ask the firmware which boot-hartid it should
> pass in A0, it should use a EFI protocol and nothing else.
> 
> Whether or not the loader/firmware *implements* this EFI protocol by
> calling into SBI is a different matter (and likely the best choice).
> But that does not mean the EFI stub should make SBI calls directly.
>

The EFI stub does not need the boot-hartid. It is the main Linux kernel 
that does. And that kernel already implements SBI calls.

The main kernel could just try to read CSR mhartid which fails in S-mode 
and the SBI could emulate it.

Best regards

Heinrich