U-Boot Falcon Mode: Regenerate the Persisted Argument Snapshot When Boot Inputs Change

Changing a saved U-Boot environment value does not, by itself,
regenerate the argument snapshot loaded by a raw-MMC Falcon boot path.
That path can copy previously prepared argument bytes from configured
sectors while bypassing the U-Boot proper stage that would normally
prepare new arguments.

For a product using this mechanism, treat the persisted arguments as
a versioned boot artifact. A kernel, devicetree or boot-argument change
needs a decision about whether that artifact must also be regenerated
and deployed.

Identify the snapshot
producer

The Falcon
Mode guide distinguishes normal parameter preparation on each boot
from preparing a snapshot for SPL to load later. It also states that
spl export leaves the prepared data in RAM; writing it to
persistent media is a separate responsibility.

In the v2025.01
export implementation, the supported export paths invoke preparation
subcommands without transferring control to the kernel. The FDT path
reports the prepared address through fdtargsaddr and its
total size through fdtargslen. Those describe the RAM
result, not a completed storage update.

Do not substitute a previously remembered address or length. The
artifact can move or change size as its inputs change. Also, the
configured write-size comparison in this command prints a warning when
the FDT is larger; it is not a storage write or a hard capacity
enforcement step.

The tagged guide retains a warning that the FDT export path was
untested. Its presence is a reason to qualify the selected board
workflow, not evidence that every v2025.01 board supports a validated
export procedure. This article assumes a board-supported, independently
checked argument artifact.

Follow the raw-MMC consumer

In the SPL
MMC loader, the Falcon raw-OS path is conditional on
FALCON_BOOT_MMCSD. When the raw argument-sector option is
defined, mmc_load_image_raw_os() reads the configured
argument-sector count into
CONFIG_SPL_PAYLOAD_ARGS_ADDR.

The read must return the entire configured count or the function
reports a block-read failure. It then loads the OS image from the
configured kernel sector and checks the image’s OS classification. This
argument-loading step is a block copy; it does not rebuild the snapshot
from a newly saved bootargs string.

Board-specific preparation hooks or other boot paths can add behavior
outside this narrow sequence. Inspect those before claiming that no
later fixup exists. Likewise, the raw-OS attempt is selected through
spl_start_uboot(); its implementation is board-dependent,
rather than a universal promise that one environment variable selects
Falcon Mode.

Keep the deployed
set internally consistent

A deployment record should connect the kernel identity, the source DT
or ATAGS inputs, the arguments used during preparation, the resulting
snapshot length and the actual raw-sector layout. The sector count
controls how much SPL reads; the generated artifact’s length describes
how much meaningful data was prepared. They are related constraints, not
interchangeable units.

Changing only the environment can therefore leave two boot routes
with different inputs: a normal U-Boot route that prepares parameters
again and a Falcon route that loads the older snapshot. Comparing the
command lines or trees observed by the OS can reveal that mismatch, but
the comparison must identify which route actually booted.

No export, media write or target boot was executed here. A proposed
board qualification should preserve the generated snapshot, verify its
persisted bytes and confirm the arguments delivered by the selected
Falcon path. Include a controlled fallback check: the MMC loader may
continue toward U-Boot loading after an unsuccessful raw-OS attempt, so
a successful later boot alone does not prove that the snapshot path
worked.