On Wed, Sep 16, 2009 at 11:32:36AM +0200, Holger Schurig wrote:
> > 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 think the problem is either the "mrc" or the "add" just prior to
it. (The "add" is a jump.) To find out, I'd change the code to
something like:
@ Jump to code with shared virtual/physical mapping
add pc, r4, #(1f - mmu_trampoline)
nop
nop
nop
nop
1: @ Code is running at a vm address that is the same as its
@ physical address. Now disable the MMU.
nop
nop
nop
nop
mrc p15, 0, r0, c1, c0, 0
And see what address gets reported.
-Kevin
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
