| 00:01.36 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 00:34.31 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 01:55.32 | *** join/#openjtag AchiestDragon (n=dave@whipy.demon.co.uk) |
| 02:04.56 | *** join/#openjtag AchiestDragon (n=dave@whipy.demon.co.uk) |
| 03:46.14 | rwhitby | vmaster: ping |
| 04:18.15 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 07:24.03 | vmaster | rwhitby: pong |
| 07:24.37 | rwhitby | vmaster: I have a few architectural questions about OpenOCD - is now a good time, or is 3 hours from now better for you? |
| 07:25.22 | vmaster | later would be better |
| 07:26.52 | rwhitby | vmaster: ok, I'll check back with you in a number of hours time after I have dinner and get the kids to bed. |
| 07:27.57 | vmaster | alright |
| 07:28.08 | vmaster | just got up, and i'll be online all the day |
| 07:28.57 | rwhitby | ok, I expect I'll have some quality time in about 3 hours or so. |
| 09:47.04 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 10:23.19 | vmaster | rwhitby: hey |
| 10:23.50 | vmaster | i've had a look at the EOnCE |
| 10:24.02 | vmaster | the jtag part seems certainly doable |
| 10:24.19 | vmaster | is there GDB support for the freescale 56000 DSPs? |
| 10:25.09 | rwhitby | Yes, we believe that there is source code available, but we would obviously need to modify and upgrade that to get the maximum benefit out of OpenOCD. |
| 10:25.32 | rwhitby | (I'm not sure if the support has been contributed back to the GDB mainline) |
| 10:26.23 | rwhitby | The particular part we are looking at is the DSP56300 series. It has a OnCE which seems to be a predecessor to the EOnCE in the later parts. |
| 10:27.07 | rwhitby | And we want to be able to run multiple chips at the same time from a single JTAG chain, with two GDB sessions running through a single OpenOCD server instance. |
| 10:27.16 | rwhitby | (i.e. two targets) |
| 10:28.44 | rwhitby | We're not asking you to do the work - we're prepared to do that ourselves (we have software developers on staff). We're looking to collaborate on making sure that we follow the OpenOCD modular architecture correctly, and perhaps even help test the flexibility of the architecture to support new (and very different) devices like the DSP56300. |
| 10:29.45 | rwhitby | Unfortunately, I can't give you details of the target application (that's our confidential product information). |
| 10:29.52 | *** join/#openjtag vmaster_ (i=vmaster@p549B50F2.dip.t-dialin.net) |
| 10:30.05 | rwhitby | oops - how much did you miss? |
| 10:31.17 | vmaster_ | uhm, everything |
| 10:31.33 | vmaster_ | [12:22] < vmaster> rwhitby: hey |
| 10:31.33 | vmaster_ | [12:23] < vmaster> i've had a look at the EOnCE |
| 10:31.33 | vmaster_ | [12:23] < vmaster> the jtag part seems certainly doable |
| 10:31.33 | vmaster_ | [12:23] < vmaster> is there GDB support for the freescale 56000 DSPs? |
| 10:31.45 | rwhitby | Yes, we believe that there is source code available, but we would obviously need to modify and upgrade that to get the maximum benefit out of OpenOCD. |
| 10:31.51 | rwhitby | (I'm not sure if the support has been contributed back to the GDB mainline) |
| 10:31.59 | rwhitby | The particular part we are looking at is the DSP56300 series. It has a OnCE which seems to be a predecessor to the EOnCE in the later parts. |
| 10:32.04 | rwhitby | And we want to be able to run multiple chips at the same time from a single JTAG chain, with two GDB sessions running through a single OpenOCD server instance. |
| 10:32.10 | rwhitby | (i.e. two targets) |
| 10:32.16 | rwhitby | We're not asking you to do the work - we're prepared to do that ourselves (we have software developers on staff). We're looking to collaborate on making sure that we follow the OpenOCD modular architecture correctly, and perhaps even help test the flexibility of the architecture to support new (and very different) devices like the DSP56300. |
| 10:32.21 | vmaster_ | that's supported by the OpenOCD |
| 10:32.23 | rwhitby | Unfortunately, I can't give you details of the target application (that's our confidential product information). |
| 10:32.33 | vmaster_ | sure, no problem |
| 10:32.38 | rwhitby | ok, that's the backlog re-pasted :-) |
| 10:33.16 | vmaster_ | okay |
| 10:33.28 | vmaster_ | well, you'd have to implement the interface defined in target.h |
| 10:33.34 | rwhitby | The details of the chip in question are in chapter 7 of http://www.freescale.com/files/dsp/doc/ref_manual/DSP56300FM.pdf |
| 10:33.40 | vmaster_ | the gdb server simply uses these functions to control the targets |
| 10:34.02 | rwhitby | yep, got that far in understanding today reading your thesis and the source code. |
| 10:34.02 | vmaster_ | the API defined in jtag.h gives you access to the individual chips in the scan chain |
| 10:34.15 | rwhitby | (nice thesis, BTW) |
| 10:34.31 | vmaster_ | thx |
| 10:35.26 | vmaster_ | for the ARM parts I decided to split architectural stuff (armv4_5.[ch]), the common parts of arm7/9 (arm7_9_common.[ch]) and the parts specific to each core (arm7tdmi.[ch], ...) |
| 10:35.31 | rwhitby | The OnCE has some additional JTAG commands (ENABLE_ONCE, DEBUG_REQUEST, etc) - I presume they are handled by the target module and just pass through the jtag module. Is that correct? |
| 10:35.44 | vmaster_ | that's what I think |
| 10:36.15 | rwhitby | yeah, if the EOnCE is backwards-compatible with the OnCE, we might do a similar thing. |
| 10:36.48 | rwhitby | and there are a number of devices in the DSP563xx family which might need a similar grouping of architecture commonality. |
| 10:37.15 | rwhitby | Had you thought of putting another layer of directory structure under the target module? |
| 10:37.35 | rwhitby | (i.e. arm, dsp563x, ppc, i386, etc) |
| 10:37.41 | vmaster_ | yeah, exactly like that |
| 10:37.53 | vmaster_ | shouldn't be much of a problem changing this now |
| 10:38.19 | rwhitby | that would make it clearer which are generic target module files, and which are device specific. |
| 10:38.44 | rwhitby | (and would also make it easier to have different maintainers for different device families) |
| 10:39.28 | rwhitby | Are you intending to continue work on OpenOCD after your exams are over? |
| 10:39.34 | vmaster_ | sure |
| 10:39.51 | vmaster_ | the next thing is completing the XScale stuff |
| 10:40.00 | rwhitby | Do you have related employment which would enable you to do that full time? |
| 10:40.22 | vmaster_ | I still have to write my master's thesis |
| 10:40.47 | rwhitby | ah - is that on the same or a related topic, or a completely different area? |
| 10:40.49 | vmaster_ | I'm currently part-time employed by my university, allowing me to dedicate at least my spare-time to the OpenOCD |
| 10:41.05 | vmaster_ | It's going to be about real-time tracing |
| 10:41.08 | rwhitby | A very progessive university :-) |
| 10:41.09 | vmaster_ | like the ARM ETM |
| 10:41.52 | rwhitby | I think the OnCE or EOnCE has some trace support too. |
| 10:42.27 | vmaster_ | I'll change the /target layout once I'm done with the MinGW stuff, giving you a stable version to base your work upon |
| 10:43.07 | vmaster_ | i'll get something for lunch, be back in about 10 minutes |
| 10:43.21 | rwhitby | ok |
| 10:55.35 | rwhitby | vmaster_: how long do you think it would take a developer experienced such as yourself to add a new target to OpenOCD? |
| 10:57.08 | vmaster_ | i figured about a month for the xscale stuff, but that reused some of the existing arm code |
| 10:57.20 | vmaster_ | but it really depends on the debug features provided by the core |
| 10:57.46 | vmaster_ | on the arm7/9 you have to manually operate the pipeline |
| 10:58.03 | vmaster_ | the xscale is easier, it just runs a debug handler with which you communicate serially |
| 10:58.32 | rwhitby | I'd be interested in your first impressions of the OnCE and how hard that would be ... |
| 11:15.34 | vmaster_ | okay, it looks a bit more complicated than the arm7/9, but it's well documented |
| 11:18.38 | vmaster | the DEBUG_REQUEST instruction allows you to force the core into debug, the ENABLE_ONCE allows you to talk to the OnCE via the Shift-DR JTAG state |
| 11:19.02 | vmaster | after entering debug, you save the pipeline state to the debugger, so you can resume the core later |
| 11:19.53 | vmaster | you can then access the OnCE registers (status registers, breakpoints, pipeline state), or put a DSP instruction into the OnCE, which can then be executed, and the results examined |
| 11:20.37 | vmaster | when you're done with the debug session you restore the pipeline state, and let the core run |
| 11:22.41 | rwhitby | yeah, OPDBR, OPILR and OGDBR. |
| 11:24.10 | rwhitby | Do you have plans for supporting things like the Trace Buffer (section 7.2.5 of the DSP56300 manual)? |
| 11:25.07 | vmaster | that's the idea, currently, but I'm not sure what this is going to look like - i don't think gdb supports the idea of a back-trace |
| 11:25.55 | rwhitby | Do you think the 24-bit nature of this device will present any problems? |
| 11:25.58 | vmaster | XScale has something similar, you can always access the trace-buffer, and see the code-flow from before |
| 11:26.02 | vmaster | nope |
| 11:26.09 | vmaster | more than 32-bit would mean more work, but less is simple |
| 11:26.26 | vmaster | all data is stored in u8 arrays |
| 11:26.32 | vmaster | little-endian |
| 11:26.35 | vmaster | as that's what JTAG uses |
| 11:30.09 | rwhitby | What type of maximum download speeds are you seeing through JTAG? Which dongle is the fastest? |
| 11:31.53 | vmaster | on the ARM7/9 I can download ~150kb/s using the Amontec JTAGAccelerator, and 120kb/s using the FTDI FT2232 |
| 11:32.25 | vmaster | but it's probably a lot less with the OnCE architecture |
| 11:32.58 | rwhitby | what's the limiting factor of OnCE? |
| 11:34.05 | vmaster | 7.2.7.6 is for reading, but writing is going to be similar |
| 11:34.13 | vmaster | you often have to wait for a previous operation to complete |
| 11:34.35 | vmaster | on the arm, i have to wait once every 14 words - on the OnCE, you'll have to wait several time for every word |
| 11:34.54 | vmaster | waiting means polling a status bit |
| 11:35.13 | vmaster | and USB latency is going to kill performance |
| 11:35.14 | rwhitby | steps 3, 10 and 13? |
| 11:35.26 | vmaster | yeah |
| 11:35.42 | vmaster | you could pretend that the core is always going to be faster than your jtag interface |
| 11:35.58 | vmaster | i do this in a 'turbo' mode for the arm7/9 |
| 11:36.05 | rwhitby | would a custom wiggler that could sense the DE pin help? |
| 11:36.07 | vmaster | but it's risky, and might fail every now and then |
| 11:36.19 | rwhitby | hmm - I guess you've still got the USB latency then |
| 11:37.31 | vmaster | i'll check something in the ft2232 datasheet... hold on |
| 11:38.47 | vmaster | there's a command to wait on a line to go high/low |
| 11:38.56 | vmaster | that would allow you to greatly improve performance |
| 11:39.22 | vmaster | but of course it would break OpenOCD's generic JTAG API |
| 11:40.10 | rwhitby | Do other chips have non-standard outputs that could be supported in a generic way back to the target module? |
| 11:41.16 | vmaster | the ARM jtag header defines an external DBGACK signal, but i haven't seen a single core nor a single emulator that actually connected it |
| 11:41.46 | rwhitby | an opportunity for OpenOCD to get break-through performance? ;-) |
| 11:42.48 | vmaster | i've stopped working on these things as the necessary work didn't justify possible gains |
| 11:43.06 | vmaster | http://openocd.berlios.de/web/?page_id=22 |
| 11:43.15 | vmaster | this describes some first thoughts i had on an improved api |
| 11:43.34 | vmaster | it would communicate with a uC/fpga that is able to do the busy waiting |
| 11:47.00 | rwhitby | Assuming the core is faster than the jtag interface, do you think we could get close to the performance you are seeing on ARM with the OnCE architecture, or is it 50% or 25% or 10% ? |
| 11:47.26 | rwhitby | (i.e. if we implement the risky "turbo" mode) |
| 11:53.37 | vmaster | ok, the turbo mode on the arm isn't 120kb/s, but rather ~40kb/s (but it doesn't require any on-chip memory, while the 120kb/s require a small area of on-chip memory), and the once isn't going to reach this |
| 11:55.52 | rwhitby | I presume that there is nothing in OpenOCD which is a bottleneck - i.e. the bottlenecks are all elsewhere in the OnCE architecture or the USB latency for small packets? |
| 11:57.58 | vmaster | the 40kb/s are because of USB latency and the FT2232C, which doesn't achieve the theoretical 6mhz with the small scan sizes associated with debugging |
| 11:58.20 | vmaster | i'm just doing some calcuations to give you a better answer for a OnCE number |
| 12:17.25 | vmaster | okay, on the arm, it takes about 2.4 tck cycles per bit of data, with the OnCE it's going to be more than 5.5 |
| 12:21.10 | vmaster | writing a register of the OnCE takes 89 tck cycles, and storing that register takes 42 tck cycles |
| 12:25.59 | rwhitby | Macgraigor says that their USB2Demon gets 89000bytes/sec to ARM7 and 104000bytes/sec to ARM9. How do they achieve those types of numbers (or are they exaggerating)? |
| 12:26.43 | rwhitby | did you mean storing or reading a register takes 42 tck cycles? |
| 12:27.16 | vmaster | storing the register to target memory |
| 12:28.43 | vmaster | i believe macraigor is exaggerating - using a Wiggler and a Raven, I've never achieved more than 2/3 of what they claimed |
| 12:28.50 | vmaster | maybe on a really high-end system |
| 12:31.37 | vmaster | just did some test runs, on an lpc2294 i achieve ~50kb/s |
| 12:32.02 | vmaster | but i don't know what hardware the usb2demon uses |
| 12:32.36 | vmaster | or if the 89kb/s are quoted for DCC downloads, where the openocd achieves 120kb/s |
| 12:32.47 | rwhitby | So you've calculated that the OnCE is going to be about 40% of the ARM performance? (2.4 vs 5.5 => 17kb/s for OnCE)? |
| 12:32.56 | vmaster | something like that, yeah |
| 12:33.27 | vmaster | on the arm, i can tell the core to load 14 registers at once, and then supply just the data for each register |
| 12:33.38 | vmaster | on the once, you have to tell the core to load each register invidiually |
| 12:33.40 | rwhitby | I expect Mcgraigor would quote for the fastest download mode (DCC) |
| 12:34.31 | rwhitby | Hmm - multiple registers would really help for the gdb server support. |
| 12:35.02 | vmaster | hmm? |
| 12:35.47 | rwhitby | being able to tell the core to load 14 registers instead of one at a time would be good for the gdb server support. |
| 12:36.20 | vmaster | well, it only matters for bulk transfers, for course |
| 12:36.26 | vmaster | where you load larger amounts of memory |
| 12:36.52 | rwhitby | oh, I thought you were referring to saving and restoring state |
| 12:36.55 | vmaster | examining/modifying registers is still going to be faster than you'll notice, probably only limiting single-step performance |
| 12:38.11 | rwhitby | are you aware of any other products with an API to jtag and OCD functionality, or is OpenOCD really the first of it's kind? |
| 12:38.55 | vmaster | there are several jtag debuggers for ARMs |
| 12:38.58 | vmaster | jtagger |
| 12:39.00 | vmaster | jelie for xscale |
| 12:39.15 | vmaster | they're all unmaintained since more than 2 years |
| 12:40.25 | vmaster | oh, it's jtager, not jtagger |
| 12:40.29 | rwhitby | all are arm-specific though, with no thought to modularity for other device families ? |
| 12:40.46 | vmaster | yes |
| 12:41.05 | vmaster | they also support only one device per scan chain |
| 12:41.05 | rwhitby | yeah, that's what drew us to OpenOCD in the first place. The software architecture looked clean. |
| 12:41.32 | rwhitby | (clean from the point of view of adding a non-ARM device) |
| 12:41.37 | vmaster | and their jtag api doesn't allow commands to be queued - if you send every jtag scan directly through usb, you'll end up at 1% of openocds performance) |
| 12:42.12 | vmaster | i tried to keep it clean, but of course you only know what you're missing when you need it |
| 12:42.26 | rwhitby | what's the performance difference between a good parallel port wiggler and a good USB wiggler? |
| 12:42.30 | *** join/#openjtag prpplague (n=billybob@72.22.131.223) |
| 12:42.54 | vmaster | to me, "Wiggler" refers to bit-banging devices |
| 12:43.13 | vmaster | which is only possible over the parallel port |
| 12:43.20 | rwhitby | s/wiggler/dongle/ |
| 12:43.33 | rwhitby | heh |
| 12:43.38 | rwhitby | s/wiggler/dongle/g |
| 12:43.39 | prpplague | vmaster: why can't you bit bang using usb? |
| 12:43.55 | prpplague | vmaster: as i've done with the ez-usb stuff |
| 12:43.57 | vmaster | it's going to be horribly slow |
| 12:44.15 | prpplague | vmaster: its as fast as a standard parport wiggler |
| 12:44.26 | vmaster | as i said, horribly slow ;) |
| 12:44.44 | vmaster | well, i never tried the ez-usb, only the ft2232, and using it for bitbanging was a nightmare |
| 12:45.11 | prpplague | vmaster: yea |
| 12:45.23 | prpplague | vmaster: it leaves something to be desired |
| 12:45.39 | prpplague | vmaster: i also use the ft2232 for other bit banging, such as programming nand flash |
| 12:45.45 | rwhitby | so a USB dongle outdoes a parport wiggler every time for jtag work? |
| 12:46.03 | rwhitby | or does it depend on the software driving it? |
| 12:46.27 | prpplague | rwhitby: depends on both the hardware and software |
| 12:47.13 | rwhitby | vmaster: for best performance with OpenOCD, which dongle should we buy/make? |
| 12:48.06 | vmaster | the JTAGAccelerator (IEEE1284 EPP mode) is less latency sensitive, but rather expensive and proprietary |
| 12:48.29 | vmaster | the FT2232C is a good compromise |
| 12:48.51 | vmaster | and performance is comparable if you don't have to poll your target too often |
| 12:49.10 | vmaster | you can get a DLP2232M evaluation module, add a 3V3 regulator, and have a working dongle |
| 12:49.16 | rwhitby | Is that the Amontec JTAG Accelerator and the JTAGkey respectively? |
| 12:49.21 | vmaster | yes |
| 12:49.50 | vmaster | JTAGAccelerator is a configuration for amontec's Chameleon (Xilinx CPLD + IEEE1284 transceiver) |
| 12:50.06 | vmaster | JTAGkey is just a FT2232 + buffers for low-voltage targets |
| 12:50.17 | rwhitby | For OnCE, I guess we will be polling a bit, so the accel might be a better choice? |
| 12:50.29 | vmaster | i think so, yes |
| 12:50.30 | rwhitby | (irrespective of cost) |
| 12:51.06 | rwhitby | And I guess with the POD we could do the DE output signal sensing too ? |
| 12:52.25 | vmaster | with the Chameleon? IIRC the protocol had some status bits left, which Amontec could use to display the state of this extra line |
| 12:52.34 | vmaster | but they would have to change the configuration |
| 12:53.28 | rwhitby | We have a guy who could probably work out how to reprogram it ... |
| 12:53.56 | vmaster | mhh, reprogramming the Chameleon is easy - use the OpenOCD ;) |
| 12:54.15 | vmaster | but Amontec doesn't provide the VHDL of the JTAGAccelerator configuration |
| 12:54.34 | rwhitby | And for our customers who don't need the extra speed, they can just make a standard parport wiggler for the lowest cost... |
| 12:54.39 | vmaster | yep |
| 12:55.21 | rwhitby | HG? |
| 12:55.22 | vmaster | prpplague: OnCE adds some extra overhead |
| 12:55.33 | vmaster | home-grown? |
| 12:55.47 | prpplague | Holly-Gates |
| 12:55.50 | vmaster | ah, hehehe ;) |
| 12:56.35 | vmaster | you'll need the additional nSRST line if you want to debug out of reset |
| 12:56.48 | vmaster | (on the OnCE) |
| 12:57.29 | rwhitby | Looks like Amontec will sell you the VHDL code for the accelerator ... |
| 12:57.47 | prpplague | everyone is welcome to register and add additional information |
| 12:59.06 | rwhitby | no mention of OpenOCD on that page yet? |
| 12:59.51 | prpplague | rwhitby: naw, i keep forgetting to add it |
| 13:07.45 | rwhitby | vmaster: thanks for your help - time for sleep here now. talk to you another day. |
| 13:08.34 | vmaster | you're welcome - good night |
| 13:33.48 | prpplague | hmm, does openocd support debugging on arm in thumb mode? |
| 13:34.22 | prpplague | vmaster: jtager doesn't |
| 13:34.28 | vmaster | OpenOCD does |
| 13:34.33 | prpplague | vmaster: ahh cool |
| 13:35.04 | vmaster | but GDB support for Thumb debugging on armv4t isn't optimal |
| 13:35.13 | prpplague | vmaster: isn't 0x787 the standard ARM manufacturer id when in debug? |
| 13:35.32 | prpplague | vmaster: yea, i just need to reverse enginer a few things |
| 13:37.30 | vmaster | mhh, no idea what ID you mean |
| 13:37.46 | vmaster | the disassembler I've wrote for the OpenOCD doesn't support thumb yet |
| 13:38.01 | vmaster | but you can disassemble with the GDB at address+1 |
| 13:38.02 | prpplague | vmaster: ahh, i just want registers |
| 13:38.42 | prpplague | vmaster: when in ice you can call for a device id, for arm7 it should respond as 0x0f0f0f0f |
| 13:39.00 | vmaster | ah, you mean the IDCODE? |
| 13:39.13 | prpplague | yea |
| 13:39.15 | vmaster | LPC for example replies as 0x3f0f0f0f |
| 13:39.40 | prpplague | right |
| 13:39.49 | vmaster | but i don't think this is mandatory, or is it? |
| 13:40.28 | prpplague | i can't find any info on it |
| 13:40.37 | vmaster | http://www.arm.com/support/faqip/3843.html |
| 13:40.38 | prpplague | but i have found just bits and pieces |
| 13:44.22 | prpplague | ahh thanks |
| 13:44.26 | prpplague | don't know how i missed that |
| 13:46.30 | prpplague | ahh yea, looks like both jtag tools and jtager both have the information incorrect |
| 13:46.50 | prpplague | they have the 0x787 manufacturer id attributed to samsung |
| 17:00.35 | prpplague | vmaster: hmm "command core_state not found" in oocd |
| 17:01.29 | vmaster | armv4_5 |
| 17:01.38 | vmaster | this is an armv4_5 specific command |
| 17:01.50 | vmaster | so you should enter it as "armv4_5 core_state" |
| 17:02.25 | vmaster | i'll have to change the layout of the help output a bit to make it clear which commands belong to each other |
| 17:02.37 | vmaster | same goes for "flash info" "flash write" etc. |
| 17:02.58 | vmaster | i'll get my dinner, be back in a bit... |
| 17:03.57 | prpplague | ahh |
| 17:04.45 | prpplague | vmaster: what about the syntax of jtag_reset ? |
| 17:05.19 | prpplague | vmaster: btw , you might want to add one more entry in the parport dongles, as the holly-gates is a popular design and its identical config to the triton |
| 17:24.26 | prpplague | vmaster: how robust is the scripting? |
| 17:24.51 | prpplague | vmaster: does it just feed the commands to the commandline parser? |
| 17:28.11 | vmaster | prpplague: actually, you're the first and only one i've ever heard mentioning "holly-gates", but adding this to the cable definitions isn't a problem, just show me the line you're using |
| 17:28.54 | prpplague | vmaster: its the one marked triton |
| 17:30.36 | vmaster | prpplague: does it have a nSRST line? |
| 17:31.36 | vmaster | triton is a pxa250 board by karo electronics, with a built-in "wiggler", but it lacks the SRST, so it's no use for debugging |
| 17:36.23 | prpplague | no the default design of the HG does not have SRST |
| 17:36.43 | prpplague | i've added one to my board |
| 17:37.22 | prpplague | vmaster: you can check out the schematic at http://www.lartmaker.nl/projects/jtag/ |
| 17:37.46 | vmaster | ah, i have that one ;) |
| 17:43.55 | vmaster | i've added a note to the docs that 'triton' is the same layout as is used by the holly gates design |
| 17:44.54 | prpplague | thanks |
| 17:44.58 | prpplague | just a helpful item |
| 17:58.27 | vmaster | yeah, thanks, i completely forgot about the dongle that came with my lart |
| 20:55.51 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 23:39.26 | wookey | vmaster: you have a lart? Quite a rare beast these days :-) |
| 23:39.37 | wookey | We still have a pile of those JTAG devices |
| 23:41.18 | wookey | (and curently use them for programming balloons, although they are about to be superceded by a wiggler-compatible |
| 23:41.22 | wookey | ) |
| 23:51.45 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |