• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 352 subscribers
  • Views 5563 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to generate an _asynchronous_ external abort by software ?

Vincent Siles

Hi,

while I was working with an imx6 board, I got the following behavior: normal world code triggered an external abort (was in the PCIe driver) just before a switch from NS -> S, so the abort actually happened in the Secure world.

My goal is to detect such scenario et correctly ignore the EA in the secure world. I started to test in the monitor if the ISR[A] bit is set or not, to detect a pending Abort from NS, and in this case, I take the abort with a special abort handler (which is a nop, just to clear the ISR).

 

Sadly, I don't have the board anymore to test this behavior, and my current board doesn't trigger EA.

Is there a way to trigger an _asynchronous_ external abort via software, in a more or less predictable way ?

 

Best,

Vincent

  • 0
    Note: I tried to read/write in a CSU/TZASC protected region, and all I got was a _Synchronous_ external abort :'(
  • +1
    It's a little involved, but...
    For the address you found generated a Synchronous external abort, mark is as write-able and cacheable+RA/WA+writeback. If you write to the address it'll lead to a dirty cache line. Doing a cache clean of the address will lead to the line being written back, which will then abort.
  • 0 Arm Employee Badge in reply to ttfn
    I think this is the only way without special hardware hooks. This should work for security related aborts too. If you have an address that is secure in the fabric (ie TZC protected) you can mark it non-secure cacheable in the page tables. The initial write that dirties the cache line will succeed as the cache doesn't know the memory is really secure. When the cache line gets written back you should get the abort from the tZC at that time.

    This method is a little messy as it is difficult to guarantee that the line won;t get evicted for another reason but in a test system with limited other memory traffic it's pretty doable.
  • 0 in reply to ttfn
    Thank you very much for this idea. For further reference here is how I did it:
    - protected some RAM with a TZASC
    - try to access such RAM -> synchronous external abort
    - try to access such RAM with MMU configured with Cacheable Memory (no TEX remap) WB, WA -> TEX[2:0] = 101, C = 1, B = 0