Rick Altherr wrote: > This looks like an excellent direction for this. A few questions: > - Under what conditions would we need to re-enumerate the JTAG chain?
It is not "renumerate the chain" - it is more of an internal thing - using symbolic names internally makes more sense, also - from the stand point of the configuration scripts - today - you have a Beagle board with exactly 1 chip in the chain (with N internal taps). Somebody else might have other chips in the chain. From a "openocd.cfg" point of view - named targets is a *BETTER* solution for us humans. > - What other operations are needed for the new JTAG syntax? I'm sure we will have some housekeeping problems to deal with. I'm not sure of the total list. > [snip ... ] consider abstracting the idea of the conduit for talking to a target/pld? [snip] I think that generally exists today - by way of "execute_que()" in the interface structure. The issue is: The interface structure only supports ONE type of que, hence my suggestion in other (SPI) email about renaming execute_que() to execute_jtag_que() - and adding execute_spi_que(). The general idea is if "execute_spi_que()" is NULL - then that interface does not support SPI... We probably could also have a execute_gpio_que() to just do bit bang stuff. What I do not know enough about is SWJ - for example do we need execute_swj_que()? Which - perhaps uses the same "jtag_work_que" ... I don't know enough about SWJ to answer. Maybe one day we add: execute_pic_chip_que() ... who knows. > - Is it possible to do some form of autodetection of the JTAG chain? I believe mostly 90% yes - what I don't know about is the "IR Register Length" detection. I am fuzzy in that area. But - for example UrJTAG seems to do that - that is the purpose of the data base. One problem: Not every vendor of arm chips has been good about identifying tap numbers. ie: Many chips respond with identical numbers - the "arm7tdmi number" is a good example. In other cases, some chip makers changed the "arm7tdmi" default number to something else. It seems to be a mixed bag. We can perhaps have a "Gee this really looks (90%) confidence this is an ARM7TDMI..." Or - another message: "If this is number 0x12345678 really is an ARM7DMI - please report info about it to openocd". But we *MUST* have a OVER-RIDE feature ... in some form. -Duane. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
