On Tuesday 24 November 2009, Øyvind Harboe wrote: > On Tue, Nov 24, 2009 at 1:14 AM, David Brownell <davi...@pacbell.net> wrote: > > On Monday 23 November 2009, Ųyvind Harboe wrote: > >> Wow. :-) > > > > I hope that's not all you'll have to say. ;) > > The arm11 stuff needed a lot of work to be streamlined with the > rest of the code and I trust you to make good choices here if > the past is anything to judge by.
In that case I'll commit the rest of this set, now that it passes my basic testing. The flash erase check behaves, so do register modifications and "arm reg", single step behaves. Overall it's now looking and acting a lot more like any other ARM core. (And there's soon to be a place to hang that context-sensitive breakpoint stuff too...) Plus this shrinks the size of "arm11.c" by 20%, measured by line count ... that type of update I like a WHOLE lot! :) > I'm sure there will be regressions with as many changes, but we have > a long way to go with the arm11 support, so we need a firm foundation > to build on. I expect regressions to be bugs rather than architectural with > your normal quality. The thing I would fear the most is stuff that > just happened to work today, like some convoluted path through the > JTAG state machine that just happend to pass through or evade a state... I haven't touched that level of code, though I think that the ARM11 code is doing some stuff it doesn't need to do. This is just putting the existing lowlevel JTAG ops into the same kind of framework other ARMs use. However, I *have* been testing with those new "even shorter" JTAG paths I sent by a while ago ... which include the more visible initialization, building the bit vectors from lists of states instead of just being cryptic. I heard about an FT2232 issue we may want to pay attention to: http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00292.html That would affect such low-level things. But for now I'm content to not worry about such issues. :) - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
