IRC logs for #openrisc Monday, 2013-07-08

--- Log opened Mon Jul 08 00:00:17 2013
stekernmaybe this is why I see the odd behaviour:
stekernnow it starts to make a little bit of sense12:02
stekernfrom what I've understood by studying the usb logs, it's basically the good'ol usb-blaster protocol, but with some addition12:03
stekernevery write ends with an 0x5f, but I'm not sure what that means12:03
stekernI 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
LoneTechthat sounds a little familiar, one moment (I have reimplemented a usb blaster recently)12:06
stekernbut at least it feels like there's hope to get this working12:06
stekernLoneTech: any hints would be greatly appreciated!12:06
LoneTech5f is a bit read command, so it does expect a byte back12:06
stekernyeah, but I'm inserting that (and it's hidden from the upper layer)12:07
stekernso 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 back12:08
LoneTechso it's off by 2?12:08
stekernno, I think the 0x5c has a "special meaning" in usb-blaster II12:08
stekern...that's just a guess though12:09
LoneTechI may need more context. I am not aware of protocol differences between usb blasters12:10
stekernme, neither, that's what I'm trying to figure out ;)12:10
LoneTechbut there's a bunch of other confusing bits at usb level12:10
stekernyeah, usb = users dream and engineers nightmare IMO12:11
LoneTechnah, users aren't that fond of it12:11
LoneTechin my implementation quartus does work, and I have no special handling of 5c or 5f12:12
LoneTechone 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 urbs12:14
LoneTechI expect lack of SHORT_NOT_OK may very well make the placement of those headers unpredictable12:16
LoneTech... or it does something different. need to read up12:16
LoneTechI 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 case12:18
LoneTechdo you have a log I could look at for your issue?12:19
LoneTechto make matters more interesting, the FTDI chip is *expected* to send spurious short packets - there's a timeout intended to ensure URBs finish12:24
LoneTechthe 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 each12:26
LoneTechI have not found a place ftdi specify that timer to ever reset, which suggests it may arbitrarily break up any transfer12:30
LoneTechstekern: ping12:33
stekernLoneTech: sorry, went afk for a while...12:58
stekern5c was a typo, it's always 5f12:59
stekernI've got logs, I'll put them somewhere asap13:00
stekernbut just to clarify, there's no ftdi chip on blaster ii13:01
stekernand writing typical ftdi registers (except latency something) through ep0 doesn't work, so I don't think it's emulating an ftdi13:02
stekernthe issue I have with EREMOTEIO, is that libusb set the SHORT_NOT_OK flag on a single bulk urb13:04
stekernbut afaiu I can ignore that error13:05
stekernthat is the "scan chain" on a blaster II13:39
stekernas a reference, this is the same "command" on a blaster (1):
stekernI've borrowed a usb-blaster (1) from work, so I'll solder on a jtag header to the sockit and run the same thing there13:41
stekernLoneTech: ping =)13:41
LoneTechstekern: 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 myself13:51
LoneTechyou're supposed to get endpoint numbers out of the interface descriptors, really13:51
LoneTechah, no. they clearly do not have the headers13:53
LoneTechperhaps they've used 5f as a flush command13:54
stekernyeah, or end of msg or something like that I suspect13:54
stekernhow does quartus communicate with usb-blaster(1)?13:55
LoneTechdirectly over usb; I expect they do use some libusb variant, but I'm not sure. They are certainly not using libftdi13:55
stekernI suspect it's this they're using:
stekernat least there are stuff from there in quartus/drivers13:57
LoneTechit'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 module13:59
LoneTechI'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 itself14:02
LoneTechif we can also find a place reads aren't replied to until a 5f, that would support this hypothesis14:02
LoneTechsoftware 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
LoneTechlooks like the only big transfer in this log is the initial state flush, and even that is suffixed with 5f14:06
stekernyes, I agree, that's why I came to the conclusion that it's "special" too14:07
LoneTechpacket 31 shows the 5f directly after a read, but before another write14:07
stekernaah, so that's where the 0x31 0x60 comes from, I've been wondering about that14:07
LoneTechI expect it is like ftdi mpsse SEND_IMMEDIATE14:08
LoneTechit contains the status lines for the serial port the ft245 doesn't have - they used the same driver as the ft23214:08
LoneTechlooks like the ub2 makes for an easier protocol to put in an mcu and talk to from software14:10
stekernbut 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
stekern(the onboard) ub2 also have the nice extra feature of having two extra bulk endpoints for custom communication with the fpga14:13
LoneTechvery nice14:13
stekernby using that we could have jtag debugging of or1k without interfering with jtagd14:14
LoneTechwhat chip do they use? I assume one of the 8-bit usb capable mcus?14:14
stekernit's an FX2 (cypress)14:14
LoneTechxilinx also used those14:14
LoneTech8051 based with neat DMA system that allows pretty much bypassing the processor, iirc14:14
stekernbut 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 license14:15
stekernthere will probably still be a looong time before the last 8051 dies =P14:21
stekernthis is the capture from sockit with usb-blaster:
stekernpacket 31 in the sockit-jtagscan.pcapng is indeed interesting, that one doesn't end with 0x5f, but has a 0x3e following it19:19
stekernI wonder what that means19:19
stekernalso, it seems the bits have changed a bit for the bitbang mode19:19
stekernin ub1 bit 1 (DATAOUT) and bit 0 (TDO) is used19:20
stekernbut in ub2 it seems like bit 4 and bit 0 is used19:21
stekernbecause 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
stekernand the response from ub1 is: 0x31 0x60 0x0319:23
stekernand from ub2: 0x1119:23
stekernhmm, it seems it always return that19:39
stekernanother interesting observation can be made, on a lot of packets, ub1 does a bunch of bitbang writes with the read bit set19:40
stekernon ub2 it does the same writes, but with the readbit unset19:41
stekernmakes me wonder if bitbang reads are not supported in ub219:41
-!- Logxen is now known as Wolfxen21:16
-!- Wolfxen is now known as WolfRyder21:17
-!- WolfRyder is now known as Logxen21:18
--- Log closed Tue Jul 09 00:00:19 2013

Generated by 2.15.2 by Marius Gedminas - find it at!