| 01:09.48 | *** join/#openjtag _AchiestDragon (n=dave@whipy.demon.co.uk) |
| 01:11.58 | *** join/#openjtag ByronT_ (i=byron-po@nslu2-linux/ByronT) |
| 01:14.27 | *** join/#openjtag _AchiestDragon (n=dave@whipy.demon.co.uk) [NETSPLIT VICTIM] |
| 01:14.28 | *** join/#openjtag AchiestDragon (n=dave@whipy.demon.co.uk) |
| 01:14.28 | *** join/#openjtag wookey_ (n=wookey@217.147.92.89) [NETSPLIT VICTIM] |
| 01:14.28 | *** join/#openjtag DaKa (n=david@nslu2-linux/daka) [NETSPLIT VICTIM] |
| 01:14.37 | *** join/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) [NETSPLIT VICTIM] |
| 01:14.37 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) [NETSPLIT VICTIM] |
| 01:54.20 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 04:25.00 | *** join/#openjtag beewoolie-afk (n=beewooli@206.124.142.26) |
| 04:25.36 | beewoolie-afk | ka6sox-office: I have some sad news |
| 04:26.22 | beewoolie-afk | You all might get this in the log. |
| 04:26.38 | beewoolie-afk | I've gotten my JTAG application working to the point that it is useful for flashing. |
| 04:27.04 | beewoolie-afk | It's still got a few bugs, but that won't stop me from releasing a first version. |
| 04:27.17 | beewoolie-afk | The sad news is that the FTDI performs far below expectations. |
| 04:28.03 | beewoolie-afk | I still need to implement the generic boundary-scan code so that I can test flash programming via the scan chain. |
| 04:28.49 | beewoolie-afk | using the ARM core, I'm getting about 15.6 ms/byte. And that's without checking the result of the programming operation. |
| 04:29.12 | beewoolie-afk | If I add the check for the programming result, it's about 18.6 ms/byte. |
| 04:30.39 | beewoolie-afk | What's killing this is the latency of the USB bus. A buffered write requires four transactions of the embeddedice core: program, count, data load, data write, confirm. |
| 04:30.59 | beewoolie-afk | The data load shouldn't be a problem since we don't have to synchronize the core with the memory system. |
| 04:31.04 | beewoolie-afk | Still, it's not very efficient. |
| 04:31.26 | beewoolie-afk | The reason this is so sad is that the Xlinix cable stomps it all over the place. |
| 04:32.31 | ka6sox-office | ouch! |
| 04:33.18 | ka6sox-office | this doesn't sound good at all! |
| 04:35.21 | beewoolie-afk | It handles the same algorithm to the tune of 56K in 31s. About 571us/byte. |
| 04:35.36 | ka6sox-office | yikes. |
| 04:38.54 | beewoolie-afk | Part of this comes from the fact that the FTDI protocol is sub optimal, but I don't think that that is the real cost. |
| 04:39.07 | beewoolie-afk | I believe that the latency of the USB interface is the worst of it. |
| 04:39.08 | ka6sox-office | usb framing and latency? |
| 05:16.35 | beewoolie-afk | I don't have any visibility into the real cause. |
| 05:16.44 | beewoolie-afk | I've read over some of the USB programming docs. |
| 05:17.01 | beewoolie-afk | It has a distinctly ATM feel. |
| 05:17.09 | ka6sox-office | ah... |
| 05:17.20 | beewoolie-afk | I've found that there are oddities in the way that packets are accepted on the other end. |
| 05:17.39 | beewoolie-afk | Specifically, I was sending 64 byte chunks, but found that this broke the FTDI protocol. |
| 05:17.51 | beewoolie-afk | I had to do back to sending everything and letting the kernel do the blocking. |
| 05:17.54 | ka6sox-office | everything I've read about USB indicates that short packets are killer. |
| 05:24.05 | beewoolie-afk | the largest packet on this device is 64 bytes. |
| 05:24.46 | ka6sox-office | ewwww. |
| 05:24.50 | ka6sox-office | ugly |
| 05:33.13 | beewoolie-afk | I think that that is a limitation of the USB protocol and not really the fault of the device. |
| 05:33.28 | beewoolie-afk | On one device I've looked at, the largest packet is 128 bytes. |
| 05:33.46 | ka6sox-office | overhead is killer on packets that short |
| 06:44.53 | NAiLzZz | lennert: I can try getting network to work, so you can take a look at it. |
| 06:48.33 | NAiL | hmm |
| 06:48.38 | NAiL | I'd like to see you do that |
| 06:48.55 | NAiL | considering it is impossible right now |
| 06:49.16 | dyoung-away | If it aint got no net, I would have to use my telepathic powers to intercept your EM Waves. |
| 06:49.37 | dyoung-away | Or if its not plugged in to power, I would have to.. uh.... |
| 06:49.39 | dyoung-away | hmm |
| 06:49.46 | dyoung-away | cant th ink of a good one, sorry. youre safe. :-) |
| 06:49.51 | NAiL | Well, I powered it up now |
| 06:50.21 | NAiL | but you'd have to get through the wrt54gs, then my slug, onto my laptop and use minicom as 00t |
| 06:50.59 | dyoung-away | So Hardcore. :-) |
| 07:02.57 | NAiL | of course, you'd have to figure out my IP too :-P |
| 07:33.39 | NAiL | argh |
| 07:33.45 | NAiL | I can't get ixp networking up though |
| 07:34.27 | NAiL | http://pastebin.com/566346 |
| 10:10.00 | *** join/#openjtag bullet (n=bullet@138.28.78.83.cust.bluewin.ch) |
| 10:36.46 | lennert | NAiL: okay |
| 10:37.34 | lennert | NAiL: looks odd, is that on the ds101? |
| 10:37.43 | NAiL | yeah |
| 10:39.20 | NAiL | Dunno what makes it not work on the ds101, since it works on the lude and slug. |
| 10:39.30 | NAiL | It's got the same PHY as the lude |
| 10:41.15 | NAiL | I guess I could connect the DS101 with USB to my gateway-slug when I get home |
| 10:41.35 | NAiL | That way you could atleast get a terminal through minicom |
| 10:43.30 | lennert | would you have gcc and stuff though for testing? |
| 10:44.16 | NAiL | Hmm, not yet. I could zmodem necessary packages over though |
| 10:44.25 | lennert | right, okay |
| 10:44.34 | lennert | i'll be on the way to work in some 10 minutes |
| 10:44.36 | lennert | let me know |
| 10:44.54 | NAiL | I won't be home for a few hours, so I won't be able to do it quite yet |
| 10:45.01 | NAiL | I'll tell you when I get something working |
| 10:46.52 | lennert | great, thanks |
| 12:52.29 | *** join/#openjtag prpplague (n=billybob@72.22.131.136) |
| 14:40.46 | *** join/#openjtag toi (n=pleemans@d5152D12D.access.telenet.be) |
| 14:51.52 | *** join/#openjtag vmaster_ (i=vmaster@p549B74B5.dip.t-dialin.net) |
| 15:29.15 | *** join/#openjtag bullet_ (n=bullet@138.28.78.83.cust.bluewin.ch) |
| 15:38.13 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 15:39.48 | *** join/#openjtag toi (n=pleemans@d5152D12D.access.telenet.be) |
| 16:24.34 | *** join/#openjtag z3ro (n=z3ro@60-234-138-172.bitstream.orcon.net.nz) |
| 16:24.49 | [g2] | z3ro hey |
| 16:24.53 | [g2] | lennert ping |
| 16:24.55 | lennert | pong |
| 16:24.58 | z3ro | hi |
| 16:25.14 | [g2] | z3ro has a question about he xilinx files |
| 16:25.18 | lennert | oh |
| 16:25.22 | lennert | i was just about to run |
| 16:25.26 | lennert | but maybe a quick question? :) |
| 16:25.29 | [g2] | oh cool |
| 16:25.49 | z3ro | lennert: [g2] told me you may know information about xilinx formats... I'm aiming to replace all of the xilinx fpga toolchain with free software alternatives (licensed under the gpl) |
| 16:26.03 | lennert | cool |
| 16:26.06 | z3ro | lennert: so any information about their proprietary formats is a huge help. :) |
| 16:26.14 | lennert | how far are you so far? |
| 16:26.18 | z3ro | lennert: see z3ro.geek.nz/fpga.html for what I've done so far. |
| 16:26.29 | lennert | probably easiest is to generate an xdl file |
| 16:26.35 | lennert | convert that to ncd, and then make a bit file out of that |
| 16:26.46 | lennert | xdl is a text format that describes the fpga routing and config |
| 16:26.57 | z3ro | lennert: format wise, I've started on the xilinx-xdb formats (.ngd, etc) |
| 16:27.00 | lennert | (while you do the synthesizer/optimiser part) |
| 16:27.03 | lennert | okay |
| 16:27.12 | lennert | the hard part is getting a good synthesizer/mapper/router implemented |
| 16:27.25 | [g2] | that is a hard problem |
| 16:27.37 | [g2] | like writing a good compiler |
| 16:27.40 | lennert | my aims were kind of different, i wanted a .bit file reverse engineering tool |
| 16:27.42 | lennert | [g2]: indeed |
| 16:27.46 | z3ro | my aim so far, it to replace bitgen (takes ngd in -> .bit out) |
| 16:27.49 | lennert | [g2]: it's the hardest part of the stack |
| 16:27.53 | z3ro | lennert: *.bit is easy. |
| 16:27.56 | z3ro | lennert: it's documented. |
| 16:28.03 | lennert | is .bit documented, really? |
| 16:28.04 | lennert | where? |
| 16:28.12 | lennert | .bit is what i've been working on so far |
| 16:28.13 | z3ro | lennert: one second, let me get the xapp numbers. |
| 16:28.32 | z3ro | xapp452 for spartan3. |
| 16:28.48 | z3ro | xapp151 for virtex series. |
| 16:28.51 | lennert | xapp452 doesn't even describe 5% of the .bit format |
| 16:28.57 | lennert | not even 1%, i'd say |
| 16:29.08 | z3ro | well, it does describe a lot about the packet format, etc. |
| 16:29.21 | z3ro | but maybe not what each bit written to the addresses does. |
| 16:29.22 | ka6sox | z3ro I'd sure rather use gnu tools. |
| 16:29.37 | lennert | it describes the frame size and count, and what each frame is for, but not the individual bits |
| 16:30.16 | z3ro | lennert: right. not what the data that's written into the fpga does (only a little information about what each address configures) |
| 16:30.21 | lennert | yeah |
| 16:30.42 | lennert | i'll have a look at your page when i get home |
| 16:30.43 | lennert | thanks :) |
| 16:30.47 | z3ro | lennert: it's enough to make jtag programming tools from, anyway... |
| 16:30.51 | z3ro | the xapp, that is. |
| 16:30.58 | lennert | yeah |
| 16:31.20 | z3ro | I'm currently working on a tool to dump as much information as possible from the *.bit file, to hopefully make some kind of "view" of the fpga. |
| 16:31.28 | z3ro | eg, what each BRAM bit is set to, etc. |
| 16:31.52 | z3ro | the configuration of each IOB, and later CLB's, etc. |
| 16:31.58 | [g2] | z3ro can't you just scan the device and identify it ? |
| 16:32.04 | lennert | i can help you with that, i have a lot of reverse engineered bit locations |
| 16:32.19 | lennert | only for the spartan3 though |
| 16:32.26 | lennert | xc3s50, xc3s200, tec. |
| 16:32.27 | z3ro | lennert: oh, good... if you have written anything up I'd like to read it. :) |
| 16:32.29 | lennert | but the iobs are similar |
| 16:32.31 | lennert | sure |
| 16:32.39 | lennert | i'll try to write some stuff down when i get home |
| 16:32.39 | z3ro | lennert: and I only have s3 devices, so that's no problem. |
| 16:32.44 | lennert | in 1.5 hours or so |
| 16:32.46 | z3ro | lennert: okay, thanks. :) |
| 16:33.14 | lennert | np! |
| 16:33.14 | z3ro | [g2]: nope, the only way to readback from the fpga is in the bitstream "frame" format. it's not like a raw format. |
| 16:33.34 | z3ro | [g2]: not like an array of bits=all the bram blocks, etc... |
| 16:33.58 | z3ro | the data *is* in the *.bit file, just not in a really simple format. |
| 16:34.34 | z3ro | it's a set of writes to addresses (col,major,minor addresses) each address configures part of the fpga. |
| 16:35.00 | z3ro | eg: col 0, major 0, minor 0 might configure bram 0 (it doesn't, that's just an example) |
| 16:35.53 | z3ro | but this is all really undocumented. the *.bit frame format is well documented, the raw data that is actually used to configure the fpga isn't. |
| 16:37.08 | [g2] | z3ro I meant to just identify the type of device you had |
| 16:37.36 | z3ro | [g2]: oh, that's easy; just read the IDCODE register. |
| 16:37.41 | [g2] | right |
| 16:38.08 | [g2] | you are talking about pulling out the internal programming |
| 16:39.05 | z3ro | yes. in order to get a view (textual/graphical) of the configuration of the fpga, mostly for a debugging tool for when I somehow write mapper/placer/router tools. :p |
| 16:43.35 | z3ro | but, this will be more of a side project. the main project is to get the .ngd file format so that I can replace bitgen (takes .ngd in (netlist) and writes a .bit file) |
| 16:44.00 | z3ro | the viewer will become more of a priority when doing the p&r tools, because I'll need some debugging tool. |
| 17:36.39 | *** join/#openjtag ByronT (i=byron-po@nslu2-linux/ByronT) |
| 17:59.07 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 18:05.45 | velinp | ~seen lennert |
| 18:06.22 | purl | lennert is currently on #openjtag. Has said a total of 81 messages. Is idling for 1h 33m 8s, last said: 'np!'. |
| 18:06.23 | NAiL | 17:32 * lennert runs |
| 18:06.23 | NAiL | and it's now 19:05 |
| 18:06.58 | velinp | NAiL: lennrt too busy or coming soon ? |
| 18:07.18 | NAiL | He left somewhere, dunno when he'll be back |
| 18:07.31 | velinp | k; thanks |
| 18:07.39 | NAiL | np |
| 19:01.26 | z3ro | lennert: just so you know, I'm going to sleep soon (8am here, I sleep during the day.) feel free to /query me if you want to leave any messages. I should be back in ~10 hours (maybe a few hours more/less) |
| 19:25.09 | *** join/#openjtag purl (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 19:25.09 | *** topic/#openjtag is This is the place to discuss development of Open JTAG tools and Bootloaders - http://www.openjtag.net/ |
| 20:47.55 | *** part/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 21:30.24 | lennert | z3ro: okay |
| 21:30.42 | lennert | z3ro: i think the most interesting proof-of-concept tool would be a .bit to .xdl 'decompiler' |
| 21:34.41 | vmaster | heh, just don't forget that everything that comes out of a xilinx tool is owned by xilinx, including your bitstream :) |
| 21:35.09 | vmaster | we're just lucky they're kind enough to let you use it with their silicon |
| 21:38.49 | lennert | vmaster: all your ass are belong to xilinx? :) |
| 21:41.48 | vmaster | that, and everything else their legal dpt. could think about |
| 21:42.56 | lennert | not my gumdrop buttons :~( |
| 21:47.30 | lennert | would set a nice precedent, though, if xilinx were to claim that all your ip are belong to them |
| 21:47.38 | lennert | would be good publicity for altera and co |
| 21:47.57 | lennert | maybe altera can sponsor someone to finish reverse engineering the xilinx bitstream format :P |
| 22:29.42 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 23:30.48 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 23:42.04 | *** join/#openjtag ByronT-Away (i=byron-po@nslu2-linux/ByronT) |