Re: [Openocd-development] [PATCH] cfi: add Numonyx M29W128G reset workaround
Spencer Oliver wrote: The ST/Numonix M29W128G has an issue when a 0xff cmd is sent, it cause an internal undefined state. The workaround according to the Numonyx is to send another 0xf0 reset cmd. Looks good to me. I have had similar problems in our company's bootloader with an Intel/Numonyx part (IIRC P30 series, which had similar issues after the 65nm die shrink, but not on the older chips), so it might be necessary to use commandset-cpecific reset commands in all cases after the chip is detected. I have not tried OpenOCD on that chips, because it was on a Freescale CPU design. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] Documentation : arm920t implements armv4
There is a small typo in the cpu list, arm920t is armv4.
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 49df159..21c63a8 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -3432,7 +3432,7 @@ At this writing, the supported CPU types and variants are:
@item @code{arm11} -- this is a generation of ARMv6 cores
@item @code{arm720t} -- this is an ARMv4 core with an MMU
@item @code{arm7tdmi} -- this is an ARMv4 core
-...@item @code{arm920t} -- this is an ARMv5 core with an MMU
+...@item @code{arm920t} -- this is an ARMv4 core with an MMU
@item @code{arm926ejs} -- this is an ARMv5 core with an MMU
@item @code{arm966e} -- this is an ARMv5 core
@item @code{arm9tdmi} -- this is an ARMv4 core
--
1.7.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] Documentation: consistency in GDB command name
Always use the complete name of the GDB command, not an abbreviation.
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 21c63a8..f38c38f 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -537,7 +537,7 @@ command interpreter today is a mixture of (newer)
JIM-Tcl commands, and (older) the orginal command interpreter.
@item @b{Commands}
-...@* At the OpenOCD telnet command line (or via the GDB mon command) one
+...@* At the OpenOCD telnet command line (or via the GDB monitor command) one
can type a Tcl for() loop, set variables, etc.
Some of the commands documented in this guide are implemented
as Tcl scripts, from a @file{startup.tcl} file internal to the server.
--
1.7.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Fujitsu MBM29SL800TE flash support
Hi,
This is my first post to the list. First, I would like to thank
everyone for their work on OpenOCD, it is a great tool to work with. I
have been using it to debug code on hardware for the Rockbox project
(www.rockbox.org).
The target that I primarily work with has a Spansion/Fujitsu NOR flash
(MBM29SL800TE). I attached a patch that adds support for this flash. I
hope it can be included in the main repository. If there is something
that needs to be changed with the patch before inclusion please let me
know.
-Karl Kurbjun
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index 4ef41b9..cbb3bb0 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor/cfi.c
@@ -57,6 +57,7 @@ static const struct cfi_fixup cfi_0002_fixups[] = {
{CFI_MFR_SST, 0x00D7, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_SST, 0x2780, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_ATMEL, 0x00C8, cfi_fixup_atmel_reversed_erase_regions, NULL},
+ {CFI_MFR_FUJITSU, 0x22ea, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
{CFI_MFR_FUJITSU, 0x226b, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_AMIC, 0xb31a, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
{CFI_MFR_MX, 0x225b, cfi_fixup_0002_unlock_addresses, &cfi_unlock_addresses[CFI_UNLOCK_555_2AA]},
diff --git a/src/flash/nor/non_cfi.c b/src/flash/nor/non_cfi.c
index b49e441..e0ea568 100644
--- a/src/flash/nor/non_cfi.c
+++ b/src/flash/nor/non_cfi.c
@@ -280,6 +280,23 @@ static struct non_cfi non_cfi_flashes[] = {
ERASE_REGION(15, 64*KB)
}
},
+ {
+ .mfr = CFI_MFR_FUJITSU,
+ .id = 0x22ea,/* MBM29SL800TE */
+ .pri_id = 0x02,
+ .dev_size = 1*MB,
+ .interface_desc = 0x2, /* x8 or x16 device with nBYTE */
+ .max_buf_write_size = 0x0,
+ .status_poll_mask = CFI_STATUS_POLL_MASK_DQ5_DQ6_DQ7,
+ .num_erase_regions = 4,
+ .erase_region_info =
+ {
+ ERASE_REGION(15, 64*KB),
+ ERASE_REGION(1, 32*KB),
+ ERASE_REGION(2, 8*KB),
+ ERASE_REGION(1, 16*KB)
+ }
+ },
{
.mfr = CFI_MFR_FUJITSU,
.id = 0xba,/* 29LV400BC */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] tcl echo and puts question
Spencer Oliver wrote: {about puts)
For "puts" the model is this:
http://www.tcl.tk/man/tcl8.0/TclCmd/puts.htm
For ECHO... I know nothing..
Øyvind is probably the tcl man to answer this question :)
And I saw he's out for the week.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] tcl echo and puts question
Hi, Just a query regarding the behaviour of puts and echo and stdout. When using the telnet/gdb interfaces all is as expected. If i use the following the string is output to stdout as expected. echo "Hello World" in this case the linefeed is appended before the string is output. However if i use: puts "Hello World" Nothing is shown on stdout as the linefeed is sent as a separate operation after the string is output. The underlying output function (log_puts) only outputs to stdout if terminated by a linefeed. As you would expect the following works: puts "Hello World\n" Is this by design, or a bug? Øyvind is probably the tcl man to answer this question :) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] problem with software breakpoints
On 05/09/2010 08:52 AM, Ryan J M wrote: > On Sat, May 8, 2010 at 8:36 AM, Mitch Frazier wrote: >> I'm using openocd (0.40) on a netx50 CPU (an ARM966E-S). >> >> When I use software breakpoints and I set a breakpoint with gdb I then >> get a "false" breakpoint in some library initialization code before >> hitting the breakpoint that I actually set. The "false" breakpoint >> always occurs at the same address, in my case at 0x8006702e, although >> the address is not relevant. The debugger shows: >> >> 0x8006702e : b.n 0x80067272 >> >> The data at 0x8006702c (word that includes 0x8006702e is: 0xE120D900. >> Perhaps coincidentally or perhaps not, the software breakpoint value >> that openocd inserts (0xE1200070) starts with the same 2 bytes. A dump >> of the ARM registers is included at the end of the email. >> >> During testing I've discovered the following "workarounds": >> >> - If I single step over the "false" breakpoint and then continue, the >> program runs and >> I get to the breakpoint that I set. >> - If I include "gdb_breakpoint_override hard" in my openocd config file >> then I don't get >> the false breakpoint and I arrive at the breakpoint that I set and >> everything works fine >> (except that I'm limited to 2 breakpoints). >> - And of course, if I just don't set any breakpoints then the debugger >> runs the code >> without producing the "false" breakpoint. >> > > > how about the endianess used in your cfg? I just found/fixed a similar > bug on an ARM926ej-s bigendian system. and I take the same > 'workaround' as you did before I fix it. > My target is little endian and the config is set to little endian. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix instruction refilling bug when using software breakpoints on a big-endian arm926ej-s system
From: Jun Ma
Signed-off-by: Jun Ma
---
src/target/arm7_9_common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/target/arm7_9_common.c b/src/target/arm7_9_common.c
index 9f1bb2e..ac18b37 100644
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -377,6 +377,7 @@ static int arm7_9_unset_breakpoint(struct target *target,
struct breakpoint *bre
{
return retval;
}
+current_instr = target_buffer_get_u32(target, (uint8_t
*)¤t_instr);
if (current_instr == arm7_9->arm_bkpt)
if ((retval = target_write_memory(target,
breakpoint->address, 4, 1, breakpoint->orig_instr)) != ERROR_OK)
{
--
1.6.4.2
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Find a bug when using software breakpoints on a big-endian ARM926ej-s processor(with a fix)
Hi Ryan, On 5/9/10, Ryan J M wrote: > On Sun, May 9, 2010 at 11:41 PM, Ryan J M wrote: >> I found that after running 'continue' in gdb with software >> breakpoints, when it hit a breakpoint, it didn't write back the >> original instruction. . >> > > and, my openocd was compiled from the git HEAD version... > Please, use the diff command to create a patch and submit it here. Best Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] cfi: add Numonyx M29W128G reset workaround
The ST/Numonix M29W128G has an issue when a 0xff cmd is sent,
it cause an internal undefined state. The workaround according
to the Numonyx is to send another 0xf0 reset cmd.
Objections ?
Cheers
Spen
>From 2cff3cc5c0d50adfa53db7daeb3c1661e94890a5 Mon Sep 17 00:00:00 2001
From: Spencer Oliver
Date: Mon, 10 May 2010 12:23:41 +0100
Subject: [PATCH] cfi: add Numonyx M29W128G reset workaround
The ST/Numonix M29W128G has an issue when a 0xff cmd is sent,
it cause an internal undefined state. The workaround according
to the Numonyx is to send another 0xf0 reset cmd
Signed-off-by: Spencer Oliver
---
src/flash/nor/cfi.c | 67 ++
1 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c
index 4ef41b9..aa4540a 100644
--- a/src/flash/nor/cfi.c
+++ b/src/flash/nor/cfi.c
@@ -104,7 +104,6 @@ static __inline__ uint32_t flash_address(struct flash_bank
*bank, int sector, ui
}
return bank->base + bank->sectors[sector].offset + offset *
bank->bus_width;
}
-
}
static void cfi_command(struct flash_bank *bank, uint8_t cmd, uint8_t *cmd_buf)
@@ -232,6 +231,35 @@ static uint32_t cfi_query_u32(struct flash_bank *bank, int
sector, uint32_t offs
data[(3 * bank->bus_width) - 1] << 16 | data[(4
* bank->bus_width) - 1] << 24;
}
+static int cfi_reset(struct flash_bank *bank)
+{
+ struct cfi_flash_bank *cfi_info = bank->driver_priv;
+ int retval = ERROR_OK;
+
+ if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank, 0,
0x0))) != ERROR_OK)
+ {
+ return retval;
+ }
+
+ if ((retval = cfi_send_command(bank, 0xff, flash_address(bank, 0,
0x0))) != ERROR_OK)
+ {
+ return retval;
+ }
+
+ if (cfi_info->manufacturer == 0x20 &&
+ (cfi_info->device_id == 0x227E || cfi_info->device_id
== 0x7E))
+ {
+ /* Numonix M29W128G is cmd 0xFF intolerant - causes internal
undefined state
+* so we send an extra 0xF0 reset to fix the bug */
+ if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank,
0, 0x00))) != ERROR_OK)
+ {
+ return retval;
+ }
+ }
+
+ return retval;
+}
+
static void cfi_intel_clear_status_register(struct flash_bank *bank)
{
struct target *target = bank->target;
@@ -335,11 +363,7 @@ static int cfi_read_intel_pri_ext(struct flash_bank *bank)
if ((pri_ext->pri[0] != 'P') || (pri_ext->pri[1] != 'R') ||
(pri_ext->pri[2] != 'I'))
{
- if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank,
0, 0x0))) != ERROR_OK)
- {
- return retval;
- }
- if ((retval = cfi_send_command(bank, 0xff, flash_address(bank,
0, 0x0))) != ERROR_OK)
+ if ((retval = cfi_reset(bank)) != ERROR_OK)
{
return retval;
}
@@ -1977,11 +2001,7 @@ static int cfi_write(struct flash_bank *bank, uint8_t
*buffer, uint32_t offset,
}
/* return to read array mode, so we can read from flash again for
padding */
- if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank, 0,
0x0))) != ERROR_OK)
- {
- return retval;
- }
- if ((retval = cfi_send_command(bank, 0xff, flash_address(bank, 0,
0x0))) != ERROR_OK)
+ if ((retval = cfi_reset(bank)) != ERROR_OK)
{
return retval;
}
@@ -2015,11 +2035,7 @@ static int cfi_write(struct flash_bank *bank, uint8_t
*buffer, uint32_t offset,
}
/* return to read array mode */
- if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank, 0,
0x0))) != ERROR_OK)
- {
- return retval;
- }
- return cfi_send_command(bank, 0xff, flash_address(bank, 0, 0x0));
+ return cfi_reset(bank);
}
static void cfi_fixup_atmel_reversed_erase_regions(struct flash_bank *bank,
void *param)
@@ -2083,11 +2099,7 @@ static int cfi_query_string(struct flash_bank *bank, int
address)
if ((cfi_info->qry[0] != 'Q') || (cfi_info->qry[1] != 'R') ||
(cfi_info->qry[2] != 'Y'))
{
- if ((retval = cfi_send_command(bank, 0xf0, flash_address(bank,
0, 0x0))) != ERROR_OK)
- {
- return retval;
- }
- if ((retval = cfi_send_command(bank, 0xff, flash_address(bank,
0, 0x0))) != ERROR_OK)
+ if ((retval = cfi_reset(bank)) != ERROR_OK)
{
return retval;
}
@@ -2168,11 +2180,7 @@ static int cfi_probe(struct flash_bank *bank)
LOG_INFO("Flash Manufacturer/Device: 0x%04x 0x%04x",
cfi_info->manufacturer, cfi_info->device_id);
/* switch back to read array mode */
- if ((r
