This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Micrel 9031 on Phy address 0x0 is not working.

Other Parts Discussed in Thread: AM4378



I need guidance please to find the root cause of my problem.

Why our MIcrel 9031 PHY is working properly when the physical address is set to 0x2 and not when it is 0x0 (Means the hardware engneer set the Physical address to 0x2)?

We are using the Profile of the board am335x with ti-processor-sdk-linux-am335x-evm-02.00.00.00
PHY is properly identified but LINK remain down on eth0. Do you have an idea why this is behaving like this? Everything is working properly if we change the PHY address to 0x2 on the device (and also into the DTS).

[    1.543062] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.549193] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    1.556990] libphy: 4a101000.mdio: probed
[    1.561025] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
[    1.570832] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver Micrel KSZ9031 Gigabit PHY
[    1.581325] cpsw 4a100000.ethernet: Detected MACID = ec:24:b8:78:e2:36
[    1.588931] cpsw 4a100000.ethernet: cpsw: Detected MACID = d8:9c:da:cf:00:02

thanks

  • I will ask the Ethernet experts to look at this.
  • From the console log it looks like you have 2 PHYs, are you running in switch mode or dual mac mode? Could you also post the emac portion of your DTS file and also any changes you made to the am3xx.dtsi file?

    when you are changing the PHY address to 2 in the DTS file, the PHY are still scanning as 0 and 1?

  • Yes we have two MICREL 9031 PHY on addresses 0x0 and 0x1.

    We are using the original am33xx.dtsi as-is with no modification, same for the am335x-evmsk.dts - we kept this orginal configuration as-is (concerning the ethernet, mdio and slaves).

    We have the same issue with u-boot. into u-boot, When the MICREL PHY is on physical addr 0x0 it is not working properly (not responding, we can read the registers but they are not updated by the PHY, link remain down), when we use physical address 0x2 suddenly we see, in u-boot, that mdio idenitfies a PHY on 0x0, on 0x1 and also on 0x2. (we dont have 3 PHY just 2 !), so something is happening on physical address 0x00 (broadcast address ? broadcast mode?).

    Below the actual DTS, I played with dual mac mode also, tried it with and without, and this didnt help.

    <sweiss@ubuntu-obelix dir="dts"/>$ git diff am33xx.dtsi
    diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
    index 3a74c2d..e32aa6d 100644
    --- a/arch/arm/boot/dts/am33xx.dtsi
    +++ b/arch/arm/boot/dts/am33xx.dtsi
    @@ -731,7 +731,7 @@
                            no_bd_ram = <0>;
                            rx_descs = <64>;
                            mac_control = <0x20>;
    -                       slaves = <2>;
    +                       slaves = <1>;
                            active_slave = <0>;
                            cpts_clock_mult = <0x80000000>;
                            cpts_clock_shift = <29>;
    <sweiss@ubuntu-obelix dir="dts"/>$ 
    
    
    INside the DTS:
    
    &mac {
        pinctrl-names = "default", "sleep";
        pinctrl-0 = <&cpsw_default>;
        pinctrl-1 = <&cpsw_sleep>;
    /*  dual_emac = <1>;*/
        status = "okay";
    };
    
    &davinci_mdio {
        pinctrl-names = "default", "sleep";
        pinctrl-0 = <&davinci_mdio_default>;
        pinctrl-1 = <&davinci_mdio_sleep>;
        status = "okay";
    /*Configuration of the MICREL */
        rxdv-skew-ps = <420>;/*0    =>    0+420 = 420 */
        txen-skew-ps = <60>; /*-360 => -360+420 = 60*/
    
        rxd0-skew-ps = <420>;/*0    =>    0+420 = 420 */
        rxd1-skew-ps = <420>;/*0    =>    0+420 = 420 */
        rxd2-skew-ps = <420>;/*0    =>    0+420 = 420 */
        rxd3-skew-ps = <420>;/*0    =>    0+420 = 420 */
    
        txd0-skew-ps = <60>;/*-360 => -360+420 = 60*/
        txd1-skew-ps = <60>;/*-360 => -360+420 = 60*/
        txd2-skew-ps = <60>;/*-360 => -360+420 = 60*/
        txd3-skew-ps = <60>;/*-360 => -360+420 = 60*/
    
        txc-skew-ps = <1740>;/*840 =>  840+900 = 1740*/
        rxc-skew-ps = <1500>;/*600 =>  600+900 = 1500*/
    };
    
    &cpsw_emac0 {
        phy_id = <&davinci_mdio>, <0>;
        phy-mode = "rgmii";
        dual_emac_res_vlan = <1>;
    };
    
    &cpsw_emac1 {
        phy_id = <&davinci_mdio>, <1>;
        phy-mode = "rgmii";
        dual_emac_res_vlan = <2>;
    };
    
    

    Is this section can be the root cause of my issues , what it means ?

                phy_sel: cpsw-phy-sel@44e10650 {
                    compatible = "ti,am3352-cpsw-phy-sel";
                    reg= <0x44e10650 0x4>;
                    reg-names = "gmii-sel";
                };

  • The thing I noticed here is that phy-mode must be rgmii-txid, the phy mode here might work but will most likely create a lot of errors due to the clocking. But that should not affect how many PHYs are being scanned.

    Is this showing up in the boot log? I added the third line....
    [ 1.561025] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
    [ 1.570832] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver Micrel KSZ9031 Gigabit PHY
    davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY

    Do you want dual mac or a switch?
  • With rgmii-txid it is not working, this was the default configuration and the PHY on address 0x0 was not showing Link-UP either.


    Below the output of the kernel start when we change the PHY address to 0x2:

    [    1.547047] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
    [    1.568049] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver Micrel KSZ9031 Gigabit PHY
    [    1.584606] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver Micrel KSZ9031 Gigabit PHY
    

    At the end of Linux startup I can see:

    Configuring network interfaces... [    9.305360] net eth0: initializing cpsw version 1.12 (0)
    [    9.558720] net eth0: phy found : id is : 0x221622
    udhcpc (v1.23.1) started
    Sending discover...
    Sending discover...
    [   13.553717] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
    Sending discover...
    No lease, forking to background
    done.

    and things are up and running.

    I changed this section in the DTS to have eth0 associated to PHY 0x2:

    &cpsw_emac0 {
        phy_id = <&davinci_mdio>, <2>;
        phy-mode = "rgmii";
        dual_emac_res_vlan = <1>;
    };
    

    My question is WHY this is not working when our PHY physical addr is 0x0

  • Hi,

    I saw the schematics you have posted on the other thread: e2e.ti.com/.../1767941 From it I can see that PHY reset is done by the AM335X WARMRESETn. The KSZ9031 datasheet (reset timings section) requires that PHY reset is released at least 10ms after PHY voltages have stabilized, and Note 2 further requires that after reset deassertion at least 100us must elapse before MDIO interface is activated. Please check if these requirements are fulfilled on your board. If your timing is on the edge this would explain why the PHY isn't recognized at address 0x0, but 0x1 and 0x2 are recognized.
  • This is identical to the Am355x EVM SK Schematics.
    processors.wiki.ti.com/.../TMDSSK3358_3H0009_REV1_2B_SCH_PDF.pdf

    An in the PHY used there same NOTES are appearing:
    AR8031
    NOTE: When using crystal, clock is generated internally after the power is stable. In order to get reliable
    power-on-reset, it is recommended to keep asserting the reset low signal long enough (10 ms) to ensure
    the clock is stable and clock-to-reset (1 ms) requirement is satisfied

    I am wrong ?
  • The part used in the Starter Kit is completely different from the one you are using. In my previous post I referred to the KSZ9031 datasheet, not to AR8031. However it's up to you whether to take my suggestion seriously.
  • I understood you refer to the KSZ9031, I just wanted to show you that the device we use has the same requirements than the previous one used for this board. I am considering seriously your suggestion, just want to understand it at 100% before starting to debug this. Actually for me changing back to the CPU-Board having PHY with addr 0x0 is a little bit complex (since its a delicate  physical change on the board), so I want to be sure what to check and what to do first.

    Actually I am getting this in u-boot:

    U-Boot# mii info 2

    PHY 0x02: OUI = 0x0885, Model = 0x22, Rev = 0x02, 1000baseT, FDX

    U-Boot# mii info 1

    PHY 0x01: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX

    U-Boot# mii info 0

    PHY 0x00: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX

    Why I am getting an Answer for "mii info 0" if I have no PHY with this address on my board actually ?

    and Proper MII status on 2 and 1

    U-Boot# mii dump 2 1

    1.     (796d)                 -- PHY status register --

     (8000:0000) 1.15    =     0    100BASE-T4 able

     (4000:4000) 1.14    =     1    100BASE-X  full duplex able

     (2000:2000) 1.13    =     1    100BASE-X  half duplex able

     (1000:1000) 1.12    =     1    10 Mbps    full duplex able

     (0800:0800) 1.11    =     1    10 Mbps    half duplex able

     (0400:0000) 1.10    =     0    100BASE-T2 full duplex able

     (0200:0000) 1. 9    =     0    100BASE-T2 half duplex able

     (0100:0100) 1. 8    =     1    extended status

     (0080:0000) 1. 7    =     0    (reserved)

     (0040:0040) 1. 6    =     1    MF preamble suppression

     (0020:0020) 1. 5    =     1    A/N complete

     (0010:0000) 1. 4    =     0    remote fault

     (0008:0008) 1. 3    =     1    A/N able

     (0004:0004) 1. 2    =     1    link status

     (0002:0000) 1. 1    =     0    jabber detect

     (0001:0001) 1. 0    =     1    extended capabilities

    Can you guide me to make u-boot working with this Specific PHY ? (In Linux kernel DTS did the work but in u-boot, even after changing the am335x/board.c)

    with this it's not helping, dhcp is failing and link is identified to zero.

    static struct cpsw_slave_data cpsw_slaves[] = {
        {
            .slave_reg_ofs  = 0x208,
            .sliver_reg_ofs = 0xd80,
            .phy_addr   = 2,
        },

  • From what I am able to gather from the schematic and previous posts it appears that the reason the you are not getting a DCHP address in U-Boot is because the first interface has the PHY on it that is not completing auto negotiation and therefore no link establishment. U-Boot on the AM335x and rest of the series only uses the first port for Ethernet connectivity and since that  PHY  that appears to be not negotiating is on the first interface which is probably the problem.

    The PHY should auto negotiation without any input from the processor. It is strange that you are seeing multiple PHYs for one address,

    Could you please post the results of the following commands:

    mii info      - this will list the PHYS from U-Boot perspective

    mii info 0 1     - this looking at if auto negotiation completed A/N and link status for the PHY answering to address 0

    mii info 1 1     - same as previous command for the PHY answering to address 1

    In the case of the auto-negotiation fail you will need to contact the PHY provider for reasons why the PHY is not completing auto-negotiation. 

  • Good news,

    To recapitulate: on the actual Board we changed the PHY address of PHY0 to address 0x2, the second PHY is with address 0x1 (as always).
    The First PHY is connected to the Sitara SOC like it is described in the Scehmatic above. We can see clearly below that this PHY respond properly and
    proceed for negotiation properly since the Link is UP and the Speed is detected as 1Gb

    By chance, the PHY started to work under u-boot. Below the print screen. BTW, this is not consistent...After 'reset' in u-boot, I didnt succeed to make the PHY working again....(probably power down could help, I will check this on sunday, since I have not physical access to the machine, I am working remotly)

    So now, my original question is remaining:
    What could be the configuration mistake we made which prevent PHY0 to work properly with physical address 0x0?
    (Actually using physical address 0x2 for PHY0 is fully working in Linux (using proper DTA conf) and show good signs in u-boot), with PHY address 0x0 nothing work, not in Linux neither in u-boot , no link-up, no negotiation...nothing.... like the address MDIO 0x0 is eclipsing the real PHY standing there.

    U-Boot# mii info
    PHY 0x00: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX
    PHY 0x01: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX
    PHY 0x02: OUI = 0x0885, Model = 0x22, Rev = 0x02, 1000baseT, FDX
    U-Boot# mii info 01
    PHY 0x01: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX
    U-Boot# mii info 0 1
    PHY 0x00: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX
    U-Boot# mii info 1 1
    PHY 0x01: OUI = 0x0885, Model = 0x22, Rev = 0x02,  10baseT, HDX
    U-Boot# mii info 2 1
    PHY 0x02: OUI = 0x0885, Model = 0x22, Rev = 0x02, 1000baseT, FDX
    

    U-Boot#
    U-Boot# dhcp
    slave_num:0 phy_mask is 4
    ksz90xx_startup
    phy_ctl = 349
    phydev->speed  1000  (10=10,100=100,1000=1000)
    phydev->duplex  1 (half=0,full=1)
    link up on port 0, speed 1000, full duplex
    BOOTP broadcast 1
    BOOTP broadcast 2
    BOOTP broadcast 3
    BOOTP broadcast 4
    DHCP client bound to address 192.168.0.9 (2266 ms)
    Using cpsw device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.9
    Filename 'zImage'.
    Load address: 0x82000000
    Loading: T T T
    Abort
    U-Boot# setenv ipaddr 192.168.0.9
    U-Boot# ping 192.168.0.1
    slave_num:0 phy_mask is 4
    ksz90xx_startup
    phy_ctl = 348
    phydev->speed  1000  (10=10,100=100,1000=1000)
    phydev->duplex  1 (half=0,full=1)
    link up on port 0, speed 1000, full duplex
    Using cpsw device
    host 192.168.0.1 is alive



  • I agree with Biser here. The Micrel data manual is quite clear in that the reset and power-up requirements are critical for proper latching of the PHY address. It also appears from a cursory Google search that others have run into this same problem when switching PHYs to the Micrel.

    Please refer to Figure 16 in the Micrel data manual for power-up, reset, and MDIO access timing requirements and ensure that your design is meeting them.

  • OK, lets go for it, do you know well the code of u-boot in order to point me to the place of those initializations ?
    Do we have the control of this power up sequence in u-boot ?
    thanks in advance.
  • I need to apologize since I did a cut and paste error earlier in the thread. I wanted to ask you to do mii dump instead of mii info.

    mii dump 0 1 - this is looking at if auto negotiation completed A/N and link status for the PHY answering to address 0

    mii dump 1 1 - same as previous command for the PHY answering to address 1

    Looking at your response though it looks like you are getting auto negotiation on power up and a link is obtained. To answer your question on control of the power up sequence, to my knowledge there is not this type of control in u-boot.
  • below the info you asked.

    About MICREL PHY, Some of the TI guy wrote me this (in this thread: ):

    "Note that the Sitara AM4378 GP EVM and AM4378 Starterkit do use the KSZ9031RN PHY. It might be a good comparison point".

    Is it meaning u-boot and linux kernel are booting properly with MICREL, Meaning that they probably fixed the issue of the Power up timing , right ?

    If you have an idea how to find the relevant code fixing the timing issue, I will be very recognized. I am also digging deeper there...

    :

    U-Boot# mii dump 0 1
    1.     (7949)                 -- PHY status register --
      (8000:0000) 1.15    =     0    100BASE-T4 able
      (4000:4000) 1.14    =     1    100BASE-X  full duplex able
      (2000:2000) 1.13    =     1    100BASE-X  half duplex able
      (1000:1000) 1.12    =     1    10 Mbps    full duplex able
      (0800:0800) 1.11    =     1    10 Mbps    half duplex able
      (0400:0000) 1.10    =     0    100BASE-T2 full duplex able
      (0200:0000) 1. 9    =     0    100BASE-T2 half duplex able
      (0100:0100) 1. 8    =     1    extended status
      (0080:0000) 1. 7    =     0    (reserved)
      (0040:0040) 1. 6    =     1    MF preamble suppression
      (0020:0000) 1. 5    =     0    A/N complete
      (0010:0000) 1. 4    =     0    remote fault
      (0008:0008) 1. 3    =     1    A/N able
      (0004:0000) 1. 2    =     0    link status
      (0002:0000) 1. 1    =     0    jabber detect
      (0001:0001) 1. 0    =     1    extended capabilities
    
    U-Boot# mii dump 1 1
    1.     (7949)                 -- PHY status register --
      (8000:0000) 1.15    =     0    100BASE-T4 able
      (4000:4000) 1.14    =     1    100BASE-X  full duplex able
      (2000:2000) 1.13    =     1    100BASE-X  half duplex able
      (1000:1000) 1.12    =     1    10 Mbps    full duplex able
      (0800:0800) 1.11    =     1    10 Mbps    half duplex able
      (0400:0000) 1.10    =     0    100BASE-T2 full duplex able
      (0200:0000) 1. 9    =     0    100BASE-T2 half duplex able
      (0100:0100) 1. 8    =     1    extended status
      (0080:0000) 1. 7    =     0    (reserved)
      (0040:0040) 1. 6    =     1    MF preamble suppression
      (0020:0000) 1. 5    =     0    A/N complete
      (0010:0000) 1. 4    =     0    remote fault
      (0008:0008) 1. 3    =     1    A/N able
      (0004:0000) 1. 2    =     0    link status
      (0002:0000) 1. 1    =     0    jabber detect
      (0001:0001) 1. 0    =     1    extended capabilities
    

  • There is not any code to my knowledge in U-Boot that could affect power up timing in general.

    Does mii dump 2 1 show the phy connected after a reset?

    The console log showed an ip address was provided, but the three Ts are timeout indicators. Usually this means a tftp server is not running, in this case if would be 192.168.0.1