Workaround for non-identity MMU mappings?

[tornewuff]

This looks really awesome but I can't use it with my application as I'm using the MMU extensively with non-identity mappings.. I read your comment in the README about supporting this by dropping the app into the non-secure mode and arranging to map memory differently but this seems nontrivial.

Would it be sufficient to ensure that the app creates an identity mapping for the IO ports and RAM region that the monitor is using? Looks like the RAM from 0x01000000 and the peripheral region at 0x20000000? (I'll try this at some point when I have time, just thought you might have a better idea for sure)..

[jamieiles]

Hi Torne,

On Fri, Nov 09, 2012 at 04:39:47PM -0800, Torne Wuff wrote:

Would it be sufficient to ensure that the app creates an identity
mapping for the IO ports and RAM region that the monitor is using?
Looks like the RAM from 0x01000000 and the peripheral region at
0x20000000? (I'll try this at some point when I have time, just
thought you might have a better idea for sure)..

I think the answer here is - it depends. You'd need the identity
mapping for the peripherals and monitor code so that the exceptions get
handled correctly, but whenever gdb issued a memory access (which is
pretty often for stack frames, breakpoints etc) you'd have to make sure
that the address was correctly mapped at that time.

My plan (when I get time!) is to have the application run in the
non-secure world. There's a cp15 register that allows you to easily
translate from a non-secure world virtual address to physical address so
that could be used for doing all of the normal memory read-writes.

Jamie