[Openocd-development] arm7_9_common.c Documentation Updates
Hey all,
This is a patch that adds some function block Doxygen comments for a
number of the functions in arm7_9_command.c. I'm trying to keep the
patches small so that those who know the functions well don't have a lot
to read all of the time. Besides, I have to learn what the functions do
:). This patch also includes a little typo in the code. Look at the
very last change to see what I mean. If the community dislikes the
Javadoc type commenting, let me know and I can switch over to the more
Doxygen form with all the slashes and what not. Thanks.
// Dean Glazeski
Index: arm7_9_common.c
===
--- arm7_9_common.c (revision 1806)
+++ arm7_9_common.c (working copy)
@@ -50,6 +50,12 @@
int handle_arm7_9_dcc_downloads_command(struct command_context_s *cmd_ctx,
char *cmd, char **args, int argc);
int handle_arm7_9_etm_command(struct command_context_s *cmd_ctx, char *cmd,
char **args, int argc);
+/**
+ * Clear watchpoints for an ARM7/9 target.
+ *
+ * @param arm7_9 Pointer to the common struct for an ARM7/9 target
+ * @return JTAG error status after executing queue
+ */
static int arm7_9_clear_watchpoints(arm7_9_common_t *arm7_9)
{
embeddedice_write_reg(arm7_9-eice_cache-reg_list[EICE_W0_CONTROL_VALUE],
0x0);
@@ -62,6 +68,13 @@
return jtag_execute_queue();
}
+/**
+ * Assign a watchpoint to one of the two available hardware comparators in an
+ * ARM7 or ARM9 target.
+ *
+ * @param arm7_9 Pointer to the common struct for an ARM7/9 target
+ * @param breakpoint Pointer to the breakpoint to be used as a watchpoint
+ */
static void arm7_9_assign_wp(arm7_9_common_t *arm7_9, breakpoint_t *breakpoint)
{
if (!arm7_9-wp0_used)
@@ -82,7 +95,13 @@
}
}
-/* set up embedded ice registers */
+/**
+ * Setup an ARM7/9 target's embedded ICE registers for software breakpoints.
+ *
+ * @param arm7_9 Pointer to common struct for ARM7/9 targets
+ * @return Error codes if there is a problem finding a watchpoint or the result
+ * of executing the JTAG queue
+ */
static int arm7_9_set_software_breakpoints(arm7_9_common_t *arm7_9)
{
if (arm7_9-sw_breakpoints_added)
@@ -137,7 +156,12 @@
return jtag_execute_queue();
}
-/* set things up after a reset / on startup */
+/**
+ * Setup the common pieces for an ARM7/9 target after reset or on startup.
+ *
+ * @param target Pointer to an ARM7/9 target to setup
+ * @return Result of clearing the watchpoints on the target
+ */
int arm7_9_setup(target_t *target)
{
armv4_5_common_t *armv4_5 = target-arch_info;
@@ -146,6 +170,18 @@
return arm7_9_clear_watchpoints(arm7_9);
}
+/**
+ * Retrieves the architecture information pointers for ARMv4/5 and ARM7/9
+ * targets. A return of ERROR_OK signifies that the target is a valid target
+ * and that the pointers have been set properly.
+ *
+ * @param target Pointer to the target device to get the pointers from
+ * @param armv4_5_p Pointer to be filled in with the common struct for ARMV4/5
+ * targets
+ * @param arm7_9_p Pointer to be filled in with the common struct for ARM7/9
+ * targets
+ * @return ERROR_OK if successful
+ */
int arm7_9_get_arch_pointers(target_t *target, armv4_5_common_t **armv4_5_p,
arm7_9_common_t **arm7_9_p)
{
armv4_5_common_t *armv4_5 = target-arch_info;
@@ -167,8 +203,16 @@
return ERROR_OK;
}
-/* we set up the breakpoint even if it is already set. Some action, e.g. reset
- * might have erased the values in embedded ice
+/**
+ * Set either a hardware or software breakpoint on an ARM7/9 target. The
+ * breakpoint is set up even if it is already set. Some actions, e.g. reset,
+ * might have erased the values in Embedded ICE.
+ *
+ * @param target Pointer to the target device to set the breakpoints on
+ * @param breakpoint Pointer to the breakpoint to be set
+ * @return For hardware breakpoints, this is the result of executing the JTAG
+ * queue. For software breakpoints, this will be the status of the
+ * required memory reads and writes
*/
int arm7_9_set_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
{
@@ -280,6 +324,18 @@
return retval;
}
+/**
+ * Unsets an existing breakpoint on an ARM7/9 target. If it is a hardware
+ * breakpoint, the watchpoint used will be freed and the Embedded ICE registers
+ * will be updated. Otherwise, the software breakpoint will be restored to its
+ * original instruction if it hasn't already been modified.
+ *
+ * @param target Pointer to ARM7/9 target to unset the breakpoint from
+ * @param breakpoint Pointer to breakpoint to be unset
+ * @return For hardware breakpoints, this is the result of executing the JTAG
+ * queue. For software breakpoints, this will be the status of the
+ * required memory reads and writes
+ */
int arm7_9_unset_breakpoint(struct target_s *target, breakpoint_t *breakpoint)
{
Re: [Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes
Committed. I've updated the copyright notice so that it is clear that Michael Bruck is the first author(even if the copyright is held by someone else). Let me know if it needs updating. -- Ø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] arm7_9_common.c Documentation Updates
Committed in 1809 I missed the bugfix/typo until I reviewed your code :-) 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] JTAG, FT2232 and JLink
On Mon, May 18, 2009 at 6:36 AM, Rick Altherr kc8...@kc8apf.net wrote: On May 17, 2009, at 9:03 PM, David Brownell wrote: On Friday 15 May 2009, Øyvind Harboe wrote: So apply this patch? Can anyone test? jtagpatch.txt It failed for me on an ft2232 device. Hmm. It looks like the jtag.c changes turn on the new short sequence table for FT2232 and JLink even though the drivers aren't ready. That should be a one-line change to that patch. Once we bring in the FT2232 patch, we can reenable the short table for FT2232. Could you take charge of merging in this code in a suitable # of commits? I don't have that hardware handy to talk to + I'm away some this week and all of next. In terms of getting 0.2 out of the door it would be nice to have all major projects synched up before we start testing rounds... -- Ø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] AT91SAM7X256 Flash and verify_image
What could be going on is that the verify algorithm, which runs on the target, crashed somehow. Here is essentially what verify does: 1. uploads a small application to the target 2. this app runs a crc on the flash 3. OpenOCD checks that the crc is correct Try a reset init before you run verify... Also you can try dump_image to check if the flash was programmed correctly. Obviously error messages could be better here. If you can figure out a more precise cause, we could look at improving error messages. -- Ø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] PIC32 openocd status
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Strontium Verzonden: maandag 18 mei 2009 4:06 Aan: Xiaofan Chen CC: openocd-development@lists.berlios.de Onderwerp: Re: [Openocd-development] PIC32 openocd status This is wrong. ICSP is Microchip's proprietory protocol for programming and debugging. The ICSP module is independent from the EJTAG module in PIC32. You can read Chapter 33 of the PIC32MX Family Manual for more information. I didn't make it up. I read it. PIC32MX Flash Programming Specification 61145D.pdf : Section 5: EJTAG is designed for debugging. However that same functionality can be used to allow programming. PIC do not need to re-specify EJTAG, as that is available from MIPS. I have found no suggestion that the PIC32 does not implement a compliant EJTAG core, and as ICSP is just de-multiplexed into 4 wire jtag internally, there is no reason why EJTAG operations will not operate as expected over ICSP. There are lots of MIPS chips that have an EJTAG core. An EJTAG implementation in OpenOCD would be awesome. PIC32 is a nice cheap platform to develop and test this with. Gentlemen, AFAIK EJTAG is already implemented in OpenOCD (I'm using it for another MIPS based SOC to program external flash). I just don't know how complete it is in respect to debugging/single stepping. The flash programming routines for PIC32 are also available in OpenOCD. So I guess everything is available in OpenOCD to program a PIC32. Slighty off-topic: I think the MIPS GCC compiler from Codesourcery can be used for PIC32 straight away. It is based on GCC 4.x (not the old 3.x GCC), has newlib support and isn't crippled! The C library from mspgcc (GCC for TI's MSP430 series) is a usefull replacement for newlib because it is really really small. I had little problems compiling it for ARM. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ARM11 cleanup stale dependencies with generic arm code; added comments and whitespace fixes
On Mon, May 18, 2009 at 6:51 AM, Rick Altherr kc8...@kc8apf.net wrote: On May 17, 2009, at 2:40 PM, Michael Bruck wrote: - remove stale interdepencies between arm11 and arm7_9_common - added comments - fixed some indentation Michael openocd-arm11-small-fixes___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Is there someone more familiar with the ARM11 code that can comment on this? From my knowledge, ARM11 is an ARMv6 part and shouldn't have a dependency on the ARMv4/5 code. Sadly, I don't know enough about OpenOCD's implementation of the ARM target support to know if separating them is correct. The other ARM code is layered so that more advanced cores re-use the code of earlier cores. But that is a huge sparsely documented package that I didn't have time to dig into during the ARM11 port. That is why ARM11 is a clean room port that is not connected to the other ARM layers. The dependencies are there because I used a skeleton from another driver as starting point and never got around analyzing what this bit of code does. I only found it now after the doxygen docs highlighted some unexpected dependencies in the header files. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I agree. I'll get to reviewing the patches in depth tonight and hopefully get them committed. It would be great to have Magnus Lundin's changes committed too, just to keep things in sync... Which ones do you mean ? Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 11:12 AM, Michael Bruck mbr...@digenius.de wrote: On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I agree. I'll get to reviewing the patches in depth tonight and hopefully get them committed. It would be great to have Magnus Lundin's changes committed too, just to keep things in sync... Which ones do you mean ? jlink.c, ft2232.c and jtag.c had lots of changes from Dick Hollonbeck (amongst others). Magnus Lundin is currently working off svn 1606 to concentrate on those particular issues. I'd like to have them merged in w/svn head so we can everybody back up to speed on svn head. -- Ø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] CFI driver chip/bus width.
Hello All: Thanks a lot for the prompt answers, unlike this e-mail. I've been off from the office since my post, so sorry for it. I now notice I failed to provide sufficient details about the issue at discussion. The flash uses is a 16bit data width, but it is connected using just 8 bit width. Only the lower data byte is output by the chip and the A-1 address line is used. So in summary, one 16bit width flash chip used as 8bit width by a 8bit data width processor. On Thursday 14 May 2009 22:31:08 Michael Schwingen wrote: Raúl Sánchez Siles wrote: Hello all: I have noticed some issues on CFI flash driver related to chip and bus width affecting read and writes. The system I'm dealing with is based on a Vitesse switch chip which embeds an ARM926ejs processor. It additionally provides RAM and flash controller. In this case we are using an spansion S29GL128 16MB flash chip, using a 8bit width data bus layout, so on each read/write cycle we can only retrieve 1byte at once. The flash chip data bus width is 16bit. I declare the flash like this: flash bank cfi 0x8000 0x100 1 2 0 You mean you have *two* of those flash chips, each connected to one 8-bit half of the 16-bit bus? No, read above. = 1st problem (writing): [...] I guess the x16_as_x8 option defined but not used should be aimed at handling this, but this is unimplemented currently. Um - no. The x16_as_x8 option is used for 16-bit flashes that can be used with an 8-bit data bus. The reason for that option is that in that mode, the magic address values used for commands is shifted 1 bit against what is used on real 8-bit flashs. The option should only tell that a 16-bit flash chip is connected to a 8-bit bus - having multiple such chips in parallel must be handled by the chip/bus geometry handling. And again, I think this is the point. I'll try to implement this parameter. Looks like what I only need is that magic, it's only that so far I wasn't able to make the flash work any other way. I think I aim that the following line works: flash bank cfi 0x8000 0x100 1 1 0 x16_as_x8 Please, correct me if I'm wrong. You might have a look at the CFI code in u-boot, which I *think* does handle this situation correct, however, I have no board with such a flash layout, so I can't really tell. Thanks, I'll take a look. cu Michael Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 11:25 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, May 18, 2009 at 11:12 AM, Michael Bruck mbr...@digenius.de wrote: On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I agree. I'll get to reviewing the patches in depth tonight and hopefully get them committed. It would be great to have Magnus Lundin's changes committed too, just to keep things in sync... Which ones do you mean ? jlink.c, ft2232.c and jtag.c had lots of changes from Dick Hollonbeck (amongst others). Magnus Lundin is currently working off svn 1606 to concentrate on those particular issues. I'd like to have them merged in w/svn head so we can everybody back up to speed on svn head. Do we have a time frame for that? Can't Magnus split these changes up into small independent pieces and commit them to the trunk regularly? This way he can update his working tree from the trunk and get my and other's commits without everybody's work stalling until he has finished the whole set of changes. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
Do we have a time frame for that? Can't Magnus split these changes up into small independent pieces and commit them to the trunk regularly? This way he can update his working tree from the trunk and get my and other's commits without everybody's work stalling until he has finished the whole set of changes. The problem is testing. Once the patches have been brought up to svn head(easy, I did it in 10 minutes), then only testing is required and then we can commit them. I believe it is possible to split the changes into a number of commits so as to facilitate bisection better. We *must* commit them to get them tested, but at least ft2232 should have a decent round of testing before we commit them to svn head. -- Ø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] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 1:24 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do we have a time frame for that? Can't Magnus split these changes up into small independent pieces and commit them to the trunk regularly? This way he can update his working tree from the trunk and get my and other's commits without everybody's work stalling until he has finished the whole set of changes. The problem is testing. Once the patches have been brought up to svn head(easy, I did it in 10 minutes), then only testing is required and then we can commit them. I believe it is possible to split the changes into a number of commits so as to facilitate bisection better. We *must* commit them to get them tested, but at least ft2232 should have a decent round of testing before we commit them to svn head. Then why not just copy the current trunk to something like branches/merge-ftd2232-vs-r1809 and then commit the change there so that it can be tested? Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
Then why not just copy the current trunk to something like branches/merge-ftd2232-vs-r1809 and then commit the change there so that it can be tested? It's even easier than that :-) jtag.c needs a few tweaks and a bit of testing and it can be committed first without further ado. It just needs someone to step up to the plate and take charge. https://lists.berlios.de/pipermail/openocd-development/2009-May/006586.html I suspect that ft2232 can be refactored in two rounds. The first without no effect on functionality. I have not really worked on the ft2232 code and I'd rather leave that to someone else. -- Ø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] insulate queue pointer manipulation from general jtag.c code
If you post patches and vouch for them, then I, or another committer who beats me to it, will commit them promptly. Currently the problem is that there are patches posted, but nobody has time to say anything as to whether they are ready for testing. I think it would be *greatly* helpful if we could break these changes into a series of harmless patches and then a final patch to flip the switch... Keeping all patches small well understood. W.r.t. vouching, I'm not saying that you should guarantee that they work, but if you can simply state what testing you did then we have much better understanding of the expected quality and robustness of these patches. The *real* testing only happens after the patches are committed. That's just how the OpenOCD community works at this point. -- Ø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] OpenOCD and different versions of J-Link
Xiaofan Chen wrote: 2008/12/25 Michel Catudal michelcatu...@gmail.com: I could not get my older black j-link devices to work while the newer yellow one works. I am curious as to what the basic difference would be between the two. I tested them at work and they were working just as good on windows as the yellow one with IAR 5.2. (I don't use windows at home) Sorry to rehash this thread as I am interested in this topic as well. I have both black J-link and yellow one at work. Yellow ones are mostly of V5/V6 (and V7?) firmware. The one I have is for V6. The black one I have is of the old V3 version. The MCU used is different as far as I know. It seems to me that the Black one is using a Renesas MCU (M16C?). The yellow one seems to use AT91SAM7S. I can't answer your questions but can only add another jlink question. I know very little about the jlink. I have a yellow jlink that says jlink ks, IAR Systems on the front (ks = kickstart?). On the back it says J-Link-ARM-KS Serial Number 10001576. No idea of the rev level or processor it contains (it is borrowed). The evaluation board I am connecting it to is IAR (made by Olimex) STR712 (ARM7TDMI). Should this work with openocd? If so, what is the correct linux/bash command line? It works OK with IAR Embedded Workbench Kickstart for ARM 4.30A on windows. Right now whether the board is powered on or off or even if the jtag cable is connected or not all I see is: sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg 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 -- actually, need to 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 but can do nothing useful.) -gene ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 3:28 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: If you post patches and vouch for them, then I, or another committer who beats me to it, will commit them promptly. Currently the problem is that there are patches posted, but nobody has time to say anything as to whether they are ready for testing. I think it would be *greatly* helpful if we could break these changes into a series of harmless patches and then a final patch to flip the switch... Keeping all patches small well understood. W.r.t. vouching, I'm not saying that you should guarantee that they work, but if you can simply state what testing you did then we have much better understanding of the expected quality and robustness of these patches. The *real* testing only happens after the patches are committed. That's just how the OpenOCD community works at this point. I broke it down as small as possible. The change is trivial. I tested it here as far as possible. I can't test *all* of the functions as my target doesn't use them, but again, the rewrite is absolutely trivial. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
I broke it down as small as possible. The change is trivial. I tested it here as far as possible. I can't test *all* of the functions as my target doesn't use them, but again, the rewrite is absolutely trivial. Did Rick want something *else* or something *more*? If he wanted something *more* then perhaps it would make sense to commit this first round of patches? -- Ø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] Tighten up handling of arguments to Tcl commands
Committed.
Remove unecessary(and poptentially harmful?) around arguments
passed in to eval in command.c
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/command.c
===
--- src/helper/command.c(revision 1806)
+++ src/helper/command.c(working copy)
@@ -221,7 +221,7 @@
free((void *)full_name);
/* we now need to add an overrideable proc */
- const char *override_name=alloc_printf(proc %s%s%s {args} {if
{[catch {eval \ocd_%s%s%s $args\}]==0} {return \\} else { return
-code error }, t1, t2, t3, t1, t2, t3);
+ const char *override_name=alloc_printf(proc %s%s%s {args} {if
{[catch {eval ocd_%s%s%s $args}]==0} {return \\} else { return -code
error }, t1, t2, t3, t1, t2, t3);
Jim_Eval_Named(interp, override_name, __THIS__FILE__, __LINE__ );
free((void *)override_name);
--
Ø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] insulate queue pointer manipulation from general jtag.c code
On Mon, May 18, 2009 at 3:53 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I broke it down as small as possible. The change is trivial. I tested it here as far as possible. I can't test *all* of the functions as my target doesn't use them, but again, the rewrite is absolutely trivial. Did Rick want something *else* or something *more*? If he wanted something *more* then perhaps it would make sense to commit this first round of patches? Rick wants more. It would affect the code that I am posting but my code would still be the logical intermediate step. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Mon, May 18, 2009 at 9:37 PM, Gene Smith g...@chartertn.net wrote:
I can't answer your questions but can only add another jlink question. I
know very little about the jlink. I have a yellow jlink that says jlink
ks, IAR Systems on the front (ks = kickstart?). On the back it says
J-Link-ARM-KS Serial Number 10001576. No idea of the rev level or
processor it contains (it is borrowed).
http://www.segger.com/download_jlink.html
You can download the beta software for Linux. Here is what I get
for the V6 Jlink.
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
Updating firmware: J-Link ARM V6 compiled Jan 15 2009 11:58:34
Replacing firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
Waiting for new firmware to boot
New firmware booted successfully
** Error: Communication timed out after firmware update
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Unable to retrieve firmware info !
S/N : 156007287
OEM : IAR
VTarget = 3.248V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
RTCK reaction time is approx. 126ns
Using adaptive clocking instead of fixed JTAG speed.
The evaluation board I am
connecting it to is IAR (made by Olimex) STR712 (ARM7TDMI). Should this
work with openocd? If so, what is the correct linux/bash command line?
It works OK with IAR Embedded Workbench Kickstart for ARM 4.30A on
windows. Right now whether the board is powered on or off or even if the
jtag cable is connected or not all I see is:
sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg
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 -- actually, need to 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 but can do nothing useful.)
Similar error message here with latest svn version but it seems to work.
mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f openocd_lpc2148.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 15
force hard breakpoints
Error: J-Link command EMU_CMD_VERSION failed (-110)
Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18
Info : JLink caps 0xf7fbf
Info : JLink max mem block 9992
Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3104). Workaround: increase set remotetimeout in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3012). Workaround: increase set remotetimeout in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3237). Workaround: increase set remotetimeout in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : no tcl port specified, using default port
Info : accepting 'telnet' connection from 0
TapName| Enabled | IdCode ExpectedIrLen
IrCap IrMask Instr
---||-|||--|--|--|-
0 | lpc2148.cpu|Y| 0x | 0x4f1f0f0f | 0x04 |
0x01
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Mon, May 18, 2009 at 10:18 PM, Xiaofan Chen xiaof...@gmail.com wrote: mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f openocd_lpc2148.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ jtag_speed: 15 force hard breakpoints Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 Info : JLink caps 0xf7fbf Info : JLink max mem block 9992 Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3104). Workaround: increase set remotetimeout in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3012). Workaround: increase set remotetimeout in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3237). Workaround: increase set remotetimeout in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : no tcl port specified, using default port Info : accepting 'telnet' connection from 0 TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu | Y | 0x | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0f mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger scan_chain TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu | Y | 0x | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0f Same test for the black V3 Jlink. mc...@ubuntu904:~/Desktop/build/openocd/jlinkold$ openocd -f openocd_lpc2148.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ jtag_speed: 15 force hard breakpoints Error: J-Link command 0x01 failed (-2) Error: J-Link command EMU_CMD_VERSION failed (-110) Error: J-Link command 0x01 failed (-2) Error: J-Link command EMU_CMD_VERSION failed (-110) Error: J-Link command 0x01 failed (-2) Error: J-Link command EMU_CMD_VERSION failed (-110) 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! (9087). Workaround: increase set remotetimeout in GDB Error: J-Link setting speed failed (-2) 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 0xde failed (-2) Error: J-Link command 0xdc failed (-2) Error: J-Link command 0xde failed (-2) 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) Warn : no tcl port specified, using default port Info : accepting 'telnet' connection from 0 TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu|Y| 0x | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0f mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger scan_chain TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | lpc2148.cpu|Y| 0x | 0x4f1f0f0f | 0x04 | 0x01 | 0x0f | 0x0f More error messages. I need to learn more about openocd to carry out more tests. I have the Olimex LPC-P2148 board at home. It seemed to me that different Jlink version may need different codes to deal with. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list
Re: [Openocd-development] OpenOCD and different versions of J-Link
More tests on flash writing. I got the script from psas. Maybe it is too old (for V1257). I will try later with new scripts. http://www.linuxjournal.com/article/10421 With black J-link script oocd_flash_lpc2148.script J-Link command 0xdd failed (-2) J-Link command 0xde failed (-2) J-Link command 0xdc failed (-2) J-Link command 0xde failed (-2) J-Link command 0xdd failed (-2) J-Link command 0xdf failed (-2) usb_bulk_write failed (requested=6, result=-2) jlink_tap_execute, wrong result -107 (expected 1) usb_bulk_write failed (requested=6, result=-2) jlink_tap_execute, wrong result -107 (expected 1) Runtime error, file embedded:startup.tcl, line 172: error: -104 in procedure 'ocd_process_reset' Runtime error, file oocd_flash_lpc2148.script, line 10: in procedure 'script' called at file command.c, line 453 called at file embedded:startup.tcl, line 122 With Yellow Jlink script oocd_flash_lpc2148.script usb_bulk_read failed (requested=1, result=-110) jlink_tap_execute, wrong result -107 (expected 1) keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3245). Workaround: increase set remotetimeout in GDB usb_bulk_read failed (requested=1, result=-110) jlink_tap_execute, wrong result -107 (expected 1) Runtime error, file embedded:startup.tcl, line 172: error: -104 in procedure 'ocd_process_reset' Runtime error, file oocd_flash_lpc2148.script, line 10: in procedure 'script' called at file command.c, line 453 called at file embedded:startup.tcl, line 122 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
On Mon, May 18, 2009 at 3:36 PM, Nico Coesel ncoe...@dealogic.nl wrote: Gentlemen, AFAIK EJTAG is already implemented in OpenOCD (I'm using it for another MIPS based SOC to program external flash). I just don't know how complete it is in respect to debugging/single stepping. The flash programming routines for PIC32 are also available in OpenOCD. So I guess everything is available in OpenOCD to program a PIC32. As far as I know, the chip erase is not implemented/working for flashing the PIC32 according to the mailing list archive. So it might be barely working. I do not know the status of debugging. From: John McCarthy jg...@magma.ca Date: Mon, Jan 5, 2009 at 12:39 PM Subject: [Openocd-development] pic32mx flash fixups and speedups To: OpenOCD Development Openocd-development@lists.berlios.de I found my problems with writing boot flash and optimized single 32bit word read/writes to speed things up a bit. I also added support for writing flash using the pgm_row command to greatly speed up programming. So now all flash can be erased and/or programmed. Still no chip_erase command and data transfers to/from the target are still slow but it is usable. I will need to make a connector to test J-link with my Explorer 16 in the future. Right now I am not really using PIC32 but more on USB PIC24. And I will need to learn to use OpenOCD with LPC-2148 first. Slighty off-topic: I think the MIPS GCC compiler from Codesourcery can be used for PIC32 straight away. It is based on GCC 4.x (not the old 3.x GCC), has newlib support and isn't crippled! The C library from mspgcc (GCC for TI's MSP430 series) is a usefull replacement for newlib because it is really really small. I had little problems compiling it for ARM. The Microchip C32 compiler is not really crippled but the libraries are as far as I know. http://www.microchip.com/forums/tm.aspx?m=292995 Since then, Microchip has moved the C32 sourcecodes and build scripts to Sourceforge. http://sourceforge.net/projects/microchipopen/ -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Xiaofan Chen wrote:
On Mon, May 18, 2009 at 9:37 PM, Gene Smith g...@chartertn.net wrote:
I can't answer your questions but can only add another jlink question. I
know very little about the jlink. I have a yellow jlink that says jlink
ks, IAR Systems on the front (ks = kickstart?). On the back it says
J-Link-ARM-KS Serial Number 10001576. No idea of the rev level or
processor it contains (it is borrowed).
http://www.segger.com/download_jlink.html
You can download the beta software for Linux. Here is what I get
for the V6 Jlink.
Yes, found it too.
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
Updating firmware: J-Link ARM V6 compiled Jan 15 2009 11:58:34
Mine says: Updating firmware: J-Link compiled Feb 20 2006 18:20:20 --
Update --
Replacing firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
Mine says: Replacing firmware J-Link compiled Dec 2 2004 09:13:33
Waiting for new firmware to boot
New firmware booted successfully
** Error: Communication timed out after firmware update
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Unable to retrieve firmware info !
S/N : 156007287
Mine says: S/N : -3
WARNING: No matching core found. Selecting default core (ARM7)
*** Error: could not read hardware status!
JTAG speed: 5 Hhz
J-Link
Green LED goes off then *don't* see exactly what you see:
OEM : IAR
VTarget = 3.248V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
RTCK reaction time is approx. 126ns
Using adaptive clocking instead of fixed JTAG speed.
The evaluation board I am
connecting it to is IAR (made by Olimex) STR712 (ARM7TDMI). Should this
work with openocd? If so, what is the correct linux/bash command line?
It works OK with IAR Embedded Workbench Kickstart for ARM 4.30A on
windows. Right now whether the board is powered on or off or even if the
jtag cable is connected or not all I see is:
sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg
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 -- actually, need to 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 but can do nothing useful.)
Similar error message here with latest svn version but it seems to work.
mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f
openocd_lpc2148.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 15
force hard breakpoints
Error: J-Link command EMU_CMD_VERSION failed (-110)
But I see three re-tries on this at all fail. Yours seems to only fail
once. Then yours seems to do useful stuff:
Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18
Info : JLink caps 0xf7fbf
Info : JLink max mem block 9992
Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3104). Workaround: increase set remotetimeout in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (3012). Workaround: increase set remotetimeout in
GDB
Error: usb_bulk_read failed (requested=1, result=-110)
Error: jlink_tap_execute, wrong result -107 (expected 1)
Warn : keep_alive() was
Re: [Openocd-development] [PATCH] insulate queue pointer manipulation from general jtag.c code
On May 17, 2009, at 1:51 AM, Michael Bruck wrote: The code in jtag.c currently manipulates the command queue pointers directly in every function. This increases potential for errors and makes the code less readable by distracting the reader from the core algorithm contained in every function. This patch removes the (repetitive) direct command queue manipulation from the functions in jtag and packs it into a function called jtag_queue_command(). The main change looks like this: - jtag_command_t **last_cmd; - last_cmd = jtag_get_last_command_p(); - - *last_cmd = cmd_queue_alloc(sizeof(jtag_command_t)); - (*last_cmd)-next = NULL; - last_comand_pointer = ((*last_cmd)-next); - (*last_cmd)-type = JTAG_SCAN; + jtag_command_t * cmd = cmd_queue_alloc(sizeof(jtag_command_t)); + + jtag_queue_command(cmd); + + cmd-type = JTAG_SCAN; Patch 1 adds jtag_queue_command() Patches 2-7 rewrite the functions in jtag.c to use jtag_queue_command() They can be applied in any order. 2-6 are larger functions, 7 includes all the remaining short functions Patch 8 rewrites the direct jtag queue manipulation in svf/svf.c to use jtag_queue_command() Patch 9 can only be applied after 1-8 were applied. It changes last_comand_pointer to last_command_pointer. The patches should not change any algorithms. Michael openocd-jtag-1.txtopenocd-jtag-2.txtopenocd-jtag-3.txtopenocd- jtag-4.txtopenocd-jtag-5.txtopenocd-jtag-6.txtopenocd- jtag-7.txtopenocd-jtag-8.txtopenocd- jtag-9.txt___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Committed revision 1815 through 1823. -- 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] TCL unkown ocd_mem2array
Øyvind Harboe wrote: You have to create the target before the init command. One could talk about allowing targets to be created/deleted on the fly, but OpenOCD isn't at that stage today. This works: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c init -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Move init and it fails: openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg -c init -c target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu -c ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 Hmm, ok, on the command line this seems to be the difference. Any idea what might be different doing it at (telnet) command prompt: -- cut -- openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg Open On-Chip Debugger targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- init target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- vs. -- cut -- openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg Open On-Chip Debugger targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- target create omap3.cpu cortex_m3 -endian little -chain-position omap3.cpu targets CmdNameType Endian AbsChainPos Name State -- -- -- -- --- - -- 0: omap3.cpu cortex_m3 little 0 omap3.cpu unknown init ocd_mem2array dataval 32 [expr \0x54011000 + 0 * 4\] 1 invalid command name ocd_mem2array_dataval called at file command.c, line 453 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 93 -- cut -- ? Independent of init and target create order, both give the same result: Failing ocd_mem2array. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Short state table enabled as of r1827
I merged in the updated version of Dick's changes as 4 separate patches: - r1812 updates the state table but does not enable the short table - r1825 has the FT2232 fixes for supporting the short table - r1826 has the JLink fixes for supporting the short table - r1827 enables the short table if you build the FT2232 or JLink drivers When testing, please try the current trunk first. If it doesn't work, move back to r1826 to see if it is a problem with the new state table or something else. Continue bisecting backwards from that point to find the offending problem if it wasn't the state table. -- 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] TCL unkown ocd_mem2array
You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. -- Ø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] TCL unkown ocd_mem2array
Øyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] CFI driver chip/bus width.
Raúl Sánchez Siles wrote: Hello All: Thanks a lot for the prompt answers, unlike this e-mail. I've been off from the office since my post, so sorry for it. I now notice I failed to provide sufficient details about the issue at discussion. The flash uses is a 16bit data width, but it is connected using just 8 bit width. Only the lower data byte is output by the chip and the A-1 address line is used. So in summary, one 16bit width flash chip used as 8bit width by a 8bit data width processor. OK, so that is a chipwidth = buswidth =1 szenario. Um - no. The x16_as_x8 option is used for 16-bit flashes that can be used with an 8-bit data bus. The reason for that option is that in that mode, the magic address values used for commands is shifted 1 bit against what is used on real 8-bit flashs. The option should only tell that a 16-bit flash chip is connected to a 8-bit bus - having multiple such chips in parallel must be handled by the chip/bus geometry handling. And again, I think this is the point. I'll try to implement this parameter. Looks like what I only need is that magic, it's only that so far I wasn't able to make the flash work any other way. I think I aim that the following line works: flash bank cfi 0x8000 0x100 1 1 0 x16_as_x8 Please, correct me if I'm wrong. That looks right, yes - I can't tell if it actually works, but that is the way it is meant to be used. You might have a look at the CFI code in u-boot, which I *think* does handle this situation correct, however, I have no board with such a flash layout, so I can't really tell. Thanks, I'll take a look. In the x16_as_x8 case, I would suggest not looking at u-boot but rather directly trying to get the openocd code to work on your board - if x16_as_x8 should be broken, it should not be too difficult to fix - it is just a matter of having a board to test the code on. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TCL unkown ocd_mem2array
On Mon, May 18, 2009 at 7:55 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Any thoughts on how OpenOCD could be made clearer at this point? -- Ø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] TCL unkown ocd_mem2array
Øyvind Harboe wrote: On Mon, May 18, 2009 at 7:55 PM, Dirk Behme dirk.be...@googlemail.com wrote: Ųyvind Harboe wrote: You can't use target create on the telnet command line because it is after init. If init is not on the command line, OpenOCD runs it before launching the telnet server. Ah, that explains a lot! ;) Will try it. Any thoughts on how OpenOCD could be made clearer at this point? Some additional printfs and/or error messages? E.g. - When init is executed 'automatically' at startup: printf(Info: init successfully done\n); - When you try to do init again if it is already done once: printf(Error: System already initialized\n); - If you try to execute target create after init: printf(Error: Can't create target after initialization\n) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Øyvind Harboe wrote: [Oops - failed to copy the original to the list...] On Mon, May 18, 2009 at 8:21 AM, Peter Denison open...@marshadder.org wrote: On Sat, 16 May 2009, Øyvind Harboe wrote: Could you post a GDB backtrace? See: http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS I tried to do that, but since the changes for librification of openocd, it doesn't work, as src/openocd is no longer an executable, but is a script. I haven't yet worked out how to successfully run gdb on it. I used gdb --args openocd Still works here Grateful if you (or Zach) could let me know how to run gdb, then I will happily provide a backtrace. Please provide any extra detail you might have, because we obviously need this to work and it does work on Cygwin at least... OK. System: debian squeeze (libtool 2.2.6a, autoconf 2.63, automake 1:1.10.2) Revision: 1827 Built: ./bootstrap; ./configure --enable-jlink --enable-usbprog --enable-maintainer-mode --enable-verbose; make $ cd src/target $ gdb ../openocd GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu... path/src/openocd: not in executable format: File format not recognized $ $ gdb ../openocd --args openocd ... ends up running /usr/bin/openocd ... which is the debian-installed version, at r1409 and not the program I want to debug. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
$ gdb ../openocd --args openocd ... ends up running /usr/bin/openocd ... Try gdb --args openocd -f interface/xxx.cfg -f target/.cfg ... -- Ø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] arm7_9_common.c Documentation Updates
On Monday 18 May 2009, Dean Glazeski wrote: Do you mean the target_type_s and target_s structures? I think there may be some others too like the arm7_9_common_s struct. I'm commenting up the arm7_9_common_s struct as I go too. Yes, those interfaces. Once those get properly documented, their *implementations* can just be presumed to conform, and shouldn't really need additional documentation. However, that doesn't mean eyeballing the implementations would not be good. It's a lot of work if you don't know the details of JTAG on those chips ... but code audits tend to uncover things that deserve fixing, like code that doesn't actually meet the interface spec. Or interface specs that don't actually do what they need to be doing. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 2009-05-18 at 19:33 +0100, Peter Denison wrote: On Mon, 18 May 2009, Øyvind Harboe wrote: [Oops - failed to copy the original to the list...] On Mon, May 18, 2009 at 8:21 AM, Peter Denison open...@marshadder.org wrote: On Sat, 16 May 2009, Øyvind Harboe wrote: Could you post a GDB backtrace? See: http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS I tried to do that, but since the changes for librification of openocd, it doesn't work, as src/openocd is no longer an executable, but is a script. I haven't yet worked out how to successfully run gdb on it. I used gdb --args openocd Still works here Grateful if you (or Zach) could let me know how to run gdb, then I will happily provide a backtrace. Please provide any extra detail you might have, because we obviously need this to work and it does work on Cygwin at least... OK. System: debian squeeze (libtool 2.2.6a, autoconf 2.63, automake 1:1.10.2) Revision: 1827 Built: ./bootstrap; ./configure --enable-jlink --enable-usbprog --enable-maintainer-mode --enable-verbose; make $ cd src/target $ gdb ../openocd Try using libtool gdb ../openocd or the more pedantic (but future-proof): libtool --mode=execute gdb ../openocd Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
Try using libtool gdb ../openocd or the more pedantic (but future-proof): libtool --mode=execute gdb ../openocd Once a solution has been identified, it would be nice to have the BUGS file updated... -- Ø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] Short state table enabled as of r1827
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended
to allow switching between the long(old) or new (short)
tms_sequence tables. The patch uses the short table
as default.
Try:
tms_sequence long
tms_sequence short
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/jtag.c
===
--- C:/workspace/openocd/src/jtag/jtag.c(revision 1830)
+++ C:/workspace/openocd/src/jtag/jtag.c(working copy)
@@ -261,6 +261,7 @@
static int handle_verify_ircapture_command(struct command_context_s *cmd_ctx,
char *cmd, char **args, int argc);
static int handle_verify_jtag_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc);
+static int handle_tms_sequence_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc);
jtag_tap_t *jtag_AllTaps(void)
{
@@ -2310,6 +2311,8 @@
COMMAND_ANY, verify value captured during Capture-IR
enable|disable);
register_command(cmd_ctx, NULL, verify_jtag,
handle_verify_jtag_command,
COMMAND_ANY, verify value capture enable|disable);
+ register_command(cmd_ctx, NULL, tms_sequence,
handle_tms_sequence_command,
+ COMMAND_ANY, choose short(default) or long tms_sequence
short|long);
return ERROR_OK;
}
@@ -3129,6 +3132,7 @@
return ERROR_OK;
}
+
int jtag_power_dropout(int *dropout)
{
return jtag-power_dropout(dropout);
@@ -3248,7 +3252,7 @@
*
* DRSHIFT-DRSHIFT and IRSHIFT-IRSHIFT have to be caught in interface
specific code
*/
-static struct
+struct tms_sequences
{
u8 bits;
u8 bit_count;
@@ -3253,14 +3257,7 @@
u8 bits;
u8 bit_count;
-} tms_seqs[6][6] = /* [from_state_ndx][to_state_ndx] */
-{
- /* value clocked to TMS to move from one of six stable states to
another.
-* N.B. OOCD clocks TMS from LSB first, so read these right-to-left.
-* N.B. These values are tightly bound to the table in
tap_get_tms_path_len().
-* N.B. Reset only needs to be 0b1, but in JLink an even byte of
1's is more stable.
-* These extra ones cause no TAP state problem, because we
go into reset and stay in reset.
-*/
+};
/*
* These macros allow us to specify TMS state transitions by bits rather than
hex bytes.
@@ -3280,7 +3277,31 @@
#define B8(bits,count) { ((u8)B8__(HEX__(bits))), (count) }
-#if 1 ((BUILD_FT2232_FTD2XX==1) || (BUILD_FT2232_LIBFTDI==1) ||
(BUILD_JLINK==1))
+static const struct tms_sequences old_tms_seqs[6][6] = /*
[from_state_ndx][to_state_ndx] */
+{
+ /* value clocked to TMS to move from one of six stable states to
another.
+* N.B. OOCD clocks TMS from LSB first, so read these right-to-left.
+* N.B. These values are tightly bound to the table in
tap_get_tms_path_len().
+* N.B. Reset only needs to be 0b1, but in JLink an even byte of
1's is more stable.
+* These extra ones cause no TAP state problem, because we
go into reset and stay in reset.
+*/
+
+
+
+ /* to state: */
+ /* RESET IDLEDRSHIFT
DRPAUSE IRSHIFT IRPAUSE */
/* from state: */
+ { B8(111,7), B8(000,7), B8(0010111,7), B8(0001010,7),
B8(0011011,7), B8(0010110,7) },/* RESET */
+ { B8(111,7), B8(000,7), B8(0100101,7), B8(101,7),
B8(0101011,7), B8(0001011,7) },/* IDLE */
+ { B8(111,7), B8(0110001,7), B8(000,7), B8(001,7),
B8(000,7), B8(010,7) },/* DRSHIFT */
+ { B8(111,7), B8(011,7), B8(010,7), B8(0010111,7),
B8(000,7), B8(010,7) },/* DRPAUSE */
+ { B8(111,7), B8(0110001,7), B8(111,7), B8(0010111,7),
B8(000,7), B8(001,7) },/* IRSHIFT */
+ { B8(111,7), B8(011,7), B8(0011100,7), B8(0010111,7),
B8(000,7), B8(010,7) },/* IRPAUSE */
+};
+
+
+
+static const struct tms_sequences short_tms_seqs[6][6] = /*
[from_state_ndx][to_state_ndx] */
+{
/* this is the table submitted by Jeff Williams on 3/30/2009 with
this comment:
OK, I added Peter's version of the state table, and it works OK
for
@@ -3314,34 +3335,15 @@
{ B8(111,7), B8(011,3), B8(00111,5),
B8(010111,6), B8(00,6), B8(01,2) }, /* IRSHIFT */
{ B8(111,7), B8(011,3), B8(00111,5),
B8(010111,6), B8(01,2), B8(0,1) } /*
IRPAUSE */
-#else /* this is
[Openocd-development] [patch] NAND: update ids, nand list bugfix
Minor NAND updates:
- Comment which IDs are museum IDs: obsolete first-gen parts,
some with IDs that are reused with newer parts, 256-byte pages.
Linux doesn't support these by default, and OpenOCD rejects
the 256-byte pages.
- Recognize Micron as a NAND manufacturer.
- For nand list, part numbers are the same whether or not the
part has been probed yet.
Minor NAND updates:
- Comment which IDs are museum IDs: obsolete first-gen parts,
some with IDs that are reused with newer parts, 256-byte pages.
(Linux doesn't support these by default.)
- Recognize Micron as a NAND manufacturer.
- For nand list, part numbers are the same whether or not the
part has been probed yet.
--- a/src/flash/nand.c
+++ b/src/flash/nand.c
@@ -86,6 +88,7 @@ static command_t *nand_cmd;
*/
static nand_info_t nand_flash_ids[] =
{
+ /* start museum IDs */
{NAND 1MiB 5V 8-bit, 0x6e, 256, 1, 0x1000, 0},
{NAND 2MiB 5V 8-bit, 0x64, 256, 2, 0x1000, 0},
{NAND 4MiB 5V 8-bit, 0x6b, 512, 4, 0x2000, 0},
@@ -101,6 +104,7 @@ static nand_info_t nand_flash_ids[] =
{NAND 8MiB 3,3V 8-bit, 0xe6, 512, 8, 0x2000, 0},
{NAND 8MiB 1,8V 16-bit, 0x49, 512, 8, 0x2000, NAND_BUSWIDTH_16},
{NAND 8MiB 3,3V 16-bit, 0x59, 512, 8, 0x2000, NAND_BUSWIDTH_16},
+ /* end museum IDs */
{NAND 16MiB 1,8V 8-bit, 0x33, 512, 16, 0x4000, 0},
{NAND 16MiB 3,3V 8-bit, 0x73, 512, 16, 0x4000, 0},
@@ -172,6 +176,7 @@ static nand_manufacturer_t nand_manuf_id
{NAND_MFR_RENESAS, Renesas},
{NAND_MFR_STMICRO, ST Micro},
{NAND_MFR_HYNIX, Hynix},
+ {NAND_MFR_MICRON, Micron},
{0x0, NULL},
};
@@ -1062,7 +1067,7 @@ int nand_write_page_raw(struct nand_devi
int handle_nand_list_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
{
nand_device_t *p;
- int i = 0;
+ int i;
if (!nand_devices)
{
@@ -1070,13 +1075,13 @@ int handle_nand_list_command(struct comm
return ERROR_OK;
}
- for (p = nand_devices; p; p = p-next)
+ for (p = nand_devices, i = 0; p; p = p-next, i++)
{
if (p-device)
command_print(cmd_ctx, #%i: %s (%s) pagesize: %i, buswidth: %i, erasesize: %i,
-i++, p-device-name, p-manufacturer-name, p-page_size, p-bus_width, p-erase_size);
+i, p-device-name, p-manufacturer-name, p-page_size, p-bus_width, p-erase_size);
else
- command_print(cmd_ctx, #%i: not probed);
+ command_print(cmd_ctx, #%i: not probed, i);
}
return ERROR_OK;
--- a/src/flash/nand.h
+++ b/src/flash/nand.h
@@ -95,6 +95,7 @@ enum
NAND_MFR_RENESAS = 0x07,
NAND_MFR_STMICRO = 0x20,
NAND_MFR_HYNIX = 0xad,
+ NAND_MFR_MICRON = 0x2c,
};
typedef struct nand_manufacturer_s
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 2009-05-18 at 21:51 +0200, Øyvind Harboe wrote: Try using libtool gdb ../openocd or the more pedantic (but future-proof): libtool --mode=execute gdb ../openocd Once a solution has been identified, it would be nice to have the BUGS file updated... Committed r1832. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head should now be OK again
On Mon, 18 May 2009, Øyvind Harboe wrote:
Try using
libtool gdb ../openocd
or the more pedantic (but future-proof):
libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
Excellent! That (to be precise the second of the two) worked.
It would be nice to have the BUGS file updated.
Now, on to the actual crash. I will do more investigation, but for now,
here's the backtrace:
Starting program: path/src/.libs/lt-openocd -f
../../../openocd-usr8200-jlink.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
jtag_speed: 16
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (-110)
Program received signal SIGSEGV, Segmentation fault.
jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
940 result = usb_bulk_write_ex(jlink_jtag-usb_handle,
JLINK_WRITE_ENDPOINT,
(gdb) bt
#0 jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940
#1 0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509
#2 0xb7febbb0 in jlink_get_version_info () at jlink.c:549
#3 0xb7febf2d in jlink_init () at jlink.c:324
#4 0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333
#5 0xb7fdc456 in handle_init_command (cmd_ctx=0x804a008,
cmd=0x8057f30 init, args=0x806b3bc, argc=0) at openocd.c:133
#6 0xb8085dca in run_command (context=0x804a008, c=0x8057f50,
words=0x806b3b8, num_words=1) at command.c:399
#7 0xb8086105 in script_command (interp=0x804a020, argc=1, argv=0xbf8e58e0)
at command.c:126
#8 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806b1e8)
at jim.c:8708
#9 0xb807dfff in Jim_EvalCoreCommand (interp=0x804a020, argc=3,
argv=0xbf8e59b0) at jim.c:10846
#10 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806a260)
at jim.c:8708
#11 0xb807c7af in Jim_CatchCoreCommand (interp=0x804a020, argc=2,
argv=0xbf8e5a80) at jim.c:11413
#12 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x806a488)
at jim.c:8708
#13 0xb8078361 in Jim_EvalExpression (interp=0x804a020, exprObjPtr=0x806a5e0,
exprResultPtrPtr=0xbf8e5c04) at jim.c:6927
#14 0xb80791a8 in Jim_GetBoolFromExpr (interp=0x804a020, exprObjPtr=0x806a5e0,
boolPtr=0xbf8e5c58) at jim.c:7210
#15 0xb807f975 in Jim_IfCoreCommand (interp=0x804a020, argc=5, argv=0xbf8e5cd0)
at jim.c:10297
#16 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x8058728)
at jim.c:8708
#17 0xb80771e1 in JimCallProcedure (interp=0x804a020, cmd=0x80588d0, argc=0,
argv=0xbf8e5de0) at jim.c:8857
#18 0xb8076e62 in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x8059960)
at jim.c:8714
#19 0xb80819cc in Jim_EvalFile (interp=0x804a020,
filename=0x8059938 ../../../openocd-usr8200-jlink.cfg) at jim.c:8992
#20 0xb8082205 in Jim_SourceCoreCommand (interp=0x804a020, argc=2,
argv=0xbf8e5ef0) at jim.c:12034
#21 0xb8076a9a in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x80512f8)
at jim.c:8708
#22 0xb80771e1 in JimCallProcedure (interp=0x804a020, cmd=0x8055ee8, argc=2,
argv=0xbf8e6000) at jim.c:8857
#23 0xb8076e62 in Jim_EvalObj (interp=0x804a020, scriptObjPtr=0x80586a8)
at jim.c:8714
#24 0xb8077da1 in Jim_Eval_Named (interp=0x804a020,
script=0x80582c8 script {../../../openocd-usr8200-jlink.cfg},
filename=0xb80a64af command.c, lineno=453) at jim.c:8901
#25 0xb8085cc6 in command_run_line (context=0x804a008,
line=0x80582c8 script {../../../openocd-usr8200-jlink.cfg})
at command.c:453
#26 0xb808452d in parse_config_file (cmd_ctx=0x804a008) at configuration.c:118
#27 0xb7fdc368 in openocd_main (argc=3, argv=0xbf8e62c4) at openocd.c:268
#28 0x080484f2 in main (argc=136, argv=0x68) at main.c:39___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Switch interfaces to use tap_get_tms_path_len()
Committed 1833 use tap_get_tms_path_len() instead of fix # of 7 for all interfaces. Not tested if this builds, but at least we're looking at a build error instead of a runtime error. -- Ø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] OpenOCD and different versions of J-Link
Hello,
I posted a similar patch several month ago.
I have a JLink version v3.0
To get it to work you have to change several little things.
This is just a very ugly hack that somewhat disables support for =V5 JLinks
I'd just be interested if any of you can also get it to work this way...
I would like to build a clean version of this patch that doesen't break the
rest of the system, but I'd need some more help as I'm not experienced in any
openocd/jtag code
If you're interested I can explaine all the things that I needed to change...
Benjamin Schmidt
On Monday 18 May 2009 05:09:06 pm Gene Smith wrote:
Xiaofan Chen wrote:
On Mon, May 18, 2009 at 9:37 PM, Gene Smith g...@chartertn.net wrote:
I can't answer your questions but can only add another jlink question. I
know very little about the jlink. I have a yellow jlink that says jlink
ks, IAR Systems on the front (ks = kickstart?). On the back it says
J-Link-ARM-KS Serial Number 10001576. No idea of the rev level or
processor it contains (it is borrowed).
http://www.segger.com/download_jlink.html
You can download the beta software for Linux. Here is what I get
for the V6 Jlink.
Yes, found it too.
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
Updating firmware: J-Link ARM V6 compiled Jan 15 2009 11:58:34
Mine says: Updating firmware: J-Link compiled Feb 20 2006 18:20:20 --
Update --
Replacing firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
Mine says: Replacing firmware J-Link compiled Dec 2 2004 09:13:33
Waiting for new firmware to boot
New firmware booted successfully
** Error: Communication timed out after firmware update
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Unable to retrieve firmware info !
S/N : 156007287
Mine says: S/N : -3
WARNING: No matching core found. Selecting default core (ARM7)
*** Error: could not read hardware status!
JTAG speed: 5 Hhz
J-Link
Green LED goes off then *don't* see exactly what you see:
OEM : IAR
VTarget = 3.248V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
RTCK reaction time is approx. 126ns
Using adaptive clocking instead of fixed JTAG speed.
The evaluation board I am
connecting it to is IAR (made by Olimex) STR712 (ARM7TDMI). Should this
work with openocd? If so, what is the correct linux/bash command line?
It works OK with IAR Embedded Workbench Kickstart for ARM 4.30A on
windows. Right now whether the board is powered on or off or even if the
jtag cable is connected or not all I see is:
sudo ./openocd -f target/interface/jlink -f target/target/str710.cfg
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 -- actually, need to
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 but can do nothing useful.)
Similar error message here with latest svn version but it seems to work.
mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f
openocd_lpc2148.cfg Open On-Chip Debugger 0.2.0-in-development
(2009-05-18-19:51) svn:1809
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 15
force hard breakpoints
Error: J-Link command EMU_CMD_VERSION failed (-110)
But I see three re-tries on this at all fail. Yours seems to only fail
once. Then yours seems to do useful stuff:
Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18
Re: [Openocd-development] svn head should now be OK again
Try using libtool gdb ../openocd or the more pedantic (but future-proof): libtool --mode=execute gdb ../openocd Once a solution has been identified, it would be nice to have the BUGS file updated... -- for dev work it is often easier to configure with --disable-shared other than speeding up the build it makes debugging a lot simpler, no need to run libtool ... Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
Gentlemen, AFAIK EJTAG is already implemented in OpenOCD (I'm using it for another MIPS based SOC to program external flash). I just don't know how complete it is in respect to debugging/single stepping. The flash programming routines for PIC32 are also available in OpenOCD. So I guess everything is available in OpenOCD to program a PIC32. As far as I know, the chip erase is not implemented/working for flashing the PIC32 according to the mailing list archive. So it might be barely working. I do not know the status of debugging. With regards to pic32 debugging most of the work for the ejtag was based on the pic32. All basic functions within gdb should be working, including software/hardware breakpoints. Having said that i have not tried svn head lately with the pic32. I have a couple of patches to finish off, and complete the work on the run_algorithm. At the moment i am struggling to find any time to spend on openocd, work is very busy. Once the run_algorithm is added the flash programming should speed up, my next step was to look at using the ejtag fast_data area. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Benjamin Schmidt wrote: There's this segger closed source linux gdm server tool... http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz It can show the hardware version. With patch still gets three EMU_CMD_GET_CAPS errors and don't worry. Then LED goes off on jlink. Should it go off? Not sure how I know that it is definitely working or not working. Reset halt command fails usb_bulk_read failed flash info 0 seems to work. Will try the link above in morning. What command line do you use to start openocd with jlink and str712 board? Thanks for any pointers you can provide! -gene On Monday 18 May 2009 11:24:51 pm Gene Smith wrote: Benjamin Schmidt wrote: Hello, I posted a similar patch several month ago. I have a JLink version v3.0 To get it to work you have to change several little things. This is just a very ugly hack that somewhat disables support for =V5 JLinks I'd just be interested if any of you can also get it to work this way... I would like to build a clean version of this patch that doesen't break the rest of the system, but I'd need some more help as I'm not experienced in any openocd/jtag code If you're interested I can explaine all the things that I needed to change... I will let you know if it works before you explain it. Benjamin Schmidt Thanks! I have no idea what version jlink I have (yellow, marked j-link ks/IAR systems on front, j-link-arm-ks on back. Where do you find the version? Inside? I see your patch is against 1833 (head) which I now have so will give it a try. Thanks again! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Ramp up
On Sat, May 16, 2009 at 6:38 AM, Dean Glazeski wrote: On another note, I'm going to start working harder with Chitlesh Goorah, CC'd, on packaging the RPM for Fedora for OpenOCD. Chitlesh has a desire to get OpenOCD pushed into the Fedora Electronics Lab (FEL) distribution and I really want to learn the process of packaging for Fedora. I figure it's a win-win-win. Hello Dean, Well, just let me know once you have a working spec file, then I can help you smooth the ends. regards, Chitlesh ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Does either rev 1833 or 1833 with my patch displaying something like this in the beginning? Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Info : JLink max mem block 32 Info : Vref = 3.283 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 255 The problem is that my old JLink uses a different USB endpoint, so if one version succedes this simple output message, the other WILL fail because it is sending to a channel where the jlink doesn't answer at all I only have access to a stm32 and an at91sam7s64 board ./src/openocd -f ./src/target/interface/jlink.cfg -f ./src/target/target/stm32.cfg That's how i call oocd atm... With my patch I only get one Error: J-Link command EMU_CMD_VERSION failed (-110) error in the beginning and every other 2 or 3 times it doesn't detect the jlink at all, but if the JLink info message appeares, there's no more errors... Benjamin On Tuesday 19 May 2009 12:36:24 am Gene Smith wrote: Benjamin Schmidt wrote: There's this segger closed source linux gdm server tool... http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz It can show the hardware version. With patch still gets three EMU_CMD_GET_CAPS errors and don't worry. Then LED goes off on jlink. Should it go off? Not sure how I know that it is definitely working or not working. Reset halt command fails usb_bulk_read failed flash info 0 seems to work. Will try the link above in morning. What command line do you use to start openocd with jlink and str712 board? Thanks for any pointers you can provide! -gene On Monday 18 May 2009 11:24:51 pm Gene Smith wrote: Benjamin Schmidt wrote: Hello, I posted a similar patch several month ago. I have a JLink version v3.0 To get it to work you have to change several little things. This is just a very ugly hack that somewhat disables support for =V5 JLinks I'd just be interested if any of you can also get it to work this way... I would like to build a clean version of this patch that doesen't break the rest of the system, but I'd need some more help as I'm not experienced in any openocd/jtag code If you're interested I can explaine all the things that I needed to change... I will let you know if it works before you explain it. Benjamin Schmidt Thanks! I have no idea what version jlink I have (yellow, marked j-link ks/IAR systems on front, j-link-arm-ks on back. Where do you find the version? Inside? I see your patch is against 1833 (head) which I now have so will give it a try. Thanks again! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Benjamin, Tuesday, May 19, 2009, 12:39:26 AM, you wrote: BS There's this segger closed source linux gdm server tool... BS http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz BS It can show the hardware version. Is there a necessity to map missing JLink commands? I could find them out, e.g.: ReadHardwareVersion input: 0xF0 (1 byte) output: version (4 bytes) ReadOTS (OTP Structure) input: 0xE6 (1 byte) output: OTS buffer (256 bytes) +0x00 4 serial no +0x10 16 OEM string +0x20 16 feature string 1 +0x30 16 feature string 2 ... +0x90 16 feature string 8 etc. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Igor I think this wouldn't hurt anyone and could be very useful for debugging like this. But it should definately check via EMU_CMD_GET_CAPS first if command is available. At the moment the caps value is read from the device but for example the call to EMU_CMD_GET_MAX_MEM_BLOCK is done on my V3 JLink even though the caps value says the command is not available. This causes a segfault (not exactly sure, at least an error message), because the mem block size is set to 0. Benjamin On Tuesday 19 May 2009 01:39:06 am Igor Skochinsky wrote: Hello Benjamin, Tuesday, May 19, 2009, 12:39:26 AM, you wrote: BS There's this segger closed source linux gdm server tool... BS http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz BS It can show the hardware version. Is there a necessity to map missing JLink commands? I could find them out, e.g.: ReadHardwareVersion input: 0xF0 (1 byte) output: version (4 bytes) ReadOTS (OTP Structure) input: 0xE6 (1 byte) output: OTS buffer (256 bytes) +0x00 4 serial no +0x10 16 OEM string +0x20 16 feature string 1 +0x30 16 feature string 2 ... +0x90 16 feature string 8 etc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hello Benjamin, Tuesday, May 19, 2009, 2:48:30 AM, you wrote: BS I think this wouldn't hurt anyone and could be very useful for debugging like BS this. BS But it should definately check via EMU_CMD_GET_CAPS first if command is BS available. At the moment the caps value is read from the device but for BS example the call to EMU_CMD_GET_MAX_MEM_BLOCK is done on my V3 JLink even BS though the caps value says the command is not available. BS This causes a segfault (not exactly sure, at least an error message), because BS the mem block size is set to 0. What I mean is I could write up a list of missing/underdocumented commands and describe their input/output parameters. I don't have a J-Link so I don't really need the code myself. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD J-link under Windows
Does OpenOCD supports J-Link under Windows? From here it seems to be no. And the front page OpenOCD only supports ftdi2232. http://www.yagarto.de/howto/jlink/index.html The drive is certainly an issue. libusb-win32 filter driver may be an option but it is known to break things under Vista 32 and not working under Vista 64. libusb-win32 device driver (replacing the Segger driver) is another option. Have any one tried this out? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND documentation? My current notes...
On Sun, 17 May 2009, David Brownell wrote: The following are some notes I put together about the nand commands based on reading the source code. I plan to turn them into documentation sometime later, maybe by this time next week. I've seen no documentation on the NAND commands; that seems like a significant omission. Meanwhile I thought I'd send them around for comments and corrections. Looks all fine to me. This matches my own understanding of the code. The == comments are things which seem like they deserve some action other than documenting the current status. One example is removing (or at least disabling) the nand copy command until it gets implemented. Implementing it in a generic way would be quite slow if the data has to make the round trip to the host and back to the target over the JTAG link. Ideally each controller driver would need to implement its own copy method which would involve uploading some code on the target in order to perform the copy directly. Still I don't see this as being really useful, otherwise someone would have implemented it by now. So disabling it is probably the best option for the moment. - Dave NAND COMMANDS = At this writing: - Only NAND devices with 512 or 2048 byte pages are handled properly. Older devices with 256 byte pages are rejected. == Erm, aren't chips with 4K pages mis-handled? At least in some paths. - ECC codes can be generated when pages are written, but are not used to correct errors when data is read ... unless maybe the underlying driver has a read_page() method which does so. - Writing a file to NAND, or reading it from NAND, ignores bad block markers. == Worth fixing, yes?? Just skipping bad blocks would match one common usage. If not, then at least report errors instead of writing there... - Every NAND device is associated with a target. == Hmm, so maybe that target should be stored in the NAND device instead of the controller-private data. And the lookup should be done by the NAND core not the individual drivers. Or ... should the syntax be TARGET nand ... since the drivers are generally SoC-specific? - Nothing verifies that pages are erased before writing. == Is that the same as NOR flash does? The way to use these starts with: nand device CONTROLLER TARGET [controller-options] ... to declare each NAND chip. For chips with two halves (e.g. a 2 GByte chip with two 1GB halves), declare each half separately. nand info ... to see what number it was given nand probe NUM ... to see what sort of chip is there Then you can use write to transfer data from a file to the NAND chip, or dump to go the other direction. Configuration - nand device CONTROLLER TARGET [controller-options] There are several built-in controllers, some of which have controller-specific options or controller-specific commands. This *must* go into a config/init script. lpc3180 - extra parameter: clock frequency - special command: lpc3180 select NUM [mlc|slc] There are two NAND controllers, one for SLC chips and the other for MLC. If a parameter is given, it selects that controller. The currently selected controller is displayed unless there is an error. - MLC controller seems to use hardware ECC logic... ? orion - extra parameter: address for the NAND chip - no special commands s3c2410 s3c2412 s3c2440 s3c2443 - no extra parameters - no special commands nand list Prints a one-line summary of each device found, numbered from zero. Note that un-probed devices show no details. nand probe NUM Probes the specified device to determine key characteristics including size, manufacturer, page size, and erase size Basic I/O - nand dump NUM filename offset length [oob_raw|oob_only] Reads binary data from the NAND chip and writes it to the file, starting at the specified offset. The offset and length must be an exact multiple of the chip's page size. No error correction is done on the data that's read, unless the controller has a read_page() which does that transparently. By default, only page data is saved to the specified file. Two options allow the OOB data to be saved: - oob_raw ... output file interleaves data and OOB data. - oob_only ... output file has only raw OOB data. nand erase NUM block_first block_last Erases blocks from first to last (inclusive), excepting bad blocks. Checks for bad blocks first, if needed. nand write NUM filename offset
Re: [Openocd-development] PIC32 openocd status
Xiaofan Chen a écrit : As far as I know, the chip erase is not implemented/working for flashing the PIC32 according to the mailing list archive. So it might be barely working. I do not know the status of debugging. The mips debugger should work with it but you need some way to flash the program. I am busy working on the programmer. When I get something working I will submit it as well as my debugger and eclipse support. Slighty off-topic: I think the MIPS GCC compiler from Codesourcery can be used for PIC32 straight away. It is based on GCC 4.x (not the old 3.x GCC), has newlib support and isn't crippled! The C library from mspgcc (GCC for TI's MSP430 series) is a usefull replacement for newlib because it is really really small. I had little problems compiling it for ARM. The Microchip C32 compiler is not really crippled but the libraries are as far as I know. http://www.microchip.com/forums/tm.aspx?m=292995 Since then, Microchip has moved the C32 sourcecodes and build scripts to Sourceforge. http://sourceforge.net/projects/microchipopen/ I have created some binaries for SuSE 11.1 and Fedora 9 based on the sourceforge. I have made a debugger for mips but haven't put it on my web site. I am waiting to get my openocd implementation and need to test the debugger before I release it. The gcc that I have is missing newlib which I don't use anyhow, I don't like that bloated crap. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PIC32 openocd status
2009/5/19 Michel Catudal michelcatu...@gmail.com: The mips debugger should work with it but you need some way to flash the program. I am busy working on the programmer. When I get something working I will submit it as well as my debugger and eclipse support. That would be great. I have the PICKit 2 which works under Linux/Windows for programming PIC32. So I can probably use that for verifying when you finish. The first thing for me to do is to make a connector for my Explorer 16 board since the JTAG connector is not the same as J-Link I have. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] openocd planning [0 of 4]
Hi all, I have prepared the following e-mails to attempt to move the OpenOCD release process into motion, breaking out some various policies for managing our ongoing releases and milestones that should also give us some degree of quality-assurance. These cover several related (but separable) topics, and I decided it would be best to split them up to put each one on its own thread for easier tracking and reference. The first thread covers the demand for 0.2.0 release features, and closing out our current progress. For some perspective on what we _need_ therein, I will post my proposed release tactics and strategy in two other threads. That way, we can separate the discussions about release and milestone processes from each other, respectively. These should raise talk about both the segments and complete arc of development between 0.2.0, 0.3.0, and beyond. The fourth thread relates to a prototype for smoke-test reporting tools, which outlines my in-progress code derived from my earlier proposal. [1] Its goal should keep us from deserving retrogressive version schemes, but the code is not quite ready to share (give me a day or two). Today, this aims to provide additional perspective to supplement the preceding proposals and allow for some pre-commit feedback. While I have spent time separating the issues and providing perspective, they remain somewhat like drafts. I hope they are well-received, but they are meant primarily as my proposals for moving things forward in these areas constructively. Following the community's reaction, I will convert the basic text and any feedback to add guidelines to the doxygen developer guide. Cheers, Zach Welch Corvallis, OR [1] https://lists.berlios.de/pipermail/openocd-development/2009-May/006358.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] features for 0.2.0 [1 of 4]
Hi all, I updated The List in r1828 (see the TODO file) to help prepare the OpenOCD project for its forthcoming 0.2.0 release. Please review it to make sure that it contains the features that you want OpenOCD to have before it is done (not only for 0.2.0). Please reply to this thread with patches or suggestions; other maintainers are welcome patch the file directly. OpenOCD Release 0.2.0: Feature Status Report As far as I am aware, only three PATCH items remain on The List that should be reviewed for 0.2.0. Two relate to Dick Hollenbeck's FTDI driver contributions, and they remain simply because I am not sure how to resolve them. The third is the work for the high-speed FTDI chips, which was also incorporated in Dick's patches. If that was dropped, I can pull my version up to head if that would be desired. I can think of reasons that these remaining bits may be on-hold, but I do not want to prejudge them. I _think_ all of the outstanding patches have been reviewed or applied. It seems like everything was handled by the maintainers (other than myself), but please feel free to remind me. The following open issues have been active since my last update: - J-link stability and compatibility - CFI driver chip/bus width issues (status??) - PIC32 support (long-term) Aside from the J-Link madness, nothing seems like a blocker for 0.2.0 to me, and even that might wait. I would like to know what others think, but I have several Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD J-link under Windows
On Tue, May 19, 2009 at 1:33 PM, Rick Altherr kc8...@kc8apf.net wrote: OpenOCD certainly supports more than just FT2232. At the moment, there is support for FT2232, JLink, RLink, VSLLink, and usbprog. I don't know of any reason why these won't work on Windows. All of the USB-based interfaces use libusb and I would expect that driver to be used. I happen to know quite a bit about libusb and libusb-win32. ;-) There are two choices of libusb-win32. You can use the filter driver which works with the original driver. So you can use IAR and Openocd at the same time. The problem is that the filter driver is problematic and cause problems, especially under Vista. The other choice is to use the libusb-win32 device driver. In that case, you create the INF using the INF wizard and replace the stock Segger driver with libusb-win32 device driver.It works better than the filter driver and works under Vista 32 bit. But in this case, you can no longer use IAR to talk to the J-Link. libusb-win32 does not work under Vista 64 so I will think if you use libusb for OpenOCD, that will not work for Vista 64. I am wondering what is the driver mode people are using here, filter driver or the device driver? I will probably give the device driver a try as I have Vista 32bit. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] release strategy [2 of 4]
Hi all, This message tries to cover a proposal for a tactical release process for the OpenOCD community to consider. If there seems to be agreement that this will be acceptable, I will write start some the relevant bits up in a document and add it to the reference manual. At the moment, we are continuing to apply outstanding work and bug fixes as we move to close the merge window, which I would like to have occur by the end of this week. With that in mind, I would like to plan to branch 0.2.0 as soon as possible. That means we need to wrap up everything that is either done, or choose to postpone it; the last message about features Essentially, I want us to cut a release with what we have and plan to repeat the process again repeatedly in the following weeks. Right now, the project has taken too much time since the last release to ensure that the set of supported targets will be a strict superset of those from 0.1.0. I think we must expect some things will be broken, and we will not find out what until we produce a new release for users to test. To prevent future regressions, I have started prototyping test result reporting tools that will allow users to report success or failures with their specific configurations. For simplicity, I would like this to be used only with released versions; this consolidates the testing points. Reports of problems with the SVN trunk always go to the mailing list. We should be releasing often enough that the successful test coverage improves with each releases, so we need to start building up clear and consistent records of our progress over time. This methodology supports the idea of alpha or beta release phases, where the same release processes are used to create those deliverables. This will allow the release, testing, and reporting processes to be verified and debugged fully. The resulting data should allow us to ensure we are delivering regular fixes and improvements to the user community, without any known exceptions. The tactical goal of each release should to be focus on delivering a product with steadily increasing stability and device support (whether host, target, or interface). Once we have machine-generated records of certain combinations of hardware having worked with a certain version of OpenOCD, it will be virtually impossible for us to miss regressions with particular hardware combinations. Does this proposal sound acceptable? Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] milestone strategy [3 of 4]
Hi all, In tandem to perpetual tactical quality-improvement release goals, the OpenOCD community will be pursuing strategic development goals that lead to special milestone releases. As this indicates, I think such planning should be decoupled from the release process, in so far as we should be able to allow up to N intermediate releases to be produced for each of the M milestones that may fall out of The List. Given the scope of our ambitions and resources, I think effective milestone planning for this community might best first revolve around the major releases, allowing as many regular releases as necessary to guide the code in the proper direction. If we adopt a rigorous, the question for organizing milestones should be: how long should we wait between _major_ version releases? My feeling would be: as long (or as little) as it takes. Thus, this takes less precedence over the release process itself for the short term. Nevertheless, I hope this thread can be used by someone as the launching pad for identifying the strategic goals that we should be thinking about for 0.3.0 (which I consider the next major release). Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] testing tools [4 of 4]
Hi all,
Since this weekend, I have spent some time working on a set of Perl
scripts to prototype the back-end system that will aggregate the data
and present it for review (pre-analysis).
I started on this to replace the static developer table that I was using
to augment The List. I think most of what I am doing will need to be
rewritten in SQL to scale up, but I wanted the first draft to avoid any
serious external dependencies (e.g. a SQL engine).
These scripts work on plain text table files: one line per row, '\t'
delimits the columns. The 'tool.pl' script can be used to manipulate
the data from the shell (or other non-Perl scripts), and the 'html.pl'
script can convert the data into cross-linked static HTML pages. Both
use the included 'Tables.pm', which I whipped together this weekend for
this purpose.
The tables track reports from users detailing the results from running
the regression test suite. A report will specify the platform,
interface, and target or board that was tested by the user,
along with the 'version' of OpenOCD, the test 'results', along with a
'comment'. In this description, words in double-quotes ('')
effectively describe various primary tables, while the words in
single-quotes (') describe column fields.
Similarly, each user may specify a list of devices that they can use for
testing, so specific users may be prompted for testing particular
configurations. This last feature also allows me to create a developer
roster that improves on the one that I had been tracking in The List
(until r1828).
Presently, this user-tracking half is (all but) complete, since that was
the reason I started this work. The reporting then builds on it; users
with one platform, interface and target should not be made to specify
these parameters repeatedly when they will be contributing a single
time-series of data points.
Known problems:
- I have tried to KISS, so there are going to be definite limits.
- Additional database design work needs to be done.
- Static output only.
- Missing an 'email.pl' script to provide a gateway from e-mail messages
sent by the automated tester.
- Automated tester does not report PASS/FAIL and send e-mails.
I will try to post my initial implementation in the next day or two, but
I am curious what others think of this approach.
Cheers,
Zach Welch
Corvallis, OR
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
