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