On Thu, 23 Jan 2014 22:25:36 +0000 Peter Maydell <peter.mayd...@linaro.org> wrote:
> Hi Antony; have you noticed any issues with QEMU's handling of > MPU faults (data or address faults) on our ARM946 model? > I ask because DIGIC is the only board we have that uses the 946, > and as far as I can tell from the QEMU source code we will > incorrectly trash the access permissions registers any time we > take an MPU fault. > > By 'access permission registers' I mean these: > > MRC p15, 0, Rd, c5, c0, 2; read data access permission bits > MRC p15, 0, Rd, c5, c0, 3; read instruction access permission bits > MRC p15, 0, Rd, c5, c0, 0; read data access permission bits > MRC p15, 0, Rd, c5, c0, 1; read instruction access permission bits > > as described in the 946 TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/Babfaiic.html > > Looking at the source code it seems like cpu_arm_handle_mmu_fault() > will write the fault status into c5_data/c5_insn, because that is where > we keep the DFSR and IFSR for an ARM with an MMU. > > Since the 946 doesn't provide any way to find out what the fault > address actually was (it has no DFAR or IFAR) I presume that all > guest software treats a data abort or prefetch abort as a fatal error, > which is probably part of why nobody's ever noticed this. > > This bug would also affect the ARMv7M CPU (Cortex-M3) we emulate, > except that as far as I can tell we don't implement its MPU interface at all! > (it uses memory mapped registers rather than cp15 regs, and they just > aren't wired up in armv7m_nvic.c...) Sorry for delay! The number of software, running on DIGIC is very limited: * Canon Camera firware + maybe Magic Lantern or CHDK; * barebox. I know nothing about MPU fault handling in barebox. I'm planning to merge current qemu DIGIC support with patches from MagicLantern qemu patches. May be during this work I'll be capable to answer your question, but just now I have no answer, sorry. May be Magic Lantern people (especiall g3gg0) can help? I have added them to Cc. -- Best regards, Antony Pavlov
