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 and A133 with the secure boot fuse set, FEL starts in
non-secure state. The older direct SMC workaround is insufficient
because SMC enters monitor mode instead of returning the BROM FEL
command loop in secure SVC state. A133 also has its monitor vector
table cleared by NBROM.
Add a secure-SVC SMC thunk for this case and keep the existing global
startup workaround model. The thunk preserves the BROM SRAM workspace
using the same swap-table convention as the SPL thunk. Before issuing
SMC, it temporarily replaces the SMC vector instruction at MVBAR + 8
with "mov pc, lr". This returns to the instruction after SMC without
restoring SPSR_mon, so execution continues in monitor mode.
The thunk then restores the original vector instruction, clears
SCR.NS and MVBAR, sets the secure GIC state expected by the BROM,
copies the saved SVC SP/LR into the secure bank, switches to secure
SVC, and returns to the FEL command loop.
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.
H616 and A133 select the secure-SVC SMC thunk path and gate the
workaround on a non-zero secure boot status word at SID base + 0xa0.
The zero-word runtime probe still has to match before the thunk is
applied, so non-secure boards and already-transitioned secure-FEL
sessions do not enter the secure path just because one check matches.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
0 commit comments