| 00:10.13 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 03:46.06 | *** join/#openjtag vmaster_ (i=vmaster@p549B5B61.dip.t-dialin.net) |
| 04:10.08 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 05:02.32 | *** part/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 05:29.11 | *** join/#openjtag ep1220 (n=NN@gate.epatec.at) |
| 05:34.23 | *** join/#openjtag samms71-away (i=samms71@c-24-21-115-96.hsd1.wa.comcast.net) |
| 05:34.59 | samms71-away | \name |
| 05:36.02 | *** part/#openjtag samms71-away (i=samms71@c-24-21-115-96.hsd1.wa.comcast.net) |
| 06:41.21 | *** join/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 09:09.16 | *** part/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 10:13.35 | *** join/#openjtag vmaster (i=vmaster@p549B722D.dip.t-dialin.net) |
| 11:46.33 | *** join/#openjtag [g2] (n=g2@nslu2-linux/g2) |
| 12:08.25 | *** join/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 12:49.18 | *** join/#openjtag prpplague (n=billybob@72.22.136.211) |
| 14:08.35 | *** join/#openjtag bullet (n=bullet@89.212.203.62.cust.bluewin.ch) |
| 16:08.55 | vmaster | A first version (untested, only simulated until now) of a new parallelport JTAG interface can be found at http://mmd.ath.cx/epp_jtag/ - its using only epp access and transmits up to 8-bit per parallel port io, which should give considerably higher scan speeds compared to wiggler devices. The design is for Amontec's Chameleon POD (Xilinx Coolrunner xcr3128xl-vq100), but I believe it could be ported to other CPLDs quite easily. Any comments ar |
| 16:49.46 | *** join/#openjtag ByronT (i=ByronT@nslu2-linux/ByronT) |
| 17:21.03 | [g2] | vmaster so that parallel port interface allows a BYTE to be driven at a time correct ? |
| 17:22.04 | [g2] | and how fast does epp mode run ? 1Mb ? |
| 17:22.57 | vmaster | one port i/o takes about 2us, so you could go up to 4mhz tck if all you did was shift data out |
| 17:23.41 | vmaster | if you want to read, too, you have an additional access, giving you about 2mhz |
| 17:23.57 | vmaster | this should be considerably faster than raven for example |
| 17:34.27 | *** join/#openjtag beewoolie-afk (n=beewooli@florence.buici.com) |
| 17:35.19 | prpplague | das bee in the house |
| 17:35.22 | [g2] | vmaster so this is a parallel port plus CPLD ? |
| 17:35.45 | *** part/#openjtag ka6sox-office (n=tking@nslu2-linux/ka6sox) |
| 17:35.59 | [g2] | Last I checked the Amontec was Chameleon was like $200 |
| 17:37.25 | vmaster | [g2]: yeah, parallel port + cpld |
| 17:38.36 | prpplague | hmm is there linux support for chameleon? |
| 17:39.07 | vmaster | mhh, the arm debug value pack is 169 euros, the chameleon alone is 129 |
| 17:39.52 | vmaster | prpplague: the configuration tool is windows only, but my software (linux) is able to program it |
| 17:40.44 | prpplague | vmaster: interesting |
| 17:41.00 | prpplague | vmaster: be nice to have a config to work with smartmedia/xD |
| 17:41.01 | vmaster | i guess you could build a cpld based parallel port interface for a lot less than 129 though ;) |
| 17:41.36 | vmaster | ieee1284 transceiver + cpld + crystal, and the usual stuff an ee would have to care about |
| 17:42.14 | beewoolie | vmaster: I've heard you're making progress on the JTAG design. Thanks. |
| 17:42.45 | beewoolie | What is the interface to the host that you're planning? |
| 17:43.56 | vmaster | actually i'm thinking about several devices - the parport/cpld design, a ft2232c based solution, and ultimately something using a fpga |
| 17:44.25 | beewoolie | Oh. Perhaps I got you mixed up with someone else. I thought this was the sparton design you were working on. |
| 17:45.04 | beewoolie | I thought that the ft2232c stuff was already working, though there is little in the way of software. |
| 17:45.42 | beewoolie | I've been gunning for an ethernet interface just so we'd be able to get reasonable throughput. |
| 17:46.22 | vmaster | latency is more an issue than throughput, as long as you're not offloading everything to the target |
| 17:47.09 | vmaster | the ft2232c stuff works, i've been using it to debug arm7 and arm9 targets |
| 17:48.31 | beewoolie | The throughput is an issue if we're transferring large quantities of data, e.g. flash programming 16MiB. |
| 17:48.58 | beewoolie | Are you using the digex (IIRC) dev board? |
| 17:49.12 | vmaster | nope |
| 17:49.26 | vmaster | what's that` |
| 17:49.27 | vmaster | ? |
| 17:50.06 | beewoolie | There is a board, and I think it starts with the letter d (as in I'm such a dork for forgetting the name) that has the ft2232 chip and a 40 pin DIP header. |
| 17:50.30 | beewoolie | It's been my plan to buy one so I could mess with that device. |
| 17:50.52 | vmaster | dlp2232m |
| 17:50.57 | beewoolie | That's the one. |
| 17:51.00 | beewoolie | :-) |
| 17:51.45 | vmaster | so - yes, i'm using that one, on the prototype i have |
| 17:54.23 | beewoolie | I've never thought we had to offload to the JTAG emulator to get good performance, but speed has been a significant concern with the ft chip. |
| 17:54.56 | beewoolie | IIRC, we cannot get more than about 5MHz out of it with the back-and-forth between USB and the JTAG port. |
| 17:55.25 | vmaster | the device itself only supports up to 6mhz, but you wont get that much out of it |
| 17:55.46 | vmaster | well, probably, but only if all you do is shifting data out |
| 17:55.56 | beewoolie | What have you observed? Say, in programming a file to flash? |
| 17:56.13 | vmaster | on an arm920t i could write to target ram at 25kb/s |
| 17:56.16 | beewoolie | Oh, right. The clock speed is all about the shift register. . |
| 17:56.48 | beewoolie | Are you using the block write feature? Or the single byte writing? |
| 17:57.01 | beewoolie | Oh, wait. |
| 17:57.05 | vmaster | ram, not flash |
| 17:57.06 | beewoolie | I see you are talking about ram. |
| 17:57.22 | vmaster | but once you have the data in ram, flashing it is easy |
| 17:57.23 | beewoolie | Interesting. I'll run a test with my BDI to see what it can do. |
| 17:57.32 | vmaster | about 100kb/s |
| 17:57.37 | vmaster | maybe a bit more |
| 17:57.41 | beewoolie | Certainly, but we don't always want to write to ram to write flash. |
| 17:57.53 | vmaster | sure, only if you want to do it fast |
| 17:57.54 | beewoolie | Ram init is sometimes, well, undesirale. |
| 17:58.15 | beewoolie | Well, the BDI writes to flash about as fast as my in-memory code. |
| 17:58.22 | vmaster | yeah, it's using ram |
| 17:58.36 | vmaster | if you turn off that feature speed drop significantly |
| 17:58.41 | vmaster | *s |
| 17:58.46 | beewoolie | Only as a buffer, I thought. I was under the impression that it used the block write feature because it only uses 16 bytes of ram. |
| 17:59.23 | beewoolie | On my targets, there is SRAM available for ths. |
| 17:59.26 | beewoolie | s/ths/this/ |
| 18:00.47 | vmaster | on arm7/arm9 targets, the buffer is 1kb |
| 18:00.58 | vmaster | + the flash algorithm |
| 18:01.39 | vmaster | without using ram, it achieves about 2kb/s |
| 18:02.03 | beewoolie | Not even worth using. :-) |
| 18:02.05 | vmaster | using the ft2232, i achieved around 1kb/s |
| 18:02.34 | vmaster | all of this is _with_ debug support for the particular core |
| 18:02.51 | beewoolie | So, one of the advantages of RAM is that you can load 32 bits at a time, right? |
| 18:03.05 | beewoolie | Does debug support mean the debug core? |
| 18:03.09 | vmaster | yes |
| 18:03.53 | beewoolie | (um, to which question?) |
| 18:03.59 | vmaster | openwince jtag tools use "dumb" boundary-scanning around all package pins - that increases the number of jtag cycles by a factor of 10 or more |
| 18:04.17 | beewoolie | AHA! I knew there was something wacky going on. |
| 18:04.26 | vmaster | [20:03] < beewoolie> Does debug support mean the debug core? <- yes |
| 18:04.39 | vmaster | 20:02] < beewoolie> So, one of the advantages of RAM is that you can load 32 bits at a time, right? <- uhm, no |
| 18:04.40 | beewoolie | So, you are talking directly to the debug core to improve throughput. Nice. |
| 18:05.03 | beewoolie | Really? I would think you'd be able to shift in a word at a time to the core and dump it into memory. |
| 18:05.04 | vmaster | and the advantage of using RAM is to have the processor handle the flashing itself |
| 18:05.25 | beewoolie | Right. I get that part. My block flashing code is way faster than the byte flashing. |
| 18:13.23 | *** join/#openjtag ElkMcnq (n=luc@84.5.118.19) |
| 18:13.27 | [g2] | vmaster my understanding is the IXP4xx can be driven at 10Mhz |
| 18:14.05 | vmaster | 10MHz TCK rate? probably... |
| 18:14.11 | [g2] | right |
| 18:14.20 | vmaster | newer ARMs can be driven at up to 40mhz |
| 18:14.58 | vmaster | but you'd have a hard time getting bits out that fast, and more importantly back in again |
| 18:15.11 | [g2] | I don't think so |
| 18:16.48 | vmaster | uhm, yeah, of course it all depends on your system design |
| 18:17.32 | vmaster | and what you want to do |
| 20:07.23 | *** join/#openjtag ByronT (i=ByronT@nslu2-linux/ByronT) |
| 20:21.45 | *** join/#openjtag ByronT (i=ByronT@nslu2-linux/ByronT) |
| 22:25.38 | *** join/#openjtag ByronT_ (i=ByronT@nslu2-linux/ByronT) |
| 22:29.47 | *** join/#openjtag bullet (n=bullet@adsl-84-227-223-79.adslplus.ch) |
| 22:38.24 | *** part/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 22:43.55 | *** join/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 23:22.23 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 23:29.52 | *** join/#openjtag lennert (n=buytenh@alephnull.demon.nl) [NETSPLIT VICTIM] |