Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
- RESET is an illegal end state. It's split out as a separate thing for lots of reasons, including that this triggers events that listeners are listening for, etc. - irscan should use the drscan code implementation. They are almost identical. - DRPAUSE makes no sense for IRSCAN as an endstate according to your new and improved rules... Ditto for DRSCAN -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
Øyvind Harboe wrote: - RESET is an illegal end state. It's split out as a separate thing for lots of reasons, including that this triggers events that listeners are listening for, etc. - irscan should use the drscan code implementation. They are almost identical. - DRPAUSE makes no sense for IRSCAN as an endstate according to your new and improved rules... Ditto for DRSCAN If I were a user who wanted to work/play with direct jtag commands from the command line or in a script, I would REALLY hate it if I were told that the official stable states of the JTAG state machine were not available as end states for the scan commands. I could point to the STAPL documentation The DRSTOP statement specifies the IEEE 1149.1 end state for data register scan operations. This end state must be one of the IEEE 1149.1 states: RESET, IDLE, IRPAUSE, or DRPAUSE.. Well ... I am not playing with this at the moment and I can, and do, rewrite the code to work without unneccesary limits, but the strong selling points are lost on me. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
On Monday 01 June 2009, Øyvind Harboe wrote: - RESET is an illegal end state. It's split out as a separate thing for lots of reasons, including that this triggers events that listeners are listening for, etc. That makes sense as a policy. It's not enforced today in irscan, drscan, or endstate commands though. That seems a bit more on the post-0.2.0 side of things. Though I'd not object to taking RESET out of the list of states that are safe, so it triggers a warning... - irscan should use the drscan code implementation. They are almost identical. Well, there are relevant differences, but that's the way I'd change things too. This seems very much post-0.2.0 ... - DRPAUSE makes no sense for IRSCAN as an endstate according to your new and improved rules... Ditto for DRSCAN Those rules just say don't do anything known to be broken. But those transitions are legal, stable, safe -- not broken: IRSCAN: ... Update-IR -- Select-DR-Scan -- Capture-DR -- Exit1-DR -- Pause-DR DRSCAN: ... Update-DR -- Select-DR-Scan -- Select-IR-Scan -- Capture-IR -- Exit1-IR -- Pause-IR I don't think the API should make a policy decision to prevent those particular transitions, if some wierdo needs them. Let them be safe, legal, and rare ... but possible, without any extra roadblocks. Folk *do* have TAP engines that respond to unusual state transitions. (Although maybe all we'd really need to worry about is the IEEE 1149.7 ZBS ...) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
On Tue, Jun 2, 2009 at 8:45 AM, David Brownell davi...@pacbell.net wrote: On Monday 01 June 2009, Ųyvind Harboe wrote: - RESET is an illegal end state. It's split out as a separate thing for lots of reasons, including that this triggers events that listeners are listening for, etc. That makes sense as a policy. It's not enforced today in irscan, drscan, or endstate commands though. That seems a bit more on the post-0.2.0 side of things. Though I'd not object to taking RESET out of the list of states that are safe, so it triggers a warning... RESET *could* be made a legal state from the users point of view, even if it is handled quite differently inside OpenOCD innards. - DRPAUSE makes no sense for IRSCAN as an endstate according to your new and improved rules... Ditto for DRSCAN Those rules just say don't do anything known to be broken. But those transitions are legal, stable, safe -- not broken: IRSCAN: ... Update-IR -- Select-DR-Scan -- Capture-DR -- Exit1-DR -- Pause-DR DRSCAN: ... Update-DR -- Select-DR-Scan -- Select-IR-Scan -- Capture-IR -- Exit1-IR -- Pause-IR I don't think the API should make a policy decision to prevent those particular transitions, if some wierdo needs them. Let them be safe, legal, and rare ... but possible, without any extra roadblocks. Folk *do* have TAP engines that respond to unusual state transitions. (Although maybe all we'd really need to worry about is the IEEE 1149.7 ZBS ...) How about removing the -endstate option entirely for IRSCAN/DRSCAN and force IRPAUSE/DRPAUSE as endstates? From there the user can *move* into whatever state he wants... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
On Tuesday 02 June 2009, Øyvind Harboe wrote: How about removing the -endstate option entirely for IRSCAN/DRSCAN and force IRPAUSE/DRPAUSE as endstates? Why force such a policy, when it's not needed? Is there some issue with the current code? That change could make sense if there were an entirely queued interface though: jtag execute $SAVED. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
On Tue, Jun 2, 2009 at 10:22 AM, David Brownell davi...@pacbell.net wrote: On Tuesday 02 June 2009, Ųyvind Harboe wrote: How about removing the -endstate option entirely for IRSCAN/DRSCAN and force IRPAUSE/DRPAUSE as endstates? Why force such a policy, when it's not needed? Is there some issue with the current code? Q: if we didn't have this option today, why would we add it? The answer to this question is probably that we should remove this option. That change could make sense if there were an entirely queued interface though: jtag execute $SAVED. The queued interface(0.2) may have to be added to make things work correctly. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
