U-Boot eMMC Partition Configuration: Separate Boot Selection from Data Access

An eMMC can expose its first boot area for ordinary block access
without selecting that area as its boot source. The reverse is also
possible: a boot area can be enabled for boot while U-Boot is accessing
the user area. Treating these as one “current partition” creates
misleading provisioning checks.

U-Boot v2025.01 represents both choices in fields associated with
PARTITION_CONFIG, but its commands and software bookkeeping
serve different purposes. This article traces those distinctions; it
does not prescribe register values for an unidentified board or execute
a provisioning operation.

Decode
three fields rather than one partition number

The MMC
command guide separates boot acknowledgement, boot-partition enable
and partition access. Boot-partition enable can identify a boot area,
the user area, or disabled boot. Partition access selects the area used
for data access.

A GPT or DOS partition number inside the user area is another
namespace. It is not an eMMC boot-area number. Record hardware area and
software partition separately when a manufacturing record says where a
boot image was placed.

Neither a successful read from a boot area nor the presence of a
valid image proves that the device is configured to supply that area
during the platform’s boot sequence. Conversely, enabling a boot area
does not place an image there. The board’s ROM behavior and boot wiring
still require platform-specific qualification.

Know what
the display and environment output contain

In mmc_partconf_print,
the command extracts the three displayed fields from
mmc->part_config. The display routine itself does not
issue a fresh EXT_CSD read. Its evidence is the cached configuration
available to that command invocation.

The optional environment-variable output is narrower still: it
receives only the extracted boot-partition-enable value. It is not the
complete configuration byte and does not include acknowledgement or
access bits. An automated comparison against a packed register value
will therefore compare different representations.

The same command file implements ordinary device selection through
mmc dev. Its hardware-partition argument is passed to the
block-device selection layer. That operation is a request to change the
data-access view, not a declaration that the newly accessed area should
become the boot source.

Follow the two update paths

The MMC
core’s partition-switch helper builds a switch value by retaining
the cached non-access bits and replacing the partition-access bits.
After the relevant result conditions, it updates the block descriptor’s
hardware-partition view and capacity. The ordinary successful-switch
case therefore has a different purpose from changing boot
enablement.

By contrast, mmc_set_part_conf
constructs a configuration from all three supplied fields and sends that
byte to the device. On success it updates
mmc->part_config. Supplying an access value alongside
boot enablement is part of a real configuration update; it is not merely
a display preference.

These functions also show why a diagnostic should identify which
state it observed. A block descriptor’s hwpart, the cached
configuration and a fresh device-register read are different evidence
sources. The access-switch helper does not assign its resulting access
selection back into mmc->part_config; do not infer that
every cached display necessarily mirrors every intervening access
switch.

Build a
provisioning record with separate assertions

For a disposable qualification device, distinguish the intended
boot-enabled area, the area used for writing, the image’s offset and
extent, and the final access view expected by subsequent commands.
Record how each assertion was obtained rather than reducing them to one
“partition OK” flag.

After an authorized configuration change, use an appropriate fresh
register observation and an independently verified image readback. A
cold-boot test then addresses the board-level boot path. None of these
checks substitutes for the others.

No register was changed for this analysis. In particular, unrelated
hardware-partition completion or reset-function settings are outside its
scope. The practical correction is to separate boot-source
configuration, block-access selection and payload placement before
approving an eMMC provisioning sequence.