Hi David!
El 21/04/16 a las 18:19, David Hendricks escribió:
On Thu, Apr 21, 2016 at 1:41 PM, Salvador Eduardo Tropea
<salva...@inti.gob.ar <mailto:salva...@inti.gob.ar>> wrote:
Hi David:
Thanks for your comments.
El 20/04/16 a las 20:42, David Hendricks escribió:
Hello Salvador,
Yes, this is a very useful feature - we've had it in the
chromiumos branch for a while now :-)
I need to read your implementation. Ours is called
"fast-verify" which will read and only verify portions of the
flash specified with -i arguments.
What about writes? My problem is that I have a 4 MiB flash and
that usually need to use 32kB from it.
Yes, it works for writes as well. Using your layout file as an example:
00000000:00007e2b fpga
00007e2c:003fffff free
If the eraseblock size is 4KB and you run /"/flashrom -p <programmer>
-l layout -i fpga -w foo.bin --fast-verify/"/, chromium's flashrom will:
1. Detect the flash chip.
2. Parse the -i argument
3. Do a partial read. This is broken into a multiple steps.
3a. Determine the "required_erase_size", for example, 4KB. Right now
the mechanism is crude and chooses the smallest block size that is
eraseable.
3b. Align regions that are read based on required_erase_size. 0000 is
already aligned, but 7e2b will be aligned up to 7fff.
3c. Read the aligned region content, which is 0000:7fff instead of
0000:7e2b, into the new content buffer.
4. Copy the new content from the "fpga" region into the new content
buffer.
5. Erase and write 0000:7fff
6. Verify from 0000:7fff
Overall it looks pretty similar to what you posted.
Yes.
Here's the original implementation:
https://chromium-review.googlesource.com/#/c/240176/
<https://chromium-review.googlesource.com/#/c/240176/4>. There are a
couple of follow-up patches as well, in case you're interested.
I taked a look at this. The patch have a lot in common.
In my patch I use the first "usable" eraser, just like
erase_and_write_flash. If this eraser fails the code will try to recover
reading the whole memory. So I think this is ok.
So assuming that the first "usable" eraser is a good choice I compute
the alignments using *all* the eraseblocks information. My intention is
to support cases like it:
.block_erasers =
{
{
.eraseblocks = {
{16 * 1024, 1},
{8 * 1024, 2},
{32 * 1024, 1},
{64 * 1024, 3},
},
.block_erase = erase_sector_jedec,
}, {
.eraseblocks = { {256 * 1024, 1} },
.block_erase = erase_chip_block_jedec,
},
},
Here the first eraser is "erase_sector_jedec", but it have really
complex "block size", is not one size, but a crazy list of sizes: 16
kiB, 8 kiB, 8 kiB, 32 kiB, 64 kiB, 64 kiB, 64 kiB
So I walk the list computing the beggining of each block and checking if
the address is inside it. From what I see in the link above your patch
uses a single size, the smallest.
One more thing to note - Be careful about interactions with the
proposed patch to read the current contents of flash from a file:
https://www.flashrom.org/pipermail/flashrom/2015-December/014034.html.
Specifically, make sure that the aligned offsets are used for reading
old content no matter if the old content is in a flash chip or a file.
Thanks. It looks compatible.
Regards, SET
--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina
_______________________________________________
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom
