| --- Log opened Mon Jul 08 00:00:17 2013 | ||
| stekern | maybe this is why I see the odd behaviour: http://www.libusb.org/ticket/142 | 07:30 |
|---|---|---|
| stekern | now it starts to make a little bit of sense | 12:02 |
| stekern | from what I've understood by studying the usb logs, it's basically the good'ol usb-blaster protocol, but with some addition | 12:03 |
| stekern | every write ends with an 0x5f, but I'm not sure what that means | 12:03 |
| stekern | I get data back when reading too, but they are all off by one byte (one too little) | 12:04 |
| stekern | ... to clarify, this is when I let the openocd usb blaster higher level send data through my "low level driver" | 12:05 |
| LoneTech | that sounds a little familiar, one moment (I have reimplemented a usb blaster recently) | 12:06 |
| stekern | but at least it feels like there's hope to get this working | 12:06 |
| stekern | LoneTech: any hints would be greatly appreciated! | 12:06 |
| LoneTech | 5f is a bit read command, so it does expect a byte back | 12:06 |
| stekern | yeah, but I'm inserting that (and it's hidden from the upper layer) | 12:07 |
| stekern | so basically what I send is (data_from_upper_layer + 0x5c), and then upper layer does a read X bytes, but I always get X-1 bytes back | 12:08 |
| LoneTech | so it's off by 2? | 12:08 |
| stekern | no, I think the 0x5c has a "special meaning" in usb-blaster II | 12:08 |
| stekern | ...that's just a guess though | 12:09 |
| LoneTech | I may need more context. I am not aware of protocol differences between usb blasters | 12:10 |
| stekern | me, neither, that's what I'm trying to figure out ;) | 12:10 |
| LoneTech | but there's a bunch of other confusing bits at usb level | 12:10 |
| stekern | -, | 12:10 |
| stekern | yeah, usb = users dream and engineers nightmare IMO | 12:11 |
| LoneTech | nah, users aren't that fond of it | 12:11 |
| stekern | =P | 12:11 |
| LoneTech | in my implementation quartus does work, and I have no special handling of 5c or 5f | 12:12 |
| LoneTech | one thing that may eat pairs of bytes is the FTDI headers.. they're added in at usb packet level, but filtered out by software after completing urbs | 12:14 |
| LoneTech | I expect lack of SHORT_NOT_OK may very well make the placement of those headers unpredictable | 12:16 |
| LoneTech | ... or it does something different. need to read up | 12:16 |
| LoneTech | I see, it's a flag to request error detection when you know the length of incoming data, which you do not in general for this case | 12:18 |
| LoneTech | do you have a log I could look at for your issue? | 12:19 |
| LoneTech | to make matters more interesting, the FTDI chip is *expected* to send spurious short packets - there's a timeout intended to ensure URBs finish | 12:24 |
| LoneTech | the easy way to handle ftdi input is probably to make lots of EP-sized urbs, without short_not_ok, and strip the first two bytes of each | 12:26 |
| LoneTech | I have not found a place ftdi specify that timer to ever reset, which suggests it may arbitrarily break up any transfer | 12:30 |
| LoneTech | stekern: ping | 12:33 |
| stekern | LoneTech: sorry, went afk for a while... | 12:58 |
| stekern | 5c was a typo, it's always 5f | 12:59 |
| stekern | I've got logs, I'll put them somewhere asap | 13:00 |
| stekern | but just to clarify, there's no ftdi chip on blaster ii | 13:01 |
| stekern | and writing typical ftdi registers (except latency something) through ep0 doesn't work, so I don't think it's emulating an ftdi | 13:02 |
| stekern | the issue I have with EREMOTEIO, is that libusb set the SHORT_NOT_OK flag on a single bulk urb | 13:04 |
| stekern | but afaiu I can ignore that error | 13:05 |
| stekern | http://oompa.chokladfabriken.org/tmp/blaster-capture/sockit-jtagscan.pcapng | 13:39 |
| stekern | that is the "scan chain" on a blaster II | 13:39 |
| stekern | as a reference, this is the same "command" on a blaster (1): http://oompa.chokladfabriken.org/tmp/blaster-capture/de0_nano-jtagscan.pcapng | 13:40 |
| stekern | I've borrowed a usb-blaster (1) from work, so I'll solder on a jtag header to the sockit and run the same thing there | 13:41 |
| stekern | LoneTech: ping =) | 13:41 |
| LoneTech | stekern: apologies, I left the office. I suspect they're emulating the ftdi chip exactly well enough to talk to quartus, was a bit surprised when I noticed that endpoint order code in libftdi myself | 13:51 |
| LoneTech | you're supposed to get endpoint numbers out of the interface descriptors, really | 13:51 |
| LoneTech | ah, no. they clearly do not have the headers | 13:53 |
| LoneTech | perhaps they've used 5f as a flush command | 13:54 |
| stekern | yeah, or end of msg or something like that I suspect | 13:54 |
| stekern | how does quartus communicate with usb-blaster(1)? | 13:55 |
| LoneTech | directly over usb; I expect they do use some libusb variant, but I'm not sure. They are certainly not using libftdi | 13:55 |
| stekern | I suspect it's this they're using: http://www.jungo.com/ | 13:57 |
| stekern | at least there are stuff from there in quartus/drivers | 13:57 |
| LoneTech | ok | 13:57 |
| LoneTech | it's possible they have used that before, though. I recognize the name from back when xilinx didn't support libusb, and I don't need an extra windrvr module | 13:59 |
| LoneTech | I'd say packets 36 to 39 suggest rather strongly it's there to get the reply back.. practically no delay and no reply to the 5f itself | 14:02 |
| LoneTech | if we can also find a place reads aren't replied to until a 5f, that would support this hypothesis | 14:02 |
| LoneTech | software which expects to talk at usb level to a usb blaster 1 will expect every 62-byte block prefixed with \x31\x60 or similar (they typically ignore it, but that's from the ftdi chip) | 14:04 |
| LoneTech | looks like the only big transfer in this log is the initial state flush, and even that is suffixed with 5f | 14:06 |
| stekern | yes, I agree, that's why I came to the conclusion that it's "special" too | 14:07 |
| LoneTech | packet 31 shows the 5f directly after a read, but before another write | 14:07 |
| stekern | aah, so that's where the 0x31 0x60 comes from, I've been wondering about that | 14:07 |
| LoneTech | I expect it is like ftdi mpsse SEND_IMMEDIATE | 14:08 |
| LoneTech | it contains the status lines for the serial port the ft245 doesn't have - they used the same driver as the ft232 | 14:08 |
| stekern | ok | 14:08 |
| LoneTech | looks like the ub2 makes for an easier protocol to put in an mcu and talk to from software | 14:10 |
| stekern | but I think all that is needed for openocd to speak properly to ub2 is to straighten out those small quirks (as the 5f) and write the libusb low level driver for it (which I essentially already done) | 14:12 |
| LoneTech | right | 14:13 |
| stekern | (the onboard) ub2 also have the nice extra feature of having two extra bulk endpoints for custom communication with the fpga | 14:13 |
| LoneTech | very nice | 14:13 |
| stekern | by using that we could have jtag debugging of or1k without interfering with jtagd | 14:14 |
| LoneTech | what chip do they use? I assume one of the 8-bit usb capable mcus? | 14:14 |
| stekern | it's an FX2 (cypress) | 14:14 |
| LoneTech | xilinx also used those | 14:14 |
| LoneTech | 8051 based with neat DMA system that allows pretty much bypassing the processor, iirc | 14:14 |
| stekern | but first I want to get normal jtag working, because right now there's no way to use the onboard jtag to debug the arm processor without an DS-5 license | 14:15 |
| stekern | there will probably still be a looong time before the last 8051 dies =P | 14:21 |
| LoneTech | quite | 14:21 |
| stekern | this is the capture from sockit with usb-blaster: http://oompa.chokladfabriken.org/tmp/blaster-capture/sockit-jtagscan-ub1.pcapng | 18:52 |
| stekern | packet 31 in the sockit-jtagscan.pcapng is indeed interesting, that one doesn't end with 0x5f, but has a 0x3e following it | 19:19 |
| stekern | I wonder what that means | 19:19 |
| stekern | also, it seems the bits have changed a bit for the bitbang mode | 19:19 |
| stekern | in ub1 bit 1 (DATAOUT) and bit 0 (TDO) is used | 19:20 |
| stekern | but in ub2 it seems like bit 4 and bit 0 is used | 19:21 |
| stekern | because that packet 31 request does 0x7e 0x5f 0x3e, and 0x7e is the actual read (that can be identified as packet 104 in the ub1 capture) | 19:22 |
| stekern | s/read/write | 19:22 |
| stekern | and the response from ub1 is: 0x31 0x60 0x03 | 19:23 |
| stekern | and from ub2: 0x11 | 19:23 |
| stekern | hmm, it seems it always return that | 19:39 |
| stekern | another interesting observation can be made, on a lot of packets, ub1 does a bunch of bitbang writes with the read bit set | 19:40 |
| stekern | on ub2 it does the same writes, but with the readbit unset | 19:41 |
| stekern | makes me wonder if bitbang reads are not supported in ub2 | 19:41 |
| -!- Logxen is now known as Wolfxen | 21:16 | |
| -!- Wolfxen is now known as WolfRyder | 21:17 | |
| -!- WolfRyder is now known as Logxen | 21:18 | |
| --- Log closed Tue Jul 09 00:00:19 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!