On Sun, Mar 16, 2008 at 02:52:33AM +0000, Oliver Ford wrote: > Using simply something like 'addlist mmutrace p2v(0x40E00000)' doesn't work > as the p2v() evaluates as virtual 0xa8e00000 which nothing seems to use. > Forcing it to watch virtual 0x80e00000, the only other mapping to the same > region that I can find in the 'dump mmu' list just freezes the PDA. The PXA > tracing just never traps anything in either case.
That sounds odd. Wince generally maps two regions for mmio access to chips - one with caching and one without. I've never seen the cached region used. If the chip is accessed via DMA, you generally wont see any accesses via mmutrace or pxatrace. Also, using the right cache flushing functions is crucial to working with "wirq". Is your haret detecting the machine as a pxa (and thus using the xscale cache flushes)? >One part of this that I > didn't understand is that the xScale 3 docs say the debug registers take a > 'modified virtual address' that has been combined with the 'process ID'. If > each process has a different ID, how are you supposed to (using the debug > system) watch a specific physical location, like for instance trying to > trap anything reading or writing to the UART? The ARM stuff is a little complicated. There is a translation from VA to MVA to PA. The VA is combined with the PID to make a modified virtual address, and the modified virtual address is resolved through the mmu to make a physical address. You need to trap modified virtual addresses (post PID translation) and the debug registers do just that. (The output of "dump mmu" shows modified virtual addresses.) For more info on how PIDs work on ARM, see chapter B6 (Fast Context Switch Extension) of the ARM Architecture Reference Manual. -Kevin _______________________________________________ Haret mailing list [email protected] https://handhelds.org/mailman/listinfo/haret
