Re: [Openocd-development] Version 3 test patch for jlink.c
On Fri, Jul 10, 2009 at 1:11 PM, Gary Carlson wrote: > I agree with you in principal that in an ideal situation finding the > problems and fixing the behavior there rather then in openocd would the best > practice. We all agree with that. But the reality is different. > I think it is also safe to say that the primary testers Xiaofan, Spencer, > you, and me are all using the latest library versions. So that is safe to > rule out as a possibility for causing problems. I think it is safe to assume so. libusb 0.1 and libusb-win32 0.1 have not been changed for years. > Likewise I have reviewed the USB manual over and over as others have looking > for the missing magic link. But based on the observations that Xiaofan and > others have made about the sorry state of libusb's current development > state, I personally don't think there is one to be found. > > With all those things said, at this point as ugly as conditionals are, I > would rather have openocd work for as many platforms as possible to attract > user interest and capture mindshare. The alternative is to have no > conditionals and have users frustrated and leave when openocd is found to be > buggy on their particular platform. I agree with you. > Given the fact that fixing libusb is looking more like an improbability, I > took Spencer's latest patch and made two minor modifications (comments + > moved second open_usb up one notch so that it was excluded for Mac OS X > builds). I don't believe they will have any bearing on Windows or Linux > since the code emitted should be the same for those platforms. I am hoping > that both Spencer and Xiaofan will give the modification a lookover to > confirm that. A minor fix needs to be done as I mentioned before. usb_init(); needs to be moved up to the helper function find_jlink_device(void) (before the line usb_find_busses();) http://libusb.sourceforge.net/doc/examples-code.html Could you rework the patch? Thanks. > If they give a thumbs up, would you agree that committing the patch makes > the most sense at this point given what we know today about libusb? > -- 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] Version 3 test patch for jlink.c
Zach, I agree with you in principal that in an ideal situation finding the problems and fixing the behavior there rather then in openocd would the best practice. I think it is also safe to say that the primary testers Xiaofan, Spencer, you, and me are all using the latest library versions. So that is safe to rule out as a possibility for causing problems. Likewise I have reviewed the USB manual over and over as others have looking for the missing magic link. But based on the observations that Xiaofan and others have made about the sorry state of libusb's current development state, I personally don't think there is one to be found. With all those things said, at this point as ugly as conditionals are, I would rather have openocd work for as many platforms as possible to attract user interest and capture mindshare. The alternative is to have no conditionals and have users frustrated and leave when openocd is found to be buggy on their particular platform. Given the fact that fixing libusb is looking more like an improbability, I took Spencer's latest patch and made two minor modifications (comments + moved second open_usb up one notch so that it was excluded for Mac OS X builds). I don't believe they will have any bearing on Windows or Linux since the code emitted should be the same for those platforms. I am hoping that both Spencer and Xiaofan will give the modification a lookover to confirm that. If they give a thumbs up, would you agree that committing the patch makes the most sense at this point given what we know today about libusb? Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. jlink-patch-v4.txt Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
[previous copy had wrong addressee list, sorry] On Thursday 09 July 2009, Zach Welch wrote: > > > But for the record ... standard process for bug reporters > > in Linux most typically involves getting the submitter to > > build *current* stuff to verify the bug still exists. If > > the kernel isn't current, it's very likely that at least > > some of the symptoms changed; maybe the bug is fully fixed! > > The contributor of a patch is acting as a developer, so they should be > able to build it. I wasn't talking about someone submitting a patch. That was *specifically* about bug reports. A very common response to a bug report is to first verify that the *current* source still exhibits the problem. If it does, then it's time to develop new patches. And ... surprise, testing those requires testers (who are the folk who submit probem reports!) to be able to apply them and build the result. - Dave > I agree completely that developers should be testing > and submitting patches against the trunk HEAD. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
On Thursday 09 July 2009, Zach Welch wrote: > However, > real "users" _can't_ do development, even if they can run build a source > release using configure and make. That's sure helping in the development process. "Here, see if this patch fixes the problem for you." Without that sort of feedback loop, projects get nowhere. Also, keep in mind that anyone using a JTAG tool in their work is likely to be a developer already ... one fluent in low-level issues, in fact. There won't be many exceptions to that rule; and they'd be the kind of folk that *this* team doesn't address, much less deal with directly. Using JTAG for pass/fail board testing on a factory floor, maybe ... rather than the people who use results of such tests to figure out if the board can just get a partia repair. > It is _those_ individuals that should never be asked to build from the > SVN repository. We have established that this community does have such > individuals (via one or more vendor); those individuals can test a > nightly build or wait for their distributor (i.e. a developer) to > produce one for them with their fix using 'make dist'. Right? No. If they're getting support from their distributor, we aren't invoved anyway. (They're more part of the vendor's community than ours...) I think anyone getting support from the developers needs to be willing to test patches. If they weren't willing to apply experimental patches and then rebuild, WTF would they expect to happen? - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
Take 2, with Reply All chewiness On Thu, 2009-07-09 at 17:11 -0700, David Brownell wrote: > On Wednesday 08 July 2009, Zach Welch wrote: > > Asking the users to test the SVN is asking > > them to do everything that a developer must do. > > Not "everything" by far! "configure; make; run". Right... but it's bootstrap's autotools that are the real problem. The above steps are the easy part; bootstrapping is for developers only, and only required from the SVN repository. > > That is an unacceptable > > process for users, as it will result in more false reports from failed > > (re)building than it will help test the bug. > > Build bugs need fixing, regardless. Especially if "we" are > not in the support-binary-builds end of the business. > > But for the record ... standard process for bug reporters > in Linux most typically involves getting the submitter to > build *current* stuff to verify the bug still exists. If > the kernel isn't current, it's very likely that at least > some of the symptoms changed; maybe the bug is fully fixed! The contributor of a patch is acting as a developer, so they should be able to build it. I agree completely that developers should be testing and submitting patches against the trunk HEAD. > It's impractical to support users who are on code so old > the developers can't use it. At least, not without some > kind of paid support contract ... and at that point, it's > not the developers who are supporting the old code base. I agree, which is why need to find a balance between the forces of development, bug fixes, and frequent releases. Because there are active "users" and a lot of development remains to be done, we need to make releases frequently enough that they never feel tempted to use the SVN. > Plus ... this *is* open source. One of the strengths of > those processes is that they make it easy to morph from > user to developer, as the need arises. So IMO it's more > than counterproductive to draw a circle with "developers" > inside, and everyone else outside. Going back and forth > should be no big deal whatsoever. It should be *easy* to > contribute. If it seems hard ... that's worth fixing. I did make this point clearly. :) Labels are useless when you _can_ swap back and forth between using and developing the project. However, real "users" _can't_ do development, even if they can run build a source release using configure and make. It is _those_ individuals that should never be asked to build from the SVN repository. We have established that this community does have such individuals (via one or more vendor); those individuals can test a nightly build or wait for their distributor (i.e. a developer) to produce one for them with their fix using 'make dist'. Right? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 2/5] update Thumb layout for Thumb2
Change layout of Thumb disassembly to work better with Thumb2:
- Move opcode byte left, allow space for four bytes:
* after address, two spaces not one tab (taking 6 spaces)
* after 2-byte opcode, four spaces before tab
- Also, after opcode use a tab not a space
Sample output (after some patches decoding a few 32-bit instructions)::
0x3e5a 0xf4423200 ORR r2, r2, #131072 ; 0x2
0x3e5e 0x601a STR r2, [r3, #0x0]
0x3e60 0x2800 CMP r0, #0x00
0x3e62 0xd1f3 BNE 0x3e4c
0x3e64 0xf008fa38 BL 0xc2d8
The affected lines of code now wrap at sane margins too.
---
src/target/arm_disassembler.c | 112 +++-
1 file changed, 76 insertions(+), 36 deletions(-)
Change layout of Thumb disassembly to work better with Thumb2:
- Move opcode byte left, allow space for four bytes:
* after address, two spaces not one tab (taking 6 spaces)
* after 2-byte opcode, four spaces before tab
- Also, after opcode use a tab not a space
Sample output (after some patches decoding a few 32-bit instructions)::
0x3e5a 0xf4423200 ORR r2, r2, #131072 ; 0x2
0x3e5e 0x601a STR r2, [r3, #0x0]
0x3e60 0x2800 CMP r0, #0x00
0x3e62 0xd1f3 BNE 0x3e4c
0x3e64 0xf008fa38 BL 0xc2d8
The affected lines of code now wrap at sane margins too.
---
src/target/arm_disassembler.c | 112 +++-
1 file changed, 76 insertions(+), 36 deletions(-)
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -1363,7 +1363,9 @@ int evaluate_b_bl_blx_thumb(uint16_t opc
}
/* TODO: deals correctly with dual opcodes BL/BLX ... */
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\t%s 0x%8.8" PRIx32 , address, opcode,mnemonic, target_address);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 " 0x%4.4x\t%s\t0x%8.8" PRIx32,
+ address, opcode,mnemonic, target_address);
instruction->info.b_bl_bx_blx.reg_operand = -1;
instruction->info.b_bl_bx_blx.target_address = target_address;
@@ -1399,15 +1401,17 @@ int evaluate_add_sub_thumb(uint16_t opco
{
instruction->info.data_proc.variant = 0; /*immediate*/
instruction->info.data_proc.shifter_operand.immediate.immediate = Rm_imm;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\t%s r%i, r%i, #%d",
- address, opcode, mnemonic, Rd, Rn, Rm_imm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 " 0x%4.4x\t%s\tr%i, r%i, #%d",
+ address, opcode, mnemonic, Rd, Rn, Rm_imm);
}
else
{
instruction->info.data_proc.variant = 1; /*immediate shift*/
instruction->info.data_proc.shifter_operand.immediate_shift.Rm = Rm_imm;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\t%s r%i, r%i, r%i",
- address, opcode, mnemonic, Rd, Rn, Rm_imm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 " 0x%4.4x\t%s\tr%i, r%i, r%i",
+ address, opcode, mnemonic, Rd, Rn, Rm_imm);
}
return ERROR_OK;
@@ -1451,8 +1455,9 @@ int evaluate_shift_imm_thumb(uint16_t op
instruction->info.data_proc.shifter_operand.immediate_shift.Rm = Rm;
instruction->info.data_proc.shifter_operand.immediate_shift.shift_imm = imm;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\t%s r%i, r%i, #0x%02x" ,
- address, opcode, mnemonic, Rd, Rm, imm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 " 0x%4.4x\t%s\tr%i, r%i, #0x%02x" ,
+ address, opcode, mnemonic, Rd, Rm, imm);
return ERROR_OK;
}
@@ -1492,8 +1497,9 @@ int evaluate_data_proc_imm_thumb(uint16_
break;
}
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\t%s r%i, #0x%02x" ,
- address, opcode, mnemonic, Rd, imm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 " 0x%4.4x\t%s\tr%i, #0x%02x",
+ address, opcode, mnemonic, Rd, imm);
return ERROR_OK;
}
@@ -1544,18 +1550,28 @@ int evaluate_data_proc_thumb(uint16_t op
if (H1)
{
instruction->type = ARM_BLX;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\tBLX r%i", address, opcode, Rm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32
+ " 0x%4.4x\tBLX\tr%i",
+ address, opcode, Rm);
}
else
{
instruction->type = ARM_BX;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\tBX r%i", address, opcode, Rm);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32
+ " 0x%4.4x\tBX\tr%i",
+ address, opcode, Rm);
}
}
else
{
instruction->type = ARM_UNDEFINED_INSTRUCTION;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\tUNDEFINED INSTRUCTION", address, opcode);
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32
+ " 0x%4.4x\t"
+ "UNDEFINED INSTRUCTION",
+ address, opcode);
}
return ERROR_OK;
break;
@@ -1651,8 +1667,9 @@ int evaluate_data_proc_thumb(uint16_t op
}
[Openocd-development] [patch 3/5] 32-bit thumb2 disassembly, branches
Make the Thumb2 disassembler handle a bunch of 32-bit instructions:
A5.3.4 Branches and miscellaneous control
Note that this shifts some responsibililty out of helper functions,
making the code and layout simpler. Now they don't need to know
how to format anything except the instruction and its parameters.
---
src/target/arm_disassembler.c | 255 +++-
1 file changed, 251 insertions(+), 4 deletions(-)
Make the Thumb2 disassembler handle a bunch of 32-bit instructions:
A5.3.4 Branches and miscellaneous control
Note that this shifts some responsibililty out of helper functions,
making the code and layout simpler. Now they don't need to know
how to format anything except the instruction and its parameters.
---
src/target/arm_disassembler.c | 255 +++-
1 file changed, 251 insertions(+), 4 deletions(-)
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -2277,6 +2277,245 @@ int thumb_evaluate_opcode(uint16_t opcod
return -1;
}
+static int t2ev_b_bl(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ unsigned offset;
+ unsigned b21 = 1 << 21;
+ unsigned b22 = 1 << 22;
+
+ /* instead of combining two smaller 16-bit branch instructions,
+ * Thumb2 uses only one larger 32-bit instruction.
+ */
+ offset = opcode & 0x7ff;
+ offset |= (opcode & 0x03ff) >> 5;
+ if (opcode & (1 << 26)) {
+ offset |= 0xff << 23;
+ if ((opcode & (1 << 11)) == 0)
+ b21 = 0;
+ if ((opcode & (1 << 13)) == 0)
+ b22 = 0;
+ } else {
+ if (opcode & (1 << 11))
+ b21 = 0;
+ if (opcode & (1 << 13))
+ b22 = 0;
+ }
+ offset |= b21;
+ offset |= b22;
+
+
+ address += 4;
+ address += offset << 1;
+
+ instruction->type = (opcode & (1 << 14)) ? ARM_BL : ARM_B;
+ instruction->info.b_bl_bx_blx.reg_operand = -1;
+ instruction->info.b_bl_bx_blx.target_address = address;
+ sprintf(cp, "%s\t0x%08" PRIx32,
+ (opcode & (1 << 14)) ? "BL" : "B.W",
+ address);
+
+ return ERROR_OK;
+}
+
+static int t2ev_cond_b(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ unsigned offset;
+ unsigned b17 = 1 << 17;
+ unsigned b18 = 1 << 18;
+ unsigned cond = (opcode >> 22) & 0x0f;
+
+ offset = opcode & 0x7ff;
+ offset |= (opcode & 0x003f) >> 5;
+ if (opcode & (1 << 26)) {
+ offset |= 0x << 19;
+ if ((opcode & (1 << 11)) == 0)
+ b17 = 0;
+ if ((opcode & (1 << 13)) == 0)
+ b18 = 0;
+ } else {
+ if (opcode & (1 << 11))
+ b17 = 0;
+ if (opcode & (1 << 13))
+ b18 = 0;
+ }
+ offset |= b17;
+ offset |= b18;
+
+ address += 4;
+ address += offset << 1;
+
+ instruction->type = ARM_B;
+ instruction->info.b_bl_bx_blx.reg_operand = -1;
+ instruction->info.b_bl_bx_blx.target_address = address;
+ sprintf(cp, "B%s.W\t0x%08" PRIx32,
+ arm_condition_strings[cond],
+ address);
+
+ return ERROR_OK;
+}
+
+static const char *special_name(int number)
+{
+ char *special = "(RESERVED)";
+
+ switch (number) {
+ case 0:
+ special = "apsr";
+ break;
+ case 1:
+ special = "iapsr";
+ break;
+ case 2:
+ special = "eapsr";
+ break;
+ case 3:
+ special = "xpsr";
+ break;
+ case 5:
+ special = "ipsr";
+ break;
+ case 6:
+ special = "epsr";
+ break;
+ case 7:
+ special = "iepsr";
+ break;
+ case 8:
+ special = "msp";
+ break;
+ case 9:
+ special = "psp";
+ break;
+ case 16:
+ special = "primask";
+ break;
+ case 17:
+ special = "basepri";
+ break;
+ case 18:
+ special = "basepri_max";
+ break;
+ case 19:
+ special = "faultmask";
+ break;
+ case 20:
+ special = "control";
+ break;
+ }
+ return special;
+}
+
+static int t2ev_hint(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ const char *mnemonic = "WIDE UNRECOGNIZED HINT";
+
+ if (opcode & 0x0700) {
+ instruction->type = ARM_UNDEFINED_INSTRUCTION;
+ strcpy(cp, "UNDEFINED");
+ return ERROR_OK;
+ }
+
+ if (opcode & 0x00f0) {
+ sprintf(cp, "DBG\t#%d", opcode & 0xf);
+ return ERROR_OK;
+ }
+
+ switch (opcode & 0x0f) {
+ case 0:
+ mnemonic = "NOP.W";
+ break;
+ case 1:
+ mnemonic = "YIELD.W";
+ break;
+ case 2:
+ mnemonic = "WFE.W";
+ break;
+ case 3:
+ mnemonic = "WFI.W";
+ break;
+ case 4:
+ mnemonic = "SEV.W";
+ break;
+ }
+ strcpy(cp, mnemonic);
+ return ERROR_OK;
+}
+
+static int t2ev_misc(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ const char *mnemonic = "UNDEFINED INSTRUCTION";
+
+ switch ((opcode >> 4) & 0x0f) {
+ case 2:
+ mnemonic = "CLREX";
+ break;
+ case 4:
+ mnemonic = "DSB";
+ break;
+ case 5:
+ mnemonic = "DMB";
+ break;
+ case 6:
+ mnemonic = "ISB";
+ break;
+ }
+ strcpy(cp, mnemonic);
+ return ERROR_OK;
+}
+
+static int t2ev_b_misc(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ /* permanently undefined */
+ if ((opcode & 0x07f07000) == 0x07f02000) {
+ instruction->type = ARM_UNDEFINED_INSTRUCTION;
+ strcpy(cp, "UNDEFINED");
+ return ERROR_OK;
+ }
+
+ switc
Re: [Openocd-development] [PATCH 0/5] Documentation Updates for 0.2.0
On Wednesday 08 July 2009, Zach Welch wrote: > Asking the users to test the SVN is asking > them to do everything that a developer must do. Not "everything" by far! "configure; make; run". > That is an unacceptable > process for users, as it will result in more false reports from failed > (re)building than it will help test the bug. Build bugs need fixing, regardless. Especially if "we" are not in the support-binary-builds end of the business. But for the record ... standard process for bug reporters in Linux most typically involves getting the submitter to build *current* stuff to verify the bug still exists. If the kernel isn't current, it's very likely that at least some of the symptoms changed; maybe the bug is fully fixed! It's impractical to support users who are on code so old the developers can't use it. At least, not without some kind of paid support contract ... and at that point, it's not the developers who are supporting the old code base. Plus ... this *is* open source. One of the strengths of those processes is that they make it easy to morph from user to developer, as the need arises. So IMO it's more than counterproductive to draw a circle with "developers" inside, and everyone else outside. Going back and forth should be no big deal whatsoever. It should be *easy* to contribute. If it seems hard ... that's worth fixing. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 5/5] 32-bit thumb2 disassembly, binary immediates
Make the Thumb2 disassembler handle more 32-bit instructions:
A5.3.3 Data processing (plain binary immediate)
These use mostly twelve bit literals, but there are also bitfield
and saturated add primitives.
---
src/target/arm_disassembler.c | 101
1 file changed, 101 insertions(+)
Make the Thumb2 disassembler handle more 32-bit instructions:
A5.3.3 Data processing (plain binary immediate)
These use mostly twelve bit literals, but there are also bitfield
and saturated add primitives.
---
src/target/arm_disassembler.c | 101
1 file changed, 101 insertions(+)
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -2654,6 +2654,103 @@ static int t2ev_data_mod_immed(uint32_t
return ERROR_OK;
}
+static int t2ev_data_immed(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ char *mnemonic = NULL;
+ int rn = (opcode >> 16) & 0xf;
+ int rd = (opcode >> 8) & 0xf;
+ unsigned immed;
+ bool add = false;
+ bool is_signed = false;
+
+ immed = (opcode & 0x0ff) | ((opcode & 0x7000) >> 12);
+ if (opcode & (1 << 27))
+ immed |= (1 << 11);
+
+ switch ((opcode >> 20) & 0x1f) {
+ case 0:
+ if (rn == 0xf) {
+ add = true;
+ goto do_adr;
+ }
+ mnemonic = "ADDW";
+ break;
+ case 4:
+ mnemonic = "MOVW";
+ break;
+ case 0x0a:
+ if (rn == 0xf)
+ goto do_adr;
+ mnemonic = "SUBW";
+ break;
+ case 0x0c:
+ /* move constant to top 16 bits of register */
+ immed |= (opcode >> 4) & 0xf000;
+ sprintf(cp, "MOVT\tr%d, #%d\t;0x%x", rn, immed, immed);
+ return ERROR_OK;
+ case 0x10:
+ case 0x12:
+ is_signed = true;
+ case 0x18:
+ case 0x1a:
+ /* signed/unsigned saturated add */
+ immed = (opcode >> 6) & 0x03;
+ immed |= (opcode >> 10) & 0x1c;
+ sprintf(cp, "%sSAT\tr%d, #%d, r%d, %s #%d\t",
+is_signed ? "S" : "U",
+rd, (opcode & 0x1f) + 1, rn,
+(opcode & (1 << 21)) ? "ASR" : "LSL",
+immed ? immed : 32);
+ return ERROR_OK;
+ case 0x14:
+ is_signed = true;
+ /* FALLTHROUGH */
+ case 0x1c:
+ /* signed/unsigned bitfield extract */
+ immed = (opcode >> 6) & 0x03;
+ immed |= (opcode >> 10) & 0x1c;
+ sprintf(cp, "%sBFX\tr%d, r%d, #%d, #%d\t",
+is_signed ? "S" : "U",
+rd, rn, immed,
+(opcode & 0x1f) + 1);
+ return ERROR_OK;
+ case 0x16:
+ immed = (opcode >> 6) & 0x03;
+ immed |= (opcode >> 10) & 0x1c;
+ if (rn == 0xf) /* bitfield clear */
+ sprintf(cp, "BFC\tr%d, #%d, #%d\t",
+ rd, immed,
+ (opcode & 0x1f) + 1 - immed);
+ else /* bitfield insert */
+ sprintf(cp, "BFI\tr%d, r%d, #%d, #%d\t",
+ rd, rn, immed,
+ (opcode & 0x1f) + 1 - immed);
+ return ERROR_OK;
+ default:
+ goto undef;
+ }
+
+ sprintf(cp, "%s\tr%d, r%d, #%d\t;0x%x", mnemonic,
+ rd, rn, immed, immed);
+ return ERROR_OK;
+
+do_adr:
+ address &= ~0x03;
+ address += 4;
+ if (add)
+ address += immed;
+ else
+ address -= immed;
+ sprintf(cp, "ADR.W\tr%d, %8.8" PRIx32, rd, address);
+ return ERROR_OK;
+
+undef:
+ instruction->type = ARM_UNDEFINED_INSTRUCTION;
+ strcpy(cp, "UNDEFINED OPCODE");
+ return ERROR_OK;
+}
+
/*
* REVISIT for Thumb2 instructions, instruction->type isn't always being
* set. That means eventual arm_simulate_step() support for Thumb2 will
@@ -2708,6 +2805,10 @@ int thumb2_opcode(target_t *target, uint
if ((opcode & 0x1a008000) == 0x1000)
return t2ev_data_mod_immed(opcode, address, instruction, cp);
+ /* ARMv7-M: A5.3.3 Data processing (plain binary immediate) */
+ if ((opcode & 0x1a008000) == 0x1200)
+ return t2ev_data_immed(opcode, address, instruction, cp);
+
/* FIXME decode more 32-bit instructions */
LOG_DEBUG("Can't decode 32-bit Thumb2 yet (opcode=%08x)", opcode);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 4/5] 32-bit thumb2 disassembly, modified immediates
Make the Thumb2 disassembler handle more 32-bit instructions:
A5.3.1 Data processing (modified immediate)
My small sample shows GCC likes to use many of these instructions.
---
src/target/arm_disassembler.c | 142
1 file changed, 142 insertions(+)
Make the Thumb2 disassembler handle more 32-bit instructions:
A5.3.1 Data processing (modified immediate)
My small sample shows GCC likes to use many of these instructions.
---
src/target/arm_disassembler.c | 142
1 file changed, 142 insertions(+)
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -2515,6 +2515,144 @@ undef:
return ERROR_OK;
}
+static int t2ev_data_mod_immed(uint32_t opcode, uint32_t address,
+ arm_instruction_t *instruction, char *cp)
+{
+ char *mnemonic = NULL;
+ int rn = (opcode >> 16) & 0xf;
+ int rd = (opcode >> 8) & 0xf;
+ unsigned immed = opcode & 0xff;
+ unsigned func = (opcode >> 11) & 0x0e;
+ bool one = false;
+ char *suffix = "";
+
+ if (immed & 0x80)
+ func |= 1;
+ if (opcode & (1 << 26))
+ func |= 0x10;
+
+ /* "Modified" immediates */
+ switch (func >> 1) {
+ case 0:
+ break;
+ case 2:
+ immed <<= 8;
+ /* FALLTHROUGH */
+ case 1:
+ immed += immed << 16;
+ break;
+ case 3:
+ immed += immed << 8;
+ immed += immed << 16;
+ break;
+ default:
+ immed |= 0x80;
+ immed = ror(immed, func);
+ }
+
+ if (opcode & (1 << 20))
+ suffix = "S";
+
+ switch ((opcode >> 21) & 0xf) {
+ case 0:
+ if (rd == 0xf) {
+ instruction->type = ARM_TST;
+ mnemonic = "TST";
+ one = true;
+ suffix = "";
+ rd = rn;
+ } else {
+ instruction->type = ARM_AND;
+ mnemonic = "AND";
+ }
+ break;
+ case 1:
+ instruction->type = ARM_BIC;
+ mnemonic = "BIC";
+ break;
+ case 2:
+ if (rn == 0xf) {
+ instruction->type = ARM_MOV;
+ mnemonic = "MOV";
+ one = true;
+ } else {
+ instruction->type = ARM_ORR;
+ mnemonic = "ORR";
+ }
+ break;
+ case 3:
+ if (rn == 0xf) {
+ instruction->type = ARM_MVN;
+ mnemonic = "MVN";
+ one = true;
+ } else {
+ // instruction->type = ARM_ORN;
+ mnemonic = "ORN";
+ }
+ break;
+ case 4:
+ if (rd == 0xf) {
+ instruction->type = ARM_TEQ;
+ mnemonic = "TEQ";
+ one = true;
+ suffix = "";
+ rd = rn;
+ } else {
+ instruction->type = ARM_EOR;
+ mnemonic = "EOR";
+ }
+ break;
+ case 8:
+ if (rd == 0xf) {
+ instruction->type = ARM_CMN;
+ mnemonic = "CMN";
+ one = true;
+ suffix = "";
+ rd = rn;
+ } else {
+ instruction->type = ARM_ADD;
+ mnemonic = "ADD";
+ }
+ break;
+ case 10:
+ instruction->type = ARM_ADC;
+ mnemonic = "ADC";
+ break;
+ case 11:
+ instruction->type = ARM_SBC;
+ mnemonic = "SBC";
+ break;
+ case 13:
+ if (rd == 0xf) {
+ instruction->type = ARM_CMP;
+ mnemonic = "CMP";
+ one = true;
+ suffix = "";
+ rd = rn;
+ } else {
+ instruction->type = ARM_SUB;
+ mnemonic = "SUB";
+ }
+ break;
+ case 15:
+ instruction->type = ARM_RSB;
+ mnemonic = "RSB";
+ break;
+ default:
+ instruction->type = ARM_UNDEFINED_INSTRUCTION;
+ strcpy(cp, "UNDEFINED OPCODE");
+ return ERROR_OK;
+ }
+
+ if (one)
+ sprintf(cp, "%s\tr%d, #%d\t; 0x%x",
+mnemonic, rd, immed, immed);
+ else
+ sprintf(cp, "%s%s\tr%d, r%d, #%d\t; 0x%x",
+mnemonic, suffix, rd, rn, immed, immed);
+
+ return ERROR_OK;
+}
/*
* REVISIT for Thumb2 instructions, instruction->type isn't always being
@@ -2566,6 +2704,10 @@ int thumb2_opcode(target_t *target, uint
if ((opcode & 0x18008000) == 0x10008000)
return t2ev_b_misc(opcode, address, instruction, cp);
+ /* ARMv7-M: A5.3.1 Data processing (modified immediate) */
+ if ((opcode & 0x1a008000) == 0x1000)
+ return t2ev_data_mod_immed(opcode, address, instruction, cp);
+
/* FIXME decode more 32-bit instructions */
LOG_DEBUG("Can't decode 32-bit Thumb2 yet (opcode=%08x)", opcode);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 1/5] "cortex_m3 disassemble" for 16-bit Thumb2
Initial support for disassembling Thumb2 code. This works only for
Cortex-M3 cores so far. Eventually other cores will also need Thumb2
support ... but they don't yet support any kind of disassembly.
- A new Thumb2 instruction decode routine is provided.
* This has a different signature: pass the target, not the
instruction, so it can fetch a second halfword when needed.
The instruction size is likewise returned to the caller.
* All 16-bit instructions are decoded, calling the Thumb1
decode routine. That's been taught the new opcodes.
* The 32-bit instructions are recognized but not yet decoded.
* Start using the current "UAL" syntax in some cases. "SWI" is
renamed as "SVC"; "LDMIA" as "LDM"; "STMIA" as "STM".
- Define a new "cortex_m3 disassemble addr count" command to give
access to this disassembly.
Sanity checked against "objdump -d" output; a bunch of the new
instructions checked out fine. (CBZ, CBNZ, WFI, IT, CPSIE, ...)
---
doc/openocd.texi |5
src/target/arm_disassembler.c | 237 +---
src/target/arm_disassembler.h |5
src/target/cortex_m3.c| 53
4 files changed, 284 insertions(+), 16 deletions(-)
Initial support for disassembling Thumb2 code. This works only for
Cortex-M3 cores so far. Eventually other cores will also need Thumb2
support ... but they don't yet support any kind of disassembly.
- A new Thumb2 instruction decode routine is provided.
* This has a different signature: pass the target, not the
instruction, so it can fetch a second halfword when needed.
The instruction size is likewise returned to the caller.
* All 16-bit instructions are decoded, calling the Thumb1
decode routine. That's been taught the new opcodes.
* The 32-bit instructions are recognized but not yet decoded.
* Start using the current "UAL" syntax in some cases. "SWI" is
renamed as "SVC"; "LDMIA" as "LDM"; "STMIA" as "STM".
- Define a new "cortex_m3 disassemble addr count" command to give
access to this disassembly.
Sanity checked against "objdump -d" output; a bunch of the new
instructions checked out fine. (CBZ, CBNZ, WFI, IT, CPSIE, ...)
---
doc/openocd.texi |5
src/target/arm_disassembler.c | 237 +---
src/target/arm_disassembler.h |5
src/target/cortex_m3.c| 53
4 files changed, 284 insertions(+), 16 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5003,6 +5003,11 @@ If @var{value} is defined, first assigns
@subsection Cortex-M3 specific commands
@cindex Cortex-M3
+...@deffn Command {cortex_m3 disassemble} address count
+...@cindex disassemble
+Disassembles @var{count} Thumb2 instructions starting at @var{address}.
+...@end deffn
+
@deffn Command {cortex_m3 maskisr} (@option{on}|@option{off})
Control masking (disabling) interrupts during target step/resume.
@end deffn
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -21,6 +21,7 @@
#include "config.h"
#endif
+#include "target.h"
#include "arm_disassembler.h"
#include "log.h"
@@ -63,7 +64,9 @@ int evaluate_swi(uint32_t opcode, uint32
{
instruction->type = ARM_SWI;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%8.8" PRIx32 "\tSWI 0x%6.6" PRIx32 "", address, opcode, (opcode & 0xff));
+ snprintf(instruction->text, 128,
+ "0x%8.8" PRIx32 "\t0x%8.8" PRIx32 "\tSVC 0x%6.6" PRIx32,
+ address, opcode, (opcode & 0xff));
return ERROR_OK;
}
@@ -614,7 +617,8 @@ int evaluate_ldm_stm(uint32_t opcode, ui
if (U)
{
instruction->info.load_store_multiple.addressing_mode = 0;
- addressing_mode = "IA";
+ /* "IA" is the default in UAL syntax */
+ addressing_mode = "";
}
else
{
@@ -1180,6 +1184,7 @@ int arm_evaluate_opcode(uint32_t opcode,
/* clear fields, to avoid confusion */
memset(instruction, 0, sizeof(arm_instruction_t));
instruction->opcode = opcode;
+ instruction->instruction_size = 4;
/* catch opcodes with condition field [31:28] = b */
if ((opcode & 0xf000) == 0xf000)
@@ -1887,12 +1892,12 @@ int evaluate_load_store_multiple_thumb(u
if (L)
{
instruction->type = ARM_LDM;
- mnemonic = "LDMIA";
+ mnemonic = "LDM";
}
else
{
instruction->type = ARM_STM;
- mnemonic = "STMIA";
+ mnemonic = "STM";
}
snprintf(ptr_name,7,"r%i!, ",Rn);
}
@@ -1945,7 +1950,9 @@ int evaluate_cond_branch_thumb(uint16_t
if (cond == 0xf)
{
instruction->type = ARM_SWI;
- snprintf(instruction->text, 128, "0x%8.8" PRIx32 "\t0x%4.4x\tSWI 0x%02" PRIx32 , address, opcode, offset);
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32 "\t0x%4.4x\tSVC 0x%02" PRIx32,
+address, opcode, offset);
return ERROR_OK;
}
else if (cond == 0xe)
@@ -1971,11 +1978,137 @@ int evaluate_cond_branch_thumb(uint16_t
return ERROR_OK;
}
+static
[Openocd-development] [patch 0/5] thumb2 disassembly (partial)
For those of us who don't use GDB much, being able to disassemble things through OpenOCD is useful. Ergo, these patches: - Add a Thumb2 disassembler entry, which handles the 16-bit stuff (there are extensions to Thumb1). The Cortex-M3 chips can use it. - Change the layout of the Thumb disassembly so it copes better with 32-bit instructions - Disassemble one batch of 32-bit instructions: branches and miscellaneous control operations. - Another batch: data processing using "modified immediate" data - Another batch: data processing using "plain binary" immediates That's it for now. Coverage for the 32-bit instructions might be closer to one third than one quarter; I didn't count. But so far this seems to be fairly good at covering what GCC will issue. This has been lightly tested using "objdump -d" to compare against what the GNU tools say. I expect there will be minor goofs. Clearly this is for post-0.2.0 merge! - dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to "excuse" their Doxygen markup.
On Fri, Jul 10, 2009 at 2:51 AM, Zach Welch wrote: > On Thu, 2009-07-09 at 22:51 +0800, Xiaofan Chen wrote: >> Another issue with the TODO file. >> >> >@subsection thelistjtaginterfaces JTAG Interfaces >> > >> >The following tasks have been suggeted for improving OpenOCD's JTAG >> >interface support: >> > >> >- rework USB communication to be more robust. Two possible options are: >> > -# use libusb-1.0.1 with libusb-compat-0.1.1 (non-blocking I/O wrapper) >> > -# rewrite implementation to use non-blocking I/O >> >> I agree with the 2nd part (to use non-blocking I/O). I believe the >> first one is wrong. If you use libusb-compat-0.1, it would not help >> too much as it is still using the synchronous API of libusb-0.1. >> There may be some slight speed difference but you would not >> gain too much. > > Has anyone tried this to measure the performance difference? The author of libusb 1.0 and libusb-compat has a benchmark last time. http://libusb.wiki.sourceforge.net/LibusbCompat0.1 http://article.gmane.org/gmane.comp.lib.libusb.devel.general/5364 But a new benchmark for OpenOCD needs to be done. >> Instead, the above should have been. >> - rework USB communication to be more robust. One possible option is: >> -# use libusb-1.0 and asynchronous I/O. This will work for the operating >> systems which support libusb 1.0 (currently Linux and Mac OS X). >> -# use libusb-win32 0.1 asynchronous I/O under Windows > > So, there are really two projects. libusb != libusb-win32. This is a > serious problem for the free software community; it's forked itself. > That is a serious _bug_ by design; their maintainers need to be spanked > and then made to work out their differences. > As David mentioned, they are never the same project to begin with. Initially there was libusb as a usbfs wrapper, later Sun adopted the API for Solaris, Mac OS X backend and BSD ugen backend were added later. libusb-win32 started as a separate project and aims to be API compatible with libusb. The implementation is totally different and it adds some features (asynchronous I/O, isochronous transfer). Stefan Meyer starts the libusb-win32 1.0 efforts before Daniel Drake's libusb 1.0 (which was based on his fpusb). Its aim is to bring WinUSB and HID backend to libusb-win32 to solve some Windows specific issues (64bit Windows, HID device). OpenUSB (Sun's efforts of a thread-safe libusb) also started earlier than libusb 1.0. Unfortunately, during the libusb 1.0 API and OpenUSB (Sun's efforts of a thread-safe libusb) API discussions, Stefan did not participate. Therefore we ended up with three API incompatible USB libraries for the successors of libusb 0.1: libusb 1.0 (Linux, Mac OS X) OpenUSB (Sun Solaris, Linux, and Mac OS X ?) libusb-win32 1.0 (Windows) -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] USBprog interface regression
I've recently had the opportunity to start testing the USBprog interface again. Since the introduction of the "short" tms transition table, the USBprog interface has been broken. The attached patch fixes it in one way, but I don't really like the fact that it can be undone from the command prompt. It also means we can't get rid of the long table any time soon. However, on the good side - my XScale target now works as well with this adapter as it does with J-Link! Please apply - it's trivial and fixes a regression. Index: tcl/interface/usbprog.cfg === --- tcl/interface/usbprog.cfg (revision 2503) +++ tcl/interface/usbprog.cfg (working copy) @@ -5,4 +5,5 @@ # interface usbprog +tms_sequence long ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to "excuse" their Doxygen markup.
On Thursday 09 July 2009, Zach Welch wrote: > So, there are really two projects. libusb != libusb-win32. This is a > serious problem for the free software community; it's forked itself. ISTR it was never one project to begin with. It started out on Linux as a usbfs wrapper ... not as a cross-platform programming interface for USB. And given that Linux want to eventually do away with usbfs (it's a real mess internally), it's no surprise that there's no clear forward direction for that code. If "Someone" were to create such a cross-platform USB interface, that would likely attract users. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Identify state of a running CM3 target on startup
On Thu, 2009-07-09 at 16:54 +0200, Magnus Lundin wrote: > Thc cortex_m3_poll function does not identify that a target is running > unless we transition from RESET. > > This patch correctly identifies a running target. Is there a reason to keep the #if 0 block? If not, please remove that code entirely and resubmit. Dead code should never be committed. Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to "excuse" their Doxygen markup.
On Thu, 2009-07-09 at 22:51 +0800, Xiaofan Chen wrote: > Another issue with the TODO file. > > >@subsection thelistjtaginterfaces JTAG Interfaces > > > >The following tasks have been suggeted for improving OpenOCD's JTAG > >interface support: > > > >- rework USB communication to be more robust. Two possible options are: > > -# use libusb-1.0.1 with libusb-compat-0.1.1 (non-blocking I/O wrapper) > > -# rewrite implementation to use non-blocking I/O > > I agree with the 2nd part (to use non-blocking I/O). I believe the > first one is wrong. If you use libusb-compat-0.1, it would not help > too much as it is still using the synchronous API of libusb-0.1. > There may be some slight speed difference but you would not > gain too much. Has anyone tried this to measure the performance difference? > Instead, the above should have been. > - rework USB communication to be more robust. One possible option is: > -# use libusb-1.0 and asynchronous I/O. This will work for the operating > systems which support libusb 1.0 (currently Linux and Mac OS X). > -# use libusb-win32 0.1 asynchronous I/O under Windows So, there are really two projects. libusb != libusb-win32. This is a serious problem for the free software community; it's forked itself. That is a serious _bug_ by design; their maintainers need to be spanked and then made to work out their differences. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Identify state of a running CM3 target on startup
On Thursday 09 July 2009, Magnus Lundin wrote: > > Thc cortex_m3_poll function does not identify that a target is running > unless we transition from RESET. > > This patch correctly identifies a running target. ACK. This would be a nice annoyance to fix for 0.2 ... it's extremely visible! :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Version 3 test patch for jlink.c
Hi, On 7/9/09, Xiaofan Chen wrote: > > It would be nice to have a unified patch. But it seems a bit difficult here. > Maybe we can accept this as a temporary fix while investigating a better > fix. > Jlink still failing to me (i.MX27ADS and Ubuntu 9.04): $ sudo openocd -f interface/jlink.cfg -f board/imx27ads.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-09-12:40) svn:2503 $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS dcc downloads are enabled Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V6 compiled Jan 13 2009 15:40:53 Info : JLink caps 0x19ff7bbf Info : JLink hw version 6 Info : JLink max mem block 8968 Info : Vref = 2.653 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: jlink_usb_message failed with result=1) Error: jlink_tap_execute, wrong result -107 (expected 1) Any idea? Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Let's cut 0.2 now and move on
Is there anyone who does not want to cut 0.2 now and move onto a more normal development cycle ASAP? Please raise any objections within 24 hours! I think at this point we understand the level of quality that 0.2 offers. It's much better in many respects and there are some known regressions + some unknown ones. I expect that we need until 0.3 before all 0.1 regressions are fixed. There are a number of improvements in-flight, but I don't think that there is anything that is imminent -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Identify state of a running CM3 target on startup
Thc cortex_m3_poll function does not identify that a target is running
unless we transition from RESET.
This patch correctly identifies a running target.
Regards
Magnus
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 2503)
+++ src/target/cortex_m3.c (working copy)
@@ -512,17 +512,24 @@
}
}
- /*
+#if 0
if (cortex_m3->dcb_dhcsr & S_SLEEP)
+ {
target->state = TARGET_SLEEP;
- */
-
-#if 0
- /* Read Debug Fault Status Register, added to figure out the lockup when running flashtest.script */
- mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, &cortex_m3->nvic_dfsr);
- LOG_DEBUG("dcb_dhcsr 0x%x, nvic_dfsr 0x%x, target->state: %s", cortex_m3->dcb_dhcsr, cortex_m3->nvic_dfsr, target_state_name(target));
+ return ERROR_OK;
+ }
#endif
+ if (target->state == TARGET_UNKNOWN)
+ {
+ /* check if processor is retiring instructions */
+ if (cortex_m3->dcb_dhcsr & S_RETIRE_ST)
+ {
+ target->state = TARGET_RUNNING;
+ return ERROR_OK;
+ }
+ }
+
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] Add comments to top-level files to "excuse" their Doxygen markup.
Another issue with the TODO file. >@subsection thelistjtaginterfaces JTAG Interfaces > >The following tasks have been suggeted for improving OpenOCD's JTAG >interface support: > >- rework USB communication to be more robust. Two possible options are: > -# use libusb-1.0.1 with libusb-compat-0.1.1 (non-blocking I/O wrapper) > -# rewrite implementation to use non-blocking I/O I agree with the 2nd part (to use non-blocking I/O). I believe the first one is wrong. If you use libusb-compat-0.1, it would not help too much as it is still using the synchronous API of libusb-0.1. There may be some slight speed difference but you would not gain too much. Instead, the above should have been. - rework USB communication to be more robust. One possible option is: -# use libusb-1.0 and asynchronous I/O. This will work for the operating systems which support libusb 1.0 (currently Linux and Mac OS X). -# use libusb-win32 0.1 asynchronous I/O under Windows -- 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] Version 3 test patch for jlink.c
On Thu, Jul 9, 2009 at 5:34 PM, Zach Welch wrote: > If you have to use conditionals to use libusb, then libusb is not > portable. Perhaps I am wrong, but I thought that was one of the entire > points for existing: to provide a _portable_ USB library. Just take note there are libusb 0.1 and libusb-win32 0.1 are separate project. They are API compatible. But there may be some behavior difference across these two project. Here is a wiki entry I wrote. But it only addresses the cosmetic changes needed. http://libusb-win32.wiki.sourceforge.net/Porting+libusb+based+program+to+libusb-win32 Then there are different backend within libusb 0.1. The Linux backend, the Mac OS X backend, the BSD usbgen backend may have some subtle differences in terms of behaviors. For example, Gary pointed out this one for Mac OS X. http://osdir.com/ml/lib.libusb.devel.general/2006-06/msg00020.html > If this understanding is correct, then we are either seeing a bug in > libusb, or we are misusing its APIs. Conditionals will attempt to solve > libusb's problems in the OpenOCD code. Or did I miss something here? > > As a quick sanity check, what versions of libusb are undergoing testing > in this thread? If only older versions that fail, then this thread may > have been chasing ghosts. If nothing else, investigating how to unify > this behavior inside libusb seems to be the right approach. Doesn't it? > I believe we are all using the latest 0.1.12 version. It would be nice to have a unified patch. But it seems a bit difficult here. Maybe we can accept this as a temporary fix while investigating a better fix. -- 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] Version 3 test patch for jlink.c
On Thu, Jul 9, 2009 at 5:11 PM, Spencer Oliver wrote: >> >> It is starting to look like there is no single solution that >> will fix all OS issues with respect to this issue. I am >> starting to think it is time to turn to conditional >> compilation directives. >> >> Any thoughts, comments, or reservations? >> > > Its looking that way - try the attached. > I have tested under win32 and ubuntu. > Yes this works under Ubuntu 9.04. A minor fix is to move the usb_init() up in the find_jlink_device() helper function. -- 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] Version 3 test patch for jlink.c
On Thu, Jul 9, 2009 at 8:05 AM, Xiaofan Chen wrote:
> What I am thinking now is that this patch is still strange. Typically
> the usb_set_configuration() will solve some problems for some USB
> device (say USB toggle bit problems) since it is also a light weight
> reset.
>
> But in case usb_reset() is necessary, it is typically called during the
> closing stage.
>
> An example I wrote before.
> http://www.microchip.com/forums/tm.aspx?m=340892
>
> That is to say, typically you call these three instruction
> when closing the usb_handle (after you finish the operation and
> prepare for exit).
>
> usb_release_interface(devh, 0);
> usb_rese(devh); //adding this line makes the program happy
> usb_close(devh);
>
>
> Which means in this case:
>
> static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
> {
> usb_close(jlink_jtag->usb_handle);
> free(jlink_jtag);
> }
>
> becomes
>
> static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
> {
> usb_release_interface((jlink_jtag->usb_handle,0);
> usb_reset(jlink_jtag->usb_handle);
> usb_close(jlink_jtag->usb_handle);
> free(jlink_jtag);
> }
>
> Could you try this?
>
> Personally I observed that normally first launch of OpenOCD is okay
> and the subsequent launch of OpenOCD might cause startup problems.
> So this indicates that the exit may not be so clean and this leads to
> Jlink's initial status in a undesired state which even usb_set_configuration
> can not help.
>
> But if you see the problems even during the first launch, then the above
> may not help.
>
So I tried this way and generated the following patch.
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c(revision 2503)
+++ src/jtag/jlink.c(working copy)
@@ -864,15 +864,6 @@
{
result->usb_handle = usb_open(dev);
- /*
-* Some j-link dongles experience
intermittent communication
issues at startup to varying degrees
-* depending on the host operating system.
Troubleshooting this
problem all the way back to libusb
-* revealed that without a usb reset, the
hardware can start in
an uncertain state causing a litany
-* of annoying problems. The next step
was added to the original
code to address this problem.
-*/
-
- usb_reset(result->usb_handle);
-
/* usb_set_configuration required under win32 */
usb_set_configuration(result->usb_handle,
dev->config[0].bConfigurationValue);
usb_claim_interface(result->usb_handle, 0);
@@ -908,6 +899,8 @@
static void jlink_usb_close(jlink_jtag_t *jlink_jtag)
{
+usb_release_interface(jlink_jtag->usb_handle,0);
+usb_reset(jlink_jtag->usb_handle);
usb_close(jlink_jtag->usb_handle);
free(jlink_jtag);
}
It does help to reduce the initialization error under Ubuntu 9.04, but
not completely. So it does not work unfortunately.
--
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] Version 3 test patch for jlink.c
On Thu, 2009-07-09 at 01:11 -0700, Gary Carlson wrote: > > > On 7/9/09 12:57 AM, "Spencer Oliver" wrote: > > > > >> Zach/Spencer/Xiaofan, > >> > >> I did some more experimentation on the latest subversion > >> (2499) and was able to tweak the jlink.c code slightly to > >> possibly achieve three objectives: > >> > >> 1. Make jlink dongles work under Windows for Spencer. > >> 2. Make jlink dongles work under Mac OS X for me. > >> 3. Make jlink dongles work under Linux for Zach and Xiaofan. > >> 4. Note the possible future problem that Xiaofan uncovered > >> with libusb interactions in the Linux kernel and use it in > >> such a way that the code in jlink.c won't cause future problems. > >> > >> I have confirmed #2 and believe that #4 is satisfied. What I > >> don't know is whether #1 and #4 are. Could you try this out > >> with your dongles and let me know what happens? > >> > >> If the patch works, I need to do a little cleanup but I > >> didn't want to focus on that until I knew for sure whether it > >> would solve the issues at hand. > >> > > > > This patch will not work on windows as after the reset the handle is > > invalid. > > so the usb_close will fail. Also the dev structure is not valid either after > > the usb_reset. > > > > This is why in my patch i search for the device again after the reset. > > > > Cheers > > Spen > > It is starting to look like there is no single solution that will fix all OS > issues with respect to this issue. I am starting to think it is time to > turn to conditional compilation directives. > > Any thoughts, comments, or reservations? If you have to use conditionals to use libusb, then libusb is not portable. Perhaps I am wrong, but I thought that was one of the entire points for existing: to provide a _portable_ USB library. If this understanding is correct, then we are either seeing a bug in libusb, or we are misusing its APIs. Conditionals will attempt to solve libusb's problems in the OpenOCD code. Or did I miss something here? As a quick sanity check, what versions of libusb are undergoing testing in this thread? If only older versions that fail, then this thread may have been chasing ghosts. If nothing else, investigating how to unify this behavior inside libusb seems to be the right approach. Doesn't it? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Version 3 test patch for jlink.c
> > It is starting to look like there is no single solution that > will fix all OS issues with respect to this issue. I am > starting to think it is time to turn to conditional > compilation directives. > > Any thoughts, comments, or reservations? > Its looking that way - try the attached. I have tested under win32 and ubuntu. Cheers Spen jlink.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Version 3 test patch for jlink.c
On Thu, Jul 9, 2009 at 8:23 AM, Gary Carlson wrote: > According the the libusb manual your use syntax is right. However, I get > the feeling that the manual makes a deadly assumption that every software > program that uses a USB port cleans it up properly at the end. I ran one > experiment a few days ago alternating between a USB mouse and the J-link > dongle and it caused a 100% startup failure rate in the J-link software. This is interesting. What is the procedure to repeat this? > I am obviously assuming that cleanup is a problem, but I will make the > concession that this is conjecture on my part without doing further > research. I am also assuming that cleanup is the problem. > I do agree with you though that if the intent is to follow the libusb manual > we should do a reset at the end in the jlink code. > > If the test patch works for everyone, I can throw that in if everyone > agrees. I will try your patch and the other methods this evening. -- 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] Version 3 test patch for jlink.c
On 7/9/09 12:57 AM, "Spencer Oliver" wrote: > >> Zach/Spencer/Xiaofan, >> >> I did some more experimentation on the latest subversion >> (2499) and was able to tweak the jlink.c code slightly to >> possibly achieve three objectives: >> >> 1. Make jlink dongles work under Windows for Spencer. >> 2. Make jlink dongles work under Mac OS X for me. >> 3. Make jlink dongles work under Linux for Zach and Xiaofan. >> 4. Note the possible future problem that Xiaofan uncovered >> with libusb interactions in the Linux kernel and use it in >> such a way that the code in jlink.c won't cause future problems. >> >> I have confirmed #2 and believe that #4 is satisfied. What I >> don't know is whether #1 and #4 are. Could you try this out >> with your dongles and let me know what happens? >> >> If the patch works, I need to do a little cleanup but I >> didn't want to focus on that until I knew for sure whether it >> would solve the issues at hand. >> > > This patch will not work on windows as after the reset the handle is > invalid. > so the usb_close will fail. Also the dev structure is not valid either after > the usb_reset. > > This is why in my patch i search for the device again after the reset. > > Cheers > Spen It is starting to look like there is no single solution that will fix all OS issues with respect to this issue. I am starting to think it is time to turn to conditional compilation directives. Any thoughts, comments, or reservations? Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2471 - trunk/src/jtag
> > Hi Spencer, > > I will do some more digging. It sounds like you have a > Windows test platform. Was the intermittent startup issue > ever a problem on this operating system? > Not that i noticed - if i just remove the usb_reset all seems well. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Version 3 test patch for jlink.c
> Zach/Spencer/Xiaofan, > > I did some more experimentation on the latest subversion > (2499) and was able to tweak the jlink.c code slightly to > possibly achieve three objectives: > > 1. Make jlink dongles work under Windows for Spencer. > 2. Make jlink dongles work under Mac OS X for me. > 3. Make jlink dongles work under Linux for Zach and Xiaofan. > 4. Note the possible future problem that Xiaofan uncovered > with libusb interactions in the Linux kernel and use it in > such a way that the code in jlink.c won't cause future problems. > > I have confirmed #2 and believe that #4 is satisfied. What I > don't know is whether #1 and #4 are. Could you try this out > with your dongles and let me know what happens? > > If the patch works, I need to do a little cleanup but I > didn't want to focus on that until I knew for sure whether it > would solve the issues at hand. > This patch will not work on windows as after the reset the handle is invalid. so the usb_close will fail. Also the dev structure is not valid either after the usb_reset. This is why in my patch i search for the device again after the reset. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Strange problem with LPC2103
Freddie,
At which frequency is your LPC2103 running and which core voltage? At
higher frequencies the chip may show strange behaviour due to the core
supply voltage dropping too much (NXP has an errata sheet on this). You
can try to reduce the clock frequency to +/- 20MHz and shut down all
unused peripherals as a test.
Nico Coesel
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin
> Sent: woensdag 8 juli 2009 19:43
> To: openocd-development
> Subject: [Openocd-development] Strange problem with LPC2103
>
> I have a very simple code which just blinks the LED. The code itself
is
> fine.
>
> When I upload the code and just run it everything is fine. When I try
to
> debug the same code that I've uploaded before (flash is not modified)
> some registers have some funny values which make the code work wrong.
> When I close OpenOCD and reset the chip again everything works fine...
>
> WTF?
>
> I've done some investigation and everything is even stranger...
>
> I use GDB Hardware Debugging plugin in Eclipse. I put a breakpoint at
main.
>
> When the core hits the breakpoint I inspect the registers:
>
> > reg
> (11) r11 (/32): 0x41F9 (dirty: 0, valid: 1)
> (13) r13_usr (/32): 0x41EC (dirty: 0, valid: 1)
>
> R11 and SP are the register that miraculously have such strange
values,
> because before main there are just three lines that modify them:
>
> 0x00e8 : push {r11, lr}
> 0x00ec : add r11, sp, #4 ; 0x4
> 0x00f0 : sub sp, sp, #8; 0x8
>
> (the SP is setup in the startup of course, the value for that is
> 0x4200. That's pretty easy to count that R11 should be 0x41FC
> and SP should be ...1F0.
>
> Now the funny part... When I put my first breakpoint at Reset_Handler
> (that's exactly what you think), and then put breakpoint at the first
> line that modifies R11 (the first one of the three above) everything
> works... The reg dump at the same point as before (3 lines further, at
> the beginning of main):
>
> (11) r11 (/32): 0x41FC (dirty: 0, valid: 1)
> (13) r13_usr (/32): 0x41F0 (dirty: 0, valid: 1)
>
> When I reset and stop at Reset_Handler, then run to main directly
> without that breakpoint in-the-middle - the reg values are wrong /;
>
> I've tried OpenOCD-r2498, 0.1.0 and some revs in between - the same
>
> I've tried GDB from the most recent CodeSourcery and from some older
> version of Yagarto - the same.
>
> When I close OpenOCD and reset the chip the code works fine. During
the
> whole process the contents of flash were exactly the same...
>
> Any ideas? Any help? Who should I blame?
>
> Thx in advance...
>
> 4\/3!!
>
> full register dump at the beginning of main (only R11 and SP are
> different...):
>
> WRONG:
>
> (0) r0 (/32): 0x00E8 (dirty: 1, valid: 1)
> (1) r1 (/32): 0x4000 (dirty: 1, valid: 1)
> (2) r2 (/32): 0x4000 (dirty: 0, valid: 1)
> (3) r3 (/32): 0x4000 (dirty: 0, valid: 1)
> (4) r4 (/32): 0x (dirty: 0, valid: 1)
> (5) r5 (/32): 0x (dirty: 0, valid: 1)
> (6) r6 (/32): 0x (dirty: 0, valid: 1)
> (7) r7 (/32): 0x (dirty: 0, valid: 1)
> (8) r8 (/32): 0x (dirty: 0, valid: 1)
> (9) r9 (/32): 0x (dirty: 0, valid: 1)
> (10) r10 (/32): 0x (dirty: 0, valid: 1)
> (11) r11 (/32): 0x41F5 (dirty: 0, valid: 1)
> (12) r12 (/32): 0x (dirty: 0, valid: 1)
> (13) r13_usr (/32): 0x41E8 (dirty: 0, valid: 1)
> (14) lr_usr (/32): 0x00B0 (dirty: 0, valid: 1)
> (15) pc (/32): 0x00F4 (dirty: 1, valid: 1)
> (16) r8_fiq (/32): 0x (dirty: 0, valid: 0)
> (17) r9_fiq (/32): 0x (dirty: 0, valid: 0)
> (18) r10_fiq (/32): 0x (dirty: 0, valid: 0)
> (19) r11_fiq (/32): 0x (dirty: 0, valid: 0)
> (20) r12_fiq (/32): 0x (dirty: 0, valid: 0)
> (21) r13_fiq (/32): 0x (dirty: 0, valid: 0)
> (22) lr_fiq (/32): 0x (dirty: 0, valid: 0)
> (23) r13_irq (/32): 0x (dirty: 0, valid: 0)
> (24) lr_irq (/32): 0x (dirty: 0, valid: 0)
> (25) r13_svc (/32): 0x4200 (dirty: 0, valid: 0)
> (26) lr_svc (/32): 0x7FFFE35F (dirty: 0, valid: 0)
> (27) r13_abt (/32): 0x (dirty: 0, valid: 0)
> (28) lr_abt (/32): 0x (dirty: 0, valid: 0)
> (29) r13_und (/32): 0x (dirty: 0, valid: 0)
> (30) lr_und (/32): 0x (dirty: 0, valid: 0)
> (31) cpsr (/32): 0x6010 (dirty: 0, valid: 1)
> (32) spsr_fiq (/32): 0x (dirty: 0, valid: 0)
> (33) spsr_irq (/32): 0x (dirty: 0, valid: 0)
> (34) spsr_svc (/32): 0x0010 (dirty: 0, valid: 0)
> (35) spsr_abt (/32): 0x (dirty: 0, valid: 0)
> (36) spsr_und (/32): 0x (dirty: 0, valid: 0)
> (37) debug_ctrl (/6): 0x05 (dirty: 0, valid: 1)
> (38) debug_status (/5): 0x09 (dirty: 0, valid: 0)
> (39) comms_ctrl (/32): 0x4000 (dirty: 0, valid: 0)
> (40) comms_data (/32): 0x (dirty: 0, valid: 0)
> (41) watch
