OpenBSI and U-Boot

[Heinrich Schuchardt]

Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra <atishp at atishpatra.org>:
>On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt <xypron.glpk at gmx.de>
>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()? How do we ensure that an UEFI payload does not
>> overwrite this memory location?
>>
>
>If you are booting Linux, U-Boot runs in S-mode and SMP is disabled.

Would that also hold true on the Kendryte K210? For all what can see the secondary hart enters U-Boot and is only restrained by WFI and otherwise kept in an endless loop.

I am wondering if that endless loop needs to be marked as reserved memory for Linux.

>All memory regions containing OpenSBI code are reserved. Thus, U-Boot
>won't touch that.
>U-Boot also marks the run time services memory region as reserved as
>well.
>Thus, Linux kernel won't touch any of those memory regions either.
>
>> 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