OpenBSI and U-Boot

Heinrich Schuchardt xypron.glpk at
Sat Aug 8 18:17:42 CEST 2020

On 8/8/20 5:32 PM, Sean Anderson wrote:
> On 8/8/20 10:59 AM, Heinrich Schuchardt wrote:
>> Hello Anup,
>> I have looking at you OpenSBI code firmware/payloads/test_head.S. Here
> I think the real start is in firmware/fw_base.S. From there, secondary
> harts loop first in _wait_relocate_copy_done, and then in
> _wait_for_boot_hart, and then they execute the next stage via
> _start_warm and sbi_init.
>> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart in to
>> an enless loop (hang).
> As far as I can tell, U-Boot has all harts execute the next stage when
> SMP is enabled. smp_call_function has all harts execute that function.

U-Boot can only run on one hart. Are the other harts trapped in
secondary_hart_loop()? How do we ensure that an UEFI payload does not
overwrite this memory location?

spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to
secondary_hart_relocate() fails.

>> 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.
>> @Ard:
>> Does Linux take care of the hanging harts and redirect them to its own
>> routine before SetVirtualAddressMap()? Otherwise anything could happen.
>> 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?
> Isn't the hart lottery already implemented for U-Boot? E.g. around line
> 100 of arch/riscv/cpu/start.S.

Thanks for the hint.

> On another note, does Linux support S-Mode NOMMU? I was under the
> impression that NOMMU implied M-Mode (or the other way around).

Have a look at

Best regards


More information about the U-Boot mailing list