U-Boot Ethernet Selection: Resolve ethact Before Relying on ethprime

A board with two Ethernet interfaces can keep using yesterday’s
active port even after its preferred-port variable changes. In U-Boot
v2025.01, ethprime, ethact and
ethrotate influence different decisions. They do not form
interchangeable names for one interface setting.

This article follows the driver-model Ethernet path and the
traditional network loop’s on-demand initialization. It excludes a
custom caller that bypasses that sequence and does not claim Linux will
keep the same interface names or numbering.

Preference
does not override an existing active choice

The environment
guide describes ethprime as the interface used first,
ethact as the active interface, and
ethrotate=no as disabling rotation through available
interfaces. To predict a particular network operation, also inspect the
caller and selection code.

In the traditional
network loop, on-demand initialization halts the current interface,
calls eth_set_current(), then initializes Ethernet. The
state-only path takes a different route, so this sequence should not be
generalized to every network entry point.

In eth_set_current,
a present ethact is resolved directly. The function
consults ethprime only when ethact is absent.
Updating the preferred interface while retaining an active-interface
variable therefore does not make this function choose the new
preference.

This also makes before-and-after evidence important. The
active-interface variable can be updated by the implementation as
selection changes; it is not necessarily an untouched copy of the
product’s original configuration.

Missing choices can lead
to a fallback

The driver-model
implementation resolves an interface by device name or an
eth sequence-number alias. Resolution probes candidate
devices and only returns one that successfully probes. A name written in
the environment is not sufficient evidence that the hardware is
usable.

If no current device is set, eth_get_dev() attempts
sequence zero and then a first-device fallback. The latter depends on
device/probe ordering rather than a physical connector label. A missing
preferred interface can consequently lead to a usable alternative rather
than preserving the intended port identity.

That fallback may be useful during interactive development but
surprising in a manufacturing test expected to qualify one connector.
Record the selected U-Boot device name and sequence against the board’s
physical port map, especially after a device-tree or driver change.

Rotation control
changes failure behavior

The shared eth_try_another() helper returns without
rotating only when ethrotate exactly equals
no. Unset values and other strings do not select that
branch. Do not treat every false-looking environment value as
equivalent.

The Ethernet initialization code has a related explicit-choice check:
when rotation is disabled and ethact exists, it resolves
that choice and returns an error if it cannot find it. It does not
simply accept an invalid name as a request to use whatever interface
works.

The current-change helper also avoids rewriting ethact
when rotation is disabled. Thus the variable’s behavior depends on
policy: with rotation allowed it can track changes, while the
disabled-rotation path preserves the explicit setting. Reading it
without recording the rotation policy leaves an important part of the
explanation out.

Test selection
separately from connectivity

A small qualification matrix can distinguish an absent active
variable, a valid active choice, an invalid active choice, and a missing
preferred interface. Exercise those cases with rotation allowed and
disabled, observing the actual selected device before attributing a DHCP
or transfer result to a connector.

A successful network transaction on an unintended fallback port does
not qualify the intended port. Equally, an explicit-choice lookup
failure is different from a link, address-assignment or server problem
after the correct interface was selected.

No environment variable, network setting or packet transfer was
changed for this article. The source-derived decision is to resolve
active selection first, preference only in its applicable branch, and
rotation as a separate fallback policy.