| 00:40.47 | beewoolie-afk | Argh. It seems that the FTDI protocol has some annoying inefficiencies. |
| 03:29.55 | [g2] | hey beewoolie-afk |
| 03:30.05 | beewoolie-afk | [g2]: hey |
| 03:30.16 | beewoolie-afk | What's new? |
| 03:30.26 | [g2] | oh lots of stuff |
| 03:31.03 | [g2] | I got a pointer to setting up dnsmasq for multiple LANs today |
| 03:31.17 | beewoolie-afk | Hey, that's nice. |
| 03:31.30 | [g2] | so now it hands out DHCPs for LAN and WAN for the the wifi |
| 03:31.38 | [g2] | s/WAN/WLAN/ |
| 03:32.21 | beewoolie-afk | Very nice. |
| 03:32.27 | [g2] | I heard openssh is going to support VPNs |
| 03:32.41 | beewoolie-afk | That would be handy, too. |
| 03:32.49 | beewoolie-afk | There is that project called...hamachi? I think |
| 03:33.00 | beewoolie-afk | Is it the same idea? |
| 03:33.04 | [g2] | so I'll just put wep on there and then OpenSSH VPN over the wifi and be done with it |
| 03:33.17 | [g2] | too many open-sourcers! :) |
| 03:33.32 | beewoolie-afk | open-sorcerers |
| 03:33.43 | [g2] | those too! |
| 03:34.54 | [g2] | how the JTAG'ing going ? |
| 03:35.02 | beewoolie-afk | Really well. |
| 03:35.13 | beewoolie-afk | I've recoded everything to use ATP. |
| 03:35.14 | [g2] | that doesn't surprise me |
| 03:35.20 | [g2] | You're working on it :) |
| 03:35.24 | beewoolie-afk | Now, the parallel port driver is just an interpreter for ATP. |
| 03:35.38 | beewoolie-afk | I'm adding support for the FTDI right now. |
| 03:35.41 | [g2] | cool |
| 03:35.43 | beewoolie-afk | It's starting to work. |
| 03:35.58 | [g2] | that's the digilent adapter right ? |
| 03:36.00 | beewoolie-afk | I'll add a driver for the GW hardware as well. |
| 03:36.02 | beewoolie-afk | Right. |
| 03:36.09 | beewoolie-afk | The parallel adapters are both Xilinx compatible. |
| 03:36.22 | beewoolie-afk | The FTDI is the first one I've tackled that has SRST support. |
| 03:36.35 | beewoolie-afk | It is looking really good. |
| 03:36.55 | beewoolie-afk | Once we have hardware that uses ATP, we can simply pass the codes along to the hardware and be done with it. |
| 03:37.00 | [g2] | I'm wondering if I can JTAG my RV042 with the parallel |
| 03:37.19 | beewoolie-afk | There shouldn't be any issues. |
| 03:37.39 | beewoolie-afk | The openwince code should tell you if it is present. |
| 03:40.16 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 03:41.33 | ka6sox | beewoolie-afk, hi there |
| 03:41.36 | beewoolie-afk | ka6sox: hey |
| 03:41.55 | ka6sox | just now getting time to start reading...which areas did you change? |
| 03:42.26 | beewoolie-afk | The frequency setup mainly. |
| 03:42.48 | beewoolie-afk | There are a lot of subtlties to the protocol, so it isn't easy to tell you where to focus. |
| 03:42.59 | ka6sox | did you know that we put a DDS circuit on the board so we have frequency resolution of 2hz |
| 03:43.16 | beewoolie-afk | Yeah. I talked with AchiestDragon about that. |
| 03:43.48 | AchiestDragon | on the hat board not the aztag |
| 03:43.58 | ka6sox | I hope on the AZTAG too! |
| 03:43.59 | ka6sox | :) |
| 03:44.03 | beewoolie-afk | I could optimize that opcode for a 16 bit field, for example a count of 10s of Hz, but AD wasn't willing to let go of the fact that we might go as high as 600MHz |
| 03:44.26 | beewoolie-afk | It was easier to let the opcode be a simple frequency. |
| 03:44.28 | ka6sox | there are issues with going that high. |
| 03:44.40 | beewoolie-afk | well, what is the upper bound? |
| 03:44.49 | ka6sox | like the cable alone is a fifo of 2 samples. |
| 03:45.07 | beewoolie-afk | Interesting way to put it. |
| 03:45.28 | beewoolie-afk | I'd be fine setting the limit lower. |
| 03:45.57 | ka6sox | at this point it would be safe to say: its only software (the old DSP mantra) |
| 03:46.06 | beewoolie-afk | For example, we could make it a count of KHz. The range would be 1KHz to 655MHz. |
| 03:46.06 | AchiestDragon | 300mhz is what i am aiming for |
| 03:46.23 | ka6sox | AchiestDragon, I agree with the 300mhz number |
| 03:46.40 | beewoolie-afk | OK. Then I'm going to scale the opcode back to a 16 bit field. |
| 03:46.55 | beewoolie-afk | It will have a lower bound of 1KHz. |
| 03:47.10 | beewoolie-afk | And I'll reserve a zero value for adaptive clocking, if we ever get there. |
| 03:47.25 | beewoolie-afk | ka6sox: The other issue is whether you are comfortable with the way that the bulk IO works. |
| 03:48.02 | beewoolie-afk | I believe it is better than the encoding used by the FTDI. It is orthogonal and it has a couple of features that are handy. |
| 03:48.14 | ka6sox | lemme look in that area as we need to be able to deal with large quantities of data to sift thru to find patterns. |
| 03:48.24 | ka6sox | k |
| 03:48.30 | beewoolie-afk | There is also the piece about seeking states. |
| 03:48.42 | ka6sox | k |
| 03:48.47 | beewoolie-afk | I've discovered that there is a shortcut that can be taken in the implementation. |
| 03:49.00 | beewoolie-afk | I've done this for the parallel port interpreter. |
| 03:49.33 | beewoolie-afk | Simply put, given a start state and an end state, we can statically determine an optimal path through the FSM in five or fewer steps. |
| 03:49.45 | [g2] | bbiab |
| 03:50.19 | beewoolie-afk | It can be a table lookup where the table entries are a count and a value which is passed to the TMS opcode |
| 03:50.32 | beewoolie-afk | I just want to make sure you're comfortable with the way it works. |
| 03:50.40 | ka6sox | bbiab (dinner is on the table) |
| 03:50.49 | ka6sox | 32bit CRC |
| 03:50.51 | beewoolie-afk | k |
| 03:50.56 | ka6sox | not 16bit...too weak |
| 03:51.07 | ka6sox | we can do it in hardware |
| 03:51.07 | beewoolie-afk | That's what I was thinking, too. |
| 03:51.10 | beewoolie-afk | right. |
| 03:51.14 | beewoolie-afk | I'll change that as well. |
| 04:06.23 | ka6sox | Delay is expressed in units of time in one case and clock cycles in another case...needs to be expressed in clocks I think. |
| 04:06.40 | beewoolie-afk | ka6sox: Dined already? |
| 04:06.44 | ka6sox | yes. |
| 04:06.46 | beewoolie-afk | That is on purpose. |
| 04:07.05 | ka6sox | the FPGA is not good at doing time calcs |
| 04:07.08 | beewoolie-afk | It is better from the perspective of the user to be able to specify different kinds of time. |
| 04:07.20 | beewoolie-afk | Really? |
| 04:07.24 | ka6sox | yes |
| 04:07.29 | beewoolie-afk | Isn't is just a multiple of the clock? |
| 04:08.00 | beewoolie-afk | So, is this about the fact that it isn't good at multiplication? |
| 04:08.02 | ka6sox | it means we have to have a clock reference register (telling it what clock frequency is) |
| 04:08.09 | beewoolie-afk | yeah. |
| 04:08.10 | ka6sox | ya |
| 04:08.28 | beewoolie-afk | Is it the reference register that's a problem, or the multiply? |
| 04:08.35 | ka6sox | multiply |
| 04:08.43 | beewoolie-afk | OK. I'll change it. |
| 04:08.49 | ka6sox | (that building block is a HUGE thing) |
| 04:08.57 | beewoolie-afk | :-) |
| 04:09.15 | ka6sox | adders are good. |
| 04:09.36 | beewoolie-afk | One problem may be the range. |
| 04:09.46 | ka6sox | and it is fairly good at 2^X |
| 04:10.20 | beewoolie-afk | It'll be fine it we allow the delay to be a 32 bit count of clocks. |
| 04:10.28 | beewoolie-afk | Or, something similar. |
| 04:10.41 | beewoolie-afk | I'll have to do some fiddling. |
| 04:10.56 | beewoolie-afk | I'd like to allow for clock frequencies that are very low. |
| 04:11.00 | beewoolie-afk | As low as 1Hz. |
| 04:11.07 | beewoolie-afk | It's handy for certain kinds of testings. |
| 04:11.21 | beewoolie-afk | Are you OK with that? |
| 04:11.38 | ka6sox | okay shift registers could give us resolution down to 1hz |
| 04:11.38 | beewoolie-afk | I'd encode it with a bit. 0 is low-speed range and 1 is high-speed range. |
| 04:11.43 | beewoolie-afk | Yeah. |
| 04:11.56 | ka6sox | the DDS can give us frequencies that are very low. |
| 04:11.59 | beewoolie-afk | Well, 2 Hz is OK as well, but I'd let the protocol encode to 1Hz. |
| 04:12.14 | beewoolie-afk | I don't mean to specify the lowest possible frequency. |
| 04:12.27 | ka6sox | the DDS can go as low as 1hz |
| 04:12.29 | beewoolie-afk | it's more about allowing that the lowest frequency *not* be 100KHz. |
| 04:12.33 | beewoolie-afk | K. |
| 04:13.46 | ka6sox | AchiestDragon, I think that the reference clock should be 40mhz so that I can get 260mhz internal clocking on the FPGA |
| 04:15.16 | AchiestDragon | np , the same xtal osc module should be available in 25 , 40, 50 or 80 mhz maybe more |
| 04:16.08 | AchiestDragon | 33mhz and 66mhz seem to be other values |
| 04:16.16 | [g2] | what mode should my parallel port be in ? |
| 04:16.26 | beewoolie-afk | [g2]: for openwince? |
| 04:16.30 | [g2] | nod |
| 04:16.44 | beewoolie-afk | [g2]: I have been using SPP. I suspect that I could use other modes, but I've not tried. |
| 04:17.20 | [g2] | Ok I've got bi-directional, EPP and ECP |
| 04:17.37 | beewoolie-afk | Hmm. No non-bidirectional mode? |
| 04:17.51 | [g2] | output only ? |
| 04:18.06 | beewoolie-afk | That would be it. |
| 04:18.23 | [g2] | ok THX, I'll try |
| 04:25.38 | AchiestDragon | well been desoldering some components tonight http://www.whipy.demon.co.uk/bits.jpg |
| 04:26.01 | AchiestDragon | been trying an easy way |
| 04:26.55 | ka6sox | beewoolie-afk, one mode I want is a "bulk programmer" mode that looks at the RAM memory on the aztag card and uses that to program a flash memory. |
| 04:27.06 | ka6sox | (the data) |
| 04:27.09 | beewoolie-afk | Can you be more specific? |
| 04:27.22 | beewoolie-afk | Are you talking about having a buffer on the card? |
| 04:27.34 | ka6sox | yes 64MB of RAM |
| 04:27.48 | AchiestDragon | cook for 5 mins at about 200c in toaster overn , remove board , turn it upside down and tap |
| 04:28.01 | beewoolie-afk | Keep in mind that this protocol doesn't have any sort of knowledge of FLASH memory. |
| 04:28.19 | beewoolie-afk | So, in order to do something like that, we need to specify how that memory shall be used. |
| 04:28.43 | beewoolie-afk | So far, all I've tackled is basic JTAG operations. |
| 04:29.13 | beewoolie-afk | Meta-operations such as 'program my flash you heap of junk' haven't come to bear. |
| 04:29.14 | ka6sox | k |
| 04:29.35 | ka6sox | k |
| 04:29.36 | beewoolie-afk | One reason for the version number is that it makes it easy to extend the instruction set. |
| 04:29.46 | beewoolie-afk | I, too, would like a bulk programming mode. |
| 04:30.05 | beewoolie-afk | So far, I haven't *quite* gotten how that can be done uniformly. |
| 04:30.29 | ka6sox | I like the look of the bulk IO stuff...it makes sense (but keep MSB mode) |
| 04:30.29 | AchiestDragon | using the aztag as a serial programmer should be possible ,but data rate and handshaking needs to be soted in the fpga it would need to use apropriate inputs or outputs that are right for the buffer arangment |
| 04:30.31 | beewoolie-afk | Presently, I have code that can take a BSDL file and with a little extra data, it can perform flash write operations. |
| 04:30.39 | ka6sox | bbiaw..I need to get food for the week. |
| 04:30.42 | beewoolie-afk | Right. |
| 04:30.45 | beewoolie-afk | lol |
| 04:31.06 | AchiestDragon | and would probabaly need a connector adaptor cable making for it |
| 04:31.13 | beewoolie-afk | AchiestDragon: That's where I haven't, yet, come to an encoding for the protocol to do that. |
| 04:32.02 | beewoolie-afk | So far, it looks like flash devices are similar in the way that IO is handled, but there seem to be some places where it gets really crazy. |
| 04:32.15 | beewoolie-afk | The jflash utility, for example, has to swizzle the bits to get them in the right places. |
| 04:32.55 | AchiestDragon | you have 4 output lines and 4 input lines to play with , there use for jtag is defined ,but could have a diferent use if needed for other things |
| 04:33.12 | beewoolie-afk | I'm not sure I understand what you are talking about. |
| 04:33.38 | beewoolie-afk | We can do the programming through the TAP, but we don't yet know how to do this in a general way. |
| 04:34.29 | AchiestDragon | ha jtag programming ,, i was thinking of spi or i2c type programming |
| 04:35.56 | beewoolie-afk | Ah. That would be yet another mode. |
| 04:36.01 | beewoolie-afk | We could do that as well. |
| 04:36.09 | AchiestDragon | yes |
| 04:36.09 | beewoolie-afk | Clearly. |
| 04:38.14 | AchiestDragon | the hat (with yet another adaptor ) could support parallel boot mode programming of a fpga , but not planning on implimenting the adaptor for that |
| 04:41.16 | AchiestDragon | so could be tricked into performing programming of parallel flash boot devices |
| 04:41.45 | beewoolie-afk | I don't think I know what parallel flash boot devices are. |
| 04:42.39 | AchiestDragon | flash rom that is not serial but parallel , 8 or 16 bits wide data |
| 04:44.35 | beewoolie-afk | Ah. That's the kind of flash programming I'm talking about. I *think* that's what ka6sox is interested in doing as well. |
| 04:44.52 | ka6sox | beewoolie-afk, AchiestDragon yes that is what I'm talking about! |
| 04:45.46 | beewoolie-afk | What is this part about 'tricking' it into performing flash programming? |
| 04:46.25 | AchiestDragon | now not shure if the parallel devices are serial programable |
| 04:46.26 | ka6sox | are our chains only 1 device long or are we working on multiple devices? |
| 04:46.43 | beewoolie-afk | ka6sox: The protocol doesn't care about the lengths of the chains. |
| 04:47.10 | ka6sox | AchiestDragon, what you do is manipulate the memory and data pins and program the flash that way. |
| 04:47.14 | beewoolie-afk | I'm only working with one device at the moment, but I'd like to make sure this works with multiple cores. |
| 04:47.26 | beewoolie-afk | ka6sox: That's what I've been doing. |
| 04:47.30 | ka6sox | s/memory/adddress |
| 04:48.07 | beewoolie-afk | ka6sox: I believe we can get better performance from the CPU specific methods when a CPU is present. |
| 04:48.12 | ka6sox | beewoolie-afk, okay so we are looking to implement dummy chains to be able to target a specific device in the chain and ignor the other ones. |
| 04:48.14 | AchiestDragon | st , intel and amd do flash chips the programming modes are discribed in there data sheets |
| 04:48.33 | beewoolie-afk | If we're talking about optimizing the scan-chain method, then we may need to go down another path, as well. |
| 04:48.49 | beewoolie-afk | ka6sox: I don't know what you mean by a dummy chain. |
| 04:49.11 | beewoolie-afk | As far as I can tell, when there is more than one device, we put the uninteresting devices in BYPASS mode. |
| 04:49.21 | beewoolie-afk | That makes their scan chains 1 bit long. |
| 04:49.32 | ka6sox | k |
| 04:49.52 | ka6sox | forgot about that one...been a while since I read the spec. |
| 04:49.56 | beewoolie-afk | BYPASS mode happens to be an instruction of all 1's. |
| 04:50.38 | beewoolie-afk | As for optimizing the boundary-scan chains, we could do as was suggested in defining a virtual scan register. |
| 04:50.44 | beewoolie-afk | I commented on this on the wiki. |
| 04:50.53 | ka6sox | beewoolie-afk, nod |
| 04:51.55 | beewoolie-afk | If we allow the user to define a hold register and then we give him a way to update portions of that register quickly, we can improve the scan time. |
| 04:52.26 | beewoolie-afk | The harder part is letting the FPGA know which signals are used for OE, WE, and whether or not these signals are active low. |
| 04:52.58 | beewoolie-afk | Then, we need to describe the organization of the flash. |
| 04:53.14 | beewoolie-afk | Sometimes we have one 16 bit device. Sometimes we have two 16 bit devices. |
| 04:53.23 | beewoolie-afk | Sometimes we have one thirty-two bit device. |
| 04:53.32 | ka6sox | I know that we have been resisting the temptation to "customize" the fpga |
| 04:53.36 | beewoolie-afk | The programming is different in all of these cases. |
| 04:53.54 | ka6sox | yes |
| 04:53.59 | beewoolie-afk | Yeah. If I could come up with a good way to describe this that is general purpose enough, I'd be all over it. |
| 04:54.14 | beewoolie-afk | So, I'd like to start with something simple that we know will be useful. |
| 04:54.20 | ka6sox | k |
| 04:54.31 | beewoolie-afk | We can enhance later when we have the hardware working. |
| 04:54.42 | ka6sox | we have to do "discovery" first anyways. |
| 04:54.48 | ka6sox | even if we know what is out there. |
| 04:54.48 | beewoolie-afk | Sure. |
| 04:55.00 | beewoolie-afk | That's what my code is doing right now. |
| 04:55.11 | ka6sox | k |
| 04:55.19 | beewoolie-afk | I only tell it how the address and data bus map to the BSDL cells. |
| 04:55.32 | beewoolie-afk | The rest is handled algorithmically. |
| 04:55.49 | ka6sox | we have RAM memory out there that we can use for discription registers. |
| 04:56.55 | AchiestDragon | seams to remeber the flash have a readable divice discription regiser |
| 04:57.05 | beewoolie-afk | AchiestDragon: right. |
| 04:57.19 | beewoolie-afk | But you have to know the organization before you can read it. |
| 04:57.24 | beewoolie-afk | Bit of a catch-22. |
| 04:57.50 | beewoolie-afk | What we do write the ID command in different ways and then probe for the ID data in a known pattern. |
| 04:58.32 | ka6sox | beewoolie-afk, if we are working boards they *have* the covers off..and we can see what devices we have. |
| 04:58.49 | beewoolie-afk | ka6sox: That get you most of the way there. |
| 04:58.58 | ka6sox | so we can then write the organization table |
| 04:58.58 | beewoolie-afk | Here's how I look at it. |
| 04:59.27 | beewoolie-afk | It would be great if we could start with what is easy to identify and let the hw and sw probe for what it does well. |
| 04:59.36 | [g2] | I dunno |
| 04:59.41 | beewoolie-afk | This probing can be done efficiently |
| 05:00.01 | beewoolie-afk | Then, we download something to the FPGA telling it how the flash is organizaed along with the data to program |
| 05:00.02 | [g2] | jtag detects the digilent board but not the XScales |
| 05:00.08 | beewoolie-afk | Then we say GO! |
| 05:00.19 | ka6sox | beewoolie-afk, exactly |
| 05:00.24 | beewoolie-afk | [g2]: I'm able to detect the Xscales with the dilligent |
| 05:00.38 | beewoolie-afk | It isn't the adapter that's the problem. |
| 05:00.50 | [g2] | heh |
| 05:01.02 | beewoolie-afk | ka6sox: The point is that we don't yet have a complete picture of the parameters. |
| 05:01.12 | beewoolie-afk | Or, better put, *I* don't. |
| 05:01.15 | ka6sox | agreed |
| 05:01.21 | ka6sox | *I* don't either |
| 05:01.24 | beewoolie-afk | Once we know how to describe this, the rest is easy. |
| 05:01.28 | beewoolie-afk | Right. |
| 05:01.31 | [g2] | beewoolie-afk do you have a pull-up/down somewhere ? |
| 05:01.41 | ka6sox | but we are planning on making the FPGA re-programmable on the fly. |
| 05:01.55 | beewoolie-afk | and the reason I'm working on this jtag code is so that we can explore the possibilities |
| 05:01.57 | beewoolie-afk | ka6sox: Right! |
| 05:02.07 | beewoolie-afk | I'm counting on it. |
| 05:02.12 | beewoolie-afk | [g2]: Nothing special. |
| 05:02.13 | [g2] | or do you drive nReset or nTSRT |
| 05:02.21 | ka6sox | meaning *if* we know what we are dealing with we can "personalizing" the FPGA to optimize performance. |
| 05:02.26 | beewoolie-afk | [g2]: Neither |
| 05:02.35 | beewoolie-afk | ka6sox: Sure. |
| 05:02.51 | ka6sox | okay so first blush is find out what is there and define the chain and targets. |
| 05:02.53 | beewoolie-afk | Honestly, I think we're going to get the best performance form custom CPU drivers. |
| 05:03.04 | beewoolie-afk | s/form/from/ |
| 05:03.08 | ka6sox | like the i=cache in xscale. |
| 05:03.20 | beewoolie-afk | tee hee |
| 05:03.24 | beewoolie-afk | ka6sox: Exactly. |
| 05:03.40 | beewoolie-afk | It isn't really hard to do once we have the right JTAG hw. |
| 05:03.58 | ka6sox | yep |
| 05:04.10 | beewoolie-afk | [g2]: I've used your cable to detect the XScale without trouble. |
| 05:04.12 | ka6sox | okay I like the changes to the protocol. |
| 05:04.27 | beewoolie-afk | I've done quite a few since we talked. I'll post them later this evening. |
| 05:04.49 | [g2] | beewoolie-afk and you just power-up the device and do "detect" after the "cable" command right ? |
| 05:05.01 | beewoolie-afk | Oh, I don't use openwince at all. |
| 05:05.07 | beewoolie-afk | My code has no problem detecting the device. |
| 05:05.22 | beewoolie-afk | I don't recall whether or not openwince does. |
| 05:05.38 | [g2] | ah |
| 05:05.55 | [g2] | would I be able to try that out sometime ? :) |
| 05:05.58 | beewoolie-afk | ka6sox: I've made the delay this way: (count+1)*2^(8*s) where count is 1-256 and s is 0-3. |
| 05:06.04 | beewoolie-afk | [g2]: RSN. |
| 05:06.15 | ka6sox | beewoolie-afk, re: non-compliant devices, we need to be able to deal with them. *If* the hardware has a known issue then we deal with it. |
| 05:06.29 | ka6sox | beewoolie-afk, nod on DELAY |
| 05:06.31 | beewoolie-afk | ka6sox: That's something that I've been thinking about. |
| 05:06.40 | beewoolie-afk | It really depends on the range of non-compliance. |
| 05:06.46 | ka6sox | true |
| 05:07.09 | beewoolie-afk | For example, the Sharp LH79520 changes the value of TDO on the rising clock instead of the falling clock. |
| 05:07.19 | beewoolie-afk | That makes it 1/2 cycle late on sending out the data. |
| 05:07.39 | beewoolie-afk | The work-around is to not use the external test scan chain. |
| 05:07.59 | beewoolie-afk | Now, we could allow for this sort of craziness, but I'm not sure that we could ever account for all of them. |
| 05:08.08 | beewoolie-afk | After all, a standard is a standard. |
| 05:08.25 | beewoolie-afk | So, I added the transact opcode as a worst case catch-all. |
| 05:08.32 | ka6sox | that particular one we hope is a standalone device on the chain. |
| 05:08.33 | beewoolie-afk | It allows us to do anything we can imagine. |
| 05:08.46 | ka6sox | "its only VHDL" |
| 05:08.56 | ka6sox | we can deal with that kind of craziness. |
| 05:08.59 | beewoolie-afk | Sure. And the LH79520 can be programmed with the ARMv4 embedded ice hardware. |
| 05:09.17 | ka6sox | there you have it. |
| 05:09.18 | beewoolie-afk | The trouble is that TRANSACT isn't very efficient. |
| 05:09.34 | beewoolie-afk | It allows us to do anything, but the penalty is performance. |
| 05:09.53 | beewoolie-afk | IMHO, it is an adequate catch-all. |
| 05:10.11 | beewoolie-afk | We *can* claim that we can work with anything, no matter how broken. |
| 05:10.19 | ka6sox | remember during the "detect" phase we are looking to figure out what we have..*then* download the personality to deal with what we find. |
| 05:10.44 | beewoolie-afk | ka6sox: Please note. This is exactly the reason that I haven't gotten to the point of specifying this custome personality stuff. |
| 05:10.59 | ka6sox | nod |
| 05:11.05 | beewoolie-afk | ka6sox: Sure. But even with the custom personality, it would be good to have a standard protocol interface. |
| 05:11.13 | ka6sox | yes |
| 05:11.14 | beewoolie-afk | In other words, we download a library of functions. |
| 05:11.20 | ka6sox | nod |
| 05:11.29 | beewoolie-afk | :-) |
| 05:11.59 | beewoolie-afk | There is quite a bit of room in the standard opcode space. And we can extend with a version number on the transaction header. |
| 05:12.08 | ka6sox | k |
| 05:14.29 | beewoolie-afk | ka6sox: I updated the wiki for ATP. |
| 05:14.39 | beewoolie-afk | You can use the history feature to see the diff. |
| 05:14.50 | ka6sox | ya |
| 05:16.33 | ka6sox | back to hacking on katie. |
| 05:16.47 | ka6sox | (or at least trying to figure it out) |
| 05:17.16 | AchiestDragon | bed for me , nn |
| 05:17.52 | beewoolie-afk | NN |
| 05:19.33 | ka6sox | beewoolie-afk, nite |
| 05:28.33 | [g2] | nite AchiestDragon |
| 05:29.30 | ka6sox | nite AchiestDragon |
| 05:33.51 | ka6sox | [g2], you on west coast time these days? |
| 06:09.19 | [g2] | ka6sox nah... just a little busy |
| 06:12.37 | beewoolie-afk | ka6sox: I have a Q about the ep1220 board. |
| 06:12.54 | beewoolie-afk | I'm not getting anything on TDO. It's always 3.3V |
| 06:13.50 | beewoolie-afk | Wait, I have another thing to try. |
| 06:18.38 | beewoolie-afk | Never mind. It looks like an FTDI protocol issue. The TDO line responding to the TAP. |
| 06:30.59 | ka6sox | k |
| 07:21.56 | beewoolie-afk | Man o man. Thei FTDI protocol is worse than I thought. |
| 09:15.36 | ka6sox-zzzz | ~seen velinp |
| 09:15.39 | purl | velinp <n=velinp@c88-163.cable.netissat.bg> was last seen on IRC in channel #openjtag, 2d 18m 18s ago, saying: 'good luck with it :) ka6sox was asking about you ~1 hour ago from 'Lost Angles'; bye from me :)'. |
| 11:22.24 | *** join/#openjtag _AchiestDragon (n=dave@whipy.demon.co.uk) |
| 11:40.09 | *** join/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 11:49.56 | AchiestDragon | hot air rework station new 55 euros + 40 euro shiping ebay Item number: 6030752043 new hes got about 90 of them left , but there 230v ones |
| 11:50.02 | AchiestDragon | just ordred one |
| 12:14.16 | *** join/#openjtag prpplague (n=billybob@72.22.149.78) |
| 12:24.34 | dyoung-away | I'm full of hot air; but that doesnt count... |
| 12:30.31 | AchiestDragon | :) |
| 12:32.52 | dyoung-away | AchiestDragon: I met with ka6sox over the weekend and we spoke at length about the designs. |
| 12:32.54 | *** join/#openjtag ByronT-Away (n=byron-po@nslu2-linux/ByronT) |
| 12:33.01 | dyoung-away | there is a lot of excitement about it! |
| 12:33.08 | AchiestDragon | kool |
| 12:33.28 | dyoung-away | (Its partly my fault that SDR got into his brain.....) |
| 12:34.07 | dyoung-away | You keenly noted that we can easily turn it around. that will be pretty cool too. |
| 12:34.16 | AchiestDragon | i should be sending the quote request in for the pcb's for the AzTag on thursday |
| 12:34.33 | dyoung-away | that instantly makes it a multi-purpose device. |
| 12:35.03 | AchiestDragon | have you seen the Hat design im working on atm |
| 12:35.04 | dyoung-away | Thanks for doing all the hard work. |
| 12:35.16 | dyoung-away | Hmm, Not yet. |
| 12:35.32 | AchiestDragon | np , i need the kit in the end anyway |
| 12:36.53 | AchiestDragon | the hat ( HsAzTag ) is a pcmcia cardbus version , with a 32bit LA capabilaty and looking at 300mhz sample rate / jtag clock |
| 12:37.11 | dyoung-away | Aha, is that what its called? |
| 12:37.14 | dyoung-away | yes, I've seen that |
| 12:37.40 | dyoung-away | on that one, is the master DDS Clock going directly to the DDS or through a FPGA/CPLD ? |
| 12:38.38 | AchiestDragon | the clocking options are the dds referance clock and the dds output clock are both avalable to the fpga |
| 12:39.21 | AchiestDragon | the fpga can then multiply the dds clock for the cpld's if needed |
| 12:40.18 | dyoung-away | I was thinking that if we can clock it from a external source to a high stability clock; then we can drive a external high frequency DDS through the L/A ports turned around as outputs. |
| 12:40.33 | dyoung-away | that would make a excellent testing tool for another project I'm working on |
| 12:47.46 | AchiestDragon | :) the hat allows for some extra uses , like the 32bit cpld will opperate in jtag mode , LA mode ( all inputs) and a pio mode ( programable input or output ) |
| 12:48.54 | dyoung-away | Yes, its going to be wonderful |
| 12:49.16 | *** join/#openjtag prpplague^2 (n=billybob@72.22.149.78) |
| 12:50.06 | AchiestDragon | still no compleat but for an idea of the functions look at page 8 and 9 http://www.whipy.demon.co.uk/pcmcia.pdf |
| 12:52.21 | AchiestDragon | the 4 cpld's have 16 bits direct data inputs that allow for direct from / to ram burst mode , ram is 64 bits wide |
| 12:53.35 | AchiestDragon | there is a alternate 4bit to each cpld data path from the fpga also that will allow for use wihout affecting the ram to fpga data path |
| 12:54.17 | AchiestDragon | and each of the cpld's drive 8 bits of the 32bit az port |
| 12:55.09 | AchiestDragon | just working on te fine points of that section at the moment |
| 12:55.14 | dyoung-away | It kind of takes me a while to digest drawings like this. |
| 12:55.25 | dyoung-away | but I think I see the basic function |
| 12:55.41 | dyoung-away | direct to ram is your friend |
| 12:55.52 | AchiestDragon | read the text have tryed to descibe it |
| 13:02.44 | dyoung-away | Yes, thats the only reason I can grasp whats going on. :-) |
| 13:05.25 | AchiestDragon | the big cpld on the pcmcia bus is going to have a jtag port for inital programmingof the unit , the other cpld's and the fpga are programed using the pcmcia bus and that device |
| 13:06.10 | AchiestDragon | so the pcmcia interface cpld is fixed , and every thing else can be user programmed at any time |
| 13:06.32 | dyoung-away | yep, therein lies the infinite flexibility. |
| 13:06.36 | dyoung-away | I really like that. |
| 13:07.54 | lennert | whoops, guess not |
| 13:08.08 | dyoung-away | heh :-) |
| 13:35.43 | *** join/#openjtag bullet (n=bullet@253.56.77.83.cust.bluewin.ch) |
| 14:10.00 | lennert | http://www.cargolaw.com/images/disaster2002.RTG1.GIF |
| 14:10.04 | lennert | that's some K-LINE! |
| 14:48.14 | *** join/#openjtag vmaster (i=vmaster@p549B7D47.dip.t-dialin.net) |
| 17:04.39 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 17:52.15 | *** join/#openjtag ByronT (i=byron-po@nslu2-linux/ByronT) |
| 18:41.08 | ka6sox-office | velinp, ping |
| 18:45.24 | ka6sox-office | do you know why velnas isn't building anything? |
| 18:47.45 | ka6sox-office | (or is it and the buildd.net doesn't know it. |
| 18:50.10 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 19:23.35 | ka6sox-office | morning AD |
| 19:27.11 | velinp | ka6sox, hi; sorry I was too late |
| 19:27.25 | ka6sox-office | np...still here. |
| 19:27.52 | velinp | velnas has some buildd (sbuild) problem; just rebooted it |
| 19:28.43 | velinp | Feb 14 18:00:32 buildd: Assuming all packages unbuilt and adding to REDO: |
| 19:28.56 | velinp | Feb 14 18:00:32 buildd: sbuild now failed 3 times in a row; going to sleep |
| 19:29.20 | ka6sox-office | ah... |
| 19:30.42 | ka6sox-office | I'm making a copy of the chroots for a backup. |
| 19:31.09 | velinp | help? blinkelichten? (http://unstable.buildd.net/index-armeb.html was stuck to 09jan for ~5 days; don't know what's going on; ); |
| 19:33.46 | velinp | I could do that as well, but Yoe is not around, doesn't answer mails ... I think I'll wait next buildd-watcher |
| 19:37.02 | ka6sox-office | k |
| 19:39.10 | velinp | velnas is downloading gcj-... now; if sbuild doesn't abort l then ok; else i give up (and ask Yoe for supprt); fi |
| 19:39.24 | ka6sox-office | yep... |
| 19:39.46 | ka6sox-office | I'm really trying to get my head wrapped around the buildd system. |
| 19:39.48 | ka6sox-office | not easy... |
| 19:40.21 | velinp | no luck; Feb 14 19:43:54 buildd: sbuild now failed 3 times in a row; going to sleep |
| 19:40.43 | ka6sox-office | yep...need Support! |
| 19:40.48 | ka6sox-office | (email yoe) |
| 19:43.19 | velinp | i will; mailied about bob: autogen_1:5.7.3-1 is _obsolete_; 2006-02-14 19:35:22; devel/autogen_1:5.8.3-1: Building by velnas [optional:uncompiled]; no answer (~ a week now) |
| 19:43.48 | velinp | sorry; build was really about 10feb |
| 19:49.10 | ka6sox | ah |
| 19:53.22 | velinp | mailing Yoe; cc you; ok? |
| 19:54.19 | ka6sox | please (as I think I'm seeing the same thing) |
| 19:55.20 | ka6sox-office | I believe that is why Bob is stopped. |
| 19:56.02 | velinp | done; ask ij, dwery? |
| 19:56.27 | ka6sox-office | I'm not sure who...I might as ij tonight |
| 19:56.59 | ka6sox-office | s/as/ask |
| 19:57.18 | velinp | k; maybe it's transient? (wanna-build?) |
| 19:57.50 | velinp | haven't seen aba recently, too |
| 20:15.44 | ka6sox-office | me neither. |
| 20:16.00 | ka6sox-office | not sure about the transient |
| 20:16.38 | ka6sox-office | this is the 3rd time I've seen this problem( things not being built and the buildd machine sitting idle while buildd.net reports things being built) |
| 20:17.00 | ka6sox-office | your problem and both bob/wendy not building. |
| 20:17.42 | velinp | wendy not doing libsoup ? |
| 20:17.50 | ka6sox-office | yes it is |
| 20:18.17 | ka6sox-office | its building but before sat idle for 2 weeks while I waited for Wouter to show up (I finally rebooted it) |
| 20:18.58 | lennert | libsoup just finished, i got the build log mailed |
| 20:19.22 | ka6sox-office | k |
| 20:19.52 | ka6sox-office | I guess I'm going to have to monitor the system and manage it myself. |
| 20:19.58 | ka6sox-office | :( |
| 20:21.29 | velinp | lennert:hi; know something about ${backlog} ? |
| 20:24.05 | lennert | ${backlog} ? |
| 20:25.24 | velinp | ka6sox and were discussing about velnas idling; ka6sox said he's seen it on bob & wendy; i see 'Feb 14 19:43:54 buildd: sbuild now failed 3 times in a row; going to sleep' |
| 20:25.32 | lennert | yeah, i read that, i've been around |
| 20:25.36 | lennert | not sure what's up with the sbuild stuff |
| 20:25.52 | lennert | i don't really get involved with the buildd boxes for fear of 'contaminating' them with my non-DD-ness |
| 20:26.51 | velinp | so we simple folks just wait (: ? |
| 20:27.05 | lennert | yeah :-/ |
| 20:27.13 | lennert | us, peasants |
| 20:27.24 | lennert | people from the village |
| 20:27.52 | velinp | ka6sox, lennert: not a problem with me, but i prefer armeb going faster :) |
| 20:27.57 | lennert | me too :-/ |
| 20:28.03 | ka6sox-office | me three! |
| 22:05.26 | *** part/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 22:53.13 | *** join/#openjtag beewoolie-afk (n=beewooli@206.124.142.26) |
| 22:55.22 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 22:58.22 | *** join/#openjtag ka6sox-office (n=tking@netblock-66-159-209-61.dslextreme.com) |
