U-Boot Fastboot Sparse Images: DONT_CARE Chunks Do Not Clear Existing MMC Data

A successful sparse-image flash does not imply that every byte in the
image’s expanded range was rewritten. In U-Boot v2025.01’s ordinary
fastboot MMC partition path, a DONT_CARE chunk advances the
destination position without issuing a write or erase for that
chunk.

This matters when comparing a partition dump with a fully
materialized image, preparing repeatable factory fixtures, or deciding
whether old content has been removed. An unspecified sparse region is
not an instruction to fill that region with zeroes.

Follow the selected
storage callback

The fastboot
guide lists flash and erase as separate supported operations when
configured. Their separation is visible in the MMC
backend: the ordinary sparse-flash branch constructs storage
callbacks and calls write_sparse_image(). It does not first
erase the complete selected partition.

The sparse writer receives the partition’s start, size and block
size. Its write callback submits MMC block writes. Its reserve callback,
fb_mmc_sparse_reserve(), simply returns the requested block
count. It performs no storage operation.

Scope matters here. Special boot-partition, partition-table and other
dedicated fastboot paths are outside this explanation. So are NAND and
downstream backends with different reserve callbacks. The conclusion
follows from the selected MMC callback, not from the word “sparse”
alone.

Distinguish RAW, FILL and
DONT_CARE

The sparse-image
implementation handles these chunk types differently:

• RAW supplies bytes that are written through the
  backend.
• FILL supplies a repeated pattern that the writer
  materializes and writes.
• DONT_CARE calls the reserve callback and advances the
  destination by its returned block count.

For this MMC backend, the third operation skips the range. Existing
bytes can therefore remain there when no separate operation changes
them. A zero-filled FILL chunk and a DONT_CARE
chunk are not equivalent storage requests.

Keep three sizes in
the verification record

Record the downloaded sparse-file length, the expanded logical block
span and the bytes actually written by the sparse writer. They describe
different quantities.

The sparse format’s block size must be a multiple of the storage
backend’s block size in this implementation. Chunk lengths are converted
into backend blocks before destination progression. Do not treat the
downloaded file length as the final occupied address range.

The writer’s printed byte count increases for RAW and FILL data.
DONT_CARE advances its logical block accounting without increasing that
written-byte count. A smaller count can thus be expected, rather than
proof of an incomplete transfer. Conversely, a successful final logical
block-count check does not prove that every logical block received new
bytes.

Design a
comparison that respects unspecified regions

For a proposed disposable fixture, prepare distinct known contents in
three adjacent ranges and use a well-formed sparse image containing RAW,
DONT_CARE and FILL chunks. Verify the written ranges against their
supplied data and inspect the skipped range separately. Capture which
backend was selected and whether any preparation step erased or rewrote
the partition.

Do not report the hypothetical skipped-range result as measured here.
No fastboot client, MMC write or erase was executed for this
article.

A whole-partition digest may differ between two devices whose
specified sparse chunks were programmed identically, because their
skipped regions began with different bytes. Decide whether the product’s
verification contract covers only specified content or requires a
deterministic complete partition image. If the latter is required,
define the complete-content preparation explicitly and qualify its
storage behavior.

Likewise, do not present sparse flashing as a data-sanitization
procedure. A successful response describes the implemented flash
request, not removal of prior contents from every physical or logical
region. The engineering decision is whether unspecified regions may
retain their previous state; the image-generation and qualification
process must agree on that answer.