OpenBSI and U-Boot

Atish Patra atishp at atishpatra.org
Sun Aug 9 22:08:23 CEST 2020


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


More information about the U-Boot mailing list