On Friday 12 June 2009, Zach Welch wrote: > Since you have looked at this code closely, can you tell us how hard > would it be to support up to 64 bit IR lengths? My gut tells me that > would require more systemic work, but perhaps I am wrong.
I don't know how "closely" I looked, but one issue seems to be only where I put that "TODO" comment ... which "knows" that IR values top out at 32 bits (wrongly). Easy enough to record 64 bits in the "jtag newtap ..." code. But those "buf_set_u32" calls don't have "buf_set_u64" siblings. I think near-term it would suffice to accept up-to-64-bit IDCODE operations. Maybe the SVF stuff will want more though; or other boundary scan work. I'd hold off on such stuff till later. A better fix might involving a generic bit-array representation for IR. Semi-related, some of those ARM portability issues would work a lot better if the binary buffer utilities worked like they do on Linux: accept "unsigned long *" not "u8 *". - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
