On Sat, Oct 24, 2009 at 7:13 PM, David Brownell <[email protected]> wrote: > On Saturday 24 October 2009, Øyvind Harboe wrote: >> On Fri, Oct 23, 2009 at 10:37 PM, David Brownell <[email protected]> wrote: >> > On Friday 23 October 2009, Øyvind Harboe wrote: >> >> Here is a thought: >> >> >> >> Retire arm9 vector_catch C code and write a Tcl >> >> proc instead on top of "reg vector_catch". >> >> >> >> Thoughts? >> > >> > Erm ... why? >> > >> > Rename "arm9tdmi" to "arm9", sure. >> >> No arm7 supports this? > > None that OpenOCD supports now, from what I can tell. > You can read infocenter.arm.com docs as well as I can...
Obviously not then.... I used a BDI 2000 and it catch could break on data abort on arm7. >> arm926ejs.c does not invoke arm9tdmi_register_commands()... > > Not if you ignore the call in arm926ejs_register_commands(); > but why ignore that? :) I don't know why I ignored that. I tried to search it and didn't find it. But should vector_catch be arm9 specific even so? Doesn't xscale + arm11 support somesuch? I think the polymorphism at the C rather than command level makes sense. >> Is it unreasonable to have a common vector_catch syntax >> across e.g. Cortex, MIPS and ARMx for e.g. data abort? > > Yes. They don't all define "data abort". A command could produce an error if an option was not supported due to lack of hardware or OpenOCD support... We don't make "halt" target specific, similarly vector_catch could define a data abort catch that would work across MIPS/ARM, etc... if the hardware and OpenOCD supported it. >> Is this by inspection or testing? > > Usage, which is a flavor of testing. Though > maybe I didn't characterize the issue right. > > I know that the vector_catch settings basically > do not "stick" as expected, on any core I happen > to have tried to use them. I always felt that the register caching at the lowest level a bit eeeh.... It's a pretty advanced concept to push to the user. reg pc 0x12334 stricly speaking does not set the register, it sets the cache and then the cache is written to the hardware. The user is exposed to concepts such as "dirty" when listing "reg"... >> There is code in arm7_9_common.c reset to try to restore the >> vector_catch register after the reset vector has been caught. > > Cortex-M3 is missing such code. > > >> Ref. embeddedice_write_reg vs. embeddedice_store_reg. >> embedded_write_reg writes directly to the hardware register, >> embeddedice_store_reg writes the register cache to the >> hardware. > > The EICE cache seems fairly problematic, as do those > caches in general. I didn't see anything to persuade > me the cache is properly maintained. > > If you're after things that should move into shared > target infrastructure... cache flushing. I think > each segment of cache should have flush hooks, which > get invoked in appropriate reset paths (like when > SRST gets asserted on a target). The defaults would > invalidate everything. > > For ARM, SRST generally doesn't invalidate debug > registers. But SRST+TRST may do so, on some chips. Seems like you are not too excited about register caching either.... Before deleting all register caching we have to consider the performance impact. Perhaps we could remove register caching from the user's point of view, but keep it for performance reasons... who knows when a cache will be refreshed and stale though.... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
