On Mon, Sep 14, 2009 at 01:06:10PM +0200, Holger Schurig wrote:
> > gives "Terminating Haret due to unhandled exception
> > (pc=00b0d640), is ther a configuration to change so it boots?
>
> AFAIK something here is fishy:
>
> HaRET detects:
>
> > Initializing for machine 'Generic ARM v6'
>
> And did not use one of the two
>
> > Looking at machine Generic MSM7xxxA
> > Looking at machine Generic MSM7xxx
>
> But WinCE said
>
> > Wince reports processor: core=MSM7225-528MHz name= cat=
> > vend=QUALCOMM
Haret is currently looking for a prefix of "MSM7201A", "MSM7500",
"MSM7200" - this is easy to change, but it wont stop the crash as they
just activate the same arm6 backend that is already activated.
> But on the other hand my thinking might be completely bogus, as I
> don't have a clue what exception this might be and what is
> stored at address 0x00e6a640.
The address is the PC location during the crash - one can find the
code by disassembling the haret binary. For example:
/opt/mingw32ce/bin/arm-mingw32ce-objdump -d haret-0.5.2.exe
If one can rebuild from the exact source (by checking out the same
version from cvs) then one can get full source info too:
/opt/mingw32ce/bin/arm-mingw32ce-objdump -S haret-debug | less
The key to this address report is that the corresponding code has been
relocated:
> Trampoline setup (tram=...@000255f4/1a0255f4/00e6a5f4)
> MMU setup: mmu=A0330000/00630000
> Go Go Go...
> Terminating haret due to unhandled exception (pc=00e6a640)
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
which corresponds with src/wince/asmstuff.S:
@ Jump to code with shared virtual/physical mapping
add pc, r4, #(1f - mmu_trampoline)
1: @ Code is running at a vm address that is the same as its
@ physical address. Now disable the MMU.
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #5 @ MMU & Dcache off
bic r0, r0, #0x1000 @ Icache off
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).
In either case, haret failed to shut down the mmu - either because the
mmu shutdown request was explicitly rejected, or because haret wasn't
able to manipulate the page tables so that it could run code at the
same physical and virtual address.
I've seen this report once before on #htc-linux (at freenode).
Unfortunately, I don't have the time right now to help debug this. It
looks to be something specific to the arm6 mmu setup on a handful of
machines.
-Kevin
_______________________________________________
Haret mailing list
Haret@handhelds.org
https://handhelds.org/mailman/listinfo/haret
