search

riscv-software-src / opensbi

RISC-V Open Source Supervisor Binary Interface
Other
1.05k stars 521 forks source link

How to boot harts that's not boot hart? #244

Closed retrhelo closed 2 years ago

retrhelo commented 2 years ago

I'm developing a tiny kernel based on OpenSBI, and debugging it on QEMU. I use the flag -smp 2 to have multiple harts. However, I can't find a proper way to "wake up" hart 1 (I use hart 0 as the boot core in my kernel). I wonder what I can do to boot hart 1? My QEMU version is 5.2.0 with OpenSBI at v0.8.

maquefel commented 2 years ago

I recommend you to use the debugger to find out the details, but in general secondary hart behavior is following: 1) wait_for_coldboot (sbi_init.c) transition is done by OpenSBI itself by sending an IPI, after cold_init is completed 2) sbi_hsm_hart_wait (sbi_hsm.c) transition should be done by your kernel by invoking ECALL SBI_EXT_HSM_HART_START which will result in sbi_hsm_hart_start

repnop commented 2 years ago

Note that you generally do not get the luxury of picking which hart will boot: OpenSBI runs a hart lottery during initialization that will select a "random" (decided by atomic memory accesses) which will be your boot hart, I strongly recommend against hardcoding the assumption that hart 0 is always the boot hart, as that is rarely going to be the case on multi-hart hardware. To then boot the other harts, the SBI specification provides the Hart State Management (HSM) extensions which allows you to ask the SBI implementation to start running code at a particular physical address with an additional user-supplied parameter on the other harts. Details in the SBI specification here.

retrhelo commented 2 years ago

The problem seems to be solved by using sbi_hart_start(). Thank you guys for the help :D.

retrhelo commented 2 years ago

Note that you generally do not get the luxury of picking which hart will boot: OpenSBI runs a hart lottery during initialization that will select a "random" (decided by atomic memory accesses) which will be your boot hart, I strongly recommend against hardcoding the assumption that hart 0 is always the boot hart, as that is rarely going to be the case on multi-hart hardware.

Assuming hart 0 as the default boot hart is surely a bad idea. I'll imrove the kernel later. Thanks for pointing this out.