core: riscv: Modify S-mode boot flow to compatible with M-mode firmware #6447
Conversation
|
Hello @maroueneboubakri |
|
Hi @gagachang, I still need more time on this, since it may impacts our intended execution flow (not SBI based). |
Hi @maroueneboubakri ,Sure! |
|
Hi @maroueneboubakri |
|
Hi @gagachang, Still didn't try it, I prioritize it once I finish ongoing work in my pipe ! |
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
from
2383fec
to
e06bd71
Compare
|
Just rebase to master branch |
|
Hi @maroueneboubakri |
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
from
e06bd71
to
dfce981
Compare
|
@maroueneboubakri |
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
from
dfce981
to
032fd48
Compare
|
Hi @maroueneboubakri |
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
2 times, most recently
from
61188ea
to
631ee90
Compare
|
@maroueneboubakri The issue here is because openSBI boots OP-TEE with "random" hart. |
|
Hi @gagachang, I'll try the PR out this week. Best |
Thank you! Let me know if there is any issue. |
|
|
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
from
631ee90
to
e130952
Compare
OP-TEE may communicate with the untrusted domain by different solutions, such as M-mode secure monitor based solution, or direct messaging based solution. This commit adds CFG_RISCV_WITH_M_MODE_SM to indicate that OP-TEE uses M-mode secure monitor based solution for the communication. The CFG_RISCV_WITH_M_MODE_SM should depend on CFG_RISCV_S_MODE and CFG_RISCV_SBI, since we are using "ecall" to trap into M-mode secure monitor. Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Marouene Boubakri <[email protected]>
In RISC-V QEMU virtual platform, OP-TEE OS uses M-mode secure monitor based solution to communicate with the untrusted domain. Therefore, set CFG_RISCV_WITH_M_MODE_SM to 'y' in its configuration file. Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Marouene Boubakri <[email protected]>
Use CFG_RISCV_WITH_M_MODE_SM to determine if OP-TEE uses M-mode secure monitor based solution to communicate with the untrusetd domain. Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Marouene Boubakri <[email protected]>
The ID of primary hart should not be restricted to zero. Thus, determining primary hart and secondart harts by zero hart ID is not feasible. We refer to RISC-V linux kernel [1] to fix this issue, by adding a "hart_lottery" variable. The first hart who enters OP-TEE will win the lottery, atomically increment this variable, and be the primary hart. Other harts enter OP-TEE later won't win the lottery, so they execute the secondary boot sequence. [1]: https://github.com/torvalds/linux/blob/v6.7/arch/riscv/kernel/head.S#L244 Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Marouene Boubakri <[email protected]>
When the system adopts M-mode secure monitor based solution, the secondary harts need to hand over the control back to the secure monitor after the initial boot sequence. Add related code for this purpose. Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Marouene Boubakri <[email protected]>
gagachang
force-pushed
the
dev-riscv-hsm-boot
branch
from
e130952
to
a9c2cd7
Compare
|
@maroueneboubakri |
In system of S-mode OP-TEE, M-mode firmware transfers control flow to OP-TEE during boot. M-mode runs one hart, which called boot hart, to executes system initialization and jumps into OP-TEE.
However, the ID of boot hart might not be always zero. That is, M-mode firmware may choose a hart, whose ID is non-zero, to jump into OP-TEE "_start" symbol to do OP-TEE initialization. Therefore, it is not feasible to let all harts enter "_start" symbol, and judge whether current hart is primary boot hart, by checking ID is zero or not. Fix it by letting non-boot hart enter "reset_secondary", in S-mode OP-TEE. So that all the harts can do their right things regardless of their hart ID.
Only OP-TEE runs in M-mode will judge primary hart by checking whether the hart ID is zero.