On Tuesday 07 July 2009, Øyvind Harboe wrote: > > I can believe the chip requires "reset_config srst_pulls_trst". > > > > But I have a hard time believing "srst_only" is anything but > > a board-specific constraint. > > The TRST is tied to SRST on the *inside* of the chip if I understood > correctly.
Fine, but that's beside the point. > I'm not sure if there is a difference between "srst_pulls_trst srst_only" > and "srst_pulls_trst" from the arm926ejs codepaths point of view. That seems kind of buglike. But, I'm moderately convinced some of the reset problems are going to require lowlevel surgery to resolve them. The code is just not factored well enough to support the variety of real-world reset models we now observe. It originally handled just a few models... If there's no SRST, then any logic depending on it should obviously never kick in. And other commands should be used to reset a given target. (E.g. through a DAP or JRC.) But it should also be possible to say that *IF* a board gets reset using SRST, that has specific consequences for JTAG on a given chip. Note that's not quite the same as saying that the board has screwey wiring that connects TRST and SRST. What you summarize above applies to a single chip. But there can also be board-level behaviors ... consider a board with an i.MX27 plus another chip that doesn't couple those behaviors internally. Issue SRST ... and one chip will have undisturbed JTAG/debug state, while the i.MX27 is going to need some re-init. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
