Re: [Openocd-development] [PATCH] Build inline jimtcl
Works fine here for the case of using installed and submodule jim tcl. Tested with cross compiles for installed jim. When Jim Tcl is not installed and using --disable-internal-jimtcl, the build fails as it should. I like that there is no detection going on, it does what it is told to do. This avoids subtle issues depending on what's installed on the developer machine. I wouldn't feel to bad if the internal jim forced --with-jim-ext=nvp and didn't allow passing options through. Those that want a different kind of jim than OpenOCD does by default can either submit a patch or get by with --disable-internal-jimtcl. Except for a cool off period to catch other issues, I think it should be merged. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 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] Peripheral register view in Eclipse
Has anyone taken this plugin for a spin? It displays peripheral registers and there are databases for some common CPUs built in. http://sourceforge.net/projects/embsysregview/ -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 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] SPEAr serial NOR flash driver
Antonio Borneo wrote: I'm not thrilled about having this information local in the spearsmi Like generic SPI and SPI-flash layers. The flash support shouldn't be SPEAr-specific in the least. Understand your comments. I agree that the table could be shared between SPEAr SMI and a generic SPI or SPI-flash framework. But I think this could be the only common part. AFAIK, SPI flash is not accessible in CPU memory space directly, but requires the driver to copy to RAM the flash content. This is stated also in OpenOCD documentation, chapter 12. But, SMI controller is not a generic SPI interface (some devices in SPEAr family also provide a separate SPI controller, keeping SMI for flash only). SMI is a dedicated HW accelerator that hides the SPI protocol and maps on-the-fly the content of the SPI flash in the CPU memory space. That is true.. But SPI is still SPI, and maybe some code can be shared. Likewise the flash chips in the table may be relevant elsewhere in the code, so would be better to have their information outside spearsmi, along with enough knowledge to determine if they can be used by spearsmi or not. The SMI has some limitation while choosing a flash device. The documentation reports the list of mandatory SPI commands codes that the flash have to support, since such values are hardcoded in the controller and cannot be changed. Does the SMI have a manual command mode? What you describe is common with SPI flash controllers, but there can also be a generic mode where software can specify one command at a time to execute on SPI? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peripheral register view in Eclipse
I was wondering if the target database of peripheral registers could somehow be leveraged in OpenOCD. Recall all those pesky target combinations? Isn't there information in this peripheral register view plugin that OpenOCD could use? FAE's from silicon vendors would probably spend time assuring that such databases are up to date. They do for Keil, IAR and their ilk. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 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] Peripheral register view in Eclipse
Øyvind Harboe wrote: I was wondering if the target database of peripheral registers could somehow be leveraged in OpenOCD. .. Isn't there information in this peripheral register view plugin that OpenOCD could use? At the very least it would be neat to have upstream's register names in mww commands etc. FAE's from silicon vendors would probably spend time assuring that such databases are up to date. They do for Keil, IAR and their ilk. Yes, just need to make it very simple for them to do so. Maybe web based for starters. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault when gdb connects, but target is not connected
Does the attached patch fix the problem? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer From f41192ab7ff1da1d9b6ac7908987de8478a35db4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=98yvind=20Harboe?= oyvind.har...@zylin.com Date: Sat, 13 Nov 2010 13:03:29 +0100 Subject: [PATCH] gdb: fix occasional crash when flash probe failed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- src/server/gdb_server.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c index 9503a13..77142df 100644 --- a/src/server/gdb_server.c +++ b/src/server/gdb_server.c @@ -833,9 +833,6 @@ static int gdb_new_connection(struct connection *connection) breakpoint_clear_target(gdb_service-target); watchpoint_clear_target(gdb_service-target); - /* register callback to be informed about target events */ - target_register_event_callback(gdb_target_callback_event_handler, connection); - /* remove the initial ACK from the incoming buffer */ if ((retval = gdb_get_char(connection, initial_ack)) != ERROR_OK) return retval; @@ -873,6 +870,13 @@ static int gdb_new_connection(struct connection *connection) target_name(gdb_service-target), target_state_name(gdb_service-target)); + /* DANGER! If we fail subsequently, we must remove this handler, + * otherwise we occasionally see crashes as the timer can invoke the + * callback fn. + * + * register callback to be informed about target events */ + target_register_event_callback(gdb_target_callback_event_handler, connection); + return ERROR_OK; } -- 1.7.0.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] SPEAr serial NOR flash driver
Øyvind Harboe wrote: So basically if OpenOCD had some generic support for interfacing to SPI chips via the target CPU over JTAG, then you could build on that for your flash driver? That seems a completely separate feature to your patch. That's the point basically, there are parts of the patch which should be separated out, because they are not really specific to spearsmi. Your flash driver could be refactored once such support was added, possibly by factoring out some code from your flash driver. Refactor now, or then? Copypaste later is more likely what we'll see.. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Add cortex_m3 capabilities soft_reset command
This is work-in-progress, but before continuing I'd like to hear your
comments - I can stop now if you don't like that idea.
User can execute command cortex_m3 capabilities soft_reset + all
supported soft-reset methods, can be selected from two: sysresetreq
and/or vectreset (or none).
This can be used in cortex_m3_assert_reset() to select best reset method.
BTW - I'm not sure whether I've added the commands right (especially
capabilities chain), but that code works fine (but currently does
nothing more than set target variables) - I've tested it.
I hope you like it...
4\/3!!
From bbd6137fdade1b2760ade58cc23d6f9fc9b52cc2 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 13:07:08 +0100
Subject: [PATCH] Add cortex_m3 capabilities soft_reset command
Add cortex_m3 capabilities command group. Add cortex_m3 capabilities
soft_reset command that allows user to specify all soft-reset methods
supported by the target (sysresetreq, vectreset).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
src/target/cortex_m3.c | 55
src/target/cortex_m3.h |8 +++
2 files changed, 63 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/target/cortex_m3.c
mode change 100644 = 100755 src/target/cortex_m3.h
diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
old mode 100644
new mode 100755
index f2947ad..42ed45d
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -2166,6 +2166,54 @@ COMMAND_HANDLER(handle_cortex_m3_reset_config_command)
return ERROR_OK;
}
+COMMAND_HANDLER(handle_cortex_m3_capabilities_soft_reset_command)
+{
+ struct target *target = get_current_target(CMD_CTX);
+ struct cortex_m3_common *cortex_m3 = target_to_cm3(target);
+ int retval;
+ char *soft_reset_sysresetreq = , *soft_reset_vectreset = ;
+
+ retval = cortex_m3_verify_pointer(CMD_CTX, cortex_m3);
+ if (retval != ERROR_OK)
+ return retval;
+
+ cortex_m3-capabilities_soft_reset.sysresetreq = false;
+ cortex_m3-capabilities_soft_reset.vectreset = false;
+
+ for (; CMD_ARGC; CMD_ARGC--, CMD_ARGV++)
+ {
+ if (strcmp(*CMD_ARGV, sysresetreq) == 0)
+ cortex_m3-capabilities_soft_reset.sysresetreq = true;
+ else if (strcmp(*CMD_ARGV, vectreset) == 0)
+ cortex_m3-capabilities_soft_reset.vectreset = true;
+ else
+ LOG_WARNING(unknown Cortex-M3 soft-reset method
ignored: %s, *CMD_ARGV);
+ }
+
+ if (cortex_m3-capabilities_soft_reset.sysresetreq == true)
+ soft_reset_sysresetreq = sysresetreq;
+ if (cortex_m3-capabilities_soft_reset.vectreset == true)
+ soft_reset_vectreset = vectreset;
+
+ command_print(CMD_CTX, cortex_m3 capabilities soft_reset%s%s,
+ soft_reset_sysresetreq,
+ soft_reset_vectreset
+ );
+
+ return ERROR_OK;
+}
+
+static const struct command_registration
cortex_m3_capabilities_command_handlers[] = {
+ {
+ .name = soft_reset,
+ .handler = handle_cortex_m3_capabilities_soft_reset_command,
+ .mode = COMMAND_ANY,
+ .help = Specify all soft-reset methods supported by Cortex-M3
target,
+ .usage = ['sysresetreq'] ['vectreset'],
+ },
+ COMMAND_REGISTRATION_DONE
+};
+
static const struct command_registration cortex_m3_exec_command_handlers[] = {
{
.name = maskisr,
@@ -2188,8 +2236,15 @@ static const struct command_registration
cortex_m3_exec_command_handlers[] = {
.help = configure software reset handling,
.usage = ['srst'|'sysresetreq'|'vectreset'],
},
+ {
+ .name = capabilities,
+ .mode = COMMAND_ANY,
+ .help = Cortex-M3 capabilities command group,
+ .chain = cortex_m3_capabilities_command_handlers,
+ },
COMMAND_REGISTRATION_DONE
};
+
static const struct command_registration cortex_m3_command_handlers[] = {
{
.chain = armv7m_command_handlers,
diff --git a/src/target/cortex_m3.h b/src/target/cortex_m3.h
old mode 100644
new mode 100755
index db80711..6293790
--- a/src/target/cortex_m3.h
+++ b/src/target/cortex_m3.h
@@ -141,6 +141,12 @@ enum cortex_m3_soft_reset_config
CORTEX_M3_RESET_VECTRESET,
};
+struct cortex_m3_capabilities_soft_reset
+{
+ bool sysresetreq;
+ bool vectreset;
+};
+
struct cortex_m3_common
{
int common_magic;
@@ -167,6 +173,8 @@ struct cortex_m3_common
enum cortex_m3_soft_reset_config soft_reset_config;
+ struct cortex_m3_capabilities_soft_reset capabilities_soft_reset;
+
struct armv7m_common armv7m;
};
--
1.6.4.2
___
Openocd-development
Re: [Openocd-development] Peripheral register view in Eclipse
On 2010-11-13 12:48, Øyvind Harboe wrote: I was wondering if the target database of peripheral registers could somehow be leveraged in OpenOCD. Recall all those pesky target combinations? I'm not sure what do you mean ); Isn't there information in this peripheral register view plugin that OpenOCD could use? As Peter said, using names for mww, mdw etc. would be great (; FAE's from silicon vendors would probably spend time assuring that such databases are up to date. They do for Keil, IAR and their ilk. I think that they already do - releasing new versions of header files... I think that the best method is to find a way to parse such headers and create other formats with that info. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
Hi all!
Very small improvement. Tested on STM32, worst-case speed improvement is
~1.5%, best-case - ~3%.
Old one:
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
New one:
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.109375s (12.490 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.187500s (12.394 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.25s (12.319 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.156250s (12.432 KiB/s)
Image can be verified and it's fine.
4\/3!!
From a8d788763856fdf4dfeecad7827bb0e51e774c13 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 15:42:00 +0100
Subject: [PATCH] Add comments and tiny improvements to STM32 flash loader
algorithm
Add comments to assembly flash loader for STM32. Add tiny improvement in
size of the algorithm (40 vs 48 bytes) and tiny speed improvement (~1.5%,
as time is wasted on waiting for end of operation anyway).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
contrib/loaders/flash/stm32x.s | 40 ++--
src/flash/nor/stm32x.c | 33 +
2 files changed, 39 insertions(+), 34 deletions(-)
diff --git a/contrib/loaders/flash/stm32x.s b/contrib/loaders/flash/stm32x.s
index dcf2b83..6cf9f57 100644
--- a/contrib/loaders/flash/stm32x.s
+++ b/contrib/loaders/flash/stm32x.s
@@ -19,7 +19,10 @@
***/
.text
- .arm
+ .syntax unified
+ .thumb
+ .thumb_func
+ .global write
/*
r0 - source address
@@ -27,26 +30,27 @@
r2 - count (halfword-16bit)
r3 - result
r4 - temp
- r5 - temp
*/
+#define STM32_FLASH_CR_OFFSET 0x10/* offset of CR
register in FLASH struct */
+#define STM32_FLASH_SR_OFFSET 0x0c/* offset of CR
register in FLASH struct */
+
write:
- ldr r4, STM32_FLASH_CR
- ldr r5, STM32_FLASH_SR
- mov r3, #1
- str r3, [r4, #0]
- ldrhr3, [r0], #2
- strhr3, [r1], #2
+ ldr r4, STM32_FLASH_BASE
+write_half_word:
+ movsr3, #0x01
+ str r3, [r4, #STM32_FLASH_CR_OFFSET]/* PG (bit0) ==
1 = flash programming enabled */
+ ldrhr3, [r0], #0x02 /* read
one half-word from src, increment ptr */
+ strhr3, [r1], #0x02 /*
write one half-word from src, increment ptr */
busy:
- ldr r3, [r5, #0]
- tst r3, #0x01
- beq busy
- tst r3, #0x14
- bne exit
- subsr2, r2, #1
- bne write
+ ldr r3, [r4, #STM32_FLASH_SR_OFFSET]
+ tst r3, #0x01
/* BSY (bit0) == 1 = operation in progress */
+ beq busy
/* wait more... */
+ tst r3, #0x14
/* PGERR (bit2) == 1 or WRPRTERR (bit4) == 1 = error */
+ bne exit
/* fail... */
+ subsr2, r2, #0x01 /*
decrement counter */
+ bne write_half_word
/* write next half-word if anything left */
exit:
- bkpt#0
+ bkpt#0x00
-STM32_FLASH_CR: .word 0x40022010
-STM32_FLASH_SR:.word 0x4002200C
+STM32_FLASH_BASE: .word 0x40022000 /* base address
of FLASH struct */
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 6b46afc..7779ea3 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -503,25 +503,26 @@ static int stm32x_write_block(struct flash_bank *bank,
uint8_t *buffer,
/* see contib/loaders/flash/stm32x.s for src */
static const uint8_t stm32x_flash_write_code[] = {
+ /*
#define STM32_FLASH_CR_OFFSET0x10 */
+
Re: [Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
Is it conceivable that this would address the block flash programming problems I saw the other day and you were not able to reproduce? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 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] Add cortex_m3 capabilities soft_reset command
On 13/11/2010 12:12, Freddie Chopin wrote: This is work-in-progress, but before continuing I'd like to hear your comments - I can stop now if you don't like that idea. User can execute command cortex_m3 capabilities soft_reset + all supported soft-reset methods, can be selected from two: sysresetreq and/or vectreset (or none). This can be used in cortex_m3_assert_reset() to select best reset method. BTW - I'm not sure whether I've added the commands right (especially capabilities chain), but that code works fine (but currently does nothing more than set target variables) - I've tested it. I hope you like it... I like the basic idea. that way we can make the cfg a bit more intelligent. May be better calling it config_soft_reset or similar. Another point is that some targets (luminary) do not correctly support srst so it may be worth turning this into a config_reset cmd instead. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
On 2010-11-13 16:47, Øyvind Harboe wrote: Is it conceivable that this would address the block flash programming problems I saw the other day and you were not able to reproduce? Rather not... The mechanics of this algorithm are exactly the same - I've just shortened the inner write loop (no need to load addresses of registers again), and used offset ldr to use only one literal address (FLASH struct) instead of two (CR and SR). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add cortex_m3 capabilities soft_reset command
On 2010-11-13 21:40, Spencer Oliver wrote:
May be better calling it config_soft_reset or similar.
I've tried to keep that short (; The longest one to type is
capabilities anyway, but I couldn't find a better word [;
Another point is that some targets (luminary) do not correctly support
srst so it may be worth turning this into a config_reset cmd instead.
To make it more universal, I think that a general target capabilities
reset command should be used, that command can select srst, soft_reset
(or both [or none, but that wouldn't make much sense]), then target
specific soft-reset methods could be added.
BTW - is there some problem with dash ('-') in command names? Today I've
been searching for problems within the code, because I've typed
cortex-m3 ..., while it's cortex_m3 ..., which is quite unnatural
IMO... Maybe that could be changed?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
