U-Boot Regulator Startup: A Voltage Range Does Not Select an Operating Point

A board description allows several output voltages, and the boot log says its regulator was enabled. Neither fact establishes which voltage U-Boot selected. In the v2025.01 regulator uclass, an unequal minimum and maximum constrain later requests but do not, by themselves, request a startup voltage. That matters when a peripheral depends on a particular approved setting before Linux takes ownership.

This is a source-level review of ordinary devicetree-backed regulator startup, not a power-rail adjustment procedure. The implementation is pinned to U-Boot v2025.01, commit 6d41f0a39d6423c8e57e92ebbe9f8c0333a63f72. Board-specific drivers, PMIC reset defaults, earlier firmware, and electrical limits remain separate inputs. No rail was programmed or measured for this article.

Separate three different descriptions of voltage

A minimum and maximum describe the admitted operating interval. A startup target describes a requested setting inside that interval. The actual supply voltage describes a physical condition. Treating these as interchangeable makes a valid-looking devicetree hide an incomplete power-up specification.

The regulator uclass implementation reads regulator-min-microvolt, regulator-max-microvolt, and regulator-init-microvolt separately in regulator_pre_probe. Missing bounds and a missing initial setting use the -ENODATA sentinel. The initialization routine sets REGULATOR_FLAG_AUTOSET_UV only when both bounds are present and equal.

Consequently, a permitted interval with different endpoints does not express “choose its minimum” or “choose its midpoint.” A product specification must say whether the bootloader should preserve an earlier approved setting or actively request one. Otherwise different PMIC reset configurations can produce different outcomes under the same interval.

Follow eligibility before discussing the target

The same uclass reads regulator-always-on and regulator-boot-on when binding the regulator. Either property requests probing after binding. Later, regulator_autoset handles suspend configuration and force-off policy before reaching its ordinary startup enable path.

For ordinary startup, a regulator with neither always-on nor boot-on is not automatically enabled by this path; autoset returns -EMEDIUMTYPE. A fixed regulator follows a separate enable-only branch. The voltage-selection discussion below therefore applies to the non-fixed, startup-eligible branch, not every node containing voltage properties.

This distinction prevents two incorrect repairs. Adding an initial-voltage property does not itself turn an unrelated disabled supply into an automatically enabled boot supply. Conversely, changing a variable regulator into a fixed-regulator description merely to obtain a simpler startup path is not a substitute for describing the actual hardware.

Read the two possible voltage requests in order

On the non-fixed branch, AUTOSET_UV causes a call to regulator_set_value with min_uV. Because that flag came from equal bounds, the automatic request represents that one constrained value. A positive init_uV then causes a second regulator_set_value call, regardless of whether the first voltage call succeeded.

The initial setting is therefore a later requested value, not a third constraint that silently narrows the allowed interval. When the bounds differ and no positive initial setting exists, neither of these two conditions requests a voltage. Autoset can proceed to current configuration and enabling without an explicit voltage-setting operation here.

The two-call case deserves careful error attribution. The second call assigns the same ret variable as the first. A later successful initial-voltage call can replace an earlier voltage error in that local result. A qualification trace should record each attempted value and result, rather than infer the complete sequence from autoset’s final return alone.

Do not use this detail to justify contradictory properties. With equal bounds, a different initial target will encounter the normal setter’s bounds checks. A coherent board description should make the intended target compatible with its declared constraints and the regulator driver’s supported output levels.

Understand what the setter checks and what it cannot prove

regulator_set_value rejects a requested scalar below a known minimum, above a known maximum, or equal to the missing-data sentinel. It then delegates to the provider’s set_value operation. This is not an interval-selection algorithm: the caller has already supplied one value.

The driver still determines how that request maps to its hardware. Inspect the selected provider for supported settings, rounding or rejection, register access, and error propagation. A successful generic call does not independently certify the voltage at the load, startup overshoot, output discharge, or the order in which dependent components leave reset.

The uclass can also apply a calculated ramp delay under specified conditions using its recorded ramp-rate property and available old-state information. That is software sequencing derived from metadata, not a measurement. Keep rail settling and load behavior in the board’s electrical qualification rather than treating elapsed software delay as conclusive evidence.

Build a non-energizing startup matrix first

A mock-provider review can distinguish the important cases without trying questionable voltages on a board. For an eligible adjustable regulator, propose unequal bounds with no initial target, equal bounds with no initial target, and unequal bounds with an approved symbolic initial target. Record the exact set_value and set_enable calls for each case.

Add an initial target outside the configured interval and verify that the common setter rejects it before the provider voltage callback. Include an unsupported provider setting inside the interval to distinguish framework admission from hardware capability. Those are different failure stages and should not collapse into one “bad voltage” label.

Finally, test the two-request branch with an injected first-call failure and a later success. The purpose is to verify diagnostic attribution, not to endorse that configuration. These fixtures are proposed tests; none were executed in preparing this article.

Deliver a startup contract, not just a node

The release record should connect the actual control devicetree, regulator type, startup eligibility, bounds, initial target, provider behavior, and the stage responsible for powering each load. If no voltage request is intended, document the earlier stage or reset configuration that establishes the approved starting condition.

Then qualify only board-approved settings under the applicable hardware procedure, retaining provider readback separately from physical measurements. The useful acceptance statement is precise: the startup path requested the intended operating point, or deliberately retained a documented one, before the dependent function ran. An allowed range and an enabled bit cannot establish that statement on their own.