On Sat, Aug 8, 2020 at 7:59 AM Heinrich Schuchardt xypron.glpk@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