> So, we actually need to look at 0x4c bytes (0xe6a640 -
> 0xe6a5f4) from the mmu_trampoline (0x255F4) - 0x25640. My
> copy of haret-0.5.2.exe shows:
>
> 25638: e24ff004 sub pc, pc, #4 ; 0x4
> 2563c: e284f04c add pc, r4, #76 ; 0x4c
> 25640: ee110f10 mrc 15, 0, r0, cr1, cr0, {0}
> 25644: e3c00005 bic r0, r0, #5 ; 0x5
> 25648: e3c00a01 bic r0, r0, #4096 ; 0x1000
>
> Unfortunately, I don't recall if the offending instruction is
> reported (the mrc) or if the next instruction is reported
> (making the failure at the jump).
The next instruction would be the "bic" one, and I doubt that a
bit-clear operation can create an exception.
So my guess it's the "mcr" one. Maybe the this processor doesn't
allow access to the MMU coprocessor at this time? Or maybe the
OS prevented access.
I've seen processors where you had to enable access to the MMU
and/or enable clocks to the MMU before accessing them.
--
http://www.holgerschurig.de
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
