On Wednesday 19 August 2009, James Lin wrote: > Then I tried to apply the patch described in > > http://lists.berlios.de/pipermail/openocd-development/2009-June/008256.html > > I don't know if this additional step was necessary but it seemed > to get correct mfg, part, ver.
So it *was* necessary. You seem to have had better luck than I did, way back when I did that, in that you got that without first forcing a reset. Right? Maybe an updated version of that patch should merge... > But I could not halt, or examine memory. Could someone help to > see if I might have missed some steps? Thanks in advance. Current SVN seems to behave with the lowlevel JTAG ops (given a patch like the one above). But there's also the issue of adding support for the Cortex-A8 CPU; and someday, of being sure that works for chips other than OMAP3. See: http://lists.berlios.de/pipermail/openocd-development/2009-July/009652.html https://lists.berlios.de/pipermail/openocd-development/2009-July/009784.html Plus of course: --- a/tcl/target/omap3530.cfg +++ b/tcl/target/omap3530.cfg @@ -35,9 +35,7 @@ jtag newtap $_CHIPNAME jrc -irlen 6 -irc -expected-id $_JRC_TAPID # GDB target: Cortex-A8, using DAP - -# FIXME when we have A8 support, use it. A8 != M3 ... -target create omap3.cpu cortex_m3 -chain-position $_CHIPNAME.dap +target create omap3.cpu cortex_a8 -chain-position $_CHIPNAME.dap # FIXME much of this should be in reset event handlers proc omap3_dbginit { } { _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
