OpenBSI and U-Boot

[Heinrich Schuchardt]

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

https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf

Best regards

Heinrich