[Openocd-development] fix ancient bug SEGFAULT in irscan
I couldn't believe my eyes when I saw what the bug was. irscan
has *always* been broken. I checked as far back as svn 345.
A couple of possible explanations:
- irscan has never really been used
- events have somehow conspired to hide the bugs
- I'm missing something
Known problems in irscan:
- does not support 32 bit fields(?). This maybe a problem for
omap devices(?)
- why not reuse the new drscan code?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/jtag.c
===
--- src/jtag/jtag.c (revision 1750)
+++ src/jtag/jtag.c (working copy)
@@ -2889,9 +2889,11 @@
}
}
- fields = malloc(sizeof(scan_field_t) * argc / 2);
+ int num_fields= num_fields;
+
+ fields = malloc(sizeof(scan_field_t) * num_fields);
- for (i = 0; i argc / 2; i++)
+ for (i = 0; i num_fields; i++)
{
tap = jtag_TapByString( args[i*2] );
if (tap==NULL)
@@ -2901,19 +2903,20 @@
}
int field_size = tap-ir_length;
fields[i].tap = tap;
+ fields[i].num_bits = field_size;
fields[i].out_value = malloc(CEIL(field_size, 8));
buf_set_u32(fields[i].out_value, 0, field_size,
strtoul(args[i*2+1], NULL, 0));
fields[i].in_value = NULL;
}
- jtag_add_ir_scan(argc / 2, fields, TAP_INVALID);
+ jtag_add_ir_scan(num_fields, fields, TAP_INVALID);
/* did we have an endstate? */
if (endstate != TAP_INVALID)
jtag_add_end_state(endstate);
jtag_execute_queue();
- for (i = 0; i argc / 2; i++)
+ for (i = 0; i num_fields; i++)
free(fields[i].out_value);
free (fields);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Segfault in SVN 1743+
Fix committed. irscan has always been badly broken. I wonder if it has ever been used -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
I've committed a fix in 1753 for memory corruption introduced in 1730.
Thanks for bisecting to the offending release. This is definitely a case
of where numerous small commits saved my butt.
Hopefully this covers the problem that you are seing, but I don't
have your precise setup so I can't run the exact test case you
are running...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm9tdmi.c
===
--- src/target/arm9tdmi.c (revision 1743)
+++ src/target/arm9tdmi.c (working copy)
@@ -291,9 +291,9 @@
extern void arm_endianness(u8 *tmp, void *in, int size, int be, int flip);
-static int arm9endianness(u8 *in, jtag_callback_data_t size,
jtag_callback_data_t be, jtag_callback_data_t dummy)
+static int arm9endianness(u8 *in, jtag_callback_data_t size,
jtag_callback_data_t be, jtag_callback_data_t captured)
{
- arm_endianness(in, in, (int)size, (int)be, 0);
+ arm_endianness((u8 *)captured, in, (int)size, (int)be, 0);
return ERROR_OK;
}
@@ -317,7 +317,7 @@
fields[0].tap = jtag_info-tap;
fields[0].num_bits = 32;
fields[0].out_value = NULL;
- fields[0].in_value = (u8 *)in;
+ jtag_alloc_in_value32(fields[0]);
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 3;
@@ -331,7 +331,7 @@
jtag_add_dr_scan(3, fields, TAP_INVALID);
- jtag_add_callback4(arm9endianness, in, (jtag_callback_data_t)size,
(jtag_callback_data_t)be, 0);
+ jtag_add_callback4(arm9endianness, in, (jtag_callback_data_t)size,
(jtag_callback_data_t)be, (jtag_callback_data_t)fields[0].in_value);
jtag_add_runtest(0, TAP_INVALID);
Index: src/target/arm7tdmi.c
===
--- src/target/arm7tdmi.c (revision 1750)
+++ src/target/arm7tdmi.c (working copy)
@@ -244,9 +244,9 @@
}
}
-static int arm7endianness(u8 *in, jtag_callback_data_t size,
jtag_callback_data_t be, jtag_callback_data_t dummy)
+static int arm7endianness(u8 *in, jtag_callback_data_t size,
jtag_callback_data_t be, jtag_callback_data_t captured)
{
- arm_endianness(in, in, (int)size, (int)be, 1);
+ arm_endianness((u8 *)captured, in, (int)size, (int)be, 1);
return ERROR_OK;
}
@@ -274,11 +274,11 @@
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 32;
fields[1].out_value = NULL;
- fields[1].in_value = (u8 *)in;
+ jtag_alloc_in_value32(fields[1]);
jtag_add_dr_scan(2, fields, TAP_INVALID);
- jtag_add_callback4(arm7endianness, in, (jtag_callback_data_t)size,
(jtag_callback_data_t)be, (jtag_callback_data_t)NULL);
+ jtag_add_callback4(arm7endianness, in, (jtag_callback_data_t)size,
(jtag_callback_data_t)be, (jtag_callback_data_t)fields[1].in_value);
jtag_add_runtest(0, TAP_INVALID);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
I've committed a fix in 1738 for memory corruption introduced in 1730. Thanks for bisecting to the offending release. This is definitely a case of where numerous small commits saved my butt. Hopefully this covers the problem that you are seing. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tuesday 12 May 2009, Øyvind Harboe wrote: I think we should be extremely careful about defining public interfaces. Defining is less of an issue than committing to... :) Especially since the JTAG API still (yes still! the hard bits are done though) needs work cleanup. Again I'll mention liburjtag ... it's perhaps worth considering whether there are things to cooperate on (JTAG structures and constants?), and where to focus on differentiation (testing apps vs debug/devel support?). I don't know that liburjag is much further along than libopenocd. But I see that it's in the works. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, May 12, 2009 at 6:10 PM, David Brownell davi...@pacbell.net wrote: On Tuesday 12 May 2009, Ųyvind Harboe wrote: I think we should be extremely careful about defining public interfaces. Defining is less of an issue than committing to... :) Especially since the JTAG API still (yes still! the hard bits are done though) needs work cleanup. Again I'll mention liburjtag ... it's perhaps worth considering whether there are things to cooperate on (JTAG structures and constants?), and where to focus on differentiation (testing apps vs debug/devel support?). I don't know that liburjag is much further along than libopenocd. But I see that it's in the works. Could we make an interface driver in OpenOCD that would be able to use the urjtag device layer? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, May 12, 2009 at 11:49 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I think we should be extremely careful about defining public interfaces. Especially since the JTAG API still (yes still! the hard bits are done though) needs work cleanup. As an old colleague of mine(Mike Sinz) said: “Programming is like sex: one mistake and you have to support it for the rest of your life.” This is probably an understatement. An ABI is serious trouble. :-( I started down this path with another project, and gave up. Lots of people want me to make a stable ABI for my procps project. I set up some of the things it would need, like symbol versioning and hidden symbol visibility. Then I realized what trouble I was in for, and put the project on hold. Any struct you expose in a *.h file will become cast in stone. Users will apply the sizeof operator, access the fields in the original order, depend on the original meaning (including their own guesses), etc. You can add accessor functions I suppose, forcing the users to use them by hiding the struct definitions, but that's slow/bloated/ugly. If you return int, then later decide you wanted size_t, you need to write a second function. The old function can be marked with the gcc deprecated attribute. A few years later, you still get screams when you remove the cruft. Linux vendors will cluelessly break your ABI. You get blamed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] lower JTAG clock for SheevaPlug
3MHz is unreliable on some units while 2MHz appears to be fine. commit 343375ca7a3e004e02a4912b8ef660ffa991d901 Author: root r...@xanadu.home Date: Tue May 12 12:28:58 2009 -0400 SheevaPlug down to 2MHz JTAG clock diff --git a/src/target/interface/sheevaplug.cfg b/src/target/interface/sheevaplug.cfg index 7914ba0..556f44d 100644 --- a/src/target/interface/sheevaplug.cfg +++ b/src/target/interface/sheevaplug.cfg @@ -8,5 +8,5 @@ interface ft2232 ft2232_layout sheevaplug ft2232_vid_pid 0x9e88 0x9e8f ft2232_device_desc SheevaPlug JTAGKey FT2232D B -jtag_khz 3000 +jtag_khz 2000 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote: On Tue, 12 May 2009, Øyvind Harboe wrote: I've committed a fix in 1753 for memory corruption introduced in 1730. Thanks for bisecting to the offending release. This is definitely a case of where numerous small commits saved my butt. Hopefully this covers the problem that you are seing, but I don't have your precise setup so I can't run the exact test case you are running... Fixed, thanks a lot. Great! About performance: things are reasonable again. It takes 90 seconds to flash 450 KB to NAND instead of 5 minutes. But in the days of rev 1520 this was like 80 seconds, so there is still a slight regression left there. Any chance you can check if that residual performance regression is somewhere between 1520 and 1606? If there is a performance regression in the new stuff(inconceivable! :-) then it may well have other reasons than USB roundtrip time, the latest revision of the JTAG API handles this in the same way as before: post processing. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lower JTAG clock for SheevaPlug
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tuesday 12 May 2009, Øyvind Harboe wrote: Could we make an interface driver in OpenOCD that would be able to use the urjtag device layer? I had similar thoughts. I thought folk more expert in JTAG would be better to explore such things. There's this Øyvind guy at your company, for example ... ;) There's an interface layer in URjtag, with things like ft2232 and parport support; plus of course JTAG calls. An alternate question would be: couldn't the OOCD core be replaced with the URjtag core? Or vice versa? (NOT that I'm proposing that be done. I'm just pointing out functional similarities. Projects won't necessarily merge or cooperate like that; nor should they. Having some competition is good.) The URjtag stuff uses a different strategy for setup: it detects the devices on the chain, then configures itself based on their IDs. (Using either its own config files, or BSDL if that's enabled.) The config files are purely descriptive, and can't say much ... reading between the lines, I've suspected a testing/SVF focus. Now, I actually prefer that model to the current OOCD model of needing to say this is what you shall find. That's something of a PITA, speaking just as a user, especially for things which *can* be autoconfigured. And in fact, I'm not the only person who's found it handy to use URjtag to look at what's there, so they can come up with an OOCD configuration. BUT ... my vague practical experience suggests that maybe, just maybe, not *all* JTAG chains support that discovery model correctly. Making me think that the better model might indeed prefer autoconfiguring, but accomodate the this is what you'll be seeing model too. Plus, obviously, there will need to be backlinks from the discovered IDs into the config process. Like the debug versions of the DaVinci scan chains, which start (TDI) with an ICEpick -- with the actual SoC identifier, and hosting the boundary scan -- then add a device which we know is an ARM926ejs core even if it doesn't use ARM's manufacturer code, then an ETB11 which *does* use ARM's code. Likewise its non-debug sibling, which works like OMAP3 cores ... gotta talk to that router to get other cores into the scan chain, as those are the things that GDB will eventually talk to. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, May 12, 2009 at 7:15 PM, David Brownell davi...@pacbell.net wrote: On Tuesday 12 May 2009, Ųyvind Harboe wrote: Could we make an interface driver in OpenOCD that would be able to use the urjtag device layer? I had similar thoughts. I thought folk more expert in JTAG would be better to explore such things. There's this Ųyvind guy at your company, for example ... ;) Another thing I'd like to see is JTAG over TCP/IP. OpenOCD would implement a TCP/IP server TCP/IP interface... That may seem like a non-sequitor but JTAG over TCP/IP *is* another interface to OpenOCD which this thread is about. Or? This would be neat for remote development / testing of targets... Use ssh + port forwarding to handle security [chopped off another discussion I'm not following] -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] 4-bit ECC support for Marvell Kirkwood SOC
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tuesday 12 May 2009, Øyvind Harboe wrote: Another thing I'd like to see is JTAG over TCP/IP. OpenOCD would implement a TCP/IP server TCP/IP interface... That may seem like a non-sequitor but JTAG over TCP/IP *is* another interface to OpenOCD which this thread is about. Or? JTAG over TCP/IP resembles JTAG over USB too ... as in, talk to the microcontroller which handles JTAG details. [chopped off another discussion I'm not following] The one about the init model? I wish you would follow. There seems to be no strong reason that OpenOCD should always need to be told here's the only scan chain you should expect to use ... when it could instead just look at the scan chain it finds, then autoconfigure, in common cases. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
On Tue, 12 May 2009, Øyvind Harboe wrote: On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote: About performance: things are reasonable again. It takes 90 seconds to flash 450 KB to NAND instead of 5 minutes. But in the days of rev 1520 this was like 80 seconds, so there is still a slight regression left there. Any chance you can check if that residual performance regression is somewhere between 1520 and 1606? What I was saying is that, compared to 1520, the current head is like 10% slower. But it is way better than 1729 which was 4 times slower. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] 4-bit ECC support for Marvell Kirkwood SOC
On Tue, 12 May 2009, David Brownell wrote: On Tuesday 12 May 2009, Nicolas Pitre wrote: The Kirkwood bootrom expects 4-bit ECC from NAND. This adds 4-bit ECC computation to the NAND support and uses it with SheevaPlug. Hmm, from the outside this sounds like the 4-bit ECC in some TI DaVinci family chips: 10 bytes ECC per 512 bytes data, delivered as eight 10-bit values. Isn't ECC on the Davinci computed in hardware by the NAND controller? But otherwise it is a Reed-Solomon implementation using a x^10 + x^3 + 1 polinomial. Anyone with the same ECC characteristics may reuse this code quite trivially. Stay tuned for Linux support soon as well. Maybe some of this should share code ... probably not the compute backwards part though! No comment ... Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
On Tue, May 12, 2009 at 8:12 PM, Nicolas Pitre n...@cam.org wrote: On Tue, 12 May 2009, Øyvind Harboe wrote: On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote: About performance: things are reasonable again. It takes 90 seconds to flash 450 KB to NAND instead of 5 minutes. But in the days of rev 1520 this was like 80 seconds, so there is still a slight regression left there. Any chance you can check if that residual performance regression is somewhere between 1520 and 1606? What I was saying is that, compared to 1520, the current head is like 10% slower. But it is way better than 1729 which was 4 times slower. I can't explain, off the bat, why svn head would be slower. What if the residual regression happened between 1520 and 1606? Perhaps you could bisect it down to a release between 1520 and 1606? At least it would be good to know the performance of 1520 vs. 1606... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] fix ancient bug SEGFAULT in irscan
On Tue, May 12, 2009 at 8:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I couldn't believe my eyes when I saw what the bug was. irscan has *always* been broken. I checked as far back as svn 345. A couple of possible explanations: - irscan has never really been used - events have somehow conspired to hide the bugs - I'm missing something Known problems in irscan: - does not support 32 bit fields(?). This maybe a problem for omap devices(?) - why not reuse the new drscan code? I may be stupid and/or tired, but what does this mean? int num_fields= num_fields; --Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding 32 bit version of scan fn's in JTAG API
Øyvind Harboe wrote: The idea behind the the u8 * and buf stuff is to handle host endianness. the size of the integers in the array is orthogonal to solving the endianess. I cannot really see the need. Yes it takes a little while to learn, but any work where you stuff bits into the drscan chain needs a lot of careful consideration. The present way of doing this is clear, not very difficult to understand so what IS the problem ? Shouldn't I have brought it up? No problem, but I have this experience every time start with a new processor or supplier. - The Reference manual list all register and bit combinations, in good cases ther are defines correspoinding exactly to this structure using the same names. - The there is a programming library/api, different for every supplier, hiding what is actually going on. - When there is a problem, and there usually are a lot of problems, I have decode the library function, look up what happens in the registers, check the bitfields etc ... - So for me want a programming manual with the exact sequence of register writes, not the nice helper function. - I find it less work to do the register programming than learning a new api for every traget platform. Thats why :) Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding 32 bit version of scan fn's in JTAG API
Target/host big/small endianness and bit reversal is actually somewhat of a red herring in this discussion. jtag_add_dr_scan() scans an array of bits in/out. These bits are represented as an array of integers where lsb is shifted out first. lsb vs. msb is unambigious w.r.t. host endiannes/bit order. Once an int in that array is exhausted, the next int is shifted out lsb first. The total # of bits to shift out is num_fields. Ditto for in_value. I'm suggesting that 32 bits is a more natural fit for openocd code than 8. host / target big/small endian and bit reversal does not enter into the picture for the 32 or 8 bit version of jtag_add_dr_scan(). ? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Outsider's point of view
Sorry to interrupt (; I thought that I'd share my outsider's opinion with all. Just a while ago someone (Zach?) was talking about a need for a stable production cycle with frequent release branches. A 0.2.0 release was mentioned to happen after the recent perforance issues would got fixed (in fact 0.2.0 was mentioned ~3 times since 0.1.0). The performance is back (I've checked and it's even a tiny bit faster than 0.1.0 release on STM32), and the need for 0.2.0 is gone - there are at least 100 new ideas instead. For an average user - like myself - it is very good to know that this version is fine, use it with no fear, but the SVN in the recent weeks is bathed in chaos (; There is always something going on, so picking up a right version is pretty much a lottery. Let's say that I have a comfortable situation, because I know how to compile the package, but - believe me - there are hundreds of domestic ARM developers who know nothing about MinGW, MSYS, autotools and stuff - configuring Eclipse to handle ARM gcc is pretty much a great achievement for them (I know, 'coz I've been there just a while ago). Actually there is NO good description of how to compile OpenOCD for Windows, so it's quite exclusive knowledge. Since 0.1.0 many things have changed - I know about full RLink support and Cortex-A8 handling, but probably many more minor and major stuff had been fixed, introduced or tweaked... Sorry if I've missed something very important... Any chance for a release branch - say - once every 2 months (0.1.0 was put up around the end of January)? BTW 1 - the SVN revision guessing stuff really doesn't work for me... BTW 2 - now the compilation process gives TWO openocd.exe files and the more obvious one (src/openocd.exe) is the wrong one... The right one is placed in src/.libs/openocd.exe (or sth) - that's pretty confusing. And to make my mail a bit more positive - OpenOCD is moving (running?) in a good direction! It's very good that it's moving (running?) forward with great power. Regards! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] J-link/jlink attempt
Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a bit of mention on this list about jlink and thought I would give it a try. I was at r1567 on my initial try (after rebuilding with --enable-jlink configured). I am starting openocd like this: sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg str710.cfg seems as close to the actual str712 as there is in the cfg files. When it starts I see: Error: J-Link Command 0x01 failed (-2) Error: J-Link command EMU_CMD_VERSION failed (-110) repeated 3 times Info : J-Link initial read failed, don't worry Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-2) Error: J-Link command 0xdf failed (-2) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (9190). Workaround: increase set remotetimeout in GDB Error: J-Link setting speed failed (-2) Error: There are no enabled taps? Error: J-Link command 0xdd failed (-2) Error: J-Link command 0xdf failed (-2) Error: usb_bulk_write failed (requested=6, result=-2) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-2) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: J-Link command 0xdd failed (-2) Error: J-Link command 0xdf failed (-2) Error: usb_bulk_write failed (requested=6, result=-2) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: There are no enabled taps? Warn : no telnet port specified, using default port Warn : no gdb ports allocated as no target has been specified Warn : no tcl port specified, using default port Info : accepting 'telnet' connection from 0 Error: J-Link command 0x01 failed (-2) Then I can 'telnet localhost ' OK but everything seem to result in J-Link command failed, e.g., jlink_info J-Link command 0x01 failed (-2) J-Link command EMU_CMD_VERSION failed (-110) I see the same result when I update to the (now) current r1770. Can anyone suggest what I am doing wrong? Thanks, -gene P/S: Have been using rlink interface successfully. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] 4-bit ECC support for Marvell Kirkwood SOC
On Tuesday 12 May 2009, Nicolas Pitre wrote: On Tue, 12 May 2009, David Brownell wrote: On Tuesday 12 May 2009, Nicolas Pitre wrote: The Kirkwood bootrom expects 4-bit ECC from NAND. This adds 4-bit ECC computation to the NAND support and uses it with SheevaPlug. Hmm, from the outside this sounds like the 4-bit ECC in some TI DaVinci family chips: 10 bytes ECC per 512 bytes data, delivered as eight 10-bit values. Isn't ECC on the Davinci computed in hardware by the NAND controller? Yes, on newer chips like DM335/355/365, DA830 (and OMAP-L137). Older chips just have 1-bit HW ECC. But otherwise it is a Reed-Solomon implementation using a x^10 + x^3 + 1 polinomial. Anyone with the same ECC characteristics may reuse this code quite trivially. Stay tuned for Linux support soon as well. Linux *software* support? Patches for the DaVinci 4-bit ECC hardware are slowly wending their way to mainline ... the issue that's not quite resolved is how to use it with large page chips (since there seems to be agreement that clobbering badblock markers via ECC_HW_SYNDROME is Not Good). Maybe some of this should share code ... probably not the compute backwards part though! No comment ... Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote: Sorry to interrupt (; I thought that I'd share my outsider's opinion with all. Not at all. I hope more folks are willing to step up and share their opinions; without feedback, the maintainers cannot know what you think. Thank you for helping to demonstrate how that can be done. Just a while ago someone (Zach?) was talking about a need for a stable production cycle with frequent release branches. A 0.2.0 release was mentioned to happen after the recent perforance issues would got fixed (in fact 0.2.0 was mentioned ~3 times since 0.1.0). The performance is back (I've checked and it's even a tiny bit faster than 0.1.0 release on STM32), and the need for 0.2.0 is gone - there are at least 100 new ideas instead. This idea that OpenOCD needs regular releases is not gone, though I do not endorse the idea of forcing them out on a rigid schedule. While Øyvind indicated he thinks it might take a month, I can see a release happening much sooner, if everyone decides that will be our top priority. However, I would rather the community focus on the release process than a single goal like 0.2.0, because I think we need to be producing bi-weekly stable releases. We just need to get our act together, and planning for a single release will not do that. For an average user - like myself - it is very good to know that this version is fine, use it with no fear, but the SVN in the recent weeks is bathed in chaos (; There is always something going on, so picking up a right version is pretty much a lottery. Let's say that I have a [...] Average users should not be using SVN trunk. The fact that you are using it shows us that the release process needs to be improved. For developers, the trunk should not be a lottery, but users are playing with different odds. [...] comfortable situation, because I know how to compile the package, but - believe me - there are hundreds of domestic ARM developers who know nothing about MinGW, MSYS, autotools and stuff - configuring Eclipse to handle ARM gcc is pretty much a great achievement for them (I know, 'coz I've been there just a while ago). Actually there is NO good description of how to compile OpenOCD for Windows, so it's quite exclusive knowledge. If I have time, I will rectify this by providing some automated scripts to provide a mingw32 build. Mostly, I am tired of breaking that build. Any chance for a release branch - say - once every 2 months (0.1.0 was put up around the end of January)? A regular release schedule should be a priority for the community, and the exact details should be determine soon by a consensus process. Stay tuned. BTW 1 - the SVN revision guessing stuff really doesn't work for me... BTW 2 - now the compilation process gives TWO openocd.exe files and the more obvious one (src/openocd.exe) is the wrong one... The right one is placed in src/.libs/openocd.exe (or sth) - that's pretty confusing. This is a result of libtool support. You should be ignoring everything in the .libs directories and using libtool (e.g. libtool gdb openocd.exe). The sr/openocd.exe is a script that magically makes the rest of the in-tree libraries available to the uninstalled versions. And to make my mail a bit more positive - OpenOCD is moving (running?) in a good direction! It's very good that it's moving (running?) forward with great power. Thanks for the positive feedback! It is good to know that OpenOCD users appreciate all the hard work being done to move things forward. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On Tuesday 12 May 2009, Øyvind Harboe wrote: I don't know when the cats can be herded into a 0.2 release at this point, but I'm pretty sure it's a month away at least. Hmm, if you don't know ... then who could? The process *does* seem, for now, as if it's largely commit patches to SVN without any publicly defined goals/targets or visible criteria. Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. If that *had* been split and resubmitted ... there seems to be no process in place to say which changes are safe to merge *now* versus which can't merge because they'd destabilize release plans, versus which are worth merging even if they *do* destabilize things (because e.g. fixing TMS bugs is critical). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tuesday 12 May 2009, Zach Welch wrote: On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote: [snip] There seems to be no strong reason that OpenOCD should always need to be told here's the only scan chain you should expect to use ... when it could instead just look at the scan chain it finds, then autoconfigure, in common cases. You have convinced me that OpenOCD should add an autoconfigure mechanism but continue to allow explicit manual configuration. Good! So this will make The List? :) I seem to recall this having been discussed in the past, but perhaps I am remembering some other feature under recent development. No idea. I'm a user over here, not a developer. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, 2009-05-12 at 15:49 -0700, David Brownell wrote: On Tuesday 12 May 2009, Zach Welch wrote: On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote: [snip] There seems to be no strong reason that OpenOCD should always need to be told here's the only scan chain you should expect to use ... when it could instead just look at the scan chain it finds, then autoconfigure, in common cases. You have convinced me that OpenOCD should add an autoconfigure mechanism but continue to allow explicit manual configuration. Good! So this will make The List? :) It already has. ;) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On Tue, 2009-05-12 at 15:36 -0700, David Brownell wrote: On Tuesday 12 May 2009, Øyvind Harboe wrote: I don't know when the cats can be herded into a 0.2 release at this point, but I'm pretty sure it's a month away at least. Hmm, if you don't know ... then who could? I do. Cats can be herded. I would try to use cream and treats first. If those measures fail, I suggest loud noises and squirt bottles. :) The process *does* seem, for now, as if it's largely commit patches to SVN without any publicly defined goals/targets or visible criteria. Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. Precisely, but I can help us take these next steps too. Such criteria impose restrictions, and such could easily railroad the community down lines that it does not want to travel. I have been taking my time to assess the needs of the community and formulate a list of criteria for future development, along with a plan for gradually imposing limitations in such a way that avoids disenfranchisement of existing contributors. Nevertheless, I expect the mere presence of some of those words to ring alarm bells in some members of the community; we cannot please everyone. Simultaneously, I do not want to annoy everybody either. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? *cough* *mumble* *punt* Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. This is not what happened. I provided that feedback in order to be able to provide my own assistance, but I made the point that I was deferring to others' judgment for the monolithic patch. Unfortunately, this minor detail seems to have been lost in the shuffle, and it does not matter in the bigger picture of what happened. If that *had* been split and resubmitted ... there seems to be no process in place to say which changes are safe to merge *now* versus which can't merge because they'd destabilize release plans, versus which are worth merging even if they *do* destabilize things (because e.g. fixing TMS bugs is critical). If split and resubmitted, problems with any piece could have been backed out and the rest left intact. They could flow into the trunk after being reviewed, and the split would make that entire process easier. I think it remains possible to revive and submit that work, and I have not written it off yet. But I am not arguing with your point. We need better processes, and I hope we are moving down that road. I have started a document that should address all areas of concern, but it has a long way to go before it even represents a full draft. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, 2009-05-12 at 17:21 -0700, Rick Altherr wrote: [snip] I had mentioned this a while back. I've been thinking through the approach and I'm slowly settling on a C++ implementation that would essentially be a rewrite. That said, I believe an autoconfig mechanism could be done on the current implementation, but it would probably be pretty difficult. I'll start drafting the formal proposal for my idea. Assuming you agree that a C++ implementation amounts to a new project, I think you might be better off starting a new project on berliOS (with a new mailing list and SVN repository). I would subscribe and might even be talked into contributing, but I would want to see the C++ style guide as much as any design or implementation proposals. ;) Personally, I think this list is starting to see enough traffic about the existing implementation that discussions of a new C++ branch here will cause confusion that affects the community's focus and direction. While announcements would be okay, I think we need to show a concerted effort on producing high-quality release of the existing implementation. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On May 12, 2009, at 3:26 PM, Zach Welch wrote: On Tue, 2009-05-12 at 10:32 -0700, David Brownell wrote: [snip] There seems to be no strong reason that OpenOCD should always need to be told here's the only scan chain you should expect to use ... when it could instead just look at the scan chain it finds, then autoconfigure, in common cases. You have convinced me that OpenOCD should add an autoconfigure mechanism but continue to allow explicit manual configuration. I seem to recall this having been discussed in the past, but perhaps I am remembering some other feature under recent development. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I had mentioned this a while back. I've been thinking through the approach and I'm slowly settling on a C++ implementation that would essentially be a rewrite. That said, I believe an autoconfig mechanism could be done on the current implementation, but it would probably be pretty difficult. I'll start drafting the formal proposal for my idea. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On May 12, 2009, at 3:36 PM, David Brownell wrote: On Tuesday 12 May 2009, Øyvind Harboe wrote: I don't know when the cats can be herded into a 0.2 release at this point, but I'm pretty sure it's a month away at least. Hmm, if you don't know ... then who could? The process *does* seem, for now, as if it's largely commit patches to SVN without any publicly defined goals/targets or visible criteria. Or rather, every time the set of goals is established, it gets thrown out the window a week later. Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. Yup. A todo list is great, but we need a more rigid definition of what need to be done to make the next release. Essentially, we need to decide on features for a release. Any large changes need to be aligned with a feature. Small fixes should be accepted even if they don't align with a feature. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? Right now, the options are merge or let it die. For nearly everything that hits the list, it is automatically committed to SVN with little review or commentary. I'm not a fan of this. Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. If that *had* been split and resubmitted ... there seems to be no process in place to say which changes are safe to merge *now* versus which can't merge because they'd destabilize release plans, versus which are worth merging even if they *do* destabilize things (because e.g. fixing TMS bugs is critical). If it _had_ been split and resubmitted, I'd have voted to take the FT2232 fixes and the TMS sequencing updates. Both had been discussed for quite a while. They were implemented in an opt-in model. It was safe to take into trunk with no real impact unless you opted-in. Of course, I'd love a more formal process in which we decide on the feature set for the next release and only accept things into it that implement those features. Of course, we should also allow overlap of releases (branch the release from trunk a while before the release is finished) and also allow radical development to occur on branches where they could be merged into trunk after the release is branched. See any large project for examples. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: libopenocd strategy
On May 12, 2009, at 5:48 PM, Zach Welch wrote: On Tue, 2009-05-12 at 17:21 -0700, Rick Altherr wrote: [snip] I had mentioned this a while back. I've been thinking through the approach and I'm slowly settling on a C++ implementation that would essentially be a rewrite. That said, I believe an autoconfig mechanism could be done on the current implementation, but it would probably be pretty difficult. I'll start drafting the formal proposal for my idea. Assuming you agree that a C++ implementation amounts to a new project, I think you might be better off starting a new project on berliOS (with a new mailing list and SVN repository). I would subscribe and might even be talked into contributing, but I would want to see the C++ style guide as much as any design or implementation proposals. ;) Personally, I think this list is starting to see enough traffic about the existing implementation that discussions of a new C++ branch here will cause confusion that affects the community's focus and direction. While announcements would be okay, I think we need to show a concerted effort on producing high-quality release of the existing implementation. Cheers, Zach I agree. Of course, it is also possible to do the autodetection in C, but it would still require a pretty significant infrastructure change. Either way, this would be a long term project that should be done as a branch or as a new project. I suspect it would be better to do as a branch as it isn't _really_ a new project and much of the code for targets and interfaces would reused. At this stage though, any discussions would be merely about the proposal and what we want to do longer term. It should in no way impact the progress on current releases or projects. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On Tuesday 12 May 2009, Rick Altherr wrote: On May 12, 2009, at 3:36 PM, David Brownell wrote: On Tuesday 12 May 2009, Øyvind Harboe wrote: I don't know when the cats can be herded into a 0.2 release at this point, but I'm pretty sure it's a month away at least. Hmm, if you don't know ... then who could? The process *does* seem, for now, as if it's largely commit patches to SVN without any publicly defined goals/targets or visible criteria. Or rather, every time the set of goals is established, it gets thrown out the window a week later. I'd have said those goals weren't really established then! :) Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. Yup. A todo list is great, but we need a more rigid definition of what need to be done to make the next release. Essentially, we need to decide on features for a release. Any large changes need to be aligned with a feature. Small fixes should be accepted even if they don't align with a feature. That's one process. Not all small patches are safe enough to merge at any time though; and not all large changes should necessarily be aligned with target features of some release. (Example, some types of code cleanup.) Patches should IMO be graded more by the risk/reward ratio ... and nearer to release milestons, that ratio should shrink to near zero. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? Right now, the options are merge or let it die. For nearly everything that hits the list, it is automatically committed to SVN with little review or commentary. I'm not a fan of this. Right. I think some patches should certainly be able to fit into the keep that in the -next queue category. Effective review is probably not easy here; who knows JTAG well enough to contribute non-cosmetic feedback? One process that could hardly help but improve things is to define a release manager who herds patches for a given release ... and someone else who herds patches for the next one, keeping the queues in sync. OpenOCD doesn't seem to have anyone responsible for the next release, whatever it's called (maybe a datecode like 2009-06?). Such roles should ideally be rotated. Some projects have teams defining them. Regular status updates help too. Linux has clear progress markers via version codes (2.6.29, then merge window, then 2.6.30-rc1, etc) *and* at least brief status reports every weeks when a new version is tagged. GCC has different status reports (which get rotated among release team members) and very clear tree status. OOCD has nothing similar. Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. If that *had* been split and resubmitted ... there seems to be no process in place to say which changes are safe to merge *now* versus which can't merge because they'd destabilize release plans, versus which are worth merging even if they *do* destabilize things (because e.g. fixing TMS bugs is critical). If it _had_ been split and resubmitted, I'd have voted to take the FT2232 fixes and the TMS sequencing updates. Both had been discussed for quite a while. They were implemented in an opt-in model. It was safe to take into trunk with no real impact unless you opted-in. Both sounded technically plausible to me. But ... neither was provided as an independently reviewable patch. If they were merged, I would have argued against opt-in. When a patch is basically good, any remaining bugs should just get fixed. If it isn't, it shouldn't merge. Of course, I'd love a more formal process in which we decide on the feature set for the next release and only accept things into it that implement those features. Of course, we should also allow overlap of releases (branch the release from trunk a while before the release is finished) and also allow radical development to occur on branches where they could be merged into trunk after the release is branched. See any large project for examples. Right. The guts of it boil down, IMO, to defining some responsible roles ... and having people meet those roles. Given that, some tools work better than others. GIT makes it easy to have any number of branches without needing to grant excess permissions to anyone, for example. But we have all probably seen projects managed effectively using tools like CVS or SVN. The tools are secondary to having a process which uses them well. - Dave - Dave -- Unsigned
Re: [Openocd-development] RFC: libopenocd strategy
On Tue, 2009-05-12 at 08:02 -0700, David Brownell wrote:
On Tuesday 12 May 2009, Zach Welch wrote:
+ Which do we want: jtag.h or jtag/jtag.h? **
openocd/jtag.h since there are other jtag projects
working to provide a library interface (e.g. urjtag).
I grok and agree. That said, I think that such would require some
reorganization of the source tree (in ways that may not be desired).
The similar (but approaching pedantic) openocd/jtag/jtag.h would
require far less restructuring ('svn mv src/ openocd/', in essence).
Neither should be done without input from the community, but I could
make these changes fairly quickly. I also have started a unit test
suite that uses the public headers, so I am eager to move forward.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] J-link/jlink attempt
On Tue, 2009-05-12 at 17:59 -0400, Gene Smith wrote: Someone loaned me an IAR evaluation board STR712 (made by Olimex) and a yellow IAR J-link (marked J-LINK-ARM-KS on bottom). I had seen quite a bit of mention on this list about jlink and thought I would give it a try. I was at r1567 on my initial try (after rebuilding with --enable-jlink configured). I am starting openocd like this: sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg str710.cfg seems as close to the actual str712 as there is in the cfg files. When it starts I see: Error: J-Link Command 0x01 failed (-2) Error: J-Link command EMU_CMD_VERSION failed (-110) repeated 3 times The ENOENT error (translated via errno.h) seems to indicate that the device is not connected. I remember having similar problems, but I do not immediately recall what the problem was. It may have been an improper connections (e.g. a pair of reversed pins) between the J-Link header and my target device, or it might have been a configuration issue with my host system. I do not believe it was directly OpenOCD's fault, but I do wish it could more informative here. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On Tuesday 12 May 2009, Magnus Lundin wrote: David Brownell wrote: Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. The old list, or the new rebuild everything into loadable modules stuff? The last list I saw. Might be time to re-post it. A libocd would be one bullet on such a list. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? That seems like a big un-answerable question ... and thus a significant problem. Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. Well, since it is more than five days old I suppose it is dead fish. Unfortunate but true. But I can tell you that all the state transition stuff works well, both in 7 state version and and shortest path. There are some issues about PAUSE - SCAN paths does not go through CAPTURE, but this path is never used in the present code. What I recall was addition of some logging to help ensure the drivers go through the same state transitions. That seems like an area where regression-testing would be good; not just useful for debugging. I do not know about high speed ft2232h and ft4232h since I havnt got any such hardware. I think Amontec should send several of us some free HS jtag keys to help out. What do you think? :) Reconnect looks ok but not tested. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outsider's point of view
On May 12, 2009, at 6:09 PM, David Brownell wrote: Zack's list seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria. Yup. A todo list is great, but we need a more rigid definition of what need to be done to make the next release. Essentially, we need to decide on features for a release. Any large changes need to be aligned with a feature. Small fixes should be accepted even if they don't align with a feature. That's one process. Not all small patches are safe enough to merge at any time though; and not all large changes should necessarily be aligned with target features of some release. (Example, some types of code cleanup.) Patches should IMO be graded more by the risk/reward ratio ... and nearer to release milestons, that ratio should shrink to near zero. Agreed. Risk/reward works well as a metric for rating patches for integration. The difficulty is determining the risk and the reward. Everyone seems to have a different set of criteria for those. Even well established criteria doesn't solve all the problems since no two patches are alike. Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release? Right now, the options are merge or let it die. For nearly everything that hits the list, it is automatically committed to SVN with little review or commentary. I'm not a fan of this. Right. I think some patches should certainly be able to fit into the keep that in the -next queue category. Effective review is probably not easy here; who knows JTAG well enough to contribute non-cosmetic feedback? Actually, a fair number of us _do_ know JTAG fairly well. The target protocols are another matter. One process that could hardly help but improve things is to define a release manager who herds patches for a given release ... and someone else who herds patches for the next one, keeping the queues in sync. OpenOCD doesn't seem to have anyone responsible for the next release, whatever it's called (maybe a datecode like 2009-06?). Such roles should ideally be rotated. Some projects have teams defining them. Technically, I took that role for the 0.1.0 release. There were two factors that have make continuing as such for 0.2.0 challenging: my home life and lack of community support. My home life is in a bit of turmoil due to a home remodel, new baby, and looking for a new day job. The community support was nearly non-existent. Even slowing things down for 0.1.0 was difficult but I managed. As soon as 0.1.0 was released, trunk had already progressed well ahead and was in chaos. Attempting to slow things down and establish which in-progress developments need to be finished has been met with resistance. As soon as one in-progress item is finished, 3 others have been partially introduced. _If_ a process was put in place for accepting patches to trunk, the job of release management _might_ be possible. Otherwise, it primarily means picking an arbitrary revision of trunk and making it the branch. Then, as in-progress items are finished, merge the patches from trunk into the branch. It sucks and makes the release manager do _a lot_ of work. It's not an easy job watching every commit and determining if it should be taken for the release or not. It's also not easy backporting fixes that don't apply cleanly because trunk has moved on with other widespread changes. Enough ranting from me. We need to set some criteria for introducing patches into trunk and formalize the process. We also need to establish the same for release branches. Then, everyone with commit access needs to respect those processes. If we all play by the same rules, cutting releases more frequently will be easy and the overall quality of trunk will be better. Regular status updates help too. Linux has clear progress markers via version codes (2.6.29, then merge window, then 2.6.30-rc1, etc) *and* at least brief status reports every weeks when a new version is tagged. GCC has different status reports (which get rotated among release team members) and very clear tree status. OOCD has nothing similar. Right. This follows from the above. If you have a process, it is easy to send out updates about what stage we are in. The releases don't need to be on a strict timeline, but knowing that this release is slowing down and another will be opening helps patch authors set their schedules and use their time effectively. Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with please split into smaller patches so this can be reviewed, as happened. If that *had*
Re: [Openocd-development] Outsider's point of view
Right. I think some patches should certainly be able to fit into the keep that in the -next queue category. Effective review is probably not easy here; who knows JTAG well enough to contribute non-cosmetic feedback? Actually, a fair number of us _do_ know JTAG fairly well. That's good ... I guess I was thinking more about the difficulties in expanding that set. (The code could not have gotten to its current state without at least a core of folk with the relevant skills!) The target protocols are another matter. Right; needs hardware, testers, users, etc. One process that could hardly help but improve things is to define a release manager who herds patches for a given release ... and someone else who herds patches for the next one, keeping the queues in sync. OpenOCD doesn't seem to have anyone responsible for the next release, whatever it's called (maybe a datecode like 2009-06?). Such roles should ideally be rotated. Some projects have teams defining them. Technically, I took that role for the 0.1.0 release. There were two factors that have make continuing as such for 0.2.0 challenging: my home life and lack of community support. My home life is in a bit of turmoil due to a home remodel, new baby, and looking for a new day job. The community support was nearly non-existent. Getting a release out is rarely a picnic even in the best of cases! And it seems like you really needed help that you weren't getting (but should have had): Even slowing things down for 0.1.0 was difficult but I managed. As soon as 0.1.0 was released, trunk had already progressed well ahead and was in chaos. Attempting to slow things down and establish which in-progress developments need to be finished has been met with resistance. As soon as one in-progress item is finished, 3 others have been partially introduced. _If_ a process was put in place for accepting patches to trunk, the job of release management _might_ be possible. Likewise, for deferring some patches until the next release. This is one of the things that Linux does interestingly. Except for a brief merge window and things like new code that can't break anything (new drivers etc), the trunk is managed *always* as a release stage. Everything else gets batched up to merge later, in that merge window. It took time to get that process working well, but at this point there are a LOT of developers who are used to it. Otherwise, it primarily means picking an arbitrary revision of trunk and making it the branch. Then, as in-progress items are finished, merge the patches from trunk into the branch. It sucks and makes the release manager do _a lot_ of work. It's not an easy job watching every commit and determining if it should be taken for the release or not. It's also not easy backporting fixes that don't apply cleanly because trunk has moved on with other widespread changes. Hrrm, yes. Those all seem like *very* significant problems. It should not have been your job, actually ... folk should have said this needs to get into next release when the patches were submitted, and if it did need tweaks the work should have been done by the patch submitter. Enough ranting from me. We need to set some criteria for introducing patches into trunk and formalize the process. We also need to establish the same for release branches. Then, everyone with commit access needs to respect those processes. If we all play by the same rules, cutting releases more frequently will be easy and the overall quality of trunk will be better. Given what I've seen work on other projects, I'd agree. Regular status updates help too. Linux has clear progress markers via version codes (2.6.29, then merge window, then 2.6.30-rc1, etc) *and* at least brief status reports every weeks when a new version is tagged. GCC has different status reports (which get rotated among release team members) and very clear tree status. OOCD has nothing similar. Right. This follows from the above. If you have a process, it is easy to send out updates about what stage we are in. The releases don't need to be on a strict timeline, but knowing that this release is slowing down and another will be opening helps patch authors set their schedules and use their time effectively. Status is both output of, and feedback into, the process. Without status, you don't really have a process ... once you start tracking and measuring things (against goals), that is itself a process. Chicken/egg. If they were merged, I would have argued against opt-in. When a patch is basically good, any remaining bugs should just get fixed. If it isn't, it shouldn't merge. Actually, in this case, opt-in was the right model. In general I agree with you, but when you are changing such a fundamental part of the code, it will take time for the other pieces to be
Re: [Openocd-development] Outsider's point of view
David Brownell wrote: Right. I think some patches should certainly be able to fit into the keep that in the -next queue category. Effective review is probably not easy here; who knows JTAG well enough to contribute non-cosmetic feedback? Actually, a fair number of us _do_ know JTAG fairly well. That's good ... I guess I was thinking more about the difficulties in expanding that set. (The code could not have gotten to its current state without at least a core of folk with the relevant skills!) Here is a quick primer for those new to JTAG: JTAG is unnecessarily confusing, because JTAG is often confused with boundary scan, which is just one of its possible functions. JTAG is simply a communication interface designed to allow communication to functions contained on devices, for the designed purposes of initialisation, programming, testing, debugging, and anything else you want to use it for (as a chip designer). Think of JTAG as I2C for testing. It doesn't define what it can do, just a logical interface that allows a uniform channel for communication. See: http://en.wikipedia.org/wiki/Joint_Test_Action_Group and http://www.inaccessnetworks.com/projects/ianjtag/jtag-intro/jtag-state-machine-large.png The first page (among other things) shows a logical representation describing how multiple devices are wired up using JTAG. JTAG does not specify, data rates or interface levels (3.3V/1.8V, etc) each device can support different data rates/interface logic levels. How to wire them in a compatible way is an exercise for an engineer. Basically TMS controls which shift register is placed on the device, between TDI and TDO. The second diagram shows the state transitions on TMS which will select different shift registers. The first thing you need to do is reset the state machine, because when you connect to a chip you dont know what state the jtag is in,you need to clock TMS as 1, at least 7 times. This will put you into Test Logic Reset State. Knowing this, you can, once reset, then track what each transition on TMS will do, and hence know what state the jtag state machine is in. There are 2 types of shift registers. The Instruction shift register and the data shift register. The sizes of these are undefined, and can change from chip to chip. The Instruction register is used to select which Data register/data register function is used, and the data register is used to read data from that function or write data to it. Each of the states control what happens to either the data register or instruction register. For example, one of the data registers will be known as bypass this is (usually) a single bit which has no function and is used to bypass the chip. Eg, assume we have 3 identical chips, wired up like the picture and each has a 3 bit instruction register, and there are 2 known instructions (110 = bypass, 010 = some other function) if we want to use some other function, on the second chip in the line, and not change the other chips we would do these transitions: From Test Logic Reset - TMS goes: 0 1 1 0 0 Which puts every chip in the chain into the Shift IR state Then (while holding TMS as 0) TDI goes: 0 1 1 0 1 0 0 1 1 which puts the following values in the instruction shift register for each chip [110] [010] [110] It is reversed, because we shift out the least significant bit first. Then we transition TMS: 1 1 1 1 0 0 Which outs us in the Shift DR state Now when we clock data onto TDI (again while holding TMS to 0) , the data shifts through the data registers, and because of the instruction registers we selected (some other function has 8 bits in its data register), our total data register in the chain looks like this: 0 0 The first and last bit are in the bypassed chips, so values read from them are irrelevant and data written to them is ignored. But we need to write bits for those registers, because they are in the chain. If we wanted to write 0xF5 to the data register we would clock out of TDI (holding TMS to 0): 0 1 0 1 0 1 1 1 1 0 again we are clocking the lsbit first Then we would clock TMS: 1 1 0 Which updates the selected data register with the value 0xF5 and returns us to run test idle. If we needed to read the data register before over-writing it with F5, no sweat, that's already done, because the TDI/TDO are set up as a circular shift register, so if you write enough bits to fill the shift register, you will receive the captured contents of the data registers simultaneously on TDO. That's JTAG in a nutshell. On top of this, you need to get specs for chips and work out what the various instruction registers/data registers do, so you can actually do something useful. That's where it gets interesting. But JTAG in and of itself is actually very very simple. Strontium. ___ Openocd-development mailing list Openocd-development@lists.berlios.de
