Attention is currently required from: David Bartley, Angel Pons.
View Change
1 comment:
File flashchips.c:
Patch Set #1, Line 17757: /* Full chip erase is fastest, typically takes 200s */
Fair enough, I can start a thread on the mailing list exploring options. […]
The problem is that there is no common use-case to tune the list for.
Placing smaller blocks first is better for smaller changes, placing
bigger blocks first is better for bigger changes. We don't know in
advance what to expect.
My idea how to re-arrange things:
- Add an optional function to the programmer drivers that can check if a command is expected to succeed (or rather fail, the most obvious example is Intel's internal programmer that can be configured to only allow a specific set of SPI commands). With such a function, the list of block erasers to consider can be filtered at runtime.
- Once we know the set of block erasers that is expected to work, we can apply a heuristic that chooses the biggest block that won't unnecessarily erase unchanged data. Or maybe with a threshold, e.g. prefer 64K over 4K if >80% of the 4K blocks would get erased.
Well, maybe there is one low-hanging fruit: For the erase commandline
option (-E), we could iterate over the list in reverse order?
To view, visit change 54968. To unsubscribe, or for help writing mail filters, visit settings.
Gerrit-Project: flashrom
Gerrit-Branch: master
Gerrit-Change-Id: If369409419332070c1fed96ce0e96b7cfe42c169
Gerrit-Change-Number: 54968
Gerrit-PatchSet: 4
Gerrit-Owner: David Bartley <andareed@gmail.com>
Gerrit-Reviewer: Nico Huber <nico.h@gmx.de>
Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit-CC: Angel Pons <th3fanbus@gmail.com>
Gerrit-Attention: David Bartley <andareed@gmail.com>
Gerrit-Attention: Angel Pons <th3fanbus@gmail.com>
Gerrit-Comment-Date: Fri, 11 Jun 2021 10:51:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: David Bartley <andareed@gmail.com>
Comment-In-Reply-To: Angel Pons <th3fanbus@gmail.com>
Gerrit-MessageType: comment