Searched hist:"8 f15231912392342e7e11a244dee5b55bf7eb698" (Results 1 – 1 of 1) sorted by relevance
| /rk3399_ARM-atf/bl31/aarch64/ |
| H A D | crash_reporting.S | 8f15231912392342e7e11a244dee5b55bf7eb698 Mon Aug 11 12:35:27 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> fix(aarch64): do not print EL1 registers on EL3 panic
Lower EL execution should not be able to panic EL3. The main source of
potential panic, traps from lower ELs, are now handled gracefully with
undefined injection. Almost every other source of panic is something
going wrong within TF-A. Regardless, in both cases, ESR_EL3, ELR_EL3,
and SPSR_ELR provide the majority of necessary information to debug a
panic and printing a lot of lower EL register only clutters the crash
dump and makes it difficult to read.
Further, when EL3 panics, the ultimate source of that panic may be EL2
but the crash reporting functionality only prints out EL1 system
registers which are going to be quite useless to debug.
Finally, the panic may be happening due to some misconfiguration of
other EL3 system registers that have been introduced with a feature.
There are two logical choices:
a) extend crash reporting to report all EL1, EL2, and EL3 registers
depending on where an error came from, including all features
b) only print core EL3 registers and rely on the developer to add extra
prints as necessary
We have never strived to achieve a) (as evidenced by EL2 and feature
sysregs never having been added), so do b). Only non-EL3 registers that
are relevant to EL3's direct execution are kept (like SP_EL0).
Change-Id: Ife2fe86184bca9a4d66f367c516eececc57471da
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|