On Dec 23, 2008, at 4:17 AM, Dirk Behme wrote:
I believe it can be added. Things like runtest attempt to move in the state machine which cannot be done until the power domain is up. We need a way to force 10 TCK ticks with no other pin changes or internal state moves.Does this "waiting 10 TCK fairly easily" mean there is already a command to wait 10 TCK or does this mean it can easily implemented/ added?So we need a "10 TCK ticks with no other pin changes or internal state moves" replacement command for "runtest 10" in script below? This has to be written, and the linkhttps://lists.berlios.de/pipermail/openocd-development/2008-December/004161.html Øyvind gave could help with this?
It would be something similar to what is suggested there. The main difference is that the design settled on for that problem was a "move to state and send X TCK pulses" while this problem is before the JTAG hardware is up. We could emulate it by sending that command with the current state as the state to move to.
I'm thinking about adding something like jtag_reset wait 10 TCK to omap3530.cfg script. E.g. jtag configure $_CHIPNAME.cpu -event tap-enable { puts "Enabling Cortex-A8 @ OMAP3" => jtag_reset => wait 10 TCK irscan omap3530.jrc 7 drscan omap3530.jrc 8 0x89 irscan omap3530.jrc 2 drscan omap3530.jrc 32 0x81000080 drscan omap3530.jrc 32 0xa3002048 drscan omap3530.jrc 32 0x81002148Is this a copy/paste error and it should be 0x81000081 instead?
I started with the config provided by someone on the list. The TI doc shows a slightly different set of commands. I would trust the TI doc, but it also doesn't tell you what those commands are doing.
The good news is that we can _possibly_ bring up the DAP and not attempt a second chain examination. It means the output of scan_chain will be wrong in some ways, but at the very least, we should be able to manually query the DAP. If nothing else, being able to talk to the DAP means that development on Cortex-A8 target support can start even if the JRC isn't behaving perfectly.How would I do "we should be able to manually query the DAP"? I.e. how would I verify that I can talk to the DAP if second scan_chain "doesn't work"?scan_chain only shows OpenOCDs internal knowledge of the chain.ok.In this case, it knows that the DAP is enabled, but it did not retrieve the idcode. Manually running irscan and drscan to retreive the idcode would prove the DAP is enabled.Could you give some irscan and drscan commands to do this?
For any CoreSight device, the IDCODE should be obtainable by: irscan <tap> 0xFE drscan <tap> 32 0x0 The drscan should return the IDCODE.
Additionally, giving the irscan and drscan (?) commands to read JRC IdCode shown by scan_chain would help to better understand/learn.
The problem there is that the TI doc doesn't say which IR scan sets the DR to the IDCODE register. If we knew, we would be able to force a new chain examination and scan_chain would report the correct ID codes.
Btw.: Anybody sometimes at #openjtag IRC to discuss stuff like this?
I would be but I'm currently traveling for the holidays and won't be online regularly until Jan 2nd. I'm in the PST time zone.
Rick
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
