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