On Friday 30 October 2009, Dimitar Dimitrov wrote: > Working configuration is high-speed USB. I have only two > patches in my repository and they were attached to my previous > message. One is trivial interface configs.
Already merged into mainline... > The other one > increases (at least I think so) the FT2232 retry counts. > Without it I get errors when I "reset init". And I'm about to merge a version this one too. I looked at what libftdi is doing, and that retry count mostly controls how many times usb_bulk_read() is called. So while the semantics are screwey, it's not going to introduce new bugs. But I did add FIXMEs ... there's something screwey with how the timeouts are working. The libftdi timeout getting passed down to the kernel through libusb should be doing some good! And did you notice that the second time the ft2232.c driver uses that "retry count" it's a big ugly NOP? Sigh. We will however be able to say that the FT2232H support in the 0.3.0 release is a lot better than in the 0.2.0 code. More adapters supported ... and they'll work better now! > Browsing libftdi-0.16/src/ftdi.c:1232 I saw > if (ftdi->type == TYPE_2232H || ftdi->type == TYPE_4232H) > packet_size = 512; > else > packet_size = 64; > > I'm not acquainted with libftdi but if it assumes that > FT2232H as packet size 512 then it is wrong. In full speed > USB it must have packet size 64. Right, I noticed this too. It's clearly a libftdi bug. It should either be reading the current config descriptors, or asking "is this high speed" ... not assuming that all highspeed-capable devices always run at high speed. > Which leads me to the question, has anyone successfully > run FT2232H in full-speed USB mode? Not through libftdi. Their current git tree still has the same bug ... :( > > > After starting openocd I issue the following commands (see attached log): > > > 1. reset init > > > 2. arm7_9 dcc_downloads disable > > > 3. load_image dd 0x20000000 #THIS WORKS > > > 4. arm7_9 dcc_downloads enable > > > 5. load_image dd 0x20000000 #THIS FAILS. > > > > > > After that the FT2232H is not usable until it is power cycled. > > > > Hmm. I see two problems: > > > > - Not usable till power cycled ... can you establish > > whether this is a hardware bug of some kind? In Linux > > you should be able to force a medium-weight reset of > > the device by writing the bConfiguration sysfs value > > for that device to zero (then back to what it was). > > Setting bConfiguration to 0 and then back to 1 helps. OpenOCD > starts correctly without the need for FT2232H power cycle. > > > Being able to trigger that failure seems clearly to > > be some kind of bug on our side. Not being able to > > recover from it could be our bug; but maybe not. > > > > - The DCC download feature thing. The issue shouldn't > > be the DCC per se ... but the "fast" optimization > > that disables handshaking. If you're running the > > JTAG clock six times faster, and the code inside > > the ARM isn't running out of icache or TCM, then you > > might not be able to avoid the handshaking... > > > > Can you sort out that DCC thing a bit better, to verify > > that it works OK with handshaking enabled? > > I issued "arm7_9 fast_memory_access disable" with DCC > downloads enabled but I still get "usb bulk write failed". I was wrong ... if it uses DCC, it assumes that it doesn't need handshaking. The "fast" flag doesn't affect DCC. > I'm using RTCK. Maybe I'm hitting the following issue: > https://lists.berlios.de/pipermail/openocd-development/2009-October/011825.html Wouldn't surprise me. The DCC memory write loops are pretty tight ... just a handful of instructions to read from the DCC register then write to memory. I'd expect that in the time it takes for fifty-odd JTAG clocks to patch, at least a hundred or so ARM instructions would run. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
