OpenBSI and U-Boot

[Rick Chen]

Hi Heinrich

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

Currently if U-Boot run in S-Mode, SMP is disable, there will exist
OpenSBI version compatible issue.
You shall use OpenSBI v0.7 with HSM, thus it will trap the other harts
in OpenSBI and only main hart will jump to kernel from U-Boot proper.

Thanks,
Rick

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