On Fri, 2009-06-12 at 15:15 -0700, David Brownell wrote: > 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 *".
Yeah, such rework would be post 0.2.0, but I think your suggestion of the generic bit-array representation might be the right one for the reasons you give (JTAG/BS or SVF). I think that 64-bit helpers would be easy to put together and allow immediate tinkering, but even that might be too invasive for 0.2.0. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
