Icon: Add some SFDP ideas

2024-01-20T17:05:00Z

Add some SFDP ideas

← Older revision		Revision as of 17:05, 20 January 2024
Line 20:		Line 20:

	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).		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.

Icon: Describe "Streamline flash writes" ideas

2024-01-20T16:57:38Z

Describe "Streamline flash writes" ideas

New page

= 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).

Project Ideas - Revision history

Icon: Add some SFDP ideas

Icon: Describe "Streamline flash writes" ideas