OpenBSI and U-Boot

[Heinrich Schuchardt <xypron.glpk@gmx.de>]

On 8/8/20 7:22 PM, Sean Anderson wrote:
> 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.

There is no such requirement in the UEFI specification.

The way to tell which memory should not be overwritten by the UEFI
payload is an entry in the memory map that the payload can read via
GetMemoryMap(). So we have to make reservations in the memory map, by
calling efi_add_memory_map() or by putting the code into the
__efi_runtime section.

Do I understand it correctly that the secondary harts stay in the
unrelocated secondary_hart_loop()? In this case __efi_runtime would not
be the right section, because that memory section is also relocated and
only the relocated code is reserved in the memory map.

We would also have to consider the location of secondary_hart_loop()
when defining the load address of any payload be it UEFI or not.

Best regards

Heinrich

>
>> 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
>