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 < > > [email protected]> 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 -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
