Hi Atish,
Is the HARTID in DT used to *define* which thread should used as the booted payload (Linux) or is it used to *inform* Linux that it was started on this particular HARTID?
If we assume two DTs are used: one for OpenSBI and one for Linux, which one (or both) is used to contain the HARTID?
Cheers
FF
On Wed, Sep 16, 2020 at 9:04 AM François Ozog francois.ozog@linaro.org wrote:
Hi Atish,
Is the HARTID in DT used to *define* which thread should used as the booted payload (Linux) or is it used to *inform* Linux that it was started on this particular HARTID?
The latter. It is just to inform EFI stub that booting HARTID is X so that it can be set to a0 while booting proper Linux.
If we assume two DTs are used: one for OpenSBI and one for Linux, which one (or both) is used to contain the HARTID?
The DT used only in OpenSBI doesn't need to contain the HARTID. This is only required for UEFI boot. That's why the first EFI loader (U-Boot/EDK2) should set it in the device tree.
Cheers
FF _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 9/16/20 7:27 PM, Atish Patra wrote:
On Wed, Sep 16, 2020 at 9:04 AM François Ozog francois.ozog@linaro.org wrote:
Hi Atish,
Is the HARTID in DT used to *define* which thread should used as the booted payload (Linux) or is it used to *inform* Linux that it was started on this particular HARTID?
The latter. It is just to inform EFI stub that booting HARTID is X so that it can be set to a0 while booting proper Linux.
In M-Mode (the highest privilege level on RISC-V) you can read the id of the current hart from CSR register 0xf14, mhartid. But trying to read the register at another privilege level causes an exception.
In M-Mode U-Boot reads the hart id from the CSR register. In S-Mode it reads the a0 register at the entry point which is filled by the secure execution environment (SEE, e.g. OpenSBI).
Before handing over to the next boot stage U-Boot fills the 'boot-hartid' property of the /chosen node with a 32bit value containing the boot hart id (function arch_fixup_fdt()).
When Linux is started directly from the SEE the a0 register conveys the hart id. Using the device-tree information the EFI stub does the same. The necessary patch series is under review. I guess we will see it in the 5.11 kernel.
If we assume two DTs are used: one for OpenSBI and one for Linux, which one (or both) is used to contain the HARTID?
The best way to determine the boot hart id is CPU specific. If all harts are equivalent, a lottery can be used to choose a random hart. If some harts are special, the firmware may need some preseeding, e.g. by an internal device-tree.
When booting via UEFI only one device-tree is provided by the firmware as a configuration table to the UEFI payload. There is no need for the 'boot-hartid' property to be static. In the case of a boot hart lottery it has to be added dynamically like U-Boot does it.
The 'boot-hartid' property of the /chosen node should be mentioned in the EBBR specification as a requirement for the RISC-V architecture.
Best regards
Heinrich
The DT used only in OpenSBI doesn't need to contain the HARTID. This is only required for UEFI boot. That's why the first EFI loader (U-Boot/EDK2) should set it in the device tree.
Cheers
FF
On Thu, 2020-09-17 at 03:24 +0200, Heinrich Schuchardt wrote:
On 9/16/20 7:27 PM, Atish Patra wrote:
On Wed, Sep 16, 2020 at 9:04 AM François Ozog < francois.ozog@linaro.org> wrote:
Hi Atish,
Is the HARTID in DT used to *define* which thread should used as the booted payload (Linux) or is it used to *inform* Linux that it was started on this particular HARTID?
The latter. It is just to inform EFI stub that booting HARTID is X so that it can be set to a0 while booting proper Linux.
In M-Mode (the highest privilege level on RISC-V) you can read the id of the current hart from CSR register 0xf14, mhartid. But trying to read the register at another privilege level causes an exception.
In M-Mode U-Boot reads the hart id from the CSR register. In S-Mode it reads the a0 register at the entry point which is filled by the secure execution environment (SEE, e.g. OpenSBI).
Before handing over to the next boot stage U-Boot fills the 'boot-hartid' property of the /chosen node with a 32bit value containing the boot hart id (function arch_fixup_fdt()).
When Linux is started directly from the SEE the a0 register conveys the hart id. Using the device-tree information the EFI stub does the same. The necessary patch series is under review. I guess we will see it in the 5.11 kernel.
If we assume two DTs are used: one for OpenSBI and one for Linux, which one (or both) is used to contain the HARTID?
The best way to determine the boot hart id is CPU specific. If all harts are equivalent, a lottery can be used to choose a random hart. If some harts are special, the firmware may need some preseeding, e.g. by an internal device-tree.
When booting via UEFI only one device-tree is provided by the firmware as a configuration table to the UEFI payload. There is no need for the 'boot-hartid' property to be static. In the case of a boot hart lottery it has to be added dynamically like U-Boot does it.
OpenSBI also uses lottery to determin the boot hart. But U-Boot need to do lottery only if SMP is enabled. If U-Boot is running in S-mode, SMP is disabled by default because only booting hart enters to U-Boot and eventually to Linux. All non-booting harts are brought up in Linux using SBI HSM extension.
The 'boot-hartid' property of the /chosen node should be mentioned in the EBBR specification as a requirement for the RISC-V architecture.
Absolutely. I am working on the RISC-V PR for EBBR.
Best regards
Heinrich
The DT used only in OpenSBI doesn't need to contain the HARTID. This is only required for UEFI boot. That's why the first EFI loader (U-Boot/EDK2) should set it in the device tree.
Cheers
FF
boot-architecture@lists.linaro.org
-
Atish Patra -
Atish Patra -
François Ozog -
Heinrich Schuchardt