**** BEGIN LOGGING AT Thu Jul 06 02:59:57 2006
Jul 06 03:27:45 <rwhitby> vmaster: ping
Jul 06 07:05:33 <vmaster> rwhitby: pong
Jul 06 07:06:07 <rwhitby> vmaster: I have a few architectural questions about OpenOCD - is now a good time, or is 3 hours from now better for you?
Jul 06 07:06:52 <vmaster> later would be better
Jul 06 07:08:22 <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.
Jul 06 07:09:27 <vmaster> alright
Jul 06 07:09:38 <vmaster> just got up, and i'll be online all the day
Jul 06 07:10:27 <rwhitby> ok, I expect I'll have some quality time in about 3 hours or so.
Jul 06 10:04:49 <vmaster> rwhitby: hey
Jul 06 10:05:20 <vmaster> i've had a look at the EOnCE
Jul 06 10:05:31 <vmaster> the jtag part seems certainly doable
Jul 06 10:05:49 <vmaster> is there GDB support for the freescale 56000 DSPs?
Jul 06 10:06:39 <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.
Jul 06 10:07:01 <rwhitby> (I'm not sure if the support has been contributed back to the GDB mainline)
Jul 06 10:07:52 <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.
Jul 06 10:08:36 <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.
Jul 06 10:08:46 <rwhitby> (i.e. two targets)
Jul 06 10:10:14 <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.
Jul 06 10:11:15 <rwhitby> Unfortunately, I can't give you details of the target application (that's our confidential product information).
Jul 06 10:11:35 <rwhitby> oops - how much did you miss?
Jul 06 10:12:46 <vmaster_> uhm, everything
Jul 06 10:13:02 <vmaster_> [12:22] < vmaster> rwhitby: hey
Jul 06 10:13:02 <vmaster_> [12:23] < vmaster> i've had a look at the EOnCE
Jul 06 10:13:02 <vmaster_> [12:23] < vmaster> the jtag part seems certainly doable
Jul 06 10:13:02 <vmaster_> [12:23] < vmaster> is there GDB support for the freescale 56000 DSPs?
Jul 06 10:13:15 <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.
Jul 06 10:13:20 <rwhitby> (I'm not sure if the support has been contributed back to the GDB mainline)
Jul 06 10:13:26 <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.
Jul 06 10:13:34 <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.
Jul 06 10:13:39 <rwhitby> (i.e. two targets)
Jul 06 10:13:45 <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.
Jul 06 10:13:51 <vmaster_> that's supported by the OpenOCD
Jul 06 10:13:52 <rwhitby> Unfortunately, I can't give you details of the target application (that's our confidential product information).
Jul 06 10:14:02 <vmaster_> sure, no problem
Jul 06 10:14:08 <rwhitby> ok, that's the backlog re-pasted :-)
Jul 06 10:14:45 <vmaster_> okay
Jul 06 10:14:57 <vmaster_> well, you'd have to implement the interface defined in target.h
Jul 06 10:15:04 <rwhitby> The details of the chip in question are in chapter 7 of http://www.freescale.com/files/dsp/doc/ref_manual/DSP56300FM.pdf
Jul 06 10:15:10 <vmaster_> the gdb server simply uses these functions to control the targets
Jul 06 10:15:31 <rwhitby> yep, got that far in understanding today reading your thesis and the source code.
Jul 06 10:15:32 <vmaster_> the API defined in jtag.h gives you access to the individual chips in the scan chain
Jul 06 10:15:45 <rwhitby> (nice thesis, BTW)
Jul 06 10:16:00 <vmaster_> thx
Jul 06 10:16:55 <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], ...)
Jul 06 10:16:59 <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?
Jul 06 10:17:14 <vmaster_> that's what I think
Jul 06 10:17:45 <rwhitby> yeah, if the EOnCE is backwards-compatible with the OnCE, we might do a similar thing.
Jul 06 10:18:17 <rwhitby> and there are a number of devices in the DSP563xx family which might need a similar grouping of architecture commonality.
Jul 06 10:18:44 <rwhitby> Had you thought of putting another layer of directory structure under the target module?
Jul 06 10:19:04 <rwhitby> (i.e. arm, dsp563x, ppc, i386, etc)
Jul 06 10:19:10 <vmaster_> yeah, exactly like that
Jul 06 10:19:23 <vmaster_> shouldn't be much of a problem changing this now
Jul 06 10:19:48 <rwhitby> that would make it clearer which are generic target module files, and which are device specific.
Jul 06 10:20:13 <rwhitby> (and would also make it easier to have different maintainers for different device families)
Jul 06 10:20:57 <rwhitby> Are you intending to continue work on OpenOCD after your exams are over?
Jul 06 10:21:03 <vmaster_> sure
Jul 06 10:21:21 <vmaster_> the next thing is completing the XScale stuff
Jul 06 10:21:29 <rwhitby> Do you have related employment which would enable you to do that full time?
Jul 06 10:21:51 <vmaster_> I still have to write my master's thesis
Jul 06 10:22:17 <rwhitby> ah - is that on the same or a related topic, or a completely different area?
Jul 06 10:22:18 <vmaster_> I'm currently part-time employed by my university, allowing me to dedicate at least my spare-time to the OpenOCD
Jul 06 10:22:34 <vmaster_> It's going to be about real-time tracing
Jul 06 10:22:38 <rwhitby> A very progessive university :-)
Jul 06 10:22:39 <vmaster_> like the ARM ETM
Jul 06 10:23:21 <rwhitby> I think the OnCE or EOnCE has some trace support too.
Jul 06 10:23:56 <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
Jul 06 10:24:36 <vmaster_> i'll get something for lunch, be back in about 10 minutes
Jul 06 10:24:51 <rwhitby> ok
Jul 06 10:37:04 <rwhitby> vmaster_: how long do you think it would take a developer experienced such as yourself to add a new target to OpenOCD?
Jul 06 10:38:38 <vmaster_> i figured about a month for the xscale stuff, but that reused some of the existing arm code
Jul 06 10:38:49 <vmaster_> but it really depends on the debug features provided by the core
Jul 06 10:39:15 <vmaster_> on the arm7/9 you have to manually operate the pipeline
Jul 06 10:39:32 <vmaster_> the xscale is easier, it just runs a debug handler with which you communicate serially
Jul 06 10:40:01 <rwhitby> I'd be interested in your first impressions of the OnCE and how hard that would be ...
Jul 06 10:57:03 <vmaster_> okay, it looks a bit more complicated than the arm7/9, but it's well documented
Jul 06 11:00:07 <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
Jul 06 11:00:31 <vmaster> after entering debug, you save the pipeline state to the debugger, so you can resume the core later
Jul 06 11:01:22 <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
Jul 06 11:02:06 <vmaster> when you're done with the debug session you restore the pipeline state, and let the core run
Jul 06 11:04:10 <rwhitby> yeah, OPDBR, OPILR and OGDBR.
Jul 06 11:05:39 <rwhitby> Do you have plans for supporting things like the Trace Buffer (section 7.2.5 of the DSP56300 manual)?
Jul 06 11:06:36 <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
Jul 06 11:07:24 <rwhitby> Do you think the 24-bit nature of this device will present any problems?
Jul 06 11:07:27 <vmaster> XScale has something similar, you can always access the trace-buffer, and see the code-flow from before
Jul 06 11:07:31 <vmaster> nope
Jul 06 11:07:38 <vmaster> more than 32-bit would mean more work, but less is simple
Jul 06 11:07:55 <vmaster> all data is stored in u8 arrays
Jul 06 11:08:01 <vmaster> little-endian
Jul 06 11:08:04 <vmaster> as that's what JTAG uses
Jul 06 11:11:38 <rwhitby> What type of maximum download speeds are you seeing through JTAG?  Which dongle is the fastest?
Jul 06 11:13:21 <vmaster> on the ARM7/9 I can download ~150kb/s using the Amontec JTAGAccelerator, and 120kb/s using the FTDI FT2232
Jul 06 11:13:54 <vmaster> but it's probably a lot less with the OnCE architecture
Jul 06 11:14:27 <rwhitby> what's the limiting factor of OnCE?
Jul 06 11:15:34 <vmaster> 7.2.7.6 is for reading, but writing is going to be similar
Jul 06 11:15:42 <vmaster> you often have to wait for a previous operation to complete
Jul 06 11:16:04 <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
Jul 06 11:16:23 <vmaster> waiting means polling a status bit
Jul 06 11:16:41 <vmaster> and USB latency is going to kill performance
Jul 06 11:16:43 <rwhitby> steps 3, 10 and 13?
Jul 06 11:16:55 <vmaster> yeah
Jul 06 11:17:11 <vmaster> you could pretend that the core is always going to be faster than your jtag interface
Jul 06 11:17:27 <vmaster> i do this in a 'turbo' mode for the arm7/9
Jul 06 11:17:34 <rwhitby> would a custom wiggler that could sense the DE pin help?
Jul 06 11:17:36 <vmaster> but it's risky, and might fail every now and then
Jul 06 11:17:48 <rwhitby> hmm - I guess you've still got the USB latency then
Jul 06 11:19:00 <vmaster> i'll check something in the ft2232 datasheet... hold on
Jul 06 11:20:16 <vmaster> there's a command to wait on a line to go high/low
Jul 06 11:20:25 <vmaster> that would allow you to greatly improve performance
Jul 06 11:20:51 <vmaster> but of course it would break OpenOCD's generic JTAG API
Jul 06 11:21:39 <rwhitby> Do other chips have non-standard outputs that could be supported in a generic way back to the target module?
Jul 06 11:22:45 <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
Jul 06 11:23:15 <rwhitby> an opportunity for OpenOCD to get break-through performance? ;-)
Jul 06 11:24:16 <vmaster> i've stopped working on these things as the necessary work didn't justify possible gains
Jul 06 11:24:35 <vmaster> http://openocd.berlios.de/web/?page_id=22
Jul 06 11:24:44 <vmaster> this describes some first thoughts i had on an improved api
Jul 06 11:25:03 <vmaster> it would communicate with a uC/fpga that is able to do the busy waiting
Jul 06 11:28:29 <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% ?
Jul 06 11:28:55 <rwhitby> (i.e. if we implement the risky "turbo" mode)
Jul 06 11:35:05 <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
Jul 06 11:37:21 <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?
Jul 06 11:39:27 <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
Jul 06 11:39:49 <vmaster> i'm just doing some calcuations to give you a better answer for a OnCE number
Jul 06 11:58:54 <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
Jul 06 12:02:39 <vmaster> writing a register of the OnCE takes 89 tck cycles, and storing that register takes 42 tck cycles
Jul 06 12:07:28 <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)?
Jul 06 12:08:12 <rwhitby> did you mean storing or reading a register takes 42 tck cycles?
Jul 06 12:08:44 <vmaster> storing the register to target memory
Jul 06 12:10:11 <vmaster> i believe macraigor is exaggerating - using a Wiggler and a Raven, I've never achieved more than 2/3 of what they claimed
Jul 06 12:10:19 <vmaster> maybe on a really high-end system
Jul 06 12:13:06 <vmaster> just did some test runs, on an lpc2294 i achieve ~50kb/s
Jul 06 12:13:30 <vmaster> but i don't know what hardware the usb2demon uses
Jul 06 12:14:05 <vmaster> or if the 89kb/s are quoted for DCC downloads, where the openocd achieves 120kb/s
Jul 06 12:14:16 <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)?
Jul 06 12:14:25 <vmaster> something like that, yeah
Jul 06 12:14:56 <vmaster> on the arm, i can tell the core to load 14 registers at once, and then supply just the data for each register
Jul 06 12:15:07 <vmaster> on the once, you have to tell the core to load each register invidiually
Jul 06 12:15:09 <rwhitby> I expect Mcgraigor would quote for the fastest download mode (DCC)
Jul 06 12:15:59 <rwhitby> Hmm - multiple registers would really help for the gdb server support.
Jul 06 12:16:31 <vmaster> hmm?
Jul 06 12:17:16 <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.
Jul 06 12:17:49 <vmaster> well, it only matters for bulk transfers, for course
Jul 06 12:17:54 <vmaster> where you load larger amounts of memory
Jul 06 12:18:21 <rwhitby> oh, I thought you were referring to saving and restoring state
Jul 06 12:18:24 <vmaster> examining/modifying registers is still going to be faster than you'll notice, probably only limiting single-step performance
Jul 06 12:19:40 <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?
Jul 06 12:20:24 <vmaster> there are several jtag debuggers for ARMs
Jul 06 12:20:27 <vmaster> jtagger
Jul 06 12:20:29 <vmaster> jelie for xscale
Jul 06 12:20:43 <vmaster> they're all unmaintained since more than 2 years
Jul 06 12:21:53 <vmaster> oh, it's jtager, not jtagger
Jul 06 12:21:57 <rwhitby> all are arm-specific though, with no thought to modularity for other device families ?
Jul 06 12:22:15 <vmaster> yes
Jul 06 12:22:34 <vmaster> they also support only one device per scan chain
Jul 06 12:22:34 <rwhitby> yeah, that's what drew us to OpenOCD in the first place.  The software architecture looked clean.
Jul 06 12:23:01 <rwhitby> (clean from the point of view of adding a non-ARM device)
Jul 06 12:23:05 <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)
Jul 06 12:23:40 <vmaster> i tried to keep it clean, but of course you only know what you're missing when you need it
Jul 06 12:23:55 <rwhitby> what's the performance difference between a good parallel port wiggler and a good USB wiggler?
Jul 06 12:24:22 <vmaster> to me, "Wiggler" refers to bit-banging devices
Jul 06 12:24:41 <vmaster> which is only possible over the parallel port
Jul 06 12:24:49 <rwhitby> s/wiggler/dongle/
Jul 06 12:24:49 <purl> rwhitby meant: what's the performance difference between a good parallel port dongle and a good USB wiggler?
Jul 06 12:25:02 <rwhitby> heh
Jul 06 12:25:07 <rwhitby> s/wiggler/dongle/g
Jul 06 12:25:08 <prpplague> vmaster: why can't you bit bang using usb?
Jul 06 12:25:23 <prpplague> vmaster: as i've done with the ez-usb stuff
Jul 06 12:25:25 <vmaster> it's going to be horribly slow
Jul 06 12:25:44 <prpplague> vmaster: its as fast as a standard parport wiggler
Jul 06 12:25:55 <vmaster> as i said, horribly slow ;)
Jul 06 12:26:13 <vmaster> well, i never tried the ez-usb, only the ft2232, and using it for bitbanging was a nightmare
Jul 06 12:26:39 <prpplague> vmaster: yea
Jul 06 12:26:52 <prpplague> vmaster: it leaves something to be desired
Jul 06 12:27:08 <prpplague> vmaster: i also use the ft2232 for other bit banging, such as programming nand flash
Jul 06 12:27:14 <rwhitby> so a USB dongle outdoes a parport wiggler every time for jtag work?
Jul 06 12:27:32 <rwhitby> or does it depend on the software driving it?
Jul 06 12:27:55 <prpplague> rwhitby: depends on both the hardware and software
Jul 06 12:28:41 <rwhitby> vmaster: for best performance with OpenOCD, which dongle should we buy/make?
Jul 06 12:29:34 <vmaster> the JTAGAccelerator (IEEE1284 EPP mode) is less latency sensitive, but rather expensive and proprietary
Jul 06 12:29:57 <vmaster> the FT2232C is a good compromise
Jul 06 12:30:19 <vmaster> and performance is comparable if you don't have to poll your target too often
Jul 06 12:30:39 <vmaster> you can get a DLP2232M evaluation module, add a 3V3 regulator, and have a working dongle
Jul 06 12:30:45 <rwhitby> Is that the Amontec JTAG Accelerator and the JTAGkey respectively?
Jul 06 12:30:50 <vmaster> yes
Jul 06 12:31:18 <vmaster> JTAGAccelerator is a configuration for amontec's Chameleon (Xilinx CPLD + IEEE1284 transceiver)
Jul 06 12:31:34 <vmaster> JTAGkey is just a FT2232 + buffers for low-voltage targets
Jul 06 12:31:45 <rwhitby> For OnCE, I guess we will be polling a bit, so the accel might be a better choice?
Jul 06 12:31:57 <vmaster> i think so, yes
Jul 06 12:31:58 <rwhitby> (irrespective of cost)
Jul 06 12:32:34 <rwhitby> And I guess with the POD we could do the DE output signal sensing too ?
Jul 06 12:33:53 <vmaster> with the Chameleon? IIRC the protocol had some status bits left, which Amontec could use to display the state of this extra line
Jul 06 12:34:02 <vmaster> but they would have to change the configuration
Jul 06 12:34:56 <rwhitby> We have a guy who could probably work out how to reprogram it ...
Jul 06 12:35:24 <vmaster> mhh, reprogramming the Chameleon is easy - use the OpenOCD ;)
Jul 06 12:35:43 <vmaster> but Amontec doesn't provide the VHDL of the JTAGAccelerator configuration
Jul 06 12:36:02 <rwhitby> And for our customers who don't need the extra speed, they can just make a standard parport wiggler for the lowest cost...
Jul 06 12:36:08 <vmaster> yep
Jul 06 12:36:31 * prpplague perfectly happy with his custom HG parport wiggler
Jul 06 12:36:49 <rwhitby> HG?
Jul 06 12:36:50 <vmaster> prpplague: OnCE adds some extra overhead
Jul 06 12:37:01 <vmaster> home-grown?
Jul 06 12:37:15 <prpplague> Holly-Gates
Jul 06 12:37:19 <vmaster> ah, hehehe ;)
Jul 06 12:37:37 * rwhitby only has a lowly Digilent JTAG3 cable ...
Jul 06 12:38:04 <vmaster> you'll need the additional nSRST line if you want to debug out of reset
Jul 06 12:38:17 <vmaster> (on the OnCE)
Jul 06 12:38:57 <rwhitby> Looks like Amontec will sell you the VHDL code for the accelerator ...
Jul 06 12:39:00 * prpplague has some collected jtag info at http://www.elinux.org/wiki/JTAG
Jul 06 12:39:15 <prpplague> everyone is welcome to register and add additional information
Jul 06 12:40:15 <rwhitby> no mention of OpenOCD on that page yet?
Jul 06 12:41:19 <prpplague> rwhitby: naw, i keep forgetting to add it
Jul 06 12:49:14 <rwhitby> vmaster: thanks for your help - time for sleep here now.  talk to you another day.
Jul 06 12:50:03 <vmaster> you're welcome - good night
Jul 06 13:15:17 <prpplague> hmm, does openocd support debugging on arm in thumb mode?
Jul 06 13:15:51 <prpplague> vmaster: jtager doesn't
Jul 06 13:15:56 <vmaster> OpenOCD does
Jul 06 13:16:01 <prpplague> vmaster: ahh cool
Jul 06 13:16:30 <vmaster> but GDB support for Thumb debugging on armv4t isn't optimal
Jul 06 13:16:41 <prpplague> vmaster: isn't 0x787 the standard ARM manufacturer id when in debug?
Jul 06 13:17:00 <prpplague> vmaster: yea, i just need to reverse enginer a few things
Jul 06 13:18:58 <vmaster> mhh, no idea what ID you mean
Jul 06 13:19:14 <vmaster> the disassembler I've wrote for the OpenOCD doesn't support thumb yet
Jul 06 13:19:29 <vmaster> but you can disassemble with the GDB at address+1
Jul 06 13:19:31 <prpplague> vmaster: ahh, i just want registers
Jul 06 13:20:10 <prpplague> vmaster: when in ice you can call for a device id, for arm7 it should respond as 0x0f0f0f0f
Jul 06 13:20:28 <vmaster> ah, you mean the IDCODE?
Jul 06 13:20:41 <prpplague> yea
Jul 06 13:20:43 <vmaster> LPC for example replies as 0x3f0f0f0f
Jul 06 13:21:09 <prpplague> right
Jul 06 13:21:17 <vmaster> but i don't think this is mandatory, or is it?
Jul 06 13:21:57 <prpplague> i can't find any info on it
Jul 06 13:22:05 <vmaster> http://www.arm.com/support/faqip/3843.html
Jul 06 13:22:06 <prpplague> but i have found just bits and pieces
Jul 06 13:22:12 * prpplague looks
Jul 06 13:25:50 <prpplague> ahh thanks
Jul 06 13:25:55 <prpplague> don't know how i missed that
Jul 06 13:27:59 <prpplague> ahh yea, looks like both jtag tools and jtager both have the information incorrect
Jul 06 13:28:17 <prpplague> they have the 0x787 manufacturer id attributed to samsung
Jul 06 16:42:02 <prpplague> vmaster: hmm "command core_state not found" in oocd
Jul 06 16:42:57 <vmaster> armv4_5
Jul 06 16:43:05 <vmaster> this is an armv4_5 specific command
Jul 06 16:43:17 <vmaster> so you should enter it as "armv4_5 core_state"
Jul 06 16:43:52 <vmaster> i'll have to change the layout of the help output a bit to make it clear which commands belong to each other
Jul 06 16:44:04 <vmaster> same goes for "flash info" "flash write" etc.
Jul 06 16:44:25 <vmaster> i'll get my dinner, be back in a bit...
Jul 06 16:45:25 <prpplague> ahh
Jul 06 16:45:31 * prpplague tries
Jul 06 16:46:13 <prpplague> vmaster: what about the syntax of jtag_reset ?
Jul 06 16:46:46 <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
Jul 06 17:05:53 <prpplague> vmaster: how robust is the scripting?
Jul 06 17:06:19 <prpplague> vmaster: does it just feed the commands to the commandline parser?
Jul 06 17:09:38 <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
Jul 06 17:10:21 <prpplague> vmaster: its the one marked triton
Jul 06 17:12:04 <vmaster> prpplague: does it have a nSRST line?
Jul 06 17:13:03 <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
Jul 06 17:17:50 <prpplague> no the default design of the HG does not have SRST
Jul 06 17:18:10 <prpplague> i've added one to my board
Jul 06 17:18:50 <prpplague> vmaster: you can check out the schematic at http://www.lartmaker.nl/projects/jtag/
Jul 06 17:19:13 <vmaster> ah, i have that one ;)
Jul 06 17:25:22 <vmaster> i've added a note to the docs that 'triton' is the same layout as is used by the holly gates design
Jul 06 17:26:21 <prpplague> thanks
Jul 06 17:26:26 <prpplague> just a helpful item
Jul 06 17:39:54 <vmaster> yeah, thanks, i completely forgot about the dongle that came with my lart
Jul 06 23:20:50 <wookey> vmaster: you have a lart? Quite a rare beast these days :-)
Jul 06 23:21:02 <wookey> We still have a pile of those JTAG devices
Jul 06 23:22:44 <wookey> (and curently use them for programming balloons, although they are about to be superceded by a wiggler-compatible
Jul 06 23:22:47 <wookey> )
**** ENDING LOGGING AT Fri Jul 07 02:59:56 2006