David Brownell wrote: > On Monday 12 October 2009, Michael Schwingen wrote: > >>> I'll ask the folk using XScale to sanity check; I doubt this >>> set of XScale patches would have broken anything, but I can >>> only test on this one ancient PXA255 board I've got. >>> >> I just made a short test on IXP425 - compiled & installed current head, >> attached to target & tested single-step - seems to work fine, without >> the previous manual-copy-debug-handler-step. >> > > Thanks for checking. > > How stable do you find the XScale support, by the way? > Looks quite stable to me. I use it regularly at home on IXP42x (I have a BDI2000 at work), mostly in the mode of "reset halt / erase & program flash / reset run", plus from time to time some gdb-based debugging. I had some problems with breakpoints, but forcing hard breakpoints seems to fix that.
Debugging inside the Linux kernel seems a bit tricky for now. > I found a write-to-old-stackframe bug, and checked in a > fix for it ... that may have made things a bit better, > but it's hard to tell since the behavior varies wildly. > > Seeing that this is almost the only driver that uses > the code to validate DR scans -- and observing those > warning firing pretty regularly -- says to me that > some strange behavior is common here. > > I've observed two reset-related problems. One is that > the initial "reset" (from TCL command line) will not > often work. I've got a workaround I'm not yet ready > to send around. My theory is that the original work > on this code was on a second generation core (PXA270, > like your IXP425 -- 7 bit IR length) while this first > generation core (PXA255) is a bit more finickey. > I have not had any reset problems or instabilities on IXP42x for quite some time now (longer back than 0.2.0 release). I have used both Rev. 2.0 and Rev. 2.1 IXP42x CPUs, although I think there is no real difference in the core. > The second is that the *second* reset won't work at all. > AND ... this seems like something any XScale should > be seeing. The root cause being that it won't reload > the debug handler after it's purged from the mini-icache. > (TRST clears DCSR.H ... and SRST purges the mini-icache > unless that bit is set. QED.) > > Have you observed that problem with the second reset? > What kind of "second"? Using "reset halt" or "reset run" multiple times without re-starting OpenOCD works fine for me. cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
