[http://www.oliford.co.uk/hpipaq214/haretChanges/how-to-mmutrace.txt] A quick how-to for using two of my additions to HaRET: Approximate tracing and MMU Table merging,. Intro ------- On my PDA windows seems to hide or swap out many of the DLLs and their data structures from the MMU table. Each DLL also seems to have it's own individual area of memory mapped to the hardware registers making tracing via commands like "addlist mmutrace p2v(0x40e00100)" etc impossible. In order to deal with this I have these three patches: http://www.oliford.co.uk/hpipaq214/haretChanges/0001-Initial-MMU-level-1-table-merging.patch http://www.oliford.co.uk/hpipaq214/haretChanges/0002-MMU-L1-table-merging-output.patch http://www.oliford.co.uk/hpipaq214/haretChanges/traces-report-memory-poll-post-mmutrace.patch Apply them in order. The first attempts to develop a merged copy of the MMU table as windows swaps things in and out. The second displays the table and filters them for particular areas. The third adds reporting of approximate address to the normal TRACES commands. Trace Approximate Address ---------------------------- The last patch address the reporting of the current PC when HaRET notices a register has changed. This isn't the exact place it changed and might not even end up in the same area of memory but often it will be in a delay loop shortly after the write occurred. Just carry out the trace as normal: HaRET(1)# ibit irqs 25 HaRET(2)# ibit irqs 26 HaRET(3)# ibit irqs 29 HaRET(4)# addlist traces p2v(0x40e00100) HaRET(5)# wirq 20 Beginning memory tracing. Watching TRACES(00): Addr a8e00100(@40e00100) MMU table merging disabled Replacing windows exception handlers... Finished installing exception handlers. . . . 007132: 01881528: mem IRQS(0) a8d00000=08000000 (08000000) @~0baf3984 007132: 01a79e09: mem IRQS(0) a8d00000=08000000 (08000000) @~800090f4 007132: 01c7386c: mem IRQS(0) a8d00000=08000000 (08000000) @~800090e8 007302: 02d4e119: mem TRACES(0) a8e00100=30079528 (00000008) @~07ab2d44 007302: 033417bb: mem TRACES(0) a8e00100=3007953a (00000012) @~07ab2d44 <-- WiFi on 007302: 0352f09d: mem TRACES(0) a8e00100=300795ba (00000080) @~07ab1ec8 012139: 00ccbf48: mem TRACES(0) a8e00100=300794ba (00000100) @~f000ebf8 012810: 03f7ee7c: mem TRACES(0) a8e00100=300795ba (00000100) @~079ac340 Here I switched the WiFi on at ~7sec while watching some GPIOs. Many of the changes in the GPIOs happen at MVA (Modified Virtual Addresses) 079axxxx or 079bxxxx. To check if this is sensible you can use addr2mod: HaRET(6)# addr2mod 0x07ab2d44 Address 07ab2d44 in process: device.exe (06000000 - 08000000) in module: sdhc_navajo.dll (07ab0000 - 07abb000) In this case it's the SDIO bus driver on which my WiFi chip sits. Unfortunately trying to access this virtual address will fail as windows has removed the mapping when HaRET gets control. MMU Merge Table - Finding register access --------------------------------------------- The MMU Merge table tries to build a complete picture out of the changes windows makes during a WIRQ operation. You set the Level 1 table entries you want to watch with: HaRET(12)# set mmumergestart 0 HaRET(13)# set mmumergecount 512 This watches the first 512 entires which in my case contain most useful changes. The more entries you try to watch the slower the system will be while it is in wirq. Too many and it will just hang. If neccessary do it in batches. At the end of the WIRQ session, HaRET will list the built up table that contain a specified physical address. e.g. the following will for anything mapped to the hardware registers of the PXA2xx/3xx processors: HaRET(14)# set mmumergetargetstart 0x40000000 HaRET(15)# set mmumergetargetsize 0x10000000 The output will look something like: HaRET(16)# wirq 20 Beginning memory tracing. Watching TRACES(00): Addr a8e00100(@40e00100) MMU L1 table merging enabled, watching 512 entries starting at entry 0 Replacing windows exception handlers... Finished installing exception handlers. ... Restoring windows exception handlers... Finished restoring windows exception handlers. Dumping MMU Merge table (last change mappings): Virtual | Physical | Description | Flags address | address | | ----------+----------+-------------+------------------------ 060d0000 | 40000000 | Small (4K) | AP=3333 060d1000 | 40001000 | Small (4K) | AP=3333 060f0000 | 43100000 | Small (4K) | AP=3333 ----- End L1 entry 96 (06000000) change count: 1 ----- 06100000 | 40a00000 | Small (4K) | AP=3333 06110000 | 40e10000 | Small (4K) | AP=3333 06120000 | 41340000 | Small (4K) | AP=3333 06130000 | 40e00000 | Small (4K) | AP=3333 ----- End L1 entry 98 (06200000) change count: 1 ----- 06300000 | 40e10000 | Small (4K) | AP=3333 06360000 | 40a00000 | Small (4K) | AP=3333 ----- End L1 entry 99 (06300000) change count: 1 ----- 06430000 | 40e00000 | Small (4K) | AP=3333 06480000 | 41b00000 | Small (4K) | AP=3333 06490000 | 40e00000 | Small (4K) | AP=3333 064a0000 | 40e10000 | Small (4K) | AP=3333 064b0000 | 40a00000 | Small (4K) | AP=3333 064c0000 | 41340000 | Small (4K) | AP=3333 064d0000 | 43000000 | Small (4K) | AP=3333 064e0000 | 41340000 | Small (4K) | AP=3333 ----- End L1 entry 100 (06400000) change count: 1 ----- ... You can now see various mappings have been used to many different registers. You can also use this to find the DLLs code. Run the merge again but ask it to return the whole table by setting the MMUMergeTarget vars to 0: HaRET(17)# set mmumergetargetstart 0 HaRET(18)# set mmumergetargetsize 0 This will return the entire table which is gigantic. In there somewhere will be every DLL which was used during the WIRQ. For instace the SDIO driver which was ( sdhc_navajo.dll (07ab0000 - 07abb000) ) has: 07abb000 | | UNMAPPED | 07ac1000 | c36f7000 | Small (4K) | CB AP=0000 07ac2000 | c36f8000 | Small (4K) | CB AP=0000 07ac3000 | c36f9000 | Small (4K) | CB AP=0000 07ac4000 | c3724000 | Small (4K) | CB AP=0000 07ac5000 | c3723000 | Small (4K) | CB AP=0000 07ac6000 | c3725000 | Small (4K) | CB AP=0000 07ac7000 | c36fa000 | Small (4K) | CB AP=0000 07ac8000 | c36fb000 | Small (4K) | CB AP=0000 07ac9000 | c36fc000 | Small (4K) | CB AP=0000 07aca000 | c36fd000 | Small (4K) | CB AP=0000 07acb000 | c36fe000 | Small (4K) | CB AP=0000 07acc000 | c371c000 | Small (4K) | CB AP=0000 07acd000 | c371d000 | Small (4K) | CB AP=0000 07ace000 | c3714000 | Small (4K) | CB AP=0000 07acf000 | c36f5000 | Small (4K) | CB AP=3333 07ad0000 | c36f6000 | Small (4K) | CB AP=0000 07ad1000 | | UNMAPPED | ----- End L1 entry 122 (07a00000) change count: 1 ----- The second column gives the different pages of the DLLs memory space. Fortunately, rather than having to go through them individually, on my system windows normally maps a permenant area aswell. In the normal permenant table: HaRET(25)# dump mmu 2 there is: c3abb000 | | UNMAPPED | c3ac1000 | c36f7000 | Small (4K) | CB AP=0000 c3ac2000 | c36f8000 | Small (4K) | CB AP=0000 c3ac3000 | c36f9000 | Small (4K) | CB AP=0000 c3ac4000 | c3724000 | Small (4K) | CB AP=0000 c3ac5000 | c3723000 | Small (4K) | CB AP=0000 c3ac6000 | c3725000 | Small (4K) | CB AP=0000 c3ac7000 | c36fa000 | Small (4K) | CB AP=0000 c3ac8000 | c36fb000 | Small (4K) | CB AP=0000 c3ac9000 | c36fc000 | Small (4K) | CB AP=0000 c3aca000 | c36fd000 | Small (4K) | CB AP=0000 c3acb000 | c36fe000 | Small (4K) | CB AP=0000 c3acc000 | c371c000 | Small (4K) | CB AP=0000 c3acd000 | c371d000 | Small (4K) | CB AP=0000 c3ace000 | c3714000 | Small (4K) | CB AP=0000 c3acf000 | | UNMAPPED | which you can access from HaRET.