In a simple test case for L3 firewalls I've protected a small area in SRAM. I test this by accessing SRAM before and after configuring the firewall. After the firewall is configured SRAM reads 'return' zero and I get an asynchronous external abort.
The manual however claims we can get an interrupt for a firewall error. I've unmasked every single interrupt and sometimes (but not always) I get interrupt ID 8 which is listed in the manual as 'reserved' (prior experience with OMAP4 leads me to believe this is a firewall interrupt).
I can get interrupts for L3 application errors in a deterministic way. I was wondering
- how I can achieve the same for firewall interrupts
- whether I can disable the asynchronous external aborts caused by the firewall, or figure out the source and cause of the external abort in the handler because ARMv7 standard mechanisms (DFSR/DFAR) are useless with such aborts.
I'm also not sure on how to handle the L3 application error interrupt. There is a flowchart in the manual ("typical error analysis sequence" in L3_MAIN interconnect programming guide) that describes how to determine the source of the error but it is flawed in my opinion. First of all the flowchart suggests reading every CLKi_FLAGMUX_REGERRj in which i is the clock domain (1 to 3) and j indicates either an application error (j=0) or a debug error (j=1). I don't see why checking both is necessary since there are separate interrupts for that. Then, I have to check the "L3 flag mapping table". I would appreciate it if anyone could point me to the right table in the manual. All I can find is an "interconnect flag mapping" table. In this table the flag mux for CLK2 has over 20 inputs; however the register manual shows that I can only use the 8 least significant bits of the CLKi_FLAGMUX_REGERRj registers. Somehow the more than 20 inputs must be muxed to 8 bits but either it is not in the manual how it is done or I have overlooked it. Hence I am unable to 'decode' L3 application errors.