Hello, -A- With 1149.1, hardware is available on table for testing. Openocd requires the introduction of a mode "tap enable on fly" For doing that, at every device change : - reset JTAG => jtag chain length is jrc tap length - reprogram icepick (jrc) in order to include the required tap. then the jtag chain is the jrc tap length + the length of selected tap.
Jrc is 6 bits length. For cortex_a dap length is 4 bits. (jrc cannot be set in by pass) drawback : when device is selected 40% only of bit transfer is dedicated to the device selected. -B- With 1149.7 : Few hardware available for testing star... No openocd optimized hardware for the support of new command on TCK/TMSC. Openocd requires : - CJTAG adaptation for these commands (at initialization, at star selection) Gain , the length of jrc tap can be remove. Risk : hardware availability So regarding hardware availability, the safest is 1149.1 and for openocd adaptation , part of the stuff done for step A , can be re-used for step B. Best regards -----Original Message----- From: Sébastien Baillou [mailto:sbaillou.mail...@gmail.com] Sent: Wednesday, May 11, 2011 12:01 PM To: Michel JAOUEN Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Multi-core platform support On 10/05/11 18:57, Michel JAOUEN wrote: > Hello, > For supporting optimized jtag chain length, you should look at CJTAG > specification, with star topology support. > CJTAG is not yet supported by openocd. > > Best regards Hello Michel, I had a look at the 1149.7 standard which seemed very promising at first. However, a couple of issues give me the impression that 1149.1 is the safest approach : 1- No support in OpenOCD. I guess this should't be too much of an issue since only the JTAG driver would need to be rewritten. The ZBS is already implemented (simply a special "pathmove" sequence). Therefore, only the escape sequences where TMS is used as a clock while holding TCK at '1' really needs to be added. 2- JTAG adapter lack of support for 1149.7 features. I currently have a JLink adapter, and I'm afraid the 'TMS as clock' feature is not handled as efficiently as a normal TDI/TMS scan (a separate command is necessary to change the value of TMS, whereas a scan operation can be performed in bulk). However, I don't know how much of a performance hit I should expect from this... Can you comment on this ? Do you know if other adapters would handle this better ? Do you think those issues justify sticking with 1149.1 or am I being too conservative ? Kind regards, Sébastien. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
