| 02:13.48 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 07:18.53 | *** join/#openjtag ep1220 (n=NN@gate.epatec.at) |
| 07:59.29 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 08:24.55 | *** join/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 10:26.35 | *** join/#openjtag vmaster_ (i=vmaster@p549B5426.dip.t-dialin.net) |
| 11:19.17 | lennert | vmaster: when i come home from running i'd like to have a chat about your jtag proposal |
| 11:19.24 | lennert | vmaster: is today a good day/time? |
| 11:19.35 | vmaster | heh, as good as any other day/time |
| 11:19.49 | lennert | okay |
| 11:20.07 | vmaster | just highlight me a bit when you're back :) |
| 11:21.14 | lennert | okay |
| 11:21.21 | lennert | i have http://mmd.ath.cx/epp_jtag/ |
| 11:21.29 | lennert | and there's some other link you sent but i keep forgetting.. ? |
| 11:23.11 | vmaster | openocd.berlios.de |
| 11:23.23 | lennert | thanks |
| 11:23.28 | vmaster | the eppjtag is already a bit outdated, i.e. i know that it has a serious flaw |
| 11:23.36 | lennert | the clock divider is fucked |
| 11:24.04 | vmaster | mhh, maybe, but the parallel port interfacing is even worse ;) |
| 11:24.36 | vmaster | if tck goes below 1mhz or maybe 500khz, epp timesouts are going to occur |
| 11:24.37 | lennert | okay :) |
| 11:24.43 | lennert | hmm |
| 11:24.48 | lennert | didn't look at it very carefully |
| 11:24.54 | vmaster | laurent gauch from amontec started working on a new version |
| 11:25.00 | vmaster | which he's going to release with complete vhdl code |
| 11:25.16 | vmaster | but i haven't heared from him the last two weeks |
| 11:25.22 | lennert | okay |
| 11:25.29 | lennert | is the protocol documented somewhere? |
| 11:26.21 | vmaster | epp? |
| 11:26.30 | lennert | no, the epp jtag thing |
| 11:26.51 | vmaster | uhm, on a piece of paper on my desk ;) - it's rather simple |
| 11:27.31 | vmaster | ah, i guess i wrote about it in an email, i'll see if i can find it |
| 11:27.55 | dyoung-away | this is all so wonderful |
| 11:28.30 | vmaster | There are three access methods: |
| 11:28.30 | vmaster | - Scan (EPP data write) |
| 11:28.30 | vmaster | - Write cfg (EPP address write) |
| 11:28.31 | vmaster | - Read Scan (EPP data read) |
| 11:28.31 | vmaster | The configuration latch holds the number of bits to be scanned (cfg(2:0)), |
| 11:28.33 | vmaster | whether the scan should go to TMS or TDI (cfg(3)), the desired clock divider |
| 11:28.34 | lennert | vmaster: great, thanks |
| 11:28.35 | vmaster | (cfg(5:4)), srst (cfg(6)) and trst (cfg(7)). |
| 11:28.35 | lennert | dyoung-away: what? |
| 11:30.14 | lennert | okay, that's indeed fairly simple |
| 11:30.15 | dyoung-away | VHDL and stuff |
| 11:30.34 | dyoung-away | I can almost wrap my tiny brain around it. |
| 11:30.44 | dyoung-away | The light bulb didnt quite go on yet. |
| 11:30.48 | lennert | vmaster: if the scan goes to TMS, TDI is a don't care, and if it goes to TDI, TMS is a zero? |
| 11:31.06 | lennert | dyoung-away: maybe it'll help to read the xst.pdf guide |
| 11:31.18 | lennert | dyoung-away: there are only a dozen patterns that you can make in vhdl that the synthesizer will recognise |
| 11:31.19 | vmaster | if a scan goes to TMS, TDI is Data(7) |
| 11:31.37 | vmaster | if a scan goes to TDI, TMS is zero |
| 11:31.51 | vmaster | because you want to stay in Shift-D/IR |
| 11:32.03 | lennert | ok, so when you want to scan the last bit of the D/IR, you have to issue a scan to TMS |
| 11:32.17 | vmaster | yep |
| 11:32.18 | lennert | (because when you leave shift-dr/ir, the bit in tdi is still shifted in) |
| 11:32.20 | lennert | okay |
| 11:32.32 | vmaster | that's the way it's handled on ft2232c for example |
| 11:32.52 | lennert | yeah, that doesn't sound hard to implement at all |
| 11:33.24 | lennert | do the openwince jtag tools support this kind of interface? |
| 11:33.28 | vmaster | no |
| 11:33.34 | lennert | just bit-banging? |
| 11:33.58 | vmaster | yes |
| 11:34.35 | vmaster | while it wouldn't be much of an effort to port them to that kind of interface, it would require a lot of work to port them to a high-latency interface like usb |
| 11:34.51 | lennert | parallel port is also fairly high latency |
| 11:34.59 | lennert | and the latency is going up with newer chipsets |
| 11:35.20 | vmaster | mhh, yeah, but you can do epp accesses in microseconds |
| 11:35.27 | vmaster | usb accesses take miliseconds |
| 11:35.49 | lennert | shifing in a million bits takes 10 seconds on my work pc |
| 11:36.03 | lennert | so that's.. yeah, about 200 000 parallel port writes per second |
| 11:36.25 | lennert | about 12000 processor clock cycles each |
| 11:37.12 | vmaster | with the ft2232c, writing the data out takes <1ms, but waiting for the result takes >10ms |
| 11:38.04 | lennert | is that a chip quirk or something unfixable in the usb protocol? |
| 11:38.18 | lennert | of course, we can always make a jtag pci board ;) |
| 11:39.53 | vmaster | usb 1.1 transmits data in frames of 1ms length |
| 11:39.55 | lennert | my home box does it much faster, about 4 seconds for the code download, but that's an older chipset |
| 11:40.14 | lennert | right, that sucks then |
| 11:41.03 | vmaster | usb 2.0 uses 125us frames, but there's no solution as easy as the ft2232c available |
| 11:42.06 | vmaster | the latency isn't that much an issue when you design your application for high-latency operation |
| 11:42.39 | lennert | the only case where we really care about both what we shift in and what we shift out is SAMPLE/EXTEST |
| 11:42.58 | lennert | so i.e. we issue a SAMPLE, shift out the sampled data while we shift in the new test vector, and issue EXTEST |
| 11:43.09 | lennert | but with that parallel i/f, you can do that 8 bits at a time, right? |
| 11:43.18 | vmaster | yes |
| 11:43.27 | lennert | in theory we can do that in larger groups |
| 11:43.41 | lennert | i.e. we could just write the entire scan vector, and then read out the old scan vector |
| 11:43.46 | lennert | is there any other case where the latency matters? |
| 11:44.00 | vmaster | yes |
| 11:44.07 | vmaster | when debugging arm7/arm9 systems for example |
| 11:44.27 | lennert | can you describe what the issue is there? |
| 11:45.10 | vmaster | okay, you write target memory by shifiting instructions into the pipeline that write the core registers, and an instruction that stores them to main memory afterwards |
| 11:45.34 | vmaster | after that, you have to poll a special scan chain for an acknowledgment |
| 11:45.54 | vmaster | the arm has 16 core registers, one has to be used as a base register, the last ist the program counter |
| 11:45.54 | lennert | right |
| 11:46.01 | lennert | yes |
| 11:46.08 | lennert | okay, that's annoying |
| 11:46.11 | vmaster | that gives your 14 usable registers, or 56 bytes at a time, before having to wait |
| 11:46.49 | lennert | there's something similar with xilinx fpga's in that you have to keep polling the IR after you program the chip and issue JSTART, because the IR has the 'done' bit |
| 11:47.02 | lennert | but that's only once |
| 11:47.44 | lennert | hmmm |
| 11:47.55 | vmaster | on xc9500 cplds, you have to check the result of many writes, and enter an exception handling process if the result didn't match |
| 11:47.58 | lennert | this kind of thing just makes you want to shift the control logic to the jtag interface instead of the host pc |
| 11:48.57 | lennert | which is also problematic |
| 11:49.13 | vmaster | yeah, you have a tradeoff between flexibility and performance |
| 11:49.50 | vmaster | mpeforth has a nice usb arm-jtag debugger, but it's tailored to arm debugging - not much use for other tasks |
| 11:50.07 | vmaster | they do all the work with an onboard arm7 uc |
| 11:50.15 | lennert | makes sense |
| 11:50.42 | lennert | pci writes/reads are still thousands of cycles each, so that wouldn't even be very much faster than parallel |
| 11:51.20 | vmaster | pci would just allow you to do writes of more than 8bit, but that's not the order of magnitude we're looking for |
| 11:53.20 | lennert | there's the 'long scan' case, where we benefit from burst writes, and the 'poll scan chain' case where we benefit from fast turnaround time |
| 11:56.45 | vmaster | ideally, there's a sophisticated jtag interface/api that may be implemented completely in hardware, or partly in hardware and partly on the host pc |
| 11:56.56 | vmaster | *there'd be |
| 11:57.56 | vmaster | for wigglers (which still many are going to use) or other bitbanging interfaces, this would be implemented by generic host software, while advanced devices could offload work to the hardware |
| 11:58.08 | lennert | yeah |
| 11:58.19 | lennert | i was thinking about converting my spartan3 loader to the epp interface you suggested |
| 11:58.29 | lennert | and then to write a shim layer to convert the epp stuff into bitbang stuff |
| 11:58.35 | lennert | epp->bitbang is trivial in software |
| 11:58.39 | vmaster | yep |
| 11:58.49 | lennert | so indeed, have the s/w speak some protocol that is latency-insensitive and offloadable |
| 11:58.56 | lennert | and then decide what you do in s/w and what you offload to h/w |
| 11:59.01 | vmaster | see my jtag api at openocd.berlios.de |
| 11:59.03 | lennert | okay, my running partner has arrived |
| 11:59.11 | vmaster | heh, cya later then |
| 11:59.16 | lennert | i will when i get back |
| 11:59.19 | lennert | i'm off for running now |
| 11:59.23 | lennert | be back in ~1.5 hrs |
| 11:59.26 | lennert | ciao :) |
| 11:59.29 | lennert | thanks for the conversation so far |
| 12:54.12 | *** join/#openjtag Tiersten (i=tman@nslu2-linux/Tiersten) |
| 13:03.15 | lennert | ok, back |
| 13:03.31 | lennert | need a shower though |
| 13:29.35 | vmaster | wb |
| 13:29.54 | lennert | thanks |
| 13:42.25 | *** join/#openjtag bullet (n=bullet@137.56.203.62.cust.bluewin.ch) |
| 15:10.02 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 15:10.10 | ka6sox | ep1220: ping? |
| 15:10.38 | ep1220 | ka6sox: pong |
| 15:10.48 | ka6sox | how goes it? |
| 15:11.14 | ep1220 | the PCBs arrived yesterday, late afternoon. |
| 15:11.23 | ka6sox | excellent. |
| 15:11.31 | ep1220 | all parts i ordered are here as well |
| 15:11.44 | ep1220 | just promsied to spend the weekend with the family |
| 15:11.53 | ep1220 | so work has to wait till monday |
| 15:11.58 | ep1220 | unless it rains tomorrow |
| 15:12.09 | ka6sox | family first....*unless it rains* |
| 15:12.12 | ka6sox | :) |
| 15:12.19 | ep1220 | :-) |
| 15:12.41 | ka6sox | my 4yr old should be waking up anytime soon. |
| 15:13.39 | ep1220 | so he will want breakfeast ... |
| 15:14.01 | ka6sox | ya...his mother is sleeping in today. |
| 15:15.24 | ka6sox | vmaster was worried about the speed of the drivers that are available for the ftdi parts... |
| 15:17.13 | ep1220 | i did measure on Windos, and did not see more dealy than I expected due to USB |
| 15:17.22 | ep1220 | on Linux I used libusb |
| 15:17.42 | ep1220 | as i understood on datatransfers it directly calls into the OS driver |
| 15:18.24 | ep1220 | but did no benchmarks |
| 15:18.31 | ka6sox | yes... |
| 15:18.46 | ka6sox | I don't think that there is a mpsse driver written yet. |
| 15:19.37 | ep1220 | there is a lib_fdti (not by FTDIchip) which supports JTAG and uses libusb as well |
| 15:20.17 | ka6sox | ah...okay cool. |
| 15:20.29 | ep1220 | when I looked into it libusb team said they change API |
| 15:20.43 | ka6sox | k |
| 15:20.53 | ep1220 | i did not feel comfortable having to support this lib-ftdi |
| 15:21.04 | ep1220 | so i wrote my own layer |
| 15:21.20 | ka6sox | oh excellent |
| 15:21.41 | ep1220 | Now i have same API on windos and Linux |
| 15:21.51 | ka6sox | this is very good. |
| 15:21.58 | vmaster | ah, nice |
| 15:22.29 | ep1220 | there seem to be a few quirks in libusb regarding device detection |
| 15:22.44 | vmaster | mhh, that's working fine for me |
| 15:22.57 | vmaster | but performance aint that good, using libftdi as well as ftd2xx |
| 15:23.20 | ka6sox | so it maybe ftd2xx that is the issue |
| 15:23.32 | ep1220 | on my system there were differences between what libusb detected and what usbview showed |
| 15:23.34 | *** join/#openjtag Tiersten (i=tman@nslu2-linux/Tiersten) |
| 15:24.00 | ep1220 | at that time libusb had anounces anew version soon, so i did not investigate |
| 15:24.18 | vmaster | with your own driver: do you use multi-threading? |
| 15:24.23 | ep1220 | vmaster: were do You see the performance probs |
| 15:24.27 | ep1220 | vmaster: no |
| 15:25.30 | vmaster | on ftd2xx (at least with the current version on a vanilla 2.6.13 kernel) there's a deadlock - FT_Read wont return, even though the data was received by the OS |
| 15:25.59 | vmaster | ftdi support suggested to use FT_GetQueueStatus and a sleep, to wait until the data is there |
| 15:26.03 | vmaster | that's a nightmare for latency |
| 15:26.38 | vmaster | with libftdi, i had problem when writing too much data |
| 15:27.09 | vmaster | so i had to limit the amount of data, giving reduced throughput, as the latency is ~10ms |
| 15:27.27 | vmaster | ftd2xx solves this by using multi-threading |
| 15:27.43 | vmaster | they have one thread continously reading from Bulk-In |
| 15:28.33 | ep1220 | i guess one has to be carefull when sending lots of data |
| 15:28.56 | ep1220 | the chip writes out data slower than the it can receive data from USB |
| 15:28.59 | vmaster | mhh, i guess it's rather about reading the data soon enough |
| 15:29.18 | vmaster | which is why libftdi fails, but ftd2xx not |
| 15:29.46 | vmaster | ftd2xx initiates writes of 4096 byte, but libftdi would fail when i wrote ~700 byte |
| 15:30.05 | vmaster | the only difference is that ftd2xx has concurrent reads |
| 15:30.21 | vmaster | unfortunately, libusb is synchronous, so you have to use another thread for reading |
| 15:30.36 | vmaster | and if you're not carefull enough with that, you get the deadlocks i'm experiencing with ftd2xx |
| 15:30.48 | lennert | forcing people to use blocking i/o is one of the things i hate |
| 15:32.09 | vmaster | i asked ftdi about some low-level information about the chip, but that was friday afternoon, and i guess they've already left for the weekend |
| 15:36.22 | ep1220 | sorry, the family calls .. |
| 15:36.55 | ka6sox | bye! |
| 15:36.58 | ka6sox | have fun. |
| 15:37.06 | vmaster | cya |
| 16:56.17 | lennert | is there an easy way to find out whether an input pin is unconnected? check whether it's randomly oscillating? |
| 16:59.04 | vmaster | mhh, wouldn't it be technology dependant? |
| 17:00.31 | lennert | yup |
| 17:00.56 | lennert | do non-cmos fpga's exist? |
| 17:01.31 | vmaster | heh, probably not |
| 17:04.45 | lennert | what's your opinion on openwince jtag stuff? |
| 17:05.10 | ka6sox | lennert, yes they do...but they are VERY expensive |
| 17:06.07 | lennert | ka6sox: what's the point.. higher switching speed? |
| 17:06.13 | ka6sox | yes. |
| 17:06.17 | ka6sox | very fast parts. |
| 17:06.27 | lennert | high power consumption |
| 17:06.30 | ka6sox | GHZ+ parts and RAD hard. |
| 17:06.31 | lennert | low gate counts |
| 17:06.36 | lennert | wow, ghz+ |
| 17:07.16 | lennert | great for implementing a fast arm core :P |
| 17:08.26 | ka6sox | the ARM police might be out.... |
| 17:08.30 | lennert | hehe |
| 17:09.37 | lennert | i wouldn't exactly call them police |
| 17:09.58 | lennert | police are supposed to fight for the good cause |
| 17:10.43 | ka6sox | yes indeed |
| 17:11.26 | vmaster | openwince jtag seems to be written for a limited purpose |
| 17:13.04 | ka6sox | parallel wigglers on windows? |
| 17:13.23 | vmaster | uhm, windows and linux, but that's about it |
| 17:13.57 | ka6sox | that is what was cheap. |
| 17:13.57 | vmaster | it just wont scale to anything else but low-performance boundary-scan flash writing |
| 17:16.42 | lennert | okay |
| 17:16.49 | lennert | so it's better not to bother with it? |
| 17:17.04 | vmaster | mhh, what do you want to achieve? |
| 17:17.19 | lennert | one package that can do everything! :) |
| 17:17.36 | vmaster | heh, i may be biased, but i wouldn't bother with openwince then |
| 17:19.02 | ka6sox | I wouldn't bother with it..there are better starting places.... |
| 17:19.33 | ka6sox | black(something) looks better to me (another opensource jtag thingo) |
| 17:19.37 | ka6sox | (software) |
| 17:20.12 | lennert | i kind of have in my head what i want things to look like |
| 17:20.35 | lennert | but if we start from scratch, there'll be Yet Another jtag tool out there |
| 17:20.38 | lennert | and we already have too many |
| 17:22.19 | ka6sox | look for black(something) on freshmeat |
| 17:25.16 | vmaster | hmm... freshmeat only gives 6 hits on 'jtag', and nothing with black in it |
| 17:25.41 | ka6sox | jelie is interesting (as we are playing with Xscale devices) |
| 17:27.22 | lennert | jelie? |
| 17:27.36 | vmaster | jelie.org |
| 17:27.40 | vmaster | a pxa250 debugger |
| 17:27.43 | lennert | oh |
| 17:28.41 | lennert | Manuel de l'utilisateur (seulement en français) |
| 17:28.44 | lennert | that's nice |
| 18:32.17 | *** part/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 18:32.30 | *** join/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 19:49.01 | [g2] | so are you guys following the cell phone hacking at all ? |
| 19:59.05 | *** join/#openjtag bullet (n=bullet@137.56.203.62.cust.bluewin.ch) |
| 20:53.47 | lennert | [g2]: nope |
| 20:56.37 | ka6sox | that is a BIG usage I hear of jtag...reprogramming the phones. |
| 21:53.34 | *** part/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 21:59.44 | dyoung-away | lennert, vmaster, can you remind me what the file is that may need twiddling for the Xserver to work with the webpack ? |
| 22:01.57 | ka6sox | time for me to setup s3projects.org? |
| 22:03.32 | dyoung-away | http://fjtag.sourceforge.net/ mght be of interest too |
| 22:07.50 | ka6sox | back in 30 minutes |
| 23:14.45 | ka6sox | dyoung-away: if I setup s3projects.org will you please help populate it? |
| 23:15.33 | ka6sox | (since I think its time for it to be setup :) |
| 23:39.56 | lennert | ka6sox: okay |
| 23:40.02 | lennert | ka6sox: i will help populate it |
| 23:40.09 | lennert | ka6sox: i have a subversion tree with vhdl crap |
| 23:40.18 | lennert | dyoung-away: libXm.so.something and libcurl.so.2.0.2 |
| 23:40.45 | dyoung-away | lennert, I have those; the WindU thingo wasnt starting |
| 23:41.09 | dyoung-away | I eventually found the right config file to hack out "nolisten" from |
| 23:42.12 | lennert | dyoung-away: /etc/X11/somewhere |
| 23:42.44 | dyoung-away | it was /etc/kde3/kdm/kdmrc |
| 23:43.40 | lennert | ah |
| 23:43.44 | lennert | depends on which dm you use |
| 23:43.47 | lennert | i tend to use gdm |