Attention is currently required from: David Bartley, Nico Huber.

View Change

1 comment:

• File flashchips.c:

  • Patch Set #1, Line 17757: /* Full chip erase is fastest, typically takes 200s */

    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.

    I don't know how hard implementing this would be, but I'd try to decide which block erasers to use depending on what needs to be erased. For example, a 96K contiguous region that starts/ends at a 64K boundary could be erased using a 64K erase command and a 32K erase command.

    Well, maybe there is one low-hanging fruit: For the erase commandline
    option (-E), we could iterate over the list in reverse order?

    Sounds like a very good idea. Do we have to account for region erases, though?

To view, visit change 54968. To unsubscribe, or for help writing mail filters, visit settings.