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 yo
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, reso
On Wed, Jan 20, 2010 at 8:22 AM, David Brownell 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. Some flashe
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 e
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 manufac
> 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 / Interna
> - 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 "bug/f
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 rather than the target memory, I think.
> Though: I l
Report each region of same-size sectors separately, instead
of incorrectly reporting that every sector has the same size.
This fixes a longstanding bug, exposed by other recent bugfixes
in flash handling.
---
Sanity tested with: single and dual bank with uniform sectors;
dual bank CFI with non-un
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
http://op
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
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
> > Err
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> >> With the str710 we have something nice to test against since the
> >> there are at least three sector sizes and two banks. Pretty messy :-)
> >
> > You sent the following memory map:
> >
> >> (gdb) info mem
> >> 0 y 0x 0x4000 rw
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 +-
src/server/gdb_serv
Put the memory map logic into its own subroutine.
This will make it a bit easier to package bugfixes,
and simplifies the query packet handling.
---
Again, no behavior change so I expect to commit soonish.
This is the routine which will need to change to fix the
bugs with reporting the flash region
[ Re semihosting on Cortex-M3/ARMv7-M ]
On Tuesday 19 January 2010, Spencer Oliver wrote:
> > Hmm, my notion there was to make armv7m use the same "struct arm"
> > as other ARM cores, and try to share more core infrastructure.
> > It shouldn't be *quite* so different as it is now.
> >
>
> I have
On Tuesday 19 January 2010, Spencer Oliver wrote:
> 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 adde
On Tuesday 19 January 2010, Andreas Fritiofson wrote:
> 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 envir
> One possible solution: add a "usage" string to "struct flash_driver",
> and a new "flash driver_list" command which lists all the drivers
> and their usage strings.
You've understood what I'm after and made some excellent suggestions.
I'm thinking that the help text for that new command should
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> On Tue, Jan 19, 2010 at 9:33 PM, David Brownell wrote:
> > On Tuesday 19 January 2010, Øyvind Harboe wrote:
> >> When I type "help cfi", I would have liked to see the command syntax
> >> for flash bank cfi...
> >>
> >> My idea was to invoke help_a
On Tue, Jan 19, 2010 at 11:24 PM, David Brownell wrote:
> On Tuesday 19 January 2010, Øyvind Harboe wrote:
>> It should be fixed before 0.4 as this is a clear cut regression.
>
> Let's fix the underlying bug though, not just paper over symptoms.
Agreed. The patch is just confirmation that we've i
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> It should be fixed before 0.4 as this is a clear cut regression.
Let's fix the underlying bug though, not just paper over symptoms.
> With the str710 we have something nice to test against since the
> there are at least three sector sizes and tw
On Tue, Jan 19, 2010 at 9:45 PM, David Brownell wrote:
> On Tuesday 19 January 2010, Øyvind Harboe wrote:
>> For 0.4 revert to erasing *all* flash within a region.
>
> No, this is the wrong fix. It's just papering over
> a bug in the str7 code.
The only fix we have now. The alternative is to rep
On Tue, Jan 19, 2010 at 9:44 PM, David Brownell wrote:
> 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
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 flas
On Tue, Jan 19, 2010 at 9:33 PM, David Brownell wrote:
> On Tuesday 19 January 2010, Øyvind Harboe wrote:
>> 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 & u
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 ho
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 Olive
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
OK by me, but I'd change
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.
___
Ope
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> For 0.4 revert to erasing *all* flash within a region.
No, this is the wrong fix. It's just papering over
a bug in the str7 code.
> Perhaps
> the right thing to do would be to change the memory map packet
> to return flash sectors?
Return the
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> 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 o
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 insta
Hi,
Updated patch, now correct handles step.
Cheers
Spen
>From 669c0944a09bf40bcd606964e1dee967ab594b0e Mon Sep 17 00:00:00 2001
From: Spencer Oliver
Date: Tue, 19 Jan 2010 16:44:03 +
Subject: [PATCH] ARMV7M: handle bkpt instruction on resume/step
Skip over a bkpt instruction if found on r
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 / Internatio
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 interface/dummy.c
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 (mf
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
---
src/server/gdb_server.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/s
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
---
src/flash/nor/core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/flash/nor/core.c b/src/fl
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
40 matches
Mail list logo
