On 18.09.2013 21:53, Joerg Wunsch wrote:
As Bob Cunningham wrote:
There is no reason to use a broken tool, nor to argue with folks who have
defended its decade of brokenness.
OK, so far about Bob.
I'd like to get opinions from others on this.
My ideas so far:
. The current behaviour has been intented as an optimization, and this
certainly makes a lot of sense for the more common use cases
(reading out memory to program it back later, or for some kind of
eyeball review or disassembly). So I don't like it to go away
completely.
. Sure, I see Bob's point that sometimes, one might want to retain a
full image of what has been there.
. I also see the point that with an application, followed by a
bootloader very far away, basically the same considerations as above
could be made to the intervening 0xFFs. But where to draw the line?
One option for #2 were to have a separate indication that you really
want the full image, like -U flash:R:flashfile:i, where the capital
'R' indicates it. That far, it should be simple to do.
As for #3, one idea I've got is to always consider full flash pages.
If a flash page turns out empty, omit it from the image. That way, a
few bytes of 0xFF won't be dropped, but all large holes will. (Such
holes are not only related to bootloaders, but could also happen if
there are separate application data. The Xmegas even have their
"apptable" area for that purpose.) But how to handle ancient AVRs
that don't have paged flash? Impose some kind of artificial pagesize
just for that purpose?
Any other opinions?
One of Bob's points was "It is clear that avrdude and its images are
useless for verification, since they actively prevent all bytes from
being verified. "
I did not check this, but I always thought avrdude would verify the 0xFF
if the input files contain them. So the only point left is to read all
0xFF bytes from a device into the file, so they can be checked at later
programming.
#2 I think 'R' would be nice to have.
#3 Using pagesize sounds reasonable. And if someone uses an ancient avr
device that does not have pages, so he gets all the 0xFF bytes (page
size = memory size). I guess (newer) devices with larger memory, where
you save the most, will probably have all pages.
René
_______________________________________________
avrdude-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
