On Thursday 24 December 2009, David Brownell wrote:
> +
> + /* REVISIT This needlessly touches sectors BETWEEN the
> + * sections it's writing. Without auto erase, it just
> + * writes ones; unlikely to destroy data.
For the reco
>> Qualified by an "pad" option to round up/down to nearest sector boundary,
>> if you prefer.
>
> I'll think about that. Any such dangerous "erase extra stuff"
> should certainly not be a default behavior, when someone has gone
> through the effort to specify exactly the address range they want
>
On Sunday 27 December 2009, Øyvind Harboe wrote:
> I can't test the code anytime soon, but it looks OK to me so I
> think you should commit it if you've run tests on it.
My thoughts exactly. Done.
> I would like the same padding logic added to flash erase_address
> to restore that functionality
I can't test the code anytime soon, but it looks OK to me so I
think you should commit it if you've run tests on it.
I would like the same padding logic added to flash erase_address
to restore that functionality.
Qualified by an "pad" option to round up/down to nearest sector boundary,
if you pre
On Tuesday 22 December 2009, Yegor Yefremov wrote:
> flash write_image erase image.bin 0x1000 bin
> auto erase enabled
> address range 0x1000 .. 0x000135d3 is not sector-aligned
> Command handler execution failed
The following patch should help in at least some cases;
it doesn't insert sector
On Tuesday 22 December 2009, Austin, Alex wrote:
> Read-modify-erase-write on per-sector basis?
That's more work than I want to do for now, but it would be a
more general solution.
My conclusion from looking at that code is that the intelligence
of the auto-erase code is ... a lot less than I've
On Wednesday 23 December 2009, Øyvind Harboe wrote:
> Now, there is a small problem you pointed out: that two elf images
> that are "too close together" won't work with the flash write
> image erase option,
Don't forget the original one: "flash erase_address" was
erasing data which it was told to
On Wed, Dec 23, 2009 at 1:47 PM, David Brownell wrote:
> On Wednesday 23 December 2009, Řyvind Harboe wrote:
>> I do think it might be useful to print actual address
>> ranges erased in some reasonably terse and non
>> warning format.
>
> If it's going to be erasing data beyond what it was told
>
On Wednesday 23 December 2009, Øyvind Harboe wrote:
> I do think it might be useful to print actual address
> ranges erased in some reasonably terse and non
> warning format.
If it's going to be erasing data beyond what it was told
to erase, we deserve at the very least a warning.
That's pretty b
Øyvind Harboe wrote:
> Now, there is a small problem you pointed out: that two elf images
> that are "too close together" won't work with the flash write
> image erase option, but here the user can use flash erase_address
> range in one pass and then multiple invocations of flash
> write_image, so
Some background info:
The purpose of flash erase_address / flash write_image dammit is to
use it from scripts.
A bunch of targets, new and old can then be flashed or reflashed
with some firmware with trivial scripts that have no conditional code.
The scripts do not have to be updated as the elf i
I do think it might be useful to print actual address
ranges erased in some reasonably terse and non
warning format.
This would help the user learn what flash address_range
/ write_image erase is doing and should cover your concern
as well, I think.
--
Øyvind Harboe
US toll free 1-866-980-3434 /
What flash erase address range does is to a) identify sectors
within an address range b) erase all those sectors. There is
certainly nothing broken about a) and if I wanted to do b) then
there is nothing broken about that either.
At most, there could be a non-default option to flash erase_address
e
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] [patch/rfc] NOR FLASH: only
> erase/unlock whole sectors
>
> On Tuesday 22 December 2009, Øyvind Harboe wrote:
> > This is a bit worse than I thought.
> >
> > This breaks flash write_image
On Tuesday 22 December 2009, Øyvind Harboe wrote:
> This is a bit worse than I thought.
>
> This breaks flash write_image as well.
That was *this* problem report, in fact...
> Flash write_image will first erase all sectors in address ranges of
> all segments to be written, then it will write al
On Tuesday 22 December 2009, Yegor Yefremov wrote:
> After applying the latest patches 0.4-rc1 I encountered the following error:
>
> halt
> flash write_image erase image.bin 0x1000 bin
> auto erase enabled
> address range 0x1000 .. 0x000135d3 is not sector-aligned
> Command handler execution
Ouch.
This is a bit worse than I thought.
This breaks flash write_image as well.
Flash write_image will first erase all sectors in address ranges of
all segments to be written, then it will write all segments.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http:
An alternative would be to add an option that is disabled by
default that will check that the address range matches sector
boundaries. This is incompatible, but perhaps a better way to
go?
This would be along the lines of the options we have for flash
write_image.
flash erase_address force =
On Tue, Dec 22, 2009 at 3:47 PM, Yegor Yefremov
wrote:
> On Fri, Dec 18, 2009 at 12:49 AM, David Brownell wrote:
>> Much to my surprise, I observed a "flash erase_address ..."
>> command erasing data which I didn't say should be erased.
>>
>> The issue turns out to be generic NOR flash code which
On Fri, Dec 18, 2009 at 12:49 AM, David Brownell wrote:
> Much to my surprise, I observed a "flash erase_address ..."
> command erasing data which I didn't say should be erased.
>
> The issue turns out to be generic NOR flash code which was
> silently, and rather dangerously, morphing partial-sect
Much to my surprise, I observed a "flash erase_address ..."
command erasing data which I didn't say should be erased.
The issue turns out to be generic NOR flash code which was
silently, and rather dangerously, morphing partial-sector
references into unrequested whole-sector ones.
This patch remo
21 matches
Mail list logo
