On Sat, Aug 8, 2020 at 7:59 AM Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > Hello Anup, > > I have looking at you OpenSBI code firmware/payloads/test_head.S. Here > like in U-Boot's common/spl/spl_opensbi.c you put all but one hart in to > an enless loop (hang). > > When Linux boots via UEFI it will wake up the extra harts after > ExitBootServices(). So I assume we should define function hang() in > lib/hang.c as __efi_runtime to avoid seeing it overwritten by the EFI > payload. > Proper Linux will wake up non-boot harts through SBI HSM APIs. Until then all other harts are held on OpenSBI in sbi_hsm_wait() [1].
[1] https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_hsm.c#L133 Here are the details on SBI HSM extension if you are interested. https://fosdem.org/2020/schedule/event/riscv_bootflow/ > @Ard: > Does Linux take care of the hanging harts and redirect them to its own > routine before SetVirtualAddressMap()? Otherwise anything could happen. > Linux doesn't need to as SetVirtualAddressMap is part of efistub which is only executed in the booting hart. > On the Kendryte K210 we don't have SPL. So we will not boot in the > sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply that > we have to implement the hart lottery at the entry point of main U-Boot > in this case? > Do you want OpenSBI->U-Boot or OpenSBI->U-Boot->Linux for kendryte ? Is this related to testing U-Boot EFI on Kendryte right ? > Best regards > > Heinrich -- Regards, Atish
