Project Ideas

Streamline flash writes

We currently allocate 3x the flash-chip size on the heap by default. One time for the file contents to be written, one time to track the current flash chip contents, and another time to be able to tell if anything changed, should writing fail. This becomes worse and worse for embedded environments with our ever growing flash-chip sizes. Flashing a 64MiB image would at least need a system with 256MiB RAM.

Possible solutions (incomplete)

Use checksum to compare failure state

The third allocation is only used for a binary decision: Display a fatal or non-fatal help message. We could as well calculate a checksum over the original flash contents and compare that.

Allocate per touched erase block

The second allocation could be much smaller if we'd consider every erase block individually. This would mean we have to return to write per block first. Though, that should be a manageable refactoring. Downside: We still would have to allocate a full flash size if flashprog decides to erase the whole chip.

Split the write into smaller chunks

Instead of writing per erase-block as suggested above, split the write into a pre-defined chunk size. Overall probably more code, but might be cleaner and guarantees small allocations.

Use stream objects for the input

The first allocation for the data to be written is currently required because we want to keep the libflashprog API free from file i/o (not every environment has <stdio.h>). However, we could implement our own stream objects that can hide if the data comes from a file, memory, or maybe even the flash (e.g. if the objects would be used for reading as well).

Extend SFDP support

Update for new flashprog features

The SFDP support has fallen behind what we can currently express in our flash-chip database. For instance, 4-byte address support is missing. Soon there will be support for more read and write commands (dual, quad i/o). And there's even support for status/configuration bits in SFDP (may be enough to support block protection, though we'd have to evaluate that carefully).

Make more use of SFDP information

Currently, we either use an entry from out flash-chip database or the SFDP information. However, we could save us some of the maintenance hassle if we'd mix the two. Also, if we have multiple database entries for the same chip ID, we could use SFDP information to filter the results.