David Brownell wrote:
On Monday 18 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
This is a bugfix for RAM-based code, yes?
flash or ram, most semi hosting code would be in flash however.
I am updating the arm semihosting to support armv7m
According to OpenOCD error handling rules the error is
logged at where it occurs(same site where an exception
would have been thrown).
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/flash/nor/core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
For 0.4 revert to erasing *all* flash within a region. Perhaps
the right thing to do would be to change the memory map packet
to return flash sectors?
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/server/gdb_server.c | 11 ---
1 files changed, 8 insertions(+), 3
Run the following and it will fail to halt occasionally. This is not a
regression,
but I thought I'd post this tip on how to reproduce flaky reset problems...
for {set i 0} {$i 1000} {set i [expr $i+1]} {echo Reset $i; reset
halt}
10 kHz
JTAG tap: str710.cpu tap/device found: 0x3f0f0f0f (mfg:
w/dummy driver and str710 the gdb memory map is incorrect.
This will cause gdb load to fail now that flash erase_address fails
with non-aligned
memory.
The quick fix is to revert gdb to erase all sectors in a memory range.
The better
fix is to fix the GDB memory map.
openocd -f
When I type help cfi, I would have liked to see the command syntax
for flash bank cfi...
My idea was to invoke help_add_command() from flash/nor/tcl.c and
introduce a help usage text for each of the drivers.
Any thoughts on this one?
--
Øyvind Harboe
US toll free 1-866-980-3434 /
It seems this never reached the list...
So in conclusion, the (soon to be official?) windows packages from
Freddie Chopin installs config files so they are found by the first
default search path (in $installroot). In a unix-like environment,
including cygwin/msys, the build system by default
On Tuesday 19 January 2010, Øyvind Harboe wrote:
w/dummy driver and str710 the gdb memory map is incorrect.
So the correct fix is to fix that memory map... there are a
variety of things that break when it's wrong, $SUBJECT is
just one of them.
___
On Tuesday 19 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
Only software breakpoints known to openod are handled.
So this handles the special case of a user added bkpt, eg. semi-hosting.
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
David Brownell wrote:
On Tuesday 19 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
Only software breakpoints known to openod are handled.
So this handles the special case of a user added bkpt, eg. semi-hosting.
Signed-off-by: Spencer Oliver
On Tuesday 19 January 2010, Spencer Oliver wrote:
David Brownell wrote:
On Monday 18 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
This is a bugfix for RAM-based code, yes?
flash or ram, most semi hosting code would be in flash however.
David Brownell wrote:
On Tuesday 19 January 2010, Spencer Oliver wrote:
David Brownell wrote:
On Monday 18 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
This is a bugfix for RAM-based code, yes?
flash or ram, most semi hosting code would be in
Make most methods static; net minor object code shrink.
Likewise various data symbols; no net change.
Shrink some overlong lines.
---
No behavior change; unless someone objects soonish, I'll commit.
src/server/gdb_server.c | 166 +-
On Tuesday 12 January 2010, David Brownell wrote:
On Tuesday 12 January 2010, Alexei Babich wrote:
Error: 'arm11 target' JTAG error SCREG OUT 0x1f
Error: 'arm11 target' JTAG error SCREG OUT 0x1f
Error: 'arm11 target' JTAG error SCREG OUT 0x1f
Error: DPM REG READ -- fail -4
Error: 'arm11
Here's my current summary of *OPEN* issues with RC1.
If you raised an issue and it's not on this list then either
it's now resolved, or else I missed that and it's still an
open issue. Please verify.
If you know about other issues, please post them!
- Dave
REGRESSIONS -- must be fixed before
Hello all.
I'm trying to modify the NAND-flash driver for iMX31 for support iMX35.
I start openocd, and get the log:
---
[imp...@kb33 openocd]$ src/openocd -f /home/impatt/openocd.cfg
Open On-Chip Debugger 0.4.0-rc1-dev-00118-gdab9297-dirty (2010-01-20-10:20)
For bug reports, read
- NOR structural issue: wrongly writing ones, instead of not
writing anything. Can corrupt some flashes; for example it
would modify internal ECC codes. Some flashes don't seem to
care about this, but it violates all manufacturer guidelines.
(Longstanding bug.)
Another
When I try to invoke target_read_u32(), I get a message in the log: Error:
131 6 target.c: 1477 target_read_u32(): Target not examined yet
Can anyone suggest how to try to get rid of the error?
Normally a reset init would fix that...
--
Øyvind Harboe
US toll free 1-866-980-3434 /
On Tuesday 19 January 2010, Øyvind Harboe wrote:
- NOR structural issue: wrongly writing ones, instead of not
writing anything. Can corrupt some flashes; for example it
would modify internal ECC codes. Some flashes don't seem to
care about this, but it violates all manufacturer
On Tuesday 19 January 2010, Øyvind Harboe wrote:
New thread on new features to gdb memory maps.
Not sure what you mean by caching ... if the CPU is running, we
can't assume it's not going to touch such areas.
We can tell GDB to read data from an area(e.g. disassembly) from
the elf file
On Wed, Jan 20, 2010 at 8:22 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 January 2010, Øyvind Harboe wrote:
- NOR structural issue: wrongly writing ones, instead of not
writing anything. Can corrupt some flashes; for example it
would modify internal ECC codes.
On Tuesday 19 January 2010, David Brownell wrote:
No behavior change; unless someone objects soonish, I'll commit.
I pushed the first two patches -- cleanup, no behavior should change.
I'll hold off on the third for a bit, to give you a chance to verify
that it behaves OK on STR7 (ideally,
On Tuesday 19 January 2010, Øyvind Harboe wrote:
Another bug/feature is that the LPC driver will update the checksum
automatically. This will cause verify_image to fail when writing to LPC
flashes.
I can't see anything to do with that beyond documenting it.
If you write *without*
23 matches
Mail list logo
