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. > > 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. On another note, does Linux support S-Mode NOMMU? I was under the impression that NOMMU implied M-Mode (or the other way around). --Sean
