Re: [Openocd-development] [PATCH] STM32 flash erase timeout fix
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
Re: [Openocd-development] bitbang-jtag: FT232R based JTAG with OpenOCD patch
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] Atmel AT91SAM9XXX NAND Flash
Gary == Gary Carlson gcarl...@carlson-minot.com 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
[Openocd-development] [PATCH 1/3] target: clean up target memory allocation error messages
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 oyvind.har...@zylin.com
---
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
[Openocd-development] [PATCH 2/3] str7x: improve error handling
clean up error handling a bit. No change in behavior.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
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,
[Openocd-development] [PATCH 3/3] str7x: fix bogus error messages
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 oyvind.har...@zylin.com
---
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
Re: [Openocd-development] jim_mcrmrc: no command context @iMX35
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?= oyvind.har...@zylin.com
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 oyvind.har...@zylin.com
---
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
[Openocd-development] [PATCH] flash: less bogus errors
Removed bogus errors when trying to allocate a large
a target memory buffer as possible.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
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
Re: [Openocd-development] Atmel AT91SAM9XXX NAND Flash
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 dngl...@gmail.com wrote:
On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard jac...@sunsite.dk wrote:
Gary == Gary Carlson gcarl...@carlson-minot.com 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
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 gcarl...@carlson-minot.comwrote:
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 dngl...@gmail.com wrote:
On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard jac...@sunsite.dk
wrote:
Gary == Gary Carlson gcarl...@carlson-minot.com 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 - Fixed bug in tcl-server [ was: openocd crash when sending command over tcl_port ]
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
