Actions
Forum Thread Details
  • State Not Answered
  • Replies 1 reply
  • Subscribers 353 subscribers
  • Views 292 views
  • Users 0 members are here
Related

Ultrazed phyaddr

Former Member

Hi

First of all I'm properly missing something elementary here.

But i need to ask.

UltraZed-EG SOM Hardware User Guide page 17 it states that the phyaddr of the Ethernet phy Texas Instruments DP83867 is "0001". I have checked the schematic and PCB and i can see R64 and R66 is not mounted which would set RX_D2 in mode 1 as described in the hardware user guide. Can only see that R60 and R62 is mounted so I assume they have the correct values and set RX_D0 in mode 2. So "0001" seems to be the correct phyaddr.

However I have now build my own u-boot and kernel from xilinx git latest  and can see that i have to set the phy addr to "0101" to communicate over the MDIO interface in u-boot. Furthermore the kernel device tree has to have the following entry for the phy handle:

    phyc: phy@5 {
        reg = <0x5>;
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
        ti,rxctrl-strap-worka;
    };

Again setting the phyaadr to 5 otherwise i get no Ethernet up.

Finally I can see from the supplied image on QSPI when booting in u-boot:

U-Boot 2016.01 (Nov 30 2016 - 22:15:40 -0700)

DRAM:  2 GiB
Enabling Caches...
EL Level:       EL2
MMC:   sdhci@ff160000: 0, sdhci@ff170000: 1
Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe() failed, using default environment

## Error: flags type check failure for "serverip" <= "AUTO" (type: i)
himport_r: can't insert "serverip=AUTO" into hash table
In:    serial
Out:   serial
Err:   serial
Bootmode: QSPI_MODE
Net:   ZYNQ GEM: ff0e0000, phyaddr 5, interface rgmii-id
eth0: ethernet@ff0e0000
U-BOOT for uz3eg-2016-2

 

Also indicating a phy addr of 5.

 

How can that be what I'm I missing is it a offset or something ??

 

Best regards

Esben

Parents
  • 0

    Hi Esben,

    Thanks for bringing this strange issue to our attention!  We are investigating this and so far we have found that the ZU+ device MIO pins connected to RX_D0, RX_D2 are somehow biasing the level of these nets during reset time (400 ms max as determined by Maxim MAX16025TE+ reset controller) which causes unexpected levels to appear on the level strapped pins which particularly affects any nets that are not currently biased by populated resistor dividers according to the levels indicated by the TI DP83867 datasheet.  This results in RX_D0 getting strapped at Mode 2 and RX_D2 getting strapped at Mode 3 which corresponds to address 0x05 as you are observing.  As you pointed out, that is unexpected but so far the lab observations do appear match the observed results.

    We are investigating whether RX_D2 can be assigned to a different voltage level value more predictably on our production Silicon UltraZed SOMs by utilizing the strapping resistors R64 and R66. 

    I will keep you posted on what we discover.

    Best Regards,

    -Kevin

Reply
  • 0

    Hi Esben,

    Thanks for bringing this strange issue to our attention!  We are investigating this and so far we have found that the ZU+ device MIO pins connected to RX_D0, RX_D2 are somehow biasing the level of these nets during reset time (400 ms max as determined by Maxim MAX16025TE+ reset controller) which causes unexpected levels to appear on the level strapped pins which particularly affects any nets that are not currently biased by populated resistor dividers according to the levels indicated by the TI DP83867 datasheet.  This results in RX_D0 getting strapped at Mode 2 and RX_D2 getting strapped at Mode 3 which corresponds to address 0x05 as you are observing.  As you pointed out, that is unexpected but so far the lab observations do appear match the observed results.

    We are investigating whether RX_D2 can be assigned to a different voltage level value more predictably on our production Silicon UltraZed SOMs by utilizing the strapping resistors R64 and R66. 

    I will keep you posted on what we discover.

    Best Regards,

    -Kevin

Children
No Data