You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On H616 with the secure boot fuse set, FEL starts in non-secure
state. The older direct SMC workaround is not sufficient there because
the SMC returns through monitor mode instead of directly leaving the
BROM FEL command loop in secure SVC state.
Add a secure-SVC return thunk for this case and keep the existing
global startup workaround model. The thunk issues the SMC, switches
from monitor mode to secure SVC with the banked SP/LR restored,
restores the secure GIC view expected by the BROM, and returns to the
FEL command loop. It uses the same SRAM swap-table convention as the
SPL thunk to preserve the H616 BROM SRAM workspace while the uploaded
code runs and returns to FEL.
After the transition, the normal runtime probe sees secure state and
suppresses repeat application in that sunxi-fel process, so normal SID
reads and SPL execution use the existing code paths.
Describe the SMC workaround method in SoC data and make every existing
secure-FEL user select the direct-SMC path explicitly. H616 selects the
secure-SVC thunk path and additionally gates the workaround on the
secure boot status word at SID + 0xa0, so non-secure H616 boards do not
enter the secure path just because the zero-word probe also reads as
zero.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
0 commit comments