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