On Saturday 24 October 2009, Øyvind Harboe wrote: > On Fri, Oct 23, 2009 at 10:37 PM, David Brownell <davi...@pacbell.net> 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... > arm926ejs.c does not invoke arm9tdmi_register_commands()... Not if you ignore the call in arm926ejs_register_commands(); but why ignore that? :) > 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". > > Bugfix the current code to preserve the user's > > setting for that register across resets, sure. > > Are you sure it's broken? > > 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. > 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. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
