[Openocd-development] PATCH - Fixed bug in tcl-server [ was: openocd crash when sending command over tcl_port ]

2010-05-03 Thread M B
Hello,

I have dug a little bit deeper and found a solution to solve the
segmentation fault in tcl_server.c

Attached you find the patch against v0.4.0 and master.

As this is my first patch against openocd tell me if something could
be improved.

--

Matthias Bode


openocd-v0.4.0-tcl_server.patch
Description: Binary data


openocd-master-tcl_server.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash

2010-05-03 Thread Dean Glazeski
Well that's a strange one.  Thanks for doing the comparison for me and
sharing the result and fix!

// Dean Glazeski


On Mon, May 3, 2010 at 12:01 PM, Gary Carlson wrote:

> Dean/Peter,
>
> Well I have some good news on this problem.  I finally discovered on Friday
> what the issue was.  Atmel¹s technical support confirmed my suspicions this
> morning.  On the bright side, it turns out this is not directly an OpenOCD
> issue.  :)
>
> Atmel¹s internal BootROM masked programmed at the factory utilizes the ARM
> exception vector six to determine the image size of the first stage
> bootstrapper.  If you look at the linker script and startup file they
> provide for the AT91 bootstrapper utility you will notice the crt0_gnu.S
> has
> the following define for vector 6:
>
>.word   _edata  /* Size of the image for SAM-BA */
>
>  Where _edata is defined by the linker script elf32-littlearm.lds:
>
> /* collect all initialized .data sections */
> .data : AT ( ADDR (.text) + SIZEOF (.text) ) {
> _sdata = .;
> *(.vectors)
> *(.data)
> _edata = .;
> }
>
> The problem with this is that the linker script will assign the absolute
> address of the last location rather then the size which should be
> calculated
> by subtracting the starting address from this value.  If the linker script
> is changed to:
>
>
> /* collect all initialized .data sections */
> .data : AT ( ADDR (.text) + SIZEOF (.text) ) {
> _sdata = .;
> *(.vectors)
> *(.data)
> _edata = (. - ADDR (.text));
> }
>
> Then everything works swell.  The image can be downloaded to the first
> block
> with OpenOCD and it will actually boot.
>
> So naturally this leads to the next question.  Why does this work at all?
>
> Well...Atmel confirmed that their native ISP tool is modifying the vector
> behind the scenes prior to committing the image to flash.  Although I
> downloaded the image programmed by their tool and eventually spotted the
> difference, I was so initially focused on the reset vector being right that
> I missed this subtle difference between what the compiler/linker was
> generating and what their tool actually had programmed further down the
> image.
>
> When I surrendered and actually performed a byte-by-byte comparison of the
> files out of despair rather the just looking at the reset vector, I finally
> made progress towards the solution.
>
> So while this is not a direct problem with OpenOCD, I wanted to expound on
> it so other fellow OpenOCD developer/users don't flail around for days like
> I did.  Atmel indicated that they will likely modify their application note
> to point this subtlety out also.
>
> Thanks to everyone for their help and advice!
>
> Gary
>
>
> On 5/3/10 7:10 AM, "Dean Glazeski"  wrote:
>
> > On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard 
> wrote:
> >>> "Gary" == Gary Carlson  writes:
> >>
> >>  Gary> I wanted to see if anyone has any experience trying to upload the
> >>  Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX
> parts
> >> (i.e.
> >>  Gary> AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
> >>
> >>  Gary> I have tried erasing and programming the first block of the NAND
> >>  Gary> flash in every command combination possible with the image I
> >>  Gary> have.  The programming cycle is successful, the verify command is
> >>  Gary> successful, but the internal first stage boot ROM concludes that
> >>  Gary> it isn't a valid image and goes limp (or brain dead depending on
> >>  Gary> how you want to look at it).  The Atmel startup diagnostics from
> >>  Gary> the internal boot code is naturally zero, so it is left to wild
> >>  Gary> imagination what the problem is.
> >>
> >> I haven't used it, but my guess is that the boot ROM expects a different
> >> OOB / EEC layout than what openocd writes.
> >>
> >> --
> >> Bye, Peter Korsgaard
> >> ___
> >> Openocd-development mailing list
> >> Openocd-development@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/openocd-development
> >
> > This is interesting.  I'm the one that actually wrote the original
> AT91SAM9
> > NAND flash piece.  To be honest, I haven't been able to test the
> "bootability"
> > of the flash stuff that gets written.  I thought that if I could write
> and
> > then read the same data, then everything should be okay.  Something I'm
> > thinking I should have done is try to write with SAM-BA and then verified
> what
> > was written with the OpenOCD driver.  I have plans of playing with this
> more
> > once I get out of classes for the year.  Right now, I'm sort of swamped
> in
> > projects.
> >
> > // Dean Glazeski
> >
>
>
>
>
>
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listi

Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash

2010-05-03 Thread Gary Carlson
Dean/Peter,

Well I have some good news on this problem.  I finally discovered on Friday
what the issue was.  Atmel¹s technical support confirmed my suspicions this
morning.  On the bright side, it turns out this is not directly an OpenOCD
issue.  :)

Atmel¹s internal BootROM masked programmed at the factory utilizes the ARM
exception vector six to determine the image size of the first stage
bootstrapper.  If you look at the linker script and startup file they
provide for the AT91 bootstrapper utility you will notice the crt0_gnu.S has
the following define for vector 6:

.word   _edata  /* Size of the image for SAM-BA */

 Where _edata is defined by the linker script elf32-littlearm.lds:

 /* collect all initialized .data sections */
 .data : AT ( ADDR (.text) + SIZEOF (.text) ) {
 _sdata = .;
 *(.vectors)
 *(.data)
 _edata = .;
 }

The problem with this is that the linker script will assign the absolute
address of the last location rather then the size which should be calculated
by subtracting the starting address from this value.  If the linker script
is changed to: 


 /* collect all initialized .data sections */
 .data : AT ( ADDR (.text) + SIZEOF (.text) ) {
 _sdata = .;
 *(.vectors)
 *(.data)
 _edata = (. - ADDR (.text));
 }

Then everything works swell.  The image can be downloaded to the first block
with OpenOCD and it will actually boot.

So naturally this leads to the next question.  Why does this work at all?

Well...Atmel confirmed that their native ISP tool is modifying the vector
behind the scenes prior to committing the image to flash.  Although I
downloaded the image programmed by their tool and eventually spotted the
difference, I was so initially focused on the reset vector being right that
I missed this subtle difference between what the compiler/linker was
generating and what their tool actually had programmed further down the
image.

When I surrendered and actually performed a byte-by-byte comparison of the
files out of despair rather the just looking at the reset vector, I finally
made progress towards the solution.

So while this is not a direct problem with OpenOCD, I wanted to expound on
it so other fellow OpenOCD developer/users don't flail around for days like
I did.  Atmel indicated that they will likely modify their application note
to point this subtlety out also.

Thanks to everyone for their help and advice!

Gary


On 5/3/10 7:10 AM, "Dean Glazeski"  wrote:

> On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard  wrote:
>>> "Gary" == Gary Carlson  writes:
>> 
>>  Gary> I wanted to see if anyone has any experience trying to upload the
>>  Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts
>> (i.e.
>>  Gary> AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
>> 
>>  Gary> I have tried erasing and programming the first block of the NAND
>>  Gary> flash in every command combination possible with the image I
>>  Gary> have.  The programming cycle is successful, the verify command is
>>  Gary> successful, but the internal first stage boot ROM concludes that
>>  Gary> it isn't a valid image and goes limp (or brain dead depending on
>>  Gary> how you want to look at it).  The Atmel startup diagnostics from
>>  Gary> the internal boot code is naturally zero, so it is left to wild
>>  Gary> imagination what the problem is.
>> 
>> I haven't used it, but my guess is that the boot ROM expects a different
>> OOB / EEC layout than what openocd writes.
>> 
>> --
>> Bye, Peter Korsgaard
>> ___
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
> 
> This is interesting.  I'm the one that actually wrote the original AT91SAM9
> NAND flash piece.  To be honest, I haven't been able to test the "bootability"
> of the flash stuff that gets written.  I thought that if I could write and
> then read the same data, then everything should be okay.  Something I'm
> thinking I should have done is try to write with SAM-BA and then verified what
> was written with the OpenOCD driver.  I have plans of playing with this more
> once I get out of classes for the year.  Right now, I'm sort of swamped in
> projects.
> 
> // Dean Glazeski
> 






___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] [PATCH] flash: less bogus errors

2010-05-03 Thread Øyvind Harboe
Removed bogus errors when trying to allocate a large
a target memory buffer as possible.

Signed-off-by: Øyvind Harboe 
---
 src/flash/nor/aduc702x.c  |2 +-
 src/flash/nor/cfi.c   |4 ++--
 src/flash/nor/lpc2900.c   |2 +-
 src/flash/nor/pic32mx.c   |2 +-
 src/flash/nor/stellaris.c |2 +-
 src/flash/nor/stm32x.c|2 +-
 src/flash/nor/str9x.c |2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/flash/nor/aduc702x.c b/src/flash/nor/aduc702x.c
index 57c591d..82ea2bc 100644
--- a/src/flash/nor/aduc702x.c
+++ b/src/flash/nor/aduc702x.c
@@ -227,7 +227,7 @@ static int aduc702x_write_block(struct flash_bank *bank, 
uint8_t *buffer, uint32
}
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index a64d78f..caa8068 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor/cfi.c
@@ -1116,7 +1116,7 @@ static int cfi_intel_write_block(struct flash_bank *bank, 
uint8_t *buffer, uint3
/* Get a workspace buffer for the data to flash starting with 32k size.
   Half size until buffer would be smaller 256 Bytem then fail back */
/* FIXME Why 256 bytes, why not 32 bytes (smallest flash write page */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
@@ -1444,7 +1444,7 @@ static int cfi_spansion_write_block(struct flash_bank 
*bank, uint8_t *buffer, ui
}
/* the following code still assumes target code is fixed 24*4 bytes */
 
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
diff --git a/src/flash/nor/lpc2900.c b/src/flash/nor/lpc2900.c
index 360c14d..5b00495 100644
--- a/src/flash/nor/lpc2900.c
+++ b/src/flash/nor/lpc2900.c
@@ -1288,7 +1288,7 @@ static int lpc2900_write(struct flash_bank *bank, uint8_t 
*buffer,
   reduced size if that fails. */
struct working_area *warea;
uint32_t buffer_size = lpc2900_info->max_ram_block - 1 * KiB;
-   while( (retval = target_alloc_working_area(target,
+   while( (retval = target_alloc_working_area_try(target,
   buffer_size + 
target_code_size,
   &warea)) != ERROR_OK )
{
diff --git a/src/flash/nor/pic32mx.c b/src/flash/nor/pic32mx.c
index 2540342..4ebd256 100644
--- a/src/flash/nor/pic32mx.c
+++ b/src/flash/nor/pic32mx.c
@@ -322,7 +322,7 @@ static int pic32mx_write_block(struct flash_bank *bank, 
uint8_t *buffer,
return retval;
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
diff --git a/src/flash/nor/stellaris.c b/src/flash/nor/stellaris.c
index 0b7c45a..cce5f37 100644
--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -846,7 +846,7 @@ static int stellaris_write_block(struct flash_bank *bank,
buffer_size = wcount * 4;
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= buf_min)
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 0fdd148..7afd959 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -481,7 +481,7 @@ static int stm32x_write_block(struct flash_bank *bank, 
uint8_t *buffer,
return retval;
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index 3d8b84b..2208fe3 100644
--- a/src/flash/nor/str9x.c
+++ b/src/flash/nor/str9x.c
@@ -385,7 +385,7 @@ static int str9x_write_block(struct flash_bank *bank,
(uint8_t*)str9x_flash_write_code);
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_t

Re: [Openocd-development] jim_mcrmrc: no command context @iMX35

2010-05-03 Thread Øyvind Harboe
This patch should fix the problem.

The patch is against openocd/master

As this post was made back in January, I'm including a reference to the
original discussion here...

http://www.mail-archive.com/openocd-development@lists.berlios.de/msg11864.html

-- 
Meet Zylin at ESC 2010 San Jose
April 26 - 30. 2010
http://www.zylin.com/events_esc2010.html


Øyvind Harboe
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 091a31d12f221348838ed3448dcf22cf4e134d23 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?= 
Date: Mon, 3 May 2010 17:01:53 +0200
Subject: [PATCH] command context: fix errors when running certain commands on startup
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Various commands, e.g. "arm mcr " would fail if invoked upon startup
since it there was no command context defined for the jim interpreter
in that case.

A Jim interpreter is now associated with a command context(telnet,
gdb server's) or the default global command context.

Signed-off-by: Øyvind Harboe 
---
 src/helper/command.c |8 ++--
 src/helper/command.h |4 
 src/jtag/tcl.c   |4 ++--
 src/target/armv4_5.c |8 +++-
 src/target/target.c  |   29 +++--
 5 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/src/helper/command.c b/src/helper/command.c
index 3625508..be262f2 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -167,14 +167,18 @@ static const char **script_command_args_alloc(
 	return words;
 }
 
-static struct command_context *current_command_context(Jim_Interp *interp)
+struct command_context *current_command_context(Jim_Interp *interp)
 {
 	/* grab the command context from the associated data */
 	struct command_context *cmd_ctx = Jim_GetAssocData(interp, "context");
 	if (NULL == cmd_ctx)
 	{
 		/* Tcl can invoke commands directly instead of via command_run_line(). This would
-		 * happen when the Jim Tcl interpreter is provided by eCos.
+		 * happen when the Jim Tcl interpreter is provided by eCos or if we are running
+		 * commands in a startup script.
+		 *
+		 * A telnet or gdb server would provide a non-default command context to
+		 * handle piping of error output, have a separate current target, etc.
 		 */
 		cmd_ctx = global_cmd_ctx;
 	}
diff --git a/src/helper/command.h b/src/helper/command.h
index 8a418d3..2c19241 100644
--- a/src/helper/command.h
+++ b/src/helper/command.h
@@ -311,6 +311,10 @@ void command_set_output_handler(struct command_context* context,
 
 int command_context_mode(struct command_context *context, enum command_mode mode);
 
+/* Return the current command context associated with the Jim interpreter or
+ * alternatively the global default command interpreter
+ */
+struct command_context *current_command_context(Jim_Interp *interp);
 /**
  * Creates a new command context using the startup TCL provided and
  * the existing Jim interpreter, if any. If interp == NULL, then command_init
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index 579ca9e..ea6d07e 100644
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -684,7 +684,7 @@ static int jim_jtag_arp_init(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
 		Jim_WrongNumArgs(goi.interp, 1, goi.argv-1, "(no params)");
 		return JIM_ERR;
 	}
-	struct command_context *context = Jim_GetAssocData(interp, "context");
+	struct command_context *context = current_command_context(interp);
 	int e = jtag_init_inner(context);
 	if (e != ERROR_OK) {
 		Jim_SetResult_sprintf(goi.interp, "error: %d", e);
@@ -701,7 +701,7 @@ static int jim_jtag_arp_init_reset(Jim_Interp *interp, int argc, Jim_Obj *const
 		Jim_WrongNumArgs(goi.interp, 1, goi.argv-1, "(no params)");
 		return JIM_ERR;
 	}
-	struct command_context *context = Jim_GetAssocData(interp, "context");
+	struct command_context *context = current_command_context(interp);
 	int e = jtag_init_reset(context);
 	if (e != ERROR_OK) {
 		Jim_SetResult_sprintf(goi.interp, "error: %d", e);
diff --git a/src/target/armv4_5.c b/src/target/armv4_5.c
index eeb6694..1a84a5f 100644
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -820,11 +820,9 @@ static int jim_mcrmrc(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
 	struct arm *arm;
 	int retval;
 
-	context = Jim_GetAssocData(interp, "context");
-	if (context == NULL) {
-		LOG_ERROR("%s: no command context", __func__);
-		return JIM_ERR;
-	}
+	context = current_command_context(interp);
+	assert( context != NULL);
+
 	target = get_current_target(context);
 	if (target == NULL) {
 		LOG_ERROR("%s: no current target", __func__);
diff --git a/src/target/target.c b/src/target/target.c
index a3a1b0a..d17bb74 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -3236,12 +3236,9 @@ static int jim_mem2array(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
 	struct command_context *context;
 	struct target *tar

[Openocd-development] [PATCH 3/3] str7x: fix bogus error messages

2010-05-03 Thread Øyvind Harboe
Remove bogus error messages when trying to allocate a
large chunk of target memory and then falling back to
a smaller one.

Signed-off-by: Øyvind Harboe 
---
 src/flash/nor/str7x.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/flash/nor/str7x.c b/src/flash/nor/str7x.c
index d6468d2..58b1d81 100644
--- a/src/flash/nor/str7x.c
+++ b/src/flash/nor/str7x.c
@@ -424,10 +424,9 @@ static int str7x_write_block(struct flash_bank *bank, 
uint8_t *buffer,
};
 
/* flash write code */
-   if (target_alloc_working_area(target, sizeof(str7x_flash_write_code),
+   if (target_alloc_working_area_try(target, 
sizeof(str7x_flash_write_code),
&str7x_info->write_algorithm) != ERROR_OK)
{
-   LOG_WARNING("no working area available, can't do block memory 
writes");
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
};
 
@@ -436,7 +435,7 @@ static int str7x_write_block(struct flash_bank *bank, 
uint8_t *buffer,
(uint8_t*)str7x_flash_write_code);
 
/* memory buffer */
-   while (target_alloc_working_area(target, buffer_size, &source) != 
ERROR_OK)
+   while (target_alloc_working_area_try(target, buffer_size, &source) != 
ERROR_OK)
{
buffer_size /= 2;
if (buffer_size <= 256)
@@ -565,6 +564,9 @@ static int str7x_write(struct flash_bank *bank, uint8_t 
*buffer,
/* if block write failed (no sufficient working 
area),
 * we use normal (slow) single dword accesses */
LOG_WARNING("couldn't use block writes, falling 
back to single memory accesses");
+   } else
+   {
+   return retval;
}
}
else
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] [PATCH 2/3] str7x: improve error handling

2010-05-03 Thread Øyvind Harboe
clean up error handling a bit. No change in behavior.

Signed-off-by: Øyvind Harboe 
---
 src/flash/nor/str7x.c |  192 +++--
 1 files changed, 122 insertions(+), 70 deletions(-)

diff --git a/src/flash/nor/str7x.c b/src/flash/nor/str7x.c
index d5e8e28..d6468d2 100644
--- a/src/flash/nor/str7x.c
+++ b/src/flash/nor/str7x.c
@@ -5,6 +5,9 @@
  *   Copyright (C) 2008 by Spencer Oliver  *
  *   s...@spen-soft.co.uk  *
  * *
+ *   Copyright (C) 2010 Øyvind Harboe  *
+ *   oyvind.har...@zylin.com   *
+ * *
  *   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 *
@@ -162,22 +165,79 @@ FLASH_BANK_COMMAND_HANDLER(str7x_flash_bank_command)
return ERROR_OK;
 }
 
-static uint32_t str7x_status(struct flash_bank *bank)
+/* wait for flash to become idle or report errors */
+static int str7x_waitbusy(struct flash_bank *bank)
 {
+   int err;
+   int i;
struct target *target = bank->target;
-   uint32_t retval;
+   struct str7x_flash_bank *str7x_info = bank->driver_priv;
 
-   target_read_u32(target, str7x_get_flash_adr(bank, FLASH_CR0), &retval);
+   for (i = 0 ; i < 500; i++)
+   {
+   uint32_t retval;
+   err = target_read_u32(target, str7x_get_flash_adr(bank, 
FLASH_CR0), &retval);
+   if (err != ERROR_OK)
+   return err;
 
-   return retval;
+   if ((retval & str7x_info->busy_bits) == 0)
+   return ERROR_OK;
+
+   alive_sleep(1);
+   }
+   LOG_ERROR("Timed out waiting for str7x flash");
+   return ERROR_FAIL;
 }
 
-static uint32_t str7x_result(struct flash_bank *bank)
+
+static int str7x_result(struct flash_bank *bank)
 {
struct target *target = bank->target;
uint32_t retval;
 
-   target_read_u32(target, str7x_get_flash_adr(bank, FLASH_ER), &retval);
+   int err;
+   err = target_read_u32(target, str7x_get_flash_adr(bank, FLASH_ER), 
&retval);
+   if (err != ERROR_OK)
+   return err;
+
+   if (retval & FLASH_WPF)
+   {
+   LOG_ERROR("str7x hw write protection set");
+   err = ERROR_FAIL;
+   }
+   if (retval & FLASH_RESER)
+   {
+   LOG_ERROR("str7x suspended program erase not resumed");
+   err = ERROR_FAIL;
+   }
+   if (retval & FLASH_10ER)
+   {
+   LOG_ERROR("str7x trying to set bit to 1 when it is already 0");
+   err = ERROR_FAIL;
+   }
+   if (retval & FLASH_PGER)
+   {
+   LOG_ERROR("str7x program error");
+   err = ERROR_FAIL;
+   }
+   if (retval & FLASH_ERER)
+   {
+   LOG_ERROR("str7x erase error");
+   err = ERROR_FAIL;
+   }
+   if (err == ERROR_OK)
+   {
+   if (retval & FLASH_ERR)
+   {
+   /* this should always be set if one of the others are 
set... */
+   LOG_ERROR("str7x write operation failed / bad setup");
+   err = ERROR_FAIL;
+   }
+   }
+   if (err != ERROR_OK)
+   {
+   LOG_ERROR("FLASH_ER register contents: 0x%" PRIx32, retval);
+   }
 
return retval;
 }
@@ -216,8 +276,8 @@ static int str7x_erase(struct flash_bank *bank, int first, 
int last)
 
int i;
uint32_t cmd;
-   uint32_t retval;
uint32_t sectors = 0;
+   int err;
 
if (bank->target->state != TARGET_HALTED)
{
@@ -233,28 +293,32 @@ static int str7x_erase(struct flash_bank *bank, int 
first, int last)
LOG_DEBUG("sectors: 0x%" PRIx32 "", sectors);
 
/* clear FLASH_ER register */
-   target_write_u32(target, str7x_get_flash_adr(bank, FLASH_ER), 0x0);
+   err = target_write_u32(target, str7x_get_flash_adr(bank, FLASH_ER), 
0x0);
+   if (err != ERROR_OK)
+   return err;
 
cmd = FLASH_SER;
-   target_write_u32(target, str7x_get_flash_adr(bank, FLASH_CR0), cmd);
+   err = target_write_u32(target, str7x_get_flash_adr(bank, FLASH_CR0), 
cmd);
+   if (err != ERROR_OK)
+   return err;
 
cmd = sectors;
-   target_write_u32(target, str7x_get_flash_adr(bank, FLASH_CR1), cmd);
+   err = target_write_u32(target, str7x_get_flash_adr(bank, FLASH_CR1), 
cmd);
+   if (err != ERROR_OK)
+   return err;
 
cmd = FLASH_SER | FLASH_WMS;
-   target_write_u32(target, str7x_ge

[Openocd-development] [PATCH 1/3] target: clean up target memory allocation error messages

2010-05-03 Thread Øyvind Harboe
target memory allocation can be implemented not to show
bogus error messages.

E.g. when trying a big allocation first and then a
smaller one if that fails.

Signed-off-by: Øyvind Harboe 
---
 src/target/target.c |   17 ++---
 src/target/target.h |8 
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/src/target/target.c b/src/target/target.c
index 73594fb..a3a1b0a 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -,7 +,7 @@ int target_call_timer_callbacks_now(void)
return target_call_timer_callbacks_check_time(0);
 }
 
-int target_alloc_working_area(struct target *target, uint32_t size, struct 
working_area **area)
+int target_alloc_working_area_try(struct target *target, uint32_t size, struct 
working_area **area)
 {
struct working_area *c = target->working_areas;
struct working_area *new_wa = NULL;
@@ -1189,8 +1189,6 @@ int target_alloc_working_area(struct target *target, 
uint32_t size, struct worki
 
if (free_size < size)
{
-   LOG_WARNING("not enough working area 
available(requested %u, free %u)",
-   (unsigned)(size), (unsigned)(free_size));
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
}
 
@@ -1231,6 +1229,19 @@ int target_alloc_working_area(struct target *target, 
uint32_t size, struct worki
return ERROR_OK;
 }
 
+int target_alloc_working_area(struct target *target, uint32_t size, struct 
working_area **area)
+{
+   int retval;
+
+   retval = target_alloc_working_area_try(target, size, area);
+   if (retval == ERROR_TARGET_RESOURCE_NOT_AVAILABLE)
+   {
+   LOG_WARNING("not enough working area available(requested %u)", 
(unsigned)(size));
+   }
+   return retval;
+
+}
+
 static int target_free_working_area_restore(struct target *target, struct 
working_area *area, int restore)
 {
if (area->free)
diff --git a/src/target/target.h b/src/target/target.h
index 0292945..4a48e5a 100644
--- a/src/target/target.h
+++ b/src/target/target.h
@@ -452,6 +452,14 @@ const char *target_state_name( struct target *target );
  */
 int target_alloc_working_area(struct target *target,
uint32_t size, struct working_area **area);
+/* Same as target_alloc_working_area, except that no error is logged
+ * when ERROR_TARGET_RESOURCE_NOT_AVAILABLE is returned.
+ *
+ * This allows the calling code to *try* to allocate target memory
+ * and have a fallback to another behavior(slower?).
+ */
+int target_alloc_working_area_try(struct target *target,
+   uint32_t size, struct working_area **area);
 int target_free_working_area(struct target *target, struct working_area *area);
 void target_free_all_working_areas(struct target *target);
 
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash

2010-05-03 Thread Dean Glazeski
On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard  wrote:

> > "Gary" == Gary Carlson  writes:
>
>  Gary> I wanted to see if anyone has any experience trying to upload the
>  Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts
> (i.e.
>  Gary> AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
>
>  Gary> I have tried erasing and programming the first block of the NAND
>  Gary> flash in every command combination possible with the image I
>  Gary> have.  The programming cycle is successful, the verify command is
>  Gary> successful, but the internal first stage boot ROM concludes that
>  Gary> it isn't a valid image and goes limp (or brain dead depending on
>  Gary> how you want to look at it).  The Atmel startup diagnostics from
>  Gary> the internal boot code is naturally zero, so it is left to wild
>  Gary> imagination what the problem is.
>
> I haven't used it, but my guess is that the boot ROM expects a different
> OOB / EEC layout than what openocd writes.
>
> --
> Bye, Peter Korsgaard
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>

This is interesting.  I'm the one that actually wrote the original AT91SAM9
NAND flash piece.  To be honest, I haven't been able to test the
"bootability" of the flash stuff that gets written.  I thought that if I
could write and then read the same data, then everything should be okay.
Something I'm thinking I should have done is try to write with SAM-BA and
then verified what was written with the OpenOCD driver.  I have plans of
playing with this more once I get out of classes for the year.  Right now,
I'm sort of swamped in projects.

// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash

2010-05-03 Thread Peter Korsgaard
> "Gary" == Gary Carlson  writes:

 Gary> I wanted to see if anyone has any experience trying to upload the
 Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts (i.e.
 Gary> AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?

 Gary> I have tried erasing and programming the first block of the NAND
 Gary> flash in every command combination possible with the image I
 Gary> have.  The programming cycle is successful, the verify command is
 Gary> successful, but the internal first stage boot ROM concludes that
 Gary> it isn't a valid image and goes limp (or brain dead depending on
 Gary> how you want to look at it).  The Atmel startup diagnostics from
 Gary> the internal boot code is naturally zero, so it is left to wild
 Gary> imagination what the problem is.

I haven't used it, but my guess is that the boot ROM expects a different
OOB / EEC layout than what openocd writes.

-- 
Bye, Peter Korsgaard
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] bitbang-jtag: FT232R based JTAG with OpenOCD patch

2010-05-03 Thread Øyvind Harboe
I think it is great that we see these posts w/references to
modified versions of OpenOCD.

I understand that there are people out there that need something
special done and don't want to or can't participate in the openocd mailing
list, but that doesn't mean that there aren't others who would step up
and do the merging work for changes that are of general interest.



-- 
Meet Zylin at ESC 2010 San Jose
April 26 - 30. 2010
http://www.zylin.com/events_esc2010.html


Øyvind Harboe
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] STM32 flash erase timeout fix

2010-05-03 Thread Øyvind Harboe
Merged.

Thanks!




-- 
Meet Zylin at ESC 2010 San Jose
April 26 - 30. 2010
http://www.zylin.com/events_esc2010.html


Øyvind Harboe
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