OpenBSI and U-Boot

[Sean Anderson]

On 8/8/20 12:17 PM, Heinrich Schuchardt wrote:
> 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()?

Yes. They also need handle_ipi, and by extension riscv_clear_ipi. This
latter function currently requires that gd_t be valid, and may require
other structures (e.g. a struct udevice) to be valid in the future.

> How do we ensure that an UEFI payload does not overwrite this memory location?

The most foolproof is probably to wait for all harts to start running
UEFI code before making any modifications to ram outside the binary. One
easy way to do this is to use amoadd instead of amoswap (e.g. a semaphor
and not a mutex) in the standard boot lottery code. Whichever hart gets
to it first then waits for the value of hart_lottery to reach the
expected number of harts.

> 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

Ok, so NOMMU implies M-Mode. Then use of OpenSBI should preclude Linux.

--Sean