Re: Strange memory addresses

Oliver Ford wrote:
>
> It's a little tedious, I'll think of a way of automating some of it if
> I can.
>

And here's the automation, another patch to apply after the last one:
http://www.oliford.co.uk/hpipaq214/haretChanges/0002-MMU-L1-table-merging-output.patch

Since most the L2 tables stay in memory when windows removes their L1
entry, it now scans the merged table using the existing memDumpMMU() code.

It's fairly user-friendly now. All you have to do is something this:

HaRET(24)# set MMUMergeStart 0
HaRET(25)# set MMUMergeCount 256
HaRET(26)# set MMUMergeTargetStart 0x40e00000 # PXA GPIOs and MFPs
HaRET(27)# set MMUMergeTargetSize 0x00100000
HaRET(28)# wirq 5
....
Restoring windows exception handlers...
Finished restoring windows exception handlers.
Dumping MMU Merge table:
  Virtual | Physical | Description | Flags
  address | address | |
----------+----------+-------------+------------------------
 06110000 | 40e10000 | Small (4K) | AP=3333
 06130000 | 40e00000 | Small (4K) | AP=3333
----- End L1 entry 97 (06100000) change count: 1 -----
 06270000 | 40e00000 | Small (4K) | AP=3333
 062b0000 | 40e10000 | Small (4K) | AP=3333
 ....
 0a74e000 | 40e1e000 | Small (4K) | AP=3333
 0a74f000 | 40e1f000 | Small (4K) | AP=3333
 0a750000 | 40e00000 | Small (4K) | AP=3333
----- End L1 entry 167 (0a700000) change count: 1 -----
Handled 5061 irq, 3853 abort, 13606 prefetch, 0 lost, 0 errors

Then simply:
HaRET(29)# set trace 0x0a74e018
etc

Oliver
Received on Sun Apr 20 2008 - 07:05:16 EDT