On Thu, Jan 29, 2009 at 04:45:31PM +0100, Holger Schurig wrote: > I already mentioned shortly that I seem to be unable to do > mmiotrace. For example, I know that the I2C Data register of my > CPU (i.MX21) is at physical address 0x10012010. > > Now, I can do the following: > > HaRET(1)# clear TRACES > HaRET(2)# HaRET(3)# watch TRACES 4 > Beginning memory tracing. > Watching TRACES(00): Addr b8012010(@10012010) > 000.000 TRACES I2DR=000000ff: D=ff > 001.586 TRACES I2DR: D(3 7)=77 > 001.989 TRACES I2DR: D(2)=73 > 002.352 TRACES I2DR: D(2)=77 > 002.704 TRACES I2DR: D(2)=73 > > But I'm now quite unsure if I get *ALL* access to the > data-register.
You wont. The watch command does memory polling (it reads the memory 1000 times a second and reports on changes). If you haven't already read it, you should read: http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation > Now, the "DUMP MMU" command gives me this output: > > HaRET(4)# dump mmu 1 0x10012000 0x10 > ----- Virtual address map ----- > cp15: r1=0005327f r2=c0480000 r3=00000001 r13=18000000 > > Descriptor flags legend: > C: Cacheable B: Bufferable D: Domain # > AP: Access Permissions (for up to 4 slices): > 0: No Access 1: Supervisor mode read/write > 2: User mode read 3: User mode read/write > Virtual | Physical | Description | Flags > address | address | | > ----------+----------+---------------+---------------------- > 98000000 | 10000000 | 1MB section | CB AP=1 > b8000000 | 10000000 | 1MB section | AP=1 Okay, so it's only mapped twice in ram. > Note: "dump mmu 2" (not 1) gives exactly the same output. I'm > unsure if this is right. Looks okay. The "2" option will show 4K page mappings in addition to 1Meg mappings (as opposed to just 1Meg mappings). Since that address is not mapped by any 4K pages, the output is the same for both commands. > I have a bunch of "ibit IRQS" so that I don't see every > uninteresting stuff, e.g. no Touchscreen Interrupts. > > irq:8003d...@a01843f8=809fb0ec abort:80072...@a01843f0=809fb110 > prefetch:8003c...@a01843ec=809fb13c data=809ba000 sizes=c:000014e4,t:000454e4 > Beginning memory tracing. > Watching IRQS(00): Addr b8040048(@10040048) > Watching IRQS(01): Addr b804004c(@1004004c) > 00: Mapping 98000000(@10000000) accesses to e1100000 (tbl 1000040e) > 01: Mapping b8000000(@10000000) accesses to e1200000 (tbl 10000402) > MMU table merging disabled > Replacing windows exception handlers... > Finished installing exception handlers. > 000.000 IRQS INTSRCH=00000000: > 000.000 IRQS INTSRCL=04000000: INT_GPT1=1 > Restoring windows exception handlers... > Finished restoring windows exception handlers. > Handled 6154 irq, 80582 abort, 231 prefetch, 0 lost, 0 errors > > But here I expected some output, it just didn't work. > Any ideas? I put together a page some time back to go over possible failure cases: http://www.handhelds.org/moin/moin.cgi/HaRET_20Tracing_20Details To date, lost reports have been due to one of the first three. Just to verify that mmutrace works, you can launch haret twice. Then do a mmutrace in one window, and issue a memory read in the second window (see VDUMP). -Kevin _______________________________________________ Haret mailing list [email protected] https://handhelds.org/mailman/listinfo/haret
