U-Boot DHCP Success: Prove an Artifact Was Retrieved Before Calling Network Boot Ready

A boot log reports an assigned IP address and the DHCP command
returns successfully, but the expected image is not in memory. Those
observations are compatible with a configuration-only network operation.
Treating them as a completed download sends the investigation toward the
image parser before the transfer has even occurred.

This article follows the IPv4 BOOTP/DHCP and network-command paths in
U-Boot v2025.01. It applies to the bootloader selected for a Buildroot
product with the relevant network features enabled. IPv6, HTTP-specific
loaders and board-customized protocols need their own review.

Read the message at its
actual boundary

The DHCP handler processes the acknowledgment, stores network
parameters, marks the client bound and prints the assigned-address
message. It then calls net_auto_load(). The tagged
DHCP implementation therefore places that message before the
subsequent automatic-load decision.

A useful incident record preserves the lines after address
assignment. Did the bootloader announce a transfer? Which server and
filename did it use? Did it report a completed byte count, return to the
command interpreter or enter another boot stage? The IP address is
evidence for one step, not a substitute for these later
observations.

Keep the reset condition with the log. A previous successful download
can leave plausible bytes at the same address, while a later
configuration-only attempt changes network settings without replacing
those bytes. Looking at memory alone can accidentally validate the
earlier attempt.

Configuration-only
success is deliberate

In net_auto_load(),
a false autoload setting causes the network loop to report
success without starting TFTP. The same function has separate NFS and
TFTP branches under their build conditions. This is intentional
behavior, not necessarily a transport defect.

The command wrapper makes the boundary even clearer. In netboot_common(),
a negative network-loop result becomes command failure. A zero size,
however, returns command success after the network environment update,
with no file loaded. A positive result reaches the optional
automatic-start handling.

Consequently, the command return value must be interpreted together
with the requested mode and transfer evidence. A configuration-only
command can succeed correctly. A download requirement needs additional
proof that a fresh transfer completed with an acceptable extent and
artifact identity.

Resolve the server
and filename explicitly

Do not assume the DHCP server and the artifact server are necessarily
the same endpoint. Record the actual server selected for the transfer,
the filename and the relevant build options. The DHCP code has
configuration-controlled behavior for accepting server information,
including CONFIG_BOOTP_SERVERIP and the preference for an
existing server address.

Filename provenance also matters. The network command parser
distinguishes explicit filenames from values obtained through the
environment. The BOOTP parameter handling avoids replacing an explicitly
selected filename with the reply’s file field. A retained
bootfile value can be relevant when the current invocation
does not supply its own filename.

For the release worksheet, identify each input as a reviewed
constant, server-provided discovery or retained device setting. Record
the effective value after configuration. This turns “the network
selected something wrong” into a testable claim about one source and one
precedence rule.

Do not dump unrelated environment values into a support ticket. Keep
the evidence limited to the addresses, paths and policy inputs needed
for the incident, with private infrastructure details handled through
the product’s normal support process.

Keep transfer and
execution controls separate

A retrieval investigation should also establish whether a successful
load may automatically start an image. The command wrapper calls
bootm_maybe_autostart() only after a nonzero load result.
That is a later decision than automatic retrieval itself.

A controlled qualification fixture should use harmless,
distinguishable content and an execution policy appropriate for that
fixture. Preserve authentication requirements when progressing from
transfer checks to executable images. Do not make an unverified
production image bootable merely to simplify a network test.

Likewise, review destination capacity before a transfer. The network
reaching a server does not establish that the selected memory range is
safe, and a completed download does not prove that later decompression
or relocation fits. Those are separate acceptance checks rather than
reasons to skip the network evidence.

Build a boundary-focused
test matrix

Start with a configuration-only case and confirm that its expected
result explicitly says “no artifact retrieved.” Then run the approved
retrieval path against a known test artifact. Associate the command,
destination, actual transfer extent and content digest with that
specific attempt.

Add a server that supplies usable address configuration but an
unavailable artifact path. Add a reachable artifact server with a
deliberately missing file. Finally, test a retained filename or server
setting against the intended precedence. These cases reveal whether
failure is classified at configuration, selection or transfer rather
than collapsed into a generic boot failure.

Where safe instrumentation is available, give each attempt a unique
fixture identifier and preserve the complete result. Avoid treating old
output variables or old memory contents as fresh evidence after a
failure or zero-byte result. The exact variables updated by a chosen
protocol should be checked in that protocol’s implementation.

Report the strongest
supported result

An accurate status can say that address configuration succeeded, that
a particular artifact was retrieved, or that the verified image reached
the next stage. Those statements require different evidence and should
remain distinguishable in factory logs and field diagnostics.

No network traffic or board tests were executed for this article. Its
practical recommendation is to qualify the boundaries independently so
that a successful DHCP exchange cannot silently become a false claim of
network-boot readiness.