Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra <ati...@atishpatra.org>: >On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt <xypron.g...@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
