OpenBSI and U-Boot

[Atish Patra]

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