OpenBSI and U-Boot

[Atish Patra]

On Sun, Aug 9, 2020 at 1:28 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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.
>

Is U-boot running in S-mode or M-mode ?
Are you trying to boot Linux on a Kendryte board using OpenSBI
->U-Boot -> Linux? (all in M-mode ?)

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


-- 
Regards,
Atish