Re: [Openocd-development] Openocd vrs Commercial jtag dongles
Sadly, that also requires a lot of engineering expertise to write that Actually the hardware description is not as bad as you might first think, I have a prototype Xilinx CoolRunnerII CPLD hooked up to a Cypress high speed FX2, this effectively gives a direct pipe from the OpenOCD USB calls to the CPLD (via the FX2 slave interface). I'm a software engineer and selected this challenge as a first project to teach myself Verilog, it's really just a simple state machine with a few twiddles. My long term plan is to make all of this open source including: board design, verilog code, FX2 firmware and the Openocd patch... It is very prototype at the moment, currently it implements the SCANIO in hardware everything else is still bit banged but it does work. Liam. - Original Message - From: Duane Ellis open...@duaneellis.com To: Openocd-Dev openocd-development@lists.berlios.de Sent: Saturday, November 21, 2009 3:42 PM Subject: [Openocd-development] Openocd vrs Commercial jtag dongles Recently, I've been using quite a few commercial jtag tools from chip vendors. One thing I've noticed is that they all have implement the design with an small usb-controller + FPGA of some type (typically a xilinx spartan). I can see the real benefit, they download and flash the target at an unbelievable speed, ie: couple seconds for 256K of data. In contrast, non-fpga solutions, (bitbang ftdi, etc) are much slower overall. My guess is they are creating a hugely fast chip specific download engine they just feed data bytes to - and it operates at some hugely fast speed (that probably helps) In theory, the dongle has 2 modes, simple slow bitbang - once the target is determined, download an acceleration engine the fpga. The debugger step-in/over/line/etc rate with these tools is so fast... perhaps they have have implemented some common tasks like step and register dump type sequences in the dongle's fpga. Watch windows are for example very snappy. Sadly, that also requires a lot of engineering expertise to write that fpga code. in the cases I've seen [ie: vendor supplied tools] the chip companies also have a large pool of people who know or understand verilog/vhdl and can write such fpga code. It is just blindingly fast... -Duane. ___ 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 vrs Commercial jtag dongles
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Duane Ellis Sent: zaterdag 21 november 2009 16:42 To: Openocd-Dev Subject: [Openocd-development] Openocd vrs Commercial jtag dongles Recently, I've been using quite a few commercial jtag tools from chip vendors. One thing I've noticed is that they all have implement the design with an small usb-controller + FPGA of some type (typically a xilinx spartan). I can see the real benefit, they download and flash the target at an unbelievable speed, ie: couple seconds for 256K of data. In contrast, non-fpga solutions, (bitbang ftdi, etc) are much slower overall. My guess is they are creating a hugely fast chip specific download engine they just feed data bytes to - and it operates at some hugely fast speed (that probably helps) In theory, the dongle has 2 modes, simple slow bitbang - once the target is determined, download an acceleration engine the fpga. The debugger step-in/over/line/etc rate with these tools is so fast... perhaps they have have implemented some common tasks like step and register dump type sequences in the dongle's fpga. Watch windows are for example very snappy. Sadly, that also requires a lot of engineering expertise to write that fpga code. in the cases I've seen [ie: vendor supplied tools] the chip companies also have a large pool of people who know or understand verilog/vhdl and can write such fpga code. The FPGA isn't that difficult. I've created a similar setup using OpenOCD. The biggest problem I had was that OpenOCD is spending most of its time creating JTAG bit streams. Its not the bit-banging that takes most of the time! On a 333MHz platform it took about 15 minutes to program 180kB into flash (with an FPGA for the JTAG interface!). To get more speed I created pre-defined JTAG commands for memory write and memory read and fill in the blanks (address and data) when necessary (very target specific ofcourse!). This reduced the programming time to a few seconds. I guess the effect will be less on a PC, but I think it might be worth to do some profiling. This could be made into a generic solution if OpenOCD would support a caching mechanism that allows patching existing JTAG bit streams. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] mips: remove dynamic arrays - reduces stack usage
Hi Oyvind,
Please see the patch below.
Please update the parameter num_param_in of mips32_pracc_exec while removing
dynamic arrays.
Thanks.
- Jerry
--- a/src/target/mips32_pracc.c
+++ b/src/target/mips32_pracc.c
@@ -618,11 +618,11 @@ int mips32_pracc_write_mem32(struct mips_ejtag
*ejtag_info, uint32_t addr, int c
param_in[1] = addr + count * sizeof(uint32_t); //last address
memcpy(param_in[2], buf, count * sizeof(uint32_t));
mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code, \
- sizeof(param_in)/sizeof(param_in[0]),param_in, 0, NULL, 1);
+ count + 2, param_in, 0, NULL, 1);
free(param_in);
return ERROR_OK;
}
@@ -713,11 +713,11 @@ int mips32_pracc_write_mem16(struct mips_ejtag
*ejtag_info, uint32_t addr, int c
{
param_in[i + 2] = buf[i];
}
mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code, \
- sizeof(param_in)/sizeof(param_in[0]), param_in, 0, NULL, 1);
+ count + 2, param_in, 0, NULL, 1);
free(param_in);
return ERROR_OK;
}
@@ -776,11 +776,11 @@ int mips32_pracc_write_mem8(struct mips_ejtag
*ejtag_info, uint32_t addr, int co
{
param_in[i + 2] = buf[i];
}
retval = mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code,
\
- sizeof(param_in)/sizeof(param_in[0]), param_in, 0, NULL, 1);
+ count + 2, param_in, 0, NULL, 1);
free(param_in);
return retval;
}
--
This message has been scanned for viruses and
dangerous content by Draytek E-mail System, and is
believed to be clean.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips: remove dynamic arrays - reduces stack usage
The patch didn't make it through. Please check this patch and I'll commit it. Sorry about breaking the mips stuff thanks for spotting it! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer From 308f6494e8c1281f4f17e821911043267e844ca2 Mon Sep 17 00:00:00 2001 From: Jerry Ling jerry_l...@draytek.com Date: Mon, 23 Nov 2009 12:11:54 +0100 Subject: [PATCH] mips: fix gaffe when removing dynamic array allocation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Classic sizeof() gaffe. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- src/target/mips32_pracc.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/target/mips32_pracc.c b/src/target/mips32_pracc.c index 40627e1..4f9a704 100644 --- a/src/target/mips32_pracc.c +++ b/src/target/mips32_pracc.c @@ -620,7 +620,7 @@ int mips32_pracc_write_mem32(struct mips_ejtag *ejtag_info, uint32_t addr, int c memcpy(param_in[2], buf, count * sizeof(uint32_t)); mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code, \ - sizeof(param_in)/sizeof(param_in[0]),param_in, 0, NULL, 1); + count + 2, param_in, 0, NULL, 1); free(param_in); @@ -715,7 +715,7 @@ int mips32_pracc_write_mem16(struct mips_ejtag *ejtag_info, uint32_t addr, int c } mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code, \ - sizeof(param_in)/sizeof(param_in[0]), param_in, 0, NULL, 1); + count + 2, param_in, 0, NULL, 1); free(param_in); @@ -778,7 +778,7 @@ int mips32_pracc_write_mem8(struct mips_ejtag *ejtag_info, uint32_t addr, int co } retval = mips32_pracc_exec(ejtag_info, sizeof(code)/sizeof(code[0]), code, \ - sizeof(param_in)/sizeof(param_in[0]), param_in, 0, NULL, 1); + count +2, param_in, 0, NULL, 1); free(param_in); -- 1.6.3.3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm926ejs cp15 commands retired
These are now handled by the generic mrc/mcr commands.
Testing much appreciated!
arm720t, arm920t has cp15 specific commands that I believe
can be replaced by the generic mrc/mcr syntax, but I haven't
deciphered the syntax of those cp15 commands.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From eeb4276deb5c3ba6621b8121d460bc50857c8d53 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?= oyvind.har...@zylin.com
Date: Mon, 26 Oct 2009 14:08:43 +0100
Subject: [PATCH] arm926ejs: retire cp15 commands, handled by mrc/mcr.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
doc/openocd.texi |7 -
src/target/arm926ejs.c | 66 --
tcl/board/dm355evm.cfg |2 +-
tcl/board/openrd.cfg |2 +-
tcl/board/sheevaplug.cfg |2 +-
5 files changed, 3 insertions(+), 76 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 9659e92..cff7fc5 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5704,13 +5704,6 @@ they are not built from ARM926ej-s designs.
Print information about the caches found.
@end deffn
-...@deffn Command {arm926ejs cp15} opcode1 opcode2 CRn CRm regnum [value]
-Accesses cp15 register @var{regnum} using
-...@var{opcode1}, @var{opcode2}, @var{CRn}, and @var{CRm}.
-If a @var{value} is provided, that value is written to that register.
-Else that register is read and displayed.
-...@end deffn
-
@subsection ARM966E specific commands
@cindex ARM966E
diff --git a/src/target/arm926ejs.c b/src/target/arm926ejs.c
index 56d86cc..24488c4 100644
--- a/src/target/arm926ejs.c
+++ b/src/target/arm926ejs.c
@@ -713,67 +713,6 @@ static int arm926ejs_target_create(struct target *target, Jim_Interp *interp)
return arm926ejs_init_arch_info(target, arm926ejs, target-tap);
}
-COMMAND_HANDLER(arm926ejs_handle_cp15_command)
-{
- int retval;
- struct target *target = get_current_target(CMD_CTX);
- struct arm926ejs_common *arm926ejs = target_to_arm926(target);
- int opcode_1;
- int opcode_2;
- int CRn;
- int CRm;
-
- if ((CMD_ARGC 4) || (CMD_ARGC 5))
- {
- command_print(CMD_CTX, usage: arm926ejs cp15 opcode_1 opcode_2 CRn CRm [value]);
- return ERROR_OK;
- }
-
- COMMAND_PARSE_NUMBER(int, CMD_ARGV[0], opcode_1);
- COMMAND_PARSE_NUMBER(int, CMD_ARGV[1], opcode_2);
- COMMAND_PARSE_NUMBER(int, CMD_ARGV[2], CRn);
- COMMAND_PARSE_NUMBER(int, CMD_ARGV[3], CRm);
-
- retval = arm926ejs_verify_pointer(CMD_CTX, arm926ejs);
- if (retval != ERROR_OK)
- return retval;
-
- if (target-state != TARGET_HALTED)
- {
- command_print(CMD_CTX, target must be stopped for \%s\ command, CMD_NAME);
- return ERROR_OK;
- }
-
- if (CMD_ARGC == 4)
- {
- uint32_t value;
- if ((retval = arm926ejs-read_cp15(target, opcode_1, opcode_2, CRn, CRm, value)) != ERROR_OK)
- {
- command_print(CMD_CTX, couldn't access register);
- return ERROR_OK;
- }
- if ((retval = jtag_execute_queue()) != ERROR_OK)
- {
- return retval;
- }
-
- command_print(CMD_CTX, %i %i %i %i: %8.8 PRIx32 , opcode_1, opcode_2, CRn, CRm, value);
- }
- else
- {
- uint32_t value;
- COMMAND_PARSE_NUMBER(u32, CMD_ARGV[4], value);
- if ((retval = arm926ejs-write_cp15(target, opcode_1, opcode_2, CRn, CRm, value)) != ERROR_OK)
- {
- command_print(CMD_CTX, couldn't access register);
- return ERROR_OK;
- }
- command_print(CMD_CTX, %i %i %i %i: %8.8 PRIx32 , opcode_1, opcode_2, CRn, CRm, value);
- }
-
- return ERROR_OK;
-}
-
COMMAND_HANDLER(arm926ejs_handle_cache_info_command)
{
int retval;
@@ -829,11 +768,6 @@ int arm926ejs_register_commands(struct command_context *cmd_ctx)
NULL, COMMAND_ANY,
arm926ejs specific commands);
- register_command(cmd_ctx, arm926ejs_cmd, cp15,
- arm926ejs_handle_cp15_command, COMMAND_EXEC,
- display/modify cp15 register
- opcode_1 opcode_2 CRn CRm [value]);
-
register_command(cmd_ctx, arm926ejs_cmd, cache_info,
arm926ejs_handle_cache_info_command, COMMAND_EXEC,
display information about target caches);
diff --git a/tcl/board/dm355evm.cfg b/tcl/board/dm355evm.cfg
index 1f814b2..2e298b7 100644
--- a/tcl/board/dm355evm.cfg
+++ b/tcl/board/dm355evm.cfg
@@ -182,7 +182,7 @@ proc dm355evm_init {} {
# turn on icache - set I bit in cp15 register c1
- arm926ejs cp15 0 0 1 0 0x00051078
+ mcr 0 0 1 0 0x00051078
}
# NAND -- socket has two chipselects, MT29F16G08FAA puts 1GByte on each one.
diff --git a/tcl/board/openrd.cfg b/tcl/board/openrd.cfg
index e8784d4..4bc708d 100644
--- a/tcl/board/openrd.cfg
+++ b/tcl/board/openrd.cfg
@@ -29,7 +29,7 @@ proc openrd_init { } {
jtag_reset 0 0
wait_halt
- arm926ejs cp15 0 0 1 0 0x00052078
+ mcr 0 0 1 0 0x00052078
mww 0xD0001400 0x43000C30 # DDR SDRAM Configuration Register
mww 0xD0001404 0x37543000 # Dunit Control Low Register
diff --git a/tcl/board/sheevaplug.cfg
[Openocd-development] retire arm920t and arm720t cp15 commands
Would anyone mind if the arm920t and arm720t cp15 commands were retired? The only user of arm920t in the tcl directory is csb337.cfg. If someone could offer a translation of the arm920t cp15 2 0xc0001078 command to mcr syntax + test it. We'd be ready to retire the arm920t/arm720t commands in favor of the generic mrc/mcr commands. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retire arm920t and arm720t cp15 commands
On Mon, 2009-11-23 at 14:19 +0100, Øyvind Harboe wrote: Would anyone mind if the arm920t and arm720t cp15 commands were retired? The only user of arm920t in the tcl directory is csb337.cfg. If someone could offer a translation of the arm920t cp15 2 0xc0001078 command to mcr syntax + test it. We'd be ready to retire the arm920t/arm720t commands in favor of the generic mrc/mcr commands. I have a patch to convert 720t command to the new command registration. If you're going to drop it, then I'll skip that part of 920t for now, but are there other bits that may disappear in the next day or so (i.e. before I wrap up and eventually push my series)? --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retire arm920t and arm720t cp15 commands
On Mon, Nov 23, 2009 at 2:55 PM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-23 at 14:19 +0100, Øyvind Harboe wrote: Would anyone mind if the arm920t and arm720t cp15 commands were retired? The only user of arm920t in the tcl directory is csb337.cfg. If someone could offer a translation of the arm920t cp15 2 0xc0001078 command to mcr syntax + test it. We'd be ready to retire the arm920t/arm720t commands in favor of the generic mrc/mcr commands. I have a patch to convert 720t command to the new command registration. If you're going to drop it, then I'll skip that part of 920t for now, but are there other bits that may disappear in the next day or so (i.e. before I wrap up and eventually push my series)? We *could* just drop the cp15 720t/920t commands and then just deal with any fallout for the mrc/mcr implementations... I have no testing feedback that mcr/mcr works or is complete enough to replace 720t/920t cp15 commands, but I believe so... Essentially there will then be one script that ships with OpenOCD that has a syntax error which will need a rewrite to the mcr syntax. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
On Monday 23 November 2009, Nico Coesel wrote: The biggest problem I had was that OpenOCD is spending most of its time creating JTAG bit streams. Its not the bit-banging that takes most of the time! On a 333MHz platform it took about 15 minutes to program 180kB into flash (with an FPGA for the JTAG interface!). To get more speed I created pre-defined JTAG commands for memory write and memory read and fill in the blanks (address and data) when necessary (very target specific ofcourse!). This reduced the programming time to a few seconds. Heh ... that seems like good feedback for some of those questions about how the JTAG layer should get fixed! :) I guess the effect will be less on a PC, but I think it might be worth to do some profiling. This could be made into a generic solution if OpenOCD would support a caching mechanism that allows patching existing JTAG bit streams. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retire arm920t and arm720t cp15 commands
How's this?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 828d006a9d05b24b6dcdf1c552912e04586d6f7d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?= oyvind.har...@zylin.com
Date: Mon, 23 Nov 2009 18:23:10 +0100
Subject: [PATCH] arm926ejs: fix gaffe when converting from arm926ejs cp15 to mcr
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
the first arg is the register number 15 = cp15.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
tcl/board/dm355evm.cfg |2 +-
tcl/board/openrd.cfg |2 +-
tcl/board/sheevaplug.cfg |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tcl/board/dm355evm.cfg b/tcl/board/dm355evm.cfg
index 2e298b7..2c8bea8 100644
--- a/tcl/board/dm355evm.cfg
+++ b/tcl/board/dm355evm.cfg
@@ -182,7 +182,7 @@ proc dm355evm_init {} {
# turn on icache - set I bit in cp15 register c1
- mcr 0 0 1 0 0x00051078
+ mcr 15 0 0 1 0 0x00051078
}
# NAND -- socket has two chipselects, MT29F16G08FAA puts 1GByte on each one.
diff --git a/tcl/board/openrd.cfg b/tcl/board/openrd.cfg
index 4bc708d..12cc79e 100644
--- a/tcl/board/openrd.cfg
+++ b/tcl/board/openrd.cfg
@@ -29,7 +29,7 @@ proc openrd_init { } {
jtag_reset 0 0
wait_halt
- mcr 0 0 1 0 0x00052078
+ mcr 15 0 0 1 0 0x00052078
mww 0xD0001400 0x43000C30 # DDR SDRAM Configuration Register
mww 0xD0001404 0x37543000 # Dunit Control Low Register
diff --git a/tcl/board/sheevaplug.cfg b/tcl/board/sheevaplug.cfg
index 8e8396d..9267eb9 100644
--- a/tcl/board/sheevaplug.cfg
+++ b/tcl/board/sheevaplug.cfg
@@ -29,7 +29,7 @@ proc sheevaplug_init { } {
jtag_reset 0 0
wait_halt
- mcr 0 0 1 0 0x00052078
+ mcr 15 0 0 1 0 0x00052078
mww 0xD0001400 0x43000C30 # DDR SDRAM Configuration Register
mww 0xD0001404 0x39543000 # Dunit Control Low Register
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] AT91SAM9 NAND Driver
Hi all, I've finished up the implementation and documentation for an AT91SAM9 NAND driver for OpenOCD. In total there are about 34 patches that includes some refactor work for both the NAND controller layer and the ARM NAND I/O pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. I'm not sure what the best approach is for working this into the tree cause this is the biggest change I've attempted to contribute. I can only verify that this works for my Olimex SAM9-L9260 board. Any suggestions, testing, or improvements are very welcome. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
Wow. That's one big patch series. Great work! :-)
Did you run git rebase -i ? There seems to be some funny things going on
in that the at91sam9_nand.c is added in a *later* commit than the Makefile.am
is added.
This means that some of these commits won't compile...
If you haven't used git rebase -i yet, you are in for a treat. You'll
*love* it once
you get the hang of it. It allows you to carefully edit the commit
history in your
branch so it's pretty perfect. You can reorder, join split commits. You can
also edit the commit comments.
Check out the format of the commit comments by David Zach and you'll
get the drift.
Can you say something about the danger of regression? It's kinda hard to
tell without diving into details... This will be *much* easier to evaluate once
you're done w/git rebase -i.
I know there will be the compulsory comments about C style
deviating a bit. I prefer the latter style below, but even if
formatting is something
that we, Zach especially, have been trying to tighten up, I hope it
won't derail a careful examination of your new feature and refactoring work.
if (CMD_ARGC == 4) {
OpenOCD style =Z
if (CMD_ARGC == 4)
{
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
On Monday 23 November 2009, Dean Glazeski wrote: pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. That's an intriguing and useful first: substantial patches that could eventually be pulled from a new developers's GIT branch! :) That'll need review and surely cleanup. Øyvind commented about the patch sequence -- make sure it builds at each step along the way -- which is important (so git bisect continues to work). (I'm not keen on that particular style he mentions, FWIW...) For review ... the best solution is to post patches to the list. (Inline, not attachments, unless your mailer is Microsoftian in its eagerness to mangle text.) With that many, small chunks will be better. You sent a couple already -- accelerating reads, and refactoring command sequences. The latter is on my queue of stuff to test after my current ARM11 stuff is out for feedback (*); have you replaced that patch? At any rate, please continue to be gentle on our review/merge time by grouping your patches in bite-size morsels. Maybe the best thing to do would be to reorder your patches with all the core updates/refactoring first, then just submit one ready-to-roll SAM9 nand driver depending on them. - Dave (*) Someone with an AT91SAM11 could probably combine your NAND stuff with this, and be glad to have it all working together. I suspect the SAM11 isn't more slidware than silicon though. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
Hey, Alright, I went through and reordered the patches and split a few of them up. The result has been pushed to http://repo.or.cz/w/dnglaze.git. There are now two additional branches: master = synced manually with origin/master armnandio = master + arm nand i/o patches nand-refactor = master + nand patches at91sam9-nand = working driver dependent on all patches Take a quick look and let me know if there is something further I should do. Barring that, I'll post the core changes as a patch set to the list (patches from nand-refactor and armnandio) and I'll combine all the patches for at91sam9-nand as a single patch and submit that. Does this sound like a good plan? Once all of that is done, I'll submit some patches to fix formatting if there are any issues. Thanks. // Dean Glazeski On Mon, Nov 23, 2009 at 1:53 PM, David Brownell davi...@pacbell.net wrote: On Monday 23 November 2009, Dean Glazeski wrote: pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.gitunder the at91sam9-nand head. That's an intriguing and useful first: substantial patches that could eventually be pulled from a new developers's GIT branch! :) That'll need review and surely cleanup. Řyvind commented about the patch sequence -- make sure it builds at each step along the way -- which is important (so git bisect continues to work). (I'm not keen on that particular style he mentions, FWIW...) For review ... the best solution is to post patches to the list. (Inline, not attachments, unless your mailer is Microsoftian in its eagerness to mangle text.) With that many, small chunks will be better. You sent a couple already -- accelerating reads, and refactoring command sequences. The latter is on my queue of stuff to test after my current ARM11 stuff is out for feedback (*); have you replaced that patch? At any rate, please continue to be gentle on our review/merge time by grouping your patches in bite-size morsels. Maybe the best thing to do would be to reorder your patches with all the core updates/refactoring first, then just submit one ready-to-roll SAM9 nand driver depending on them. - Dave (*) Someone with an AT91SAM11 could probably combine your NAND stuff with this, and be glad to have it all working together. I suspect the SAM11 isn't more slidware than silicon though. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
I took a super quick peek: 1. What's the order in which the branches should be applied? 2. The new .c file and modification of the Makefile.am belongs in the same commit. Any reason why you split those into two commits? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? Yes. Other programmers will copy and paste your code. We've got the code clean of dynamic arrays on the stack and we should keep it that way. Since C99 has been accepted as the project's language standard, I think it is reasonable to expect that valid language constructs that are still *not* acceptable by the project be clearly stated in the Style Guide. Likewise if being optimized for embedded hosts is a priority for the project as a whole. Rejecting even trivial patches on the grounds of previously unspoken goals does not encourage developers to contribute. With that said, I'll happily resign in this case. Actually, my first draft was using asprintf() but I rejected it for not being standard. Seeing there's an equivalent already in the code, I'll update the patch using that. However, alloc_vprintf() seems to have a rather cumbersome implementation. Is there a reason why it is looping, trying with increasingly larger allocations? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
Thanks for following up on this. The style guide needs updating w.r.t. embedded considerations(I was going to work on the style guide the other day, but docs didn't build at the time and then I forgot about it...) However, alloc_vprintf() seems to have a rather cumbersome implementation. Is there a reason why it is looping, trying with increasingly larger allocations? It was optimized for maximum exercise of code paths at the time rather than performance. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
nand-refactor and armnandio can be applied in any order, but at91sam9-nand must be after them I went ahead and fixed some of the tree problems that I noticed with gitk to remove some redundant patches to make the dependencies a bit clearer. I didn't mention this with the previous email, but I did update the patches so that everything compiles after each patch. I've squashed the patch that imports the initial driver and the Makefile.am change. There wasn't any reason other than I was trying to keep patches small and often. That would have happened in the grandiose patch for the SAM9 driver later anyways :). // Dean Glazeski On Mon, Nov 23, 2009 at 2:58 PM, Øyvind Harboe oyvind.har...@zylin.comwrote: I took a super quick peek: 1. What's the order in which the branches should be applied? 2. The new .c file and modification of the Makefile.am belongs in the same commit. Any reason why you split those into two commits? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote: Hi all, I've finished up the implementation and documentation for an AT91SAM9 NAND driver for OpenOCD. In total there are about 34 patches that includes some refactor work for both the NAND controller layer and the ARM NAND I/O pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. I'm not sure what the best approach is for working this into the tree cause this is the biggest change I've attempted to contribute. I can only verify that this works for my Olimex SAM9-L9260 board. Any suggestions, testing, or improvements are very welcome. My first question is: would you mind moving your repository to be a fork of openocd.git? You need to contact pasky (the maintainer), but he will put it in the right place for you. There are several good reasons for him to do this, including saving mirroring bandwidth and disk space on the server. For us, it puts you in the list with the other forks, so others can see when you have pushed new work more easily. Anyway, I just pulled your branches and verified each patch builds okay. That's a step in the right direction. I'll look more closely at them when I am done with my command registration series, which I am getting nearly ready to post. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Mon, 2009-11-23 at 22:22 +0100, Andreas Fritiofson wrote: On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? Yes. Other programmers will copy and paste your code. We've got the code clean of dynamic arrays on the stack and we should keep it that way. Since C99 has been accepted as the project's language standard, I think it is reasonable to expect that valid language constructs that are still *not* acceptable by the project be clearly stated in the Style Guide. Likewise if being optimized for embedded hosts is a priority for the project as a whole. Rejecting even trivial patches on the grounds of previously unspoken goals does not encourage developers to contribute. If it makes you feel better, I think we have started using variable length arrays elsewhere in the code, but this is one place where I think it does make sense to keep things off the stack. With that said, I'll happily resign in this case. Actually, my first draft was using asprintf() but I rejected it for not being standard. Seeing there's an equivalent already in the code, I'll update the patch using that. It would probably be best to use asprintf when it is available, but we probably need to provide our own implementation... which would be known as alloc_vprintf in current terms. Icky name. However, alloc_vprintf() seems to have a rather cumbersome implementation. Is there a reason why it is looping, trying with increasingly larger allocations? I was reviewing this code today, and it's due for a serious overhaul. IIRC, there should be at most 2 passes through that loop, but that would be a cheap and fast fix. Feel free to submit patches to clean this up, as you'll be saving me time doing it! :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd
On Mon, Nov 23, 2009 at 10:57 PM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-23 at 22:22 +0100, Andreas Fritiofson wrote: On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? Yes. Other programmers will copy and paste your code. We've got the code clean of dynamic arrays on the stack and we should keep it that way. Since C99 has been accepted as the project's language standard, I think it is reasonable to expect that valid language constructs that are still *not* acceptable by the project be clearly stated in the Style Guide. Likewise if being optimized for embedded hosts is a priority for the project as a whole. Rejecting even trivial patches on the grounds of previously unspoken goals does not encourage developers to contribute. If it makes you feel better, I think we have started using variable length arrays elsewhere in the code, but this is one place where I think it does make sense to keep things off the stack. There are no sites where we use variable length arrays in OpenOCD anymore according to stackcheck.pl. I don't see a good reason to start now. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
The FPGA isn't that difficult. I've created a similar setup using OpenOCD. The biggest problem I had was that OpenOCD is spending most of its time creating JTAG bit streams. Its not the bit-banging that takes most of the time! On a 333MHz platform it took about 15 minutes to program 180kB into flash (with an FPGA for the JTAG interface!). To get more speed I created pre-defined JTAG commands for memory write and memory read and fill in the blanks (address and data) when necessary (very target specific ofcourse!). This reduced the programming time to a few seconds. I guess the effect will be less on a PC, but I think it might be worth to do some profiling. This could be made into a generic solution if OpenOCD would support a caching mechanism that allows patching existing JTAG bit streams. If you have a low latency system embedded system, then you will get the best performance by implementing a minidriver. You can then e.g. implement a hardware FIFO for JTAG commands(zy1000 does this). With a hardware fifo all jtag_add_xxx() calls are then synchronous which saves *lots* of copying, etc. ZY1000 gets 400kBytes/s speeds w/an arm7 CPU running eCos. There's some documentation on minidrivers in openocd, but if you are doing this for commercial reasons, then perhaps you would like to contact Zylin to get a finished(or customizable by you/us) solution? ;-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
I went ahead and moved everything over as a fork on my own. I'll leave the other around until this stuff gets hammered out and I'll remove it at that point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git. I've rebased everything to the new origin/master. Is there a good way to rebase two branches that merge to create another branch? With my current layout, if I rebase each branch individually, the merge disappears. // Dean Glazeski On Mon, Nov 23, 2009 at 3:47 PM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote: Hi all, I've finished up the implementation and documentation for an AT91SAM9 NAND driver for OpenOCD. In total there are about 34 patches that includes some refactor work for both the NAND controller layer and the ARM NAND I/O pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. I'm not sure what the best approach is for working this into the tree cause this is the biggest change I've attempted to contribute. I can only verify that this works for my Olimex SAM9-L9260 board. Any suggestions, testing, or improvements are very welcome. My first question is: would you mind moving your repository to be a fork of openocd.git? You need to contact pasky (the maintainer), but he will put it in the right place for you. There are several good reasons for him to do this, including saving mirroring bandwidth and disk space on the server. For us, it puts you in the list with the other forks, so others can see when you have pushed new work more easily. Anyway, I just pulled your branches and verified each patch builds okay. That's a step in the right direction. I'll look more closely at them when I am done with my command registration series, which I am getting nearly ready to post. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
There's some documentation on minidrivers in openocd, but if you are doing this for commercial reasons, then perhaps you would like to contact Zylin to get a finished(or customizable by you/us) solution? ;-) What about us poor graduate students who make less than unemployed people? I can't afford big name JTAG dongles! :) I would be very interested in trying to work on a project like this in the time I have available. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 0/7] ARM11 register handling
I'm posting this as an preview of some work that's not yet complete, in case someone has insightful comments they want to share... It's actually two things: - ARM Debug Programmer's Model (DPM) for ARMv6/ARMv7 cores (but not the M profiles, Cortex-M cores). Basically the debug interface is now architectural, so a certain level of code shareability is guaranteed. I think this stuff might as well merge ASAP, unless there's some issue with the concept. It can't break anything until it gets used, after all! * DPM interface, and support for register access. We can eventually share breakpoint and watchpoint code too. * ARM11 support. This is an extremely thin layer over the current Debug TAP interface. Cortex-A8 support will be easy too. (But needs at least one minor tweak to the interface.) - Make ARM11 use that stuff ... so it can work better (with support for different core modes and states), reuse lots of standard code, and support more standard interfaces. This is a significant overhaul, so I don't plan to put most of it back until I resolve one issue (see below). There's no overall solution for partial/incremental merge either, since intermediate steps necessarily leave some key loose ends. Or so it looks to me... * Add a _second_ register cache to ARM11, covering all standard registers. Gives access to e.g. FIQ shadows. (Loose end: the previous stuff is still used along various code paths!) arm reg works, etc. * Use standard single step code, not custom ARM11 glue. Just simplification; removes one code path that still used the old register set, and one expects Thumb will now behave. * Use standard V4/V5 run_algorithm(), not a trimmed-down subset. ISSUE: doesn't quite work, not sure why yet. (flash erase_check misbehaved, but at least one of the bugs seems to lie outside the ARM11 code.) * Remove history mechanism. It's only for debug help, and if it's desirable it should be done for *ALL* cores. (This could actually be removed before any of these patches merge.) * Remove most of that original register cache, and switch to the DPM primitives for the tasks it handled. Only a few debug registers are left (for now). So I expect to merge the two add DPM patches and the remove histor mechanism patch by tomorrow, unless somone has a good counter-argument, and continue to chase down the breakage I see in the flash erase_check code. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 1/7] ARM: new DPM interface
First version of interface for sharing code between ARMv6 and ARMv7a
debug modules ... now the architecture includes debug support. (Not
the same as for the trimmed-down v7m or v6m though!) This is a first
version of an interface that will let the ARM11 and Cortex-A8 support
share code, features, and bugfixes. Based on existing code from both
of those cores.
The ARM v7-AR architecture specification calls this commonality the
Debug Programmer's Model (DPM), which seemed to be an appropriate
acronym -- a TLA even! -- for use in our code. Made it so. :)
The initial scope of this just supports register access, and is geared
towards supporting top level struct arm mechanisms. Later, things
like breakpoint and watchpoint support should be included.
---
src/target/Makefile.am |2
src/target/arm_dpm.c | 531 +++
src/target/arm_dpm.h | 87 +++
src/target/armv4_5.c |1
src/target/armv4_5.h |6
5 files changed, 627 insertions(+)
--- a/src/target/Makefile.am
+++ b/src/target/Makefile.am
@@ -75,6 +75,7 @@ ARMV7_SRC = \
cortex_a8.c
ARM_DEBUG_SRC = \
+ arm_dpm.c \
arm_jtag.c \
arm_disassembler.c \
arm_simulator.c \
@@ -96,6 +97,7 @@ MIPS32_SRC = \
noinst_HEADERS = \
algorithm.h \
+ arm_dpm.h \
arm_jtag.h \
arm_adi_v5.h \
arm_disassembler.h \
--- /dev/null
+++ b/src/target/arm_dpm.c
@@ -0,0 +1,531 @@
+/*
+ * Copyright (C) 2009 by David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the
+ * Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include armv4_5.h /* REVISIT to become arm.h */
+#include arm_dpm.h
+#include jtag.h
+#include register.h
+
+
+/**
+ * @file
+ * Implements various ARM DPM operations using architectural debug registers.
+ * These routines layer over core-specific communication methods to cope with
+ * implementation differences between cores like ARM1136 and Cortex-A8.
+ */
+
+/* Toggles between recorded core mode (USR, SVC, etc) and a temporary one.
+ * Routines *must* restore the original mode before returning!!
+ */
+static int dpm_modeswitch(struct arm_dpm *dpm, enum armv4_5_mode mode)
+{
+ int retval;
+ uint32_t cpsr;
+
+ /* restore previous mode */
+ if (mode == ARMV4_5_MODE_ANY)
+ cpsr = buf_get_u32(dpm-arm-cpsr-value, 0, 32);
+
+ /* else force to the specified mode */
+ else
+ cpsr = mode;
+
+ retval = dpm-instr_write_data_r0(dpm, ARMV4_5_MSR_GP(0, 0xf, 0), cpsr);
+
+ /* REVISIT on Cortex-A8, we need a Prefetch Flush operation too ...
+ cortex_a8_exec_opcode(target,
+ ARMV4_5_MCR(15, 0, 0, 7, 5, 4));
+*/
+
+ return retval;
+}
+
+/* just read the register -- rely on the core mode being right */
+static int dpm_read_reg(struct arm_dpm *dpm, struct reg *r, unsigned regnum)
+{
+ uint32_t value;
+ int retval;
+
+ switch (regnum) {
+ case 0 ... 14:
+ /* return via DCC: MCR p14, 0, Rnum, c0, c5, 0 */
+ retval = dpm-instr_read_data_dcc(dpm,
+ ARMV4_5_MCR(14, 0, regnum, 0, 5, 0),
+ value);
+ break;
+ case 15:/* PC */
+ /* MOV r0, pc; then return via DCC */
+ retval = dpm-instr_read_data_r0(dpm, 0xe1af, value);
+
+ /* NOTE: this seems like a slightly awkward place to update
+* this value ... but if the PC gets written (the only way
+* to change what we compute), the arch spec says subsequent
+* reads return values which are unpredictable. So this
+* is always right except in those broken-by-intent cases.
+*/
+ switch (dpm-arm-core_state) {
+ case ARMV4_5_STATE_ARM:
+ value -= 8;
+ break;
+ case ARMV4_5_STATE_THUMB:
+ case ARM_STATE_THUMB_EE:
+ value -= 4;
+ break;
+ case ARMV4_5_STATE_JAZELLE:
+ /* core-specific ... ? */
+
[Openocd-development] [patch 3/7] ARM11: partial support for standard ARM register interfaces
This provides standard ARM register support -- with twenty or
more shadow registers on top of what this code now handles, but
properly associated with the various core modes -- parallel to
the current register code. That is, the current code is stilil
managing the current registers; the new code shadows them.
You can see all the registers with arm reg, modify the shadows
like r8_fiq or sp_abt with reg, and see them get properly
written back when you step. (Just don't do that with any of the
registers managed by the old code ...)
It also switches to using more standard code, relying on those
standard registers, in two places: (a) the poll status display,
which now shows core state (ARM/Thumb/...) and mode (Supervisor,
IRQ, etc); and (b) GDB register access.
So it's not a full migration, there are warts, but it's a small
more-or-less-comprehensible step that's even somewhat useful.
Later patches complete the migration.
---
src/target/arm11.c | 66 +++
1 file changed, 31 insertions(+), 35 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -144,9 +144,6 @@ enum arm11_regcache_ids
ARM11_RC_MAX,
};
-/* GDB expects ARMs to give R0..R15, CPSR, and 7 FPA dummies */
-#define ARM11_GDB_REGISTER_COUNT 26
-
static int arm11_on_enter_debug_state(struct arm11_common *arm11);
static int arm11_step(struct target *target, int current,
uint32_t address, int handle_breakpoints);
@@ -226,6 +223,9 @@ static int arm11_on_enter_debug_state(st
{
int retval;
+ /* REVISIT entire cache should already be invalid !!! */
+ register_cache_invalidate(arm11-arm.core_cache);
+
for (size_t i = 0; i ARRAY_SIZE(arm11-reg_values); i++)
{
arm11-reg_list[i].valid= 1;
@@ -300,6 +300,10 @@ static int arm11_on_enter_debug_state(st
}
#endif
+ retval = arm_dpm_read_current_registers(arm11-dpm);
+ if (retval != ERROR_OK)
+ LOG_ERROR(DPM REG READ -- fail %d, retval);
+
retval = arm11_run_instr_data_prepare(arm11);
if (retval != ERROR_OK)
return retval;
@@ -469,6 +473,9 @@ static int arm11_leave_debug_state(struc
}
}
+/* DEBUG for now, trust new code only for shadowed registers */
+retval = arm_dpm_write_dirty_registers(arm11-dpm);
+
retval = arm11_run_instr_data_prepare(arm11);
if (retval != ERROR_OK)
return retval;
@@ -508,6 +515,11 @@ static int arm11_leave_debug_state(struc
if (retval != ERROR_OK)
return retval;
+/* DEBUG use this when new code is really managing core registers */
+// retval = arm_dpm_write_dirty_registers(arm11-dpm);
+
+ register_cache_invalidate(arm11-arm.core_cache);
+
/* restore DSCR */
arm11_write_DSCR(arm11, R(DSCR));
@@ -595,14 +607,13 @@ static int arm11_poll(struct target *tar
/* architecture specific status reply */
static int arm11_arch_state(struct target *target)
{
- struct arm11_common *arm11 = target_to_arm11(target);
+ int retval;
- LOG_USER(target halted due to %s\ncpsr: 0x%8.8 PRIx32 pc: 0x%8.8
PRIx32 ,
-Jim_Nvp_value2name_simple(nvp_target_debug_reason,
target-debug_reason)-name,
-R(CPSR),
-R(PC));
+ retval = armv4_5_arch_state(target);
- return ERROR_OK;
+ /* REVISIT also display ARM11-specific MMU and cache status ... */
+
+ return retval;
}
/* target request support */
@@ -1117,31 +1128,6 @@ static int arm11_soft_reset_halt(struct
return ERROR_FAIL;
}
-/* target register access for gdb */
-static int arm11_get_gdb_reg_list(struct target *target,
- struct reg **reg_list[], int *reg_list_size)
-{
- struct arm11_common *arm11 = target_to_arm11(target);
-
- *reg_list_size = ARM11_GDB_REGISTER_COUNT;
- *reg_list = malloc(sizeof(struct reg*) *
ARM11_GDB_REGISTER_COUNT);
-
- /* nine unused legacy FPA registers are expected by GDB */
- for (size_t i = 16; i 24; i++)
- (*reg_list)[i] = arm_gdb_dummy_fp_reg;
- (*reg_list)[24] = arm_gdb_dummy_fps_reg;
-
- for (size_t i = 0; i ARM11_REGCACHE_COUNT; i++)
- {
- if (arm11_reg_defs[i].gdb_num == -1)
- continue;
-
- (*reg_list)[arm11_reg_defs[i].gdb_num] = arm11-reg_list + i;
- }
-
- return ERROR_OK;
-}
-
/* target memory access
* size: 1 = byte (8bit), 2 = half-word (16bit), 4 = word (32bit)
* count: number of items of size
@@ -1683,6 +1669,8 @@ static int arm11_examine(struct target *
uint32_t didr, device_id;
uint8_t implementor;
+ /* FIXME split into do-first-time and do-every-time logic ... */
+
/* check IDCODE */
arm11_add_IR(arm11, ARM11_IDCODE, ARM11_TAP_DEFAULT);
@@ -1755,6 +1743,14 @@
[Openocd-development] [patch 4/7] ARM11: use standard single step simulation
The previous stuff was needed because the ARM11 code wasn't using
the standard ARM base type and register access ... but now those
mechanisms work, so we can switch out that special-purpose glue.
This should resolve all the FIXME -- handle Thumb single stepping
comments too, and properly handle the processor's mode.
Clarify the comments about the the hardware single stepping. When
we eventually share breakpoint code with Cortex-A8, we can just make
that be the default on cores which support it. We may still want an
override command, not just to facilitate testing but to cope with
instruction address mismatch not quite being true single-step.
---
TODO |3 -
src/target/arm11.c | 125 +++
2 files changed, 29 insertions(+), 99 deletions(-)
--- a/TODO
+++ b/TODO
@@ -167,8 +167,7 @@ https://lists.berlios.de/pipermail/openo
mdw 0xb80005f0 0x8, mdh 0xb80005f0 0x10, mdb 0xb80005f0 0x20. mdb returns
garabage.
- implement missing functionality (grep FNC_INFO_NOTIMPLEMENTED ...)
- - thumb support is missing: ISTR ARMv6 requires Thumb.
- ARM1156 has Thumb2; ARM1136 doesn't.
+- Thumb2 single stepping: ARM1156T2 needs simulator support
- Cortex A8 support (ML)
- add target implementation (ML)
- Generic ARM run_algorithm() interface
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -811,96 +811,6 @@ static int arm11_resume(struct target *t
return ERROR_OK;
}
-
-static int armv4_5_to_arm11(int reg)
-{
- if (reg 16)
- return reg;
- switch (reg)
- {
- case ARMV4_5_CPSR:
- return ARM11_RC_CPSR;
- case 16:
- /* FIX!!! handle thumb better! */
- return ARM11_RC_CPSR;
- default:
- LOG_ERROR(BUG: register translation from armv4_5 to arm11 not
supported %d, reg);
- exit(-1);
- }
-}
-
-
-static uint32_t arm11_sim_get_reg(struct arm_sim_interface *sim, int reg)
-{
- struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- reg=armv4_5_to_arm11(reg);
-
- return buf_get_u32(arm11-reg_list[reg].value, 0, 32);
-}
-
-static void arm11_sim_set_reg(struct arm_sim_interface *sim,
- int reg, uint32_t value)
-{
- struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- reg=armv4_5_to_arm11(reg);
-
- buf_set_u32(arm11-reg_list[reg].value, 0, 32, value);
-}
-
-static uint32_t arm11_sim_get_cpsr(struct arm_sim_interface *sim,
- int pos, int bits)
-{
- struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- return buf_get_u32(arm11-reg_list[ARM11_RC_CPSR].value, pos, bits);
-}
-
-static enum armv4_5_state arm11_sim_get_state(struct arm_sim_interface *sim)
-{
-// struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- /* FIX we should implement thumb for arm11 */
- return ARMV4_5_STATE_ARM;
-}
-
-static void arm11_sim_set_state(struct arm_sim_interface *sim,
- enum armv4_5_state mode)
-{
-// struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- /* FIX we should implement thumb for arm11 */
- LOG_ERROR(Not implemented: %s, __func__);
-}
-
-
-static enum armv4_5_mode arm11_sim_get_mode(struct arm_sim_interface *sim)
-{
- //struct arm11_common * arm11 = (struct arm11_common *)sim-user_data;
-
- /* FIX we should implement something that returns the current mode
here!!! */
- return ARMV4_5_MODE_USR;
-}
-
-static int arm11_simulate_step(struct target *target, uint32_t *dry_run_pc)
-{
- struct arm_sim_interface sim;
-
- sim.user_data=target-arch_info;
- sim.get_reg=arm11_sim_get_reg;
- sim.set_reg=arm11_sim_set_reg;
- sim.get_reg_mode=arm11_sim_get_reg;
- sim.set_reg_mode=arm11_sim_set_reg;
- sim.get_cpsr=arm11_sim_get_cpsr;
- sim.get_mode=arm11_sim_get_mode;
- sim.get_state=arm11_sim_get_state;
- sim.set_state=arm11_sim_set_state;
-
- return arm_simulate_step_core(target, dry_run_pc, sim);
-
-}
-
static int arm11_step(struct target *target, int current,
uint32_t address, int handle_breakpoints)
{
@@ -969,24 +879,38 @@ static int arm11_step(struct target *tar
if (arm11_config_hardware_step)
{
- /* hardware single stepping be used if possible or is
it better to
-* always use the same code path? Hardware single
stepping is not supported
-* on all hardware
+ /* Hardware single stepping (instruction address
+* mismatch) is used if enabled. It's not quite
+* exactly run one instruction; branch to here
+* loops won't break, neither will some other cases,
+* but it's probably the best default.
+
[Openocd-development] [patch 5/7] ARM11: use standard run_algorithm()
As with single stepping, the previous stuff was needed because
the ARM11 code wasn't using the standard ARM base type and
register access ... but now those mechanisms work, so we can
switch out that special-purpose glue, in favor of the more
thoroughly tested/capable standard code.
This should resolve the FIXME comments too, for Thumb and
processor mode support. It also gets rid of a nasty exit()
call; servers shouldn't only have *clean* shutdown paths.
---
NOTE: this is partially broken, it seems to cause some
other bug(s) to fire. Not sure what's up with that, yet.
src/target/arm11.c | 172 ---
1 file changed, 1 insertion(+), 171 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -1372,176 +1372,6 @@ static int arm11_remove_watchpoint(struc
return ERROR_FAIL;
}
-// HACKHACKHACK - FIXME mode/state
-/* target algorithm support */
-static int arm11_run_algorithm(struct target *target,
- int num_mem_params, struct mem_param *mem_params,
- int num_reg_params, struct reg_param *reg_params,
- uint32_t entry_point, uint32_t exit_point,
- int timeout_ms, void *arch_info)
-{
- struct arm11_common *arm11 = target_to_arm11(target);
-// enum armv4_5_state core_state = arm11-core_state;
-// enum armv4_5_mode core_mode = arm11-core_mode;
- uint32_t context[16];
- uint32_t cpsr;
- int exit_breakpoint_size = 0;
- int retval = ERROR_OK;
- LOG_DEBUG(Running algorithm);
-
-
- if (target-state != TARGET_HALTED)
- {
- LOG_WARNING(target not halted);
- return ERROR_TARGET_NOT_HALTED;
- }
-
- // FIXME
-// if (!is_arm_mode(arm11-core_mode))
-// return ERROR_FAIL;
-
- // Save regs
- for (unsigned i = 0; i 16; i++)
- {
- context[i] =
buf_get_u32((uint8_t*)(arm11-reg_values[i]),0,32);
- LOG_DEBUG(Save %u: 0x% PRIx32 , i, context[i]);
- }
-
- cpsr = buf_get_u32((uint8_t*)(arm11-reg_values + ARM11_RC_CPSR),0,32);
- LOG_DEBUG(Save CPSR: 0x% PRIx32 , cpsr);
-
- for (int i = 0; i num_mem_params; i++)
- {
- target_write_buffer(target, mem_params[i].address,
mem_params[i].size, mem_params[i].value);
- }
-
- // Set register parameters
- for (int i = 0; i num_reg_params; i++)
- {
- struct reg *reg = register_get_by_name(arm11-core_cache,
reg_params[i].reg_name, 0);
- if (!reg)
- {
- LOG_ERROR(BUG: register '%s' not found,
reg_params[i].reg_name);
- return ERROR_INVALID_ARGUMENTS;
- }
-
- if (reg-size != reg_params[i].size)
- {
- LOG_ERROR(BUG: register '%s' size doesn't match
reg_params[i].size, reg_params[i].reg_name);
- return ERROR_INVALID_ARGUMENTS;
- }
- arm11_set_reg(reg,reg_params[i].value);
-// printf(%i: Set %s =%08x\n, i, reg_params[i].reg_name,val);
- }
-
- exit_breakpoint_size = 4;
-
-/* arm11-core_state = arm11_algorithm_info-core_state;
- if (arm11-core_state == ARMV4_5_STATE_ARM)
- exit_breakpoint_size = 4;
- else if (arm11-core_state == ARMV4_5_STATE_THUMB)
- exit_breakpoint_size = 2;
- else
- {
- LOG_ERROR(BUG: can't execute algorithms when not in ARM or
Thumb state);
- exit(-1);
- }
-*/
-
-
-/* arm11 at this point only supports ARM not THUMB mode
- however if this test needs to be reactivated the current state can be read
back
- from CPSR */
-#if 0
- if (arm11_algorithm_info-core_mode != ARMV4_5_MODE_ANY)
- {
- LOG_DEBUG(setting core_mode: 0x%2.2x,
arm11_algorithm_info-core_mode);
- buf_set_u32(arm11-reg_list[ARM11_RC_CPSR].value, 0, 5,
arm11_algorithm_info-core_mode);
- arm11-reg_list[ARM11_RC_CPSR].dirty = 1;
- arm11-reg_list[ARM11_RC_CPSR].valid = 1;
- }
-#endif
-
- if ((retval = breakpoint_add(target, exit_point, exit_breakpoint_size,
BKPT_HARD)) != ERROR_OK)
- {
- LOG_ERROR(can't add breakpoint to finish algorithm execution);
- retval = ERROR_TARGET_FAILURE;
- goto restore;
- }
-
- // no debug, otherwise breakpoint is not set
- CHECK_RETVAL(target_resume(target, 0, entry_point, 1, 0));
-
- CHECK_RETVAL(target_wait_state(target, TARGET_HALTED, timeout_ms));
-
- if (target-state != TARGET_HALTED)
- {
- CHECK_RETVAL(target_halt(target));
-
- CHECK_RETVAL(target_wait_state(target, TARGET_HALTED, 500));
-
- retval = ERROR_TARGET_TIMEOUT;
-
- goto del_breakpoint;
- }
-
- if
[Openocd-development] [patch 2/7] ARM11: implement provider for new DPM interface
This is a very thin layer over some of the current ARM11
debug TAP utilities. The layer isn't yet hooked up.
---
src/target/arm11.h|4 ++
src/target/arm11_dbgtap.c | 73
src/target/arm11_dbgtap.h |3 +
3 files changed, 80 insertions(+)
--- a/src/target/arm11.h
+++ b/src/target/arm11.h
@@ -24,6 +24,7 @@
#define ARM11_H
#include armv4_5.h
+#include arm_dpm.h
/* TEMPORARY -- till we switch to the shared infrastructure */
#define ARM11_REGCACHE_COUNT 20
@@ -59,6 +60,9 @@ struct arm11_common
struct arm arm;
struct target * target; /** Reference back to the owner */
+ /** Debug module state. */
+ struct arm_dpm dpm;
+
/** \name Processor type detection */
/*...@{*/
--- a/src/target/arm11_dbgtap.c
+++ b/src/target/arm11_dbgtap.c
@@ -951,3 +951,76 @@ int arm11_read_memory_word(struct arm11_
return arm11_run_instr_data_finish(arm11);
}
+
+//
+
+/*
+ * ARM11 provider for the OpenOCD implementation of the standard
+ * architectural ARM v6/v7 Debug Programmer's Model (DPM).
+ */
+
+static inline struct arm11_common *dpm_to_arm11(struct arm_dpm *dpm)
+{
+ return container_of(dpm, struct arm11_common, dpm);
+}
+
+static int arm11_dpm_prepare(struct arm_dpm *dpm)
+{
+ struct arm11_common *arm11 = dpm_to_arm11(dpm);
+
+ arm11 = container_of(dpm-arm, struct arm11_common, arm);
+
+ return arm11_run_instr_data_prepare(dpm_to_arm11(dpm));
+}
+
+static int arm11_dpm_finish(struct arm_dpm *dpm)
+{
+ return arm11_run_instr_data_finish(dpm_to_arm11(dpm));
+}
+
+static int arm11_dpm_instr_write_data_dcc(struct arm_dpm *dpm,
+ uint32_t opcode, uint32_t data)
+{
+ return arm11_run_instr_data_to_core(dpm_to_arm11(dpm),
+ opcode, data, 1);
+}
+
+static int arm11_dpm_instr_write_data_r0(struct arm_dpm *dpm,
+ uint32_t opcode, uint32_t data)
+{
+ return arm11_run_instr_data_to_core_via_r0(dpm_to_arm11(dpm),
+ opcode, data);
+}
+
+static int arm11_dpm_instr_read_data_dcc(struct arm_dpm *dpm,
+ uint32_t opcode, uint32_t *data)
+{
+ return arm11_run_instr_data_from_core(dpm_to_arm11(dpm),
+ opcode, data, 1);
+}
+
+static int arm11_dpm_instr_read_data_r0(struct arm_dpm *dpm,
+ uint32_t opcode, uint32_t *data)
+{
+ return arm11_run_instr_data_from_core_via_r0(dpm_to_arm11(dpm),
+ opcode, data);
+}
+
+
+void arm11_dpm_init(struct arm11_common *arm11, uint32_t didr)
+{
+ struct arm_dpm *dpm = arm11-dpm;
+
+ dpm-arm = arm11-arm;
+
+ dpm-didr = didr;
+
+ dpm-prepare = arm11_dpm_prepare;
+ dpm-finish = arm11_dpm_finish;
+
+ dpm-instr_write_data_dcc = arm11_dpm_instr_write_data_dcc;
+ dpm-instr_write_data_r0 = arm11_dpm_instr_write_data_r0;
+
+ dpm-instr_read_data_dcc = arm11_dpm_instr_read_data_dcc;
+ dpm-instr_read_data_r0 = arm11_dpm_instr_read_data_r0;
+}
--- a/src/target/arm11_dbgtap.h
+++ b/src/target/arm11_dbgtap.h
@@ -60,4 +60,7 @@ void arm11_sc7_set_vcr(struct arm11_comm
int arm11_read_memory_word(struct arm11_common *arm11,
uint32_t address, uint32_t *result);
+/* Set up high-level debug module utilities */
+void arm11_dpm_init(struct arm11_common *arm11, uint32_t didr);
+
#endif // ARM11_DBGTAP_H
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 7/7] ARM11: remove old R0..R15 code
This finishes the basic switchover to the new register code,
for everything except the debug registers. (And maybe we
shouldn't have a cache for *those* which works this way...)
The context save/restore code now uses the new code, but
it's in a slightly different sequence. That should be fine
since the R0/PC/CPSR stuff is all that really matters (and
if we can update those, we can update the rest).
---
src/target/arm11.c | 264 +--
src/target/arm11.h |5
2 files changed, 73 insertions(+), 196 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -48,26 +48,6 @@ static bool arm11_config_hardware_step =
enum arm11_regtype
{
- ARM11_REGISTER_CORE,
- ARM11_REGISTER_CPSR,
-
- ARM11_REGISTER_FX,
- ARM11_REGISTER_FPS,
-
- ARM11_REGISTER_FIQ,
- ARM11_REGISTER_SVC,
- ARM11_REGISTER_ABT,
- ARM11_REGISTER_IRQ,
- ARM11_REGISTER_UND,
- ARM11_REGISTER_MON,
-
- ARM11_REGISTER_SPSR_FIQ,
- ARM11_REGISTER_SPSR_SVC,
- ARM11_REGISTER_SPSR_ABT,
- ARM11_REGISTER_SPSR_IRQ,
- ARM11_REGISTER_SPSR_UND,
- ARM11_REGISTER_SPSR_MON,
-
/* debug regs */
ARM11_REGISTER_DSCR,
ARM11_REGISTER_WDTR,
@@ -86,25 +66,6 @@ struct arm11_reg_defs
/* update arm11_regcache_ids when changing this */
static const struct arm11_reg_defs arm11_reg_defs[] =
{
- {r0, 0, 0, ARM11_REGISTER_CORE},
- {r1, 1, 1, ARM11_REGISTER_CORE},
- {r2, 2, 2, ARM11_REGISTER_CORE},
- {r3, 3, 3, ARM11_REGISTER_CORE},
- {r4, 4, 4, ARM11_REGISTER_CORE},
- {r5, 5, 5, ARM11_REGISTER_CORE},
- {r6, 6, 6, ARM11_REGISTER_CORE},
- {r7, 7, 7, ARM11_REGISTER_CORE},
- {r8, 8, 8, ARM11_REGISTER_CORE},
- {r9, 9, 9, ARM11_REGISTER_CORE},
- {r10, 10, 10, ARM11_REGISTER_CORE},
- {r11, 11, 11, ARM11_REGISTER_CORE},
- {r12, 12, 12, ARM11_REGISTER_CORE},
- {sp, 13, 13, ARM11_REGISTER_CORE},
- {lr, 14, 14, ARM11_REGISTER_CORE},
- {pc, 15, 15, ARM11_REGISTER_CORE},
-
- {cpsr,0, 25, ARM11_REGISTER_CPSR},
-
/* Debug Registers */
{dscr,0, -1, ARM11_REGISTER_DSCR},
{wdtr,0, -1, ARM11_REGISTER_WDTR},
@@ -113,30 +74,6 @@ static const struct arm11_reg_defs arm11
enum arm11_regcache_ids
{
- ARM11_RC_R0,
- ARM11_RC_RX = ARM11_RC_R0,
-
- ARM11_RC_R1,
- ARM11_RC_R2,
- ARM11_RC_R3,
- ARM11_RC_R4,
- ARM11_RC_R5,
- ARM11_RC_R6,
- ARM11_RC_R7,
- ARM11_RC_R8,
- ARM11_RC_R9,
- ARM11_RC_R10,
- ARM11_RC_R11,
- ARM11_RC_R12,
- ARM11_RC_R13,
- ARM11_RC_SP = ARM11_RC_R13,
- ARM11_RC_R14,
- ARM11_RC_LR = ARM11_RC_R14,
- ARM11_RC_R15,
- ARM11_RC_PC = ARM11_RC_R15,
-
- ARM11_RC_CPSR,
-
ARM11_RC_DSCR,
ARM11_RC_WDTR,
ARM11_RC_RDTR,
@@ -229,6 +166,8 @@ static int arm11_on_enter_debug_state(st
arm11-reg_list[i].dirty= 0;
}
+ /* See e.g. ARM1136 TRM, 14.8.4 Entering Debug state */
+
/* Save DSCR */
CHECK_RETVAL(arm11_read_DSCR(arm11, R(DSCR)));
@@ -254,10 +193,12 @@ static int arm11_on_enter_debug_state(st
}
- /* DSCR: set ARM11_DSCR_EXECUTE_ARM_INSTRUCTION_ENABLE */
- /* ARM1176 spec says this is needed only for wDTR/rDTR's ITR mode,
but not to issue ITRs
- ARM1136 seems to require this to issue ITR's as well */
-
+ /* DSCR: set ARM11_DSCR_EXECUTE_ARM_INSTRUCTION_ENABLE
+*
+* ARM1176 spec says this is needed only for wDTR/rDTR's ITR mode,
+* but not to issue ITRs. ARM1136 seems to require this to issue
+* ITR's as well...
+*/
uint32_t new_dscr = R(DSCR) | ARM11_DSCR_EXECUTE_ARM_INSTRUCTION_ENABLE;
/* this executes JTAG queue: */
@@ -297,6 +238,11 @@ static int arm11_on_enter_debug_state(st
}
#endif
+ /* Save registers.
+*
+* NOTE: ARM1136 TRM suggests saving just R0 here now, then
+* CPSR and PC after the rDTR stuff. We do it all at once.
+*/
retval = arm_dpm_read_current_registers(arm11-dpm);
if (retval != ERROR_OK)
LOG_ERROR(DPM REG READ -- fail %d, retval);
@@ -305,19 +251,7 @@ static int arm11_on_enter_debug_state(st
if (retval != ERROR_OK)
return retval;
- /* save r0 - r14 */
-
- /** \todo TODO: handle other mode registers */
-
- for (size_t i = 0; i 15; i++)
- {
- /* MCR p14,0,R?,c0,c5,0 */
- retval = arm11_run_instr_data_from_core(arm11, 0xEE000E15 | (i
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
On Monday 23 November 2009, Dean Glazeski wrote: What about us poor graduate students who make less than unemployed people? I can't afford big name JTAG dongles! :) I would be very interested in trying to work on a project like this in the time I have available. That's part of why I suggested someone whip together a standard (reference?) platform, and sketched what it might look like. Something breadboardable, or which can be put together by simple hacks to a widely available board, would be a place to start. The first team to start working on that stuff probably gets a lot of say on how that sub-project moves forward... ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 6/7] ARM11: remove register history debug stuff
This was private mechanism to snapshot registers before leaving
debug state, and then optionally display what changed. It was
coupled to the private register cache, which won't be sticking
around in that form for much longer. Remove (instead of teaching
it how to handle *all* the registers).
(The idea is interesting, but we ought to be able to implement
this in a generic way. Ideally through Tcl scripts that can
automatically be invoked following debug entry...)
---
src/target/arm11.c | 50 --
src/target/arm11.h |9 -
2 files changed, 59 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -152,9 +152,6 @@ static int arm11_build_reg_cache(struct
static int arm11_set_reg(struct reg *reg, uint8_t *buf);
static int arm11_get_reg(struct reg *reg);
-static void arm11_record_register_history(struct arm11_common * arm11);
-static void arm11_dump_reg_changes(struct arm11_common * arm11);
-
/** Check and if necessary take control of the system
*
@@ -384,41 +381,9 @@ static int arm11_on_enter_debug_state(st
if (retval != ERROR_OK)
return retval;
- arm11_dump_reg_changes(arm11);
-
return ERROR_OK;
}
-static void arm11_dump_reg_changes(struct arm11_common * arm11)
-{
-
- if (!(debug_level = LOG_LVL_DEBUG))
- {
- return;
- }
-
- for (size_t i = 0; i ARM11_REGCACHE_COUNT; i++)
- {
- if (!arm11-reg_list[i].valid)
- {
- if (arm11-reg_history[i].valid)
- LOG_DEBUG(%8s INVALID (%08 PRIx32 ),
arm11_reg_defs[i].name, arm11-reg_history[i].value);
- }
- else
- {
- if (arm11-reg_history[i].valid)
- {
- if (arm11-reg_history[i].value !=
arm11-reg_values[i])
- LOG_DEBUG(%8s %08 PRIx32 (%08
PRIx32 ), arm11_reg_defs[i].name, arm11-reg_values[i],
arm11-reg_history[i].value);
- }
- else
- {
- LOG_DEBUG(%8s %08 PRIx32 (INVALID),
arm11_reg_defs[i].name, arm11-reg_values[i]);
- }
- }
- }
-}
-
/** Restore processor state
*
* This is called in preparation for the RESTART function.
@@ -544,24 +509,9 @@ retval = arm_dpm_write_dirty_registers(
arm11_add_dr_scan_vc(ARRAY_SIZE(chain5_fields), chain5_fields,
TAP_DRPAUSE);
}
- arm11_record_register_history(arm11);
-
return ERROR_OK;
}
-static void arm11_record_register_history(struct arm11_common *arm11)
-{
- for (size_t i = 0; i ARM11_REGCACHE_COUNT; i++)
- {
- arm11-reg_history[i].value = arm11-reg_values[i];
- arm11-reg_history[i].valid = arm11-reg_list[i].valid;
-
- arm11-reg_list[i].valid= 0;
- arm11-reg_list[i].dirty= 0;
- }
-}
-
-
/* poll current target status */
static int arm11_poll(struct target *target)
{
--- a/src/target/arm11.h
+++ b/src/target/arm11.h
@@ -41,12 +41,6 @@
} \
} while (0)
-struct arm11_register_history
-{
- uint32_tvalue;
- uint8_t valid;
-};
-
enum arm11_debug_version
{
ARM11_DEBUG_V6 = 0x01,
@@ -84,9 +78,6 @@ struct arm11_common
/*...@}*/
- struct arm11_register_history
- reg_history[ARM11_REGCACHE_COUNT]; /** register state
before last resume */
-
size_t free_brps; /** keep track of
breakpoints allocated by arm11_add_breakpoint() */
size_t free_wrps; /** keep track of
breakpoints allocated by arm11_add_watchpoint() */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
On Mon, Nov 23, 2009 at 11:45 PM, Dean Glazeski dngl...@gmail.com wrote: There's some documentation on minidrivers in openocd, but if you are doing this for commercial reasons, then perhaps you would like to contact Zylin to get a finished(or customizable by you/us) solution? ;-) What about us poor graduate students who make less than unemployed people? I can't afford big name JTAG dongles! :) I would be very interested in trying to work on a project like this in the time I have available. Big name JTAG dongles, I like that. Don't underestimate blatant flatter :-) If you have a project where you need Altera Nios + FPGA + JTAG interface for academic work, then get in touch with us and describe the project and we'll see what we can do. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/3] support for scripts in $HOME/.openocd
Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.
Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.
Add entry to NEWS as well.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
NEWS |1 +
doc/openocd.texi | 22 ++
src/helper/options.c | 15 ++-
3 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 1a024e4..0dcc4bc 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,7 @@ Flash Layer:
Board, Target, and Interface Configuration Scripts:
ARM9
- ETM and ETB hookup for iMX2* targets
+ Add $HOME/.openocd to the search path.
Documentation:
Build and Release:
diff --git a/doc/openocd.texi b/doc/openocd.texi
index cff7fc5..e94c9d0 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -483,14 +483,24 @@ bash$ openocd --help
--pipe | -p use pipes when talking to gdb
@end verbatim
-By default OpenOCD reads the file configuration file @file{openocd.cfg}
-in the current directory. To specify a different (or multiple)
-configuration file, you can use the ``-f'' option. For example:
+By default OpenOCD reads the configuration file @file{openocd.cfg}.
+To specify a different (or multiple)
+configuration file, you can use the @option{-f} option. For example:
@example
openocd -f config1.cfg -f config2.cfg -f config3.cfg
@end example
+Configuration files and scripts are searched for in
+...@enumerate
+...@item the current directory,
+...@item any search dir specified on the command line using the @option{-s}
option,
+...@item @file{$HOME/.openocd} (not on Windows),
+...@item the site wide script library @file{$pkgdatadir/site} and
+...@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}.
+...@end enumerate
+The first found file with a matching file name will be used.
+
OpenOCD starts by processing the configuration commands provided
on the command line or in @file{openocd.cfg}.
@xref{Configuration Stage}.
@@ -507,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands
issued through
those channels.
If you are having problems, you can enable internal debug messages via
-the ``-d'' option.
+the @option{-d} option.
Also it is possible to interleave JIM-Tcl commands w/config scripts using the
@option{-c} command line switch.
@@ -523,10 +533,6 @@ setting from within a telnet or gdb session using
@command{debug_level
You can redirect all output from the daemon to a file using the
@option{-l logfile} switch.
-Search paths for config/script files can be added to OpenOCD by using
-the @option{-s search} switch. The current directory and the OpenOCD
-target library is in the search path by default.
-
For details on the @option{-p} option. @xref{Connecting to GDB}.
Note! OpenOCD will launch the GDB telnet server even if it can not
diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..e036d61 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -101,7 +101,20 @@ static void add_default_dirs(void)
* listed last in the built-in search order, so the user can
* override these scripts with site-specific customizations.
*/
- /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+ const char *home = getenv(HOME);
+
+ if (home) {
+ char *path;
+
+ path = alloc_printf(%s/.openocd, home);
+
+ if (path) {
+ add_script_search_dir(path);
+ free(path);
+ }
+ }
+
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
#endif
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] improve alloc_vprintf
The previous implementation was unnecessarily complex. Get rid of the loops,
let vsnprintf() tell us directly how much storage we need and allocate that. A
second pass writes the actual string. Also add a va_end() that was missing.
This should be much faster for large strings and less wasteful for small ones.
A quirk that has been retained is that some callers patch in a newline at the
end of the returned string and depend on alloc_vprintf to allocate at least
one byte extra.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/helper/log.c | 43 ---
1 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/src/helper/log.c b/src/helper/log.c
index caaed42..6869d2e 100644
--- a/src/helper/log.c
+++ b/src/helper/log.c
@@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv)
/* return allocated string w/printf() result */
char *alloc_vprintf(const char *fmt, va_list ap)
{
- /* no buffer at the beginning, force realloc to do the job */
- char *string = NULL;
-
- /* start with buffer size suitable for typical messages */
- int size = 128;
-
- for (;;)
- {
- char *t = string;
- va_list ap_copy;
- int ret;
- string = realloc(string, size);
- if (string == NULL)
- {
- if (t != NULL)
- free(t);
- return NULL;
- }
+ va_list ap_copy;
+ int len;
+ char *string;
- va_copy(ap_copy, ap);
+ /* determine the length of the buffer needed */
+ va_copy(ap_copy, ap);
+ len = vsnprintf(NULL, 0, fmt, ap_copy);
+ va_end(ap_copy);
- ret = vsnprintf(string, size, fmt, ap_copy);
- /* NB! The result of the vsnprintf() might be an *EMPTY*
string! */
- if ((ret = 0) ((ret + 1) size))
- break;
+ /* allocate and make room for terminating zero. */
+ /* FIXME: The old version always allocated at least one byte extra and
+* other code depend on that. They should be probably be fixed, but for
+* now reserve the extra byte. */
+ string = malloc(len + 2);
+ if (string == NULL)
+ return NULL;
- /* there was just enough or not enough space, allocate more in
the next round */
- size *= 2; /* double the buffer size */
- }
+ /* do the real work */
+ vsnprintf(string, len + 1, fmt, ap_copy);
- /* the returned buffer is by principle guaranteed to be at least one
character longer */
return string;
}
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 0/7] ARM11 register handling
On Monday 23 November 2009, Øyvind Harboe wrote: Wow. :-) I hope that's not all you'll have to say. ;) Yeah, it just started growing... it's amazing how much custom code can be needed when you bypass shared infrastructure. I'm suspecting that one of the issues with that algorithm stuff is breakpoint related. More later. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] How to single step without interrupts?
Hi! When single stepping on a STM32, I'm constantly caught in interrupt handler code. This makes debugging almost impossible for non-trivial programs with timer and other peripheral interrupts. I have seen that there's an cortex_m3 maskisr on/off command, but it's awkward to use from eclipse. There seems to be no way to issue monitor commands to OpenOCD during a debug session, or even bind commands to a GUI button (perhaps a nice feature for Zylin-CDT?). Is there a good way to tell OpenOCD to mask ISRs after hitting a breakpoint/single-stepping, but re-enable interrupts on run? best regards, -- Thomas Kindler m...@t-kindler.de ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
If you have a series (or tree) of branches, I wrote a small script to rebase them automatically; however, it falls down when something fails, in so far as you have to finish things manually (for now). Basically, it does this process for N steps and for any number of branches in your local web of commits: git branch step1-tmp step1 git rebase master step1 git rebase --onto step1 step1-tmp step2 git branch -D step1-tmp Is that what you mean? If so, my script is in the 'buildscripts' branch of my fork on repo.or.cz, named rebase.pl. Here are a few ways I want to see it improved: - figure out the branch tree(s) automatically - avoid leaving temporary branches around - full continuation and abort support, a la 'git rebase' - etc. :) Patches welcome, but I do not plan on adding those scripts to mainline. That branch contains things that I wrote which may be useful to others, but I am not pushing to push any of it. --Z On Mon, 2009-11-23 at 16:34 -0600, Dean Glazeski wrote: I went ahead and moved everything over as a fork on my own. I'll leave the other around until this stuff gets hammered out and I'll remove it at that point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git. I've rebased everything to the new origin/master. Is there a good way to rebase two branches that merge to create another branch? With my current layout, if I rebase each branch individually, the merge disappears. // Dean Glazeski On Mon, Nov 23, 2009 at 3:47 PM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote: Hi all, I've finished up the implementation and documentation for an AT91SAM9 NAND driver for OpenOCD. In total there are about 34 patches that includes some refactor work for both the NAND controller layer and the ARM NAND I/O pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. I'm not sure what the best approach is for working this into the tree cause this is the biggest change I've attempted to contribute. I can only verify that this works for my Olimex SAM9-L9260 board. Any suggestions, testing, or improvements are very welcome. My first question is: would you mind moving your repository to be a fork of openocd.git? You need to contact pasky (the maintainer), but he will put it in the right place for you. There are several good reasons for him to do this, including saving mirroring bandwidth and disk space on the server. For us, it puts you in the list with the other forks, so others can see when you have pushed new work more easily. Anyway, I just pulled your branches and verified each patch builds okay. That's a step in the right direction. I'll look more closely at them when I am done with my command registration series, which I am getting nearly ready to post. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] improve alloc_vprintf
Looks great, but one minor comment below
On Tue, 2009-11-24 at 00:37 +0100, Andreas Fritiofson wrote:
The previous implementation was unnecessarily complex. Get rid of the loops,
let vsnprintf() tell us directly how much storage we need and allocate that. A
second pass writes the actual string. Also add a va_end() that was missing.
This should be much faster for large strings and less wasteful for small ones.
A quirk that has been retained is that some callers patch in a newline at the
end of the returned string and depend on alloc_vprintf to allocate at least
one byte extra.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/helper/log.c | 43 ---
1 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/src/helper/log.c b/src/helper/log.c
index caaed42..6869d2e 100644
--- a/src/helper/log.c
+++ b/src/helper/log.c
@@ -395,37 +395,26 @@ int log_remove_callback(log_callback_fn fn, void *priv)
/* return allocated string w/printf() result */
char *alloc_vprintf(const char *fmt, va_list ap)
{
- /* no buffer at the beginning, force realloc to do the job */
- char *string = NULL;
-
- /* start with buffer size suitable for typical messages */
- int size = 128;
-
- for (;;)
- {
- char *t = string;
- va_list ap_copy;
- int ret;
- string = realloc(string, size);
- if (string == NULL)
- {
- if (t != NULL)
- free(t);
- return NULL;
- }
+ va_list ap_copy;
+ int len;
+ char *string;
- va_copy(ap_copy, ap);
+ /* determine the length of the buffer needed */
+ va_copy(ap_copy, ap);
+ len = vsnprintf(NULL, 0, fmt, ap_copy);
+ va_end(ap_copy);
- ret = vsnprintf(string, size, fmt, ap_copy);
- /* NB! The result of the vsnprintf() might be an *EMPTY*
string! */
- if ((ret = 0) ((ret + 1) size))
- break;
+ /* allocate and make room for terminating zero. */
+ /* FIXME: The old version always allocated at least one byte extra and
+ * other code depend on that. They should be probably be fixed, but for
+ * now reserve the extra byte. */
+ string = malloc(len + 2);
+ if (string == NULL)
+ return NULL;
- /* there was just enough or not enough space, allocate more in
the next round */
- size *= 2; /* double the buffer size */
- }
+ /* do the real work */
+ vsnprintf(string, len + 1, fmt, ap_copy);
I think you meant for this to be ap, not ap_copy.
- /* the returned buffer is by principle guaranteed to be at least one
character longer */
return string;
}
Fix this minor detail, and I'll commit both of your patches.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips: remove dynamic arrays - reduces stack usage
Many thanks for your improvement. This patch works very well. BR, -- Jerry - Original Message - From: Øyvind Harboe oyvind.har...@zylin.com To: Jerry Ling jerry_l...@draytek.com Cc: openocd-development@lists.berlios.de Sent: Monday, November 23, 2009 7:14 PM Subject: Re: [Openocd-development] mips: remove dynamic arrays - reduces stack usage The patch didn't make it through. Please check this patch and I'll commit it. Sorry about breaking the mips stuff thanks for spotting it! -- Øyvind Harboe -- This message has been scanned for viruses and dangerous content by Draytek E-mail System, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
Actually, I ran into a possible other option: git rebase -p master which is supposed to preserve merges by not ignoring them. It seems to work in the limited testing I've done. I'll wait for more commits on origin before I confirm. // Dean Glazeski On Mon, Nov 23, 2009 at 6:24 PM, Zach Welch z...@superlucidity.net wrote: If you have a series (or tree) of branches, I wrote a small script to rebase them automatically; however, it falls down when something fails, in so far as you have to finish things manually (for now). Basically, it does this process for N steps and for any number of branches in your local web of commits: git branch step1-tmp step1 git rebase master step1 git rebase --onto step1 step1-tmp step2 git branch -D step1-tmp Is that what you mean? If so, my script is in the 'buildscripts' branch of my fork on repo.or.cz, named rebase.pl. Here are a few ways I want to see it improved: - figure out the branch tree(s) automatically - avoid leaving temporary branches around - full continuation and abort support, a la 'git rebase' - etc. :) Patches welcome, but I do not plan on adding those scripts to mainline. That branch contains things that I wrote which may be useful to others, but I am not pushing to push any of it. --Z On Mon, 2009-11-23 at 16:34 -0600, Dean Glazeski wrote: I went ahead and moved everything over as a fork on my own. I'll leave the other around until this stuff gets hammered out and I'll remove it at that point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git. I've rebased everything to the new origin/master. Is there a good way to rebase two branches that merge to create another branch? With my current layout, if I rebase each branch individually, the merge disappears. // Dean Glazeski On Mon, Nov 23, 2009 at 3:47 PM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote: Hi all, I've finished up the implementation and documentation for an AT91SAM9 NAND driver for OpenOCD. In total there are about 34 patches that includes some refactor work for both the NAND controller layer and the ARM NAND I/O pieces. I have the branch posted at http://repo.or.cz/w/dnglaze.git under the at91sam9-nand head. I'm not sure what the best approach is for working this into the tree cause this is the biggest change I've attempted to contribute. I can only verify that this works for my Olimex SAM9-L9260 board. Any suggestions, testing, or improvements are very welcome. My first question is: would you mind moving your repository to be a fork of openocd.git? You need to contact pasky (the maintainer), but he will put it in the right place for you. There are several good reasons for him to do this, including saving mirroring bandwidth and disk space on the server. For us, it puts you in the list with the other forks, so others can see when you have pushed new work more easily. Anyway, I just pulled your branches and verified each patch builds okay. That's a step in the right direction. I'll look more closely at them when I am done with my command registration series, which I am getting nearly ready to post. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 5/7] ARM11: use standard run_algorithm()
On Monday 23 November 2009, David Brownell wrote:
NOTE: this is partially broken, it seems to cause some
other bug(s) to fire. Not sure what's up with that, yet.
The most blatant part of it is a bug in the resume() method, where
it misinterpreted an argument. Fixed by:
--- oocd.orig/src/target/arm11.c2009-11-23 19:26:02.0 -0800
+++ oocd/src/target/arm11.c 2009-11-23 19:18:40.0 -0800
@@ -715,8 +715,10 @@ static int arm11_resume(struct target *t
/* clear breakpoints/watchpoints and VCR*/
arm11_sc7_clear_vbw(arm11);
- /* Set up breakpoints */
if (!debug_execution)
+ target_free_all_working_areas(target);
+
+ /* Set up breakpoints */
{
/* check if one matches PC and step over it if necessary */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to single step without interrupts?
On Monday 23 November 2009, Thomas Kindler wrote: When single stepping on a STM32, I'm constantly caught in interrupt handler code. This makes debugging almost impossible for non-trivial programs with timer and other peripheral interrupts. I have seen that there's an cortex_m3 maskisr on/off command, but it's awkward to use from eclipse. Does that solve the problem you're facing though? There seems to be no way to issue monitor commands to OpenOCD during a debug session, or even bind commands to a GUI button (perhaps a nice feature for Zylin-CDT?). Is there a good way to tell OpenOCD to mask ISRs after hitting a breakpoint/single-stepping, but re-enable interrupts on run? If monitor cortex_m3 maskisr on (or off) suffices, surely you can script things so GDB runs automatically? Or maybe not; I don't use GDB much. All I can say is that I've worked with debuggers that were built around KSH, specifically so that they could embed such scripting ... anywhere. :) I'm afraid I can't be of much help here. Though I can wonder whether this isn't something that would be a good match for monitor mode support ... where you can debug one task with the aid of some debug code linked into your program, while in the background the interrupts are firing and their handlers are doing their work. Making OpenOCD support that might be a good project someday. (The chainsaw IRQ handler should probably not be held off. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to single step without interrupts?
Thomas Kindler pisze: Hi! When single stepping on a STM32, I'm constantly caught in interrupt handler code. This makes debugging almost impossible for non-trivial programs with timer and other peripheral interrupts. I have seen that there's an cortex_m3 maskisr on/off command, but it's awkward to use from eclipse. There seems to be no way to issue monitor commands to OpenOCD during a debug session, or even bind commands to a GUI button (perhaps a nice feature for Zylin-CDT?). Is there a good way to tell OpenOCD to mask ISRs after hitting a breakpoint/single-stepping, but re-enable interrupts on run? That's not your problem. On STM32 when the core is halted (whatever was the reason) some peripherals (including timers) continue to operate normally. This is a good thing - imagine writing a software for SMSP and no possibility to halt the chip - you'd have 50% chance of frying the coil and the switch when the PWM would stop working. That's why when you stop your program some peripherals keep working and keep sending interrupt signals, making single stepping virtually impossible. To solve this you can really stop the timer and some other peripherals when the core is stopped (if your hardware allows to do that) - take a look at the DBGMCU-CR register. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What became of the generic LPC config script?
Øyvind Harboe pisze: I can't seem to find the generic LPC config script work that was done(but never committed). What was the story on why it wasn't committed yet? It's dead as IMHO it's impossible to make it generic, simple and cover all wicked types of use at the same time. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to single step without interrupts?
Combined with Freddie's tips, you may be able to use some of the OpenOCD GDB events... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] mips: remove dynamic arrays - reduces stack usage
On Tue, Nov 24, 2009 at 2:03 AM, Jerry Ling jerry_l...@draytek.com wrote: Many thanks for your improvement. This patch works very well. Pushed. Thanks for testing and providing a fix! (Next time could you attach the patch as an email, I wasn't able to read it in, but as it was only three lines so recreating it was no big deal.) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What became of the generic LPC config script?
On Tue, Nov 24, 2009 at 7:22 AM, Freddie Chopin freddie_cho...@op.pl wrote: Øyvind Harboe pisze: I can't seem to find the generic LPC config script work that was done(but never committed). What was the story on why it wasn't committed yet? It's dead as IMHO it's impossible to make it generic, simple and cover all wicked types of use at the same time. Could you point me to the latest version? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
