ARM: 743626—An imprecise external abort, received while the  processor enters WFI, may cause a processor deadlock

Hi Manyam,

Looking at the tags I am assuming you are working on an iMX6 part, so first step I recommend is to check the iMX manual for a workaround.

Imprecise external aborts are extremely rare, and when they happen it usually means the system need to be fully reset as data might be corrupted (and you don't know which word to correct as it is 'imprecise' rather than 'precise').  Additionally to that it only affects transactions produced by PLDs and page table walks, not explicit memory transactions (load/store), which makes it even more rare. So, the above scenario is unlikely to happen but if it does your system is probably about to reset (depends on the SoC). On top of that you can protect any memory page with the MMU essentially eliminating the scenario ever to happen.

Hope this explains the scenario in more detail. Check back in with me in case you got additional questions. Freescale support might be another good place to get answers, especially on details for iMX6.

Regards

Stefan

Hi Stefan,

Thanks for your quick response. I contacted freescale, but they suggested to contact ARM.

From freescale: "Unfortunately for details it is necessary to apply to ARM (www.arm.com), actually this info

is provided by ARM."

Can you please explain "On top of that you can protect any memory page with the MMU essentially eliminating the scenario ever to happen." how to protect any memory page with the MMU.

Manyam

Hi,

I have seen your exchange with Freescale on their community site. They are correct to refer you to ARM since this erratum refers to the Cortex-A9 processor core and not to any other component of the i.MX part.

The statement about the MMU means that you can protect against this scenario by ensuring that the MMU memory map is configured such that any regions which may be accessed by page table walks or PLD/PLE memory accesses do not generate aborts. In general, it would most likely indicate a serious programming error for any of these scenarios to occur in any case, so it is most likely that your system already conforms to these conditions.

Hope this helps.

Chris

Hi Chris,

So in order to protect MMU, the memory map should be configured(any regions which may be accessed by page table walks or PLD/PLE memory accesses do not generate aborts) during the kernel initialization only?

Manyam.

Source : Cortex-A9 Technical reference Manual(ARM)

The micro TLB returns the physical address to the cache for the address comparison, and also checks the protection attributes to signal either a Prefetch Abort or a Data Abort. So signalling the prefetch Abort or a Data Abort should be disabled ?

As I said above, you should ensure that the protection attributes are configured so that any memory regions which are accessed for page table walks do not generate aborts. Typically, the page tables will be allocated and initialised during the OS start up sequence. However, the page tables are rarely static after OS initialization since they change constantly on events like context switches,. task creation/deletion etc.

I think you need to take note of the fact that this particular erratum is classed as rare. No fix is planned because ARM does not believe that this has a significant impact on real, practical software systems. Software systems which exhibit the kind of behaviour described in the erratum would be flawed anyway. A correctly functioning operating system would never cause these conditions to occur.

Chris

Thanks a lot Chris.

Regards,

Manyam

Hi Chris,

Could you please help me how to configure the MMU settings to protect from external aborts.

I'm unable to figure out the configurations settings/registers to be used using the MCR instruction for the coprocessor CP15.

Hi,

Configuring the memory map to guard against external aborts is a little more involved than using a few MCR instructions, I'm afraid. To cover the memory map, you will need to generate and install a complete set of address translation tables (page tables) and then configure the MMU to use these when determining access rights for memory accesses.

I think you should also note that, as has been said earlier, that this particular erratum is classes as "rare". As far as I can see, the Linux community has not seen fit to modify the Linux kernel to provide any fix or workaround to guard against it happening. Presumably, this is because they have taken the view that, in a correctly configured and functioning kernel, this situation will simply never arise!

Do you have specific reasons for wanting to go further on this one?

Chris