DP83822I: Get to know about the revision name or number

Hello Evan,

Thank you for your quick response.

Yes, I managed to get the revision number by executing mii commands.

Is there any way to identify which specific revision (A, B, C, D, E, F, or G) is used?

I would like to determine the exact revision to resolve my current issue.

Thank you,

Rohit

Hi Rohith,

Revision mapping typically looks like:

0x3[3:0] = 0x0 = "A"

0x3[3:0] = 0x1 = "B"

...

For DP83822, I expect only revision "A" is released to market.
Expected value is 0x3 = 0xa240.

Is there a suspected DTS issue causing failure to recognize device in Uboot/Linux?

If so, please share the PHY address bootstraps and DTS file.

Thank you,

Evan

Hello Evan,

I appreciate your quick response.

Yes, I have received the exact value (0xA240) that you mentioned above.

=> mii read 1 0x0003

A240

We are using the latest revision of the IC, which is revision G, as confirmed by the date codes. Additionally, I checked the datasheet, and revision G is mentioned there.

I am uncertain as to why we are still receiving Revision A data while reading from register 0x003. Could you please provide some insights into this issue?

Thank you,

Rohith

Hi Rohith,

Datasheet revision history and dates do not correspond to PHY revision in this case.

We only expect 0x3 = 0xA240 (rev A)  for DP83822 ICs released to market. Sorry for the confusion here.

Could you please help me understand any functional issues faced relative to identifying the revision?

Thank you,

Evan

Hello Evan,

On the custom board, we have two Ethernet ports. We share the binaries over them. We are facing an issue while flashing the firmware. The transfer of the binaries occurs via a TFTP server.

The errors are:

=> tftp 0x80000000 binaries/1-ems_flash_nor_emmc.img; source 0x80000000

ethernet@44002000 Waiting for PHY auto negotiation to complete. done

Speed: 100, full duplex

Using ethernet@44002000 device

TFTP from server 192.168.1.30; our IP address is 192.168.1.50

Filename 'binaries/1-ems_flash_nor_emmc.img'.

Load address: 0x80000000

Loading: *

ARP Retry count exceeded; starting again

## Executing script at 80000000

Wrong image format for "source" command

=> mii device

MII devices: 'ethernet@44002000' 

Current device: 'ethernet@44002000'

=> mii device ethernet@44002000

=> mii read 1 0x0003

A240

We suspect there might be an issue with the PHY IC because when we placed the non-working board's IC on a working board, the working board also stopped functioning.

Thank you,

Rohith

Hi Rohith,

Is reading 0x3 = 0xA240 on the PHY a condition for the firmware to flash correctly?

It seems this could be a dead IC or separate hardware issue.

On the non-working board, could the resistance across PHY's RBIAS resistor be measured? This should be ~1V if the PHY is powered and alive.

Thank you,

Evan

Hello Evan,

Thank you for the quick response, and I apologize for the delayed reply.

No, there is no condition to check the PHY register value during flashing. We are reading it now because we suspect the IC and its revision.

We tried to read the PHY's RBIAS resistor. We are getting fluctuating values from 0.1 to 0.9V on non-working boards and a constant 0.9V on working ones.

Thank you,

Rohith

Hi Rohith,

Based on this thread and other ongoing discussions for the issue, I suspect a manufacturing issue related to PHY placement, power rails, or clock inputs.

When performing an ABA swap between working board vs. non-working board, please confirm that the issue consistently follows the suspected IC.

Thank you,

Evan