Question regarding "boot-hartid" DT node

[Heinrich Schuchardt]

On 12/2/21 16:17, Sunil V L wrote:
> Hi Heinrich,
> On Thu, Dec 02, 2021 at 04:09:34PM +0100, Heinrich Schuchardt wrote:
>> On 12/2/21 16:05, Sunil V L 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.
>>>
>>>      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.
>>>
>>>      Do you have any suggestions what can be done in ACPI case? Can we use
>>>      a UEFI variable with RVI specific GUID to pass this information? This
>>>      will have the advantage that it can work with either DT or ACPI.
>>>      Also, we may not need any UEFI spec update. Do you see any issue with
>>>      this approach? Your inputs will be very helpful.
>>
>> What happened to your suggestions in
>>
>> https://linuxplumbersconf.org/event/11/contributions/1099/attachments/781/1602/LPC_2021_ACPI_RISCV_Sunil.pdf
> 
> The challenge is, the EFI stub part which comes very early even before
> proper kernel starts. If the information required in later stage of the
> kernel, we can use ACPI tables.

What I have never understood is why the core calling the EFI stub cannot 
identify it own hartid which is stored in CSR mhartid. The missing piece 
seems to be SBI support to read this piece of information. That way we 
could get rid of passing the boot hartid via a0.

Best regards

Heinrich