For what i read nothing can be done right now to solve the issue, if
someone nead some help on testing a future change on Haret please let me
know.
Agostinho
Ter, 2009-09-15 às 22:40 -0400, Kevin O'Connor escreveu:
> 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
[email protected]
https://handhelds.org/mailman/listinfo/haret
