Thank you Olivier,
I recently place the handler into NS-EL1 (in my scenario) and it can trap the READ operations. But, when I execute a WRITE instruction (e.g., ldr). I find the TZASC will "ignore" the write operation, instead of generating an exception.
This happens in both RevC FVP and Juno R2 board. Thus, if I want to generate an exception instead of "ignored", what can I do?
Sincerely, WANG Chenxu
Olivier Deprez Olivier.Deprez@arm.com 于2022年8月23日周二 14:51写道：
Hi,
Se this test: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/misc_tes...
It traps a sync EA at NS-EL2: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/misc_tes...
It isn't necessary to trap at EL3 unless required by the test goal.
Regards, Olivier.
From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 23 August 2022 00:08 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] How to trap aborts caused by TZASC?
Hi all,
I want to test how to trap the aborts caused by TZASC. For example, when I use NS-EL1 (e.g., OS) to access a Secure region (configured in TZASC), it will generate an abort.
But I am not sure how to trap it. I think it is an external abort, so I enable the SCR_EL3.EA=1 and write a handler. However I cannot trap it. Also, my other handlers in EL3 still do not report the abort.
Thus, how can I trap a TZASC abort? If I want to route it into EL3 to handle, how can I do it?
Sincerely, WANG Chenxu -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org