I am using Trusted Firmware provided by Linaro on Juno Board R1.
Now I want to disable MMU in EL3 and do some custom jobs, and then enable MMU again. As I don't want to disturb other codes in EL3, I guess I have to clear the instruction cache, data cache, TLB. But I always fail to do this. After I disabled MMU and cleared the caches, the system halts.
Is there anything I missed?
Thanks very much for your help!
Hello, after reading you question, I find that Your problem is similar to mine. Maybe you could help me. Now I want to read a buf (kmalloc in kernel) in EL3, how to do it? In other words, I want to access data at any physical address in EL3, how can I achieve this idea?
Good luck with your debugging.
DLL
Thanks a lot for your reply. I find the reason of the problem. It is caused by different SPs under different SPSEL. After I correct that, everything goes well now.
> After I disabled MMU and cleared the caches, the system halts.
If you've an entitlement to support, you might want to consider routing questions like this to juno-support@arm.com - the official support channel.
I've tried to make a few general comments below, which might help. However you'd probably need to be much more specific about the manner in which the system halts to allow people to comment meaningfully on the forum.
A few ideas...
- Can you debug *why* the system halts a little more. For example: Do you end up taking an unexpected exception while executing your modified code? If so, what does the Syndrome register (ESR_EL3) tell you about the reason for the exception and what does the Exception Link Register (ELR_EL3) tell you about the address of the instruction that caused the exception.
The problem could be many different things:
Do you have interrupts disabled? Obviously if you there's an exception intended to be handled by TF and you've disabled the MMU, this is likely to cause issues.
- Maybe you are simply making an access to an invalid physical address.
- On the data side an access to a region aborted by the memory system
- On the instruction side, If the tables aren't created with flat mappings in the region you are executing from, simply disabling the MMU is clearly problematic
- Note that with the MMU disabled the core will no longer support things like unaligned accesses - this could be an issue if you are compiling generic C code and pulling in libraries that expect to find support for these accesses enabled
MarkN.
View all questions in Arm Development Platforms forum