U-Boot AM335x Board Identity: Follow EEPROM Failure into Pinmux and DDR Selection

An unreadable board EEPROM does not necessarily stop early U-Boot
initialization. The important question is what each later hardware
selector does with the resulting invalid identity state.

Upstream U-Boot v2025.01’s TI AM335x support provides a concrete
example. With the normal SPL board-detection path enabled, an EEPROM
error can be reported while initialization continues into consumers with
different defaults. A Buildroot product using this code must review
those defaults against its actual hardware; an existing branch is not
evidence of a safe fallback.

Failure leaves a
defined identity state

The TI
EEPROM getter, ti_i2c_eeprom_am_get(), sets a
known-invalid header marker and clears the name, revision, serial and
configuration strings before reading. If the underlying read or format
check fails, it returns without replacing that invalid state with a
valid record.

The same file’s board_ti_is() rejects the invalid
marker. Consumers therefore do not simply keep matching an old board
name through that helper. Configuration-string consumers also see the
cleared string in this failed-read case.

This is format and state handling, not manufacturer authentication.
The cited path does not establish cryptographic provenance. A readable
record with a recognized header can still contain a name unsupported by
this board implementation.

The board wrapper
reports and continues

In AM335x
board.c, do_board_detect() prints an error when the
EEPROM getter fails. The wrapper is void and does not propagate a
failure status to its caller.

The AM33xx
early-init sequence calls detection when configured, then proceeds
through board-specific early setup and SDRAM initialization in the
normal SPL path. This is the point where a read failure becomes a policy
question: the source has reported it, but later configuration still
needs a decision.

Do not infer that the board actually boots successfully after this
failure. The following branches may select unsuitable hardware
parameters, and no such hardware experiment was performed here.

Pinmux and DDR
consume the state differently

The pinmux
selector checks recognized board predicates. Its final unknown-board
branch prints a warning and returns; it does not call
hang() in this tag. That does not reset all previously
configured pins, nor does it establish that the omitted board-specific
groups remain usable.

DDR selection has a concrete default. When its named predicates do
not match, get_dpll_ddr_params() selects the DDR2 266 MHz
clock parameters. sdram_init() likewise reaches a DDR2 266
MHz configuration branch with its default data and controller settings.
These functions are in the cited AM335x board implementation.

That default cannot be described as a universal reduced-speed
recovery mode. Changing memory generation and timing assumptions is more
than lowering a frequency. For a product whose intended identity selects
DDR3, an unreadable EEPROM needs an explicitly reviewed policy rather
than optimism about the final else branch.

Unknown names
and failed reads are separate cases

The board
predicates do not all inspect only the name. Some include revision
checks, while the IDK predicate examines a configuration prefix. A
readable but unfamiliar name with a nonempty configuration field can
therefore differ from the failed-read state in which all those fields
were cleared.

Use separate fixtures for a valid supported identity, a transport
failure, a bad header and a readable unsupported identity. For the last
case, specify every field used by a consumer. “Unknown name” alone is
not a complete input description.

The review output should list each consumer’s selected branch: board
pinmux, DDR clock and DDR timing. This is more informative than a single
board-name string printed later, if execution even reaches that
point.

Choose policy
before enabling the failure path

A product may stop before hardware-dependent configuration, enter a
recovery path that does not require the uncertain resources, or use a
fixed-SKU default proven compatible with its hardware. Those are design
alternatives, not guarantees supplied by this upstream
implementation.

Validate selector behavior first through code inspection or suitable
simulated fixtures. Avoid intentionally driving incompatible DDR
settings on production hardware merely to confirm a branch. Any eventual
fault-injection procedure needs board-specific recovery and electrical
review.

The source-derived lesson is precise: an invalid identity marker
prevents particular matches, but it does not by itself decide whether
startup should continue. Each hardware consumer must be included in that
decision.