An i.MX8M Mini board using a DP83848 Ethernet PHY fails before useful MDIO register data is returned. The decisive evidence is the U-Boot response NULL device name! and No such device: <NULL>. This points first to missing or uninitialized U-Boot Ethernet/PHY integration, not to a confirmed DP83848 register-level failure.
Interpret the U-Boot Results
| Command or result | NXP EVK | DP83848 board | Engineering conclusion |
|---|---|---|---|
mii read 0-1 0-6 |
PHY address 0 returns register data; address 1 returns FFFF
|
NULL device name! |
The EVK has a usable U-Boot Ethernet device context. The custom board does not expose one to this command. |
mdio read 0 00 |
Reports bus FEC0, PHY address 0, and value 0x1000
|
Reports No such device and no bus name |
The failing trace does not identify a registered MDIO bus. |
mii info |
Reports PHY information at address 0x00
|
NULL device name! |
PHY discovery cannot proceed through the current U-Boot device configuration. |
The EVK values prove only that its MDIO path works. They are not expected DP83848 values and should not be used as acceptance criteria for the custom board.
Verify DP83848 Integration in U-Boot
The evidence identifies the DP83848 support path as natsemi.c under the U-Boot PHY drivers and specifically names dp83848_startup() as a debugging point. It does not provide the required configuration symbol, U-Boot version, device-tree properties, or board initialization code, so those identifiers must be taken from the exact U-Boot source tree used for the board rather than guessed.
- Confirm that the build includes the DP83848 implementation from
natsemi.c. - Confirm that board initialization registers and initializes the Ethernet controller and its MDIO bus before issuing
miiormdiocommands. - Trace PHY connection and startup until execution reaches
dp83848_startup(). If it never reaches that function, correct device registration, PHY binding, or initialization before investigating PHY registers. - After a bus and Ethernet device appear in U-Boot, scan the intended PHY addresses and read the identification registers supported by the active driver.
Separate Interface Mode from MDIO Access
The evidence asks whether mii and mdio commands operate independently of MII or RMII configuration, but it does not establish that behavior for this U-Boot build. The observed failure occurs at device lookup: U-Boot has no named device or bus for the command. Therefore, first restore Ethernet-device and MDIO-bus registration; only then can register reads distinguish a PHY-address, electrical, reset, or interface-configuration problem.
Do not interpret NULL device name! as proof that the DP83848 failed to answer on MDIO. The trace contains no valid DP83848 register transaction or returned register value.
Verify the Repair
Repeat the same command sequence after enabling and initializing the driver. A successful repair must replace the null-device messages with a named Ethernet device or MDIO bus and return register data for the configured PHY address. Then verify that PHY identification succeeds and that the startup path reaches dp83848_startup(). Linux-side register access should be attempted only after the Linux Ethernet controller, MDIO bus, and PHY driver are bound; the supplied evidence contains no Linux command or driver API that can be documented safely.
FAQ
Why does U-Boot mii read show NULL device name?
U-Boot has no usable Ethernet device context for the command. Confirm that the Ethernet controller, MDIO bus, and DP83848 support from natsemi.c are included and initialized.
Does NULL device name prove the DP83848 is not responding?
No. The failure occurs before the trace shows a valid DP83848 register transaction, so it cannot distinguish a nonresponding PHY from missing U-Boot device registration.
Where should I debug DP83848 startup in U-Boot?
Trace the DP83848 driver in natsemi.c and check whether execution reaches dp83848_startup(). If it does not, investigate controller registration, MDIO-bus initialization, and PHY binding first.