Ultrazed carrier board Ethernet LEDs not blinking

Mike,

Were you able to get your answer from your FAE?  This is what I told him when I was asked about this:

I spoke with some of our developers.

“I did something like this for MicroZed, but not any of the UltraZeds.  I was able to do it via the device tree to set the appropriate registers in the Ethernet PHY.  For example:

&gem0 {

       status = "okay";

    phy-handle = <&phy0>;

       phy-mode = "rgmii-id";

    phy0: phy@0 {

        compatible = "marvell,88e1510";

        device_type = "ethernet-phy";

        reg = <0x0>;

        /* linux,phandle = <0x5>; */

/* phandle = <0x5>; */

        /*

         * modify PHY registers to:

         * Reg 3_16

         * LED[1] bits [7:4] = ON=link, BLINK=activity, OFF=no activity

         * LED[0] bits [3:0] = link speed detect (3 blinks= 1Gbps, 2 blinks = 100Mbps, 1 blink = 10Mbps)

         * Reg 3_17

         * LED[1:0] = ON-drive low, OFF-high

         * Reg 3_18

         * LED[0] bits [3:2] = link speed LED blink off period = 170ms

         * LED[0] bits [1:0] = link speed LED blink on period = 340ms

         */

        marvell,reg-init = <3 16 0xff00 0x42>,

<3 17 0xfff0 0x0>,

<3 18 0xfff0 0x6>;

    };

};

“

It’s rather possible that we did not enable the LEDS as there is typically a default configuration that works.  When we run our factory test we do not normally look at LEDs of things like this – but focus on the ability of the hardware to communicate – which it did and passed.

That register configuration above is for the Marvell.  They would need to construct something similar that uses information the register map in this document: http://www.ti.com/lit/ds/symlink/dp83867ir.pdf

--Dan

Mike,

Were you able to get your answer from your FAE?  This is what I told him when I was asked about this:

I spoke with some of our developers.

“I did something like this for MicroZed, but not any of the UltraZeds.  I was able to do it via the device tree to set the appropriate registers in the Ethernet PHY.  For example:

&gem0 {

       status = "okay";

    phy-handle = <&phy0>;

       phy-mode = "rgmii-id";

    phy0: phy@0 {

        compatible = "marvell,88e1510";

        device_type = "ethernet-phy";

        reg = <0x0>;

        /* linux,phandle = <0x5>; */

/* phandle = <0x5>; */

        /*

         * modify PHY registers to:

         * Reg 3_16

         * LED[1] bits [7:4] = ON=link, BLINK=activity, OFF=no activity

         * LED[0] bits [3:0] = link speed detect (3 blinks= 1Gbps, 2 blinks = 100Mbps, 1 blink = 10Mbps)

         * Reg 3_17

         * LED[1:0] = ON-drive low, OFF-high

         * Reg 3_18

         * LED[0] bits [3:2] = link speed LED blink off period = 170ms

         * LED[0] bits [1:0] = link speed LED blink on period = 340ms

         */

        marvell,reg-init = <3 16 0xff00 0x42>,

<3 17 0xfff0 0x0>,

<3 18 0xfff0 0x6>;

    };

};

“

It’s rather possible that we did not enable the LEDS as there is typically a default configuration that works.  When we run our factory test we do not normally look at LEDs of things like this – but focus on the ability of the hardware to communicate – which it did and passed.

That register configuration above is for the Marvell.  They would need to construct something similar that uses information the register map in this document: http://www.ti.com/lit/ds/symlink/dp83867ir.pdf

--Dan

Hi Dan...Yes we did get that response from the FAE. I'm a hardware guy but I'm told by the software people who have looked into it that the driver for the TI PHY does not seem to support configuration of the LED control registers in the PHY. Looking at the defaults for those registers and the mode settings applied at reset, we believe there should be LED activity by default. It would be good if you could verify those findings. I wonder if those registers are getting a bad value somehow. We have a plan to use the SOM module with a carrier board of our own design and there will be a customer expectation to see the Ethernet LEDs blinking like most network equipment. I looked at the lines driving the two bipolar transistors on the carrier board and I don't see any activity; the base of the transistor is set high at 1.8V. We'll need to get to the bottom of this at some point. If you could dig into it a little more we would greatly appreciate it. Thanks...Mike

Mike,

Please follow up with your FAE and drive through him.  Due to the specific nature of this, I think it will get you a faster result.

--Dan

Ok. FWIW, we also have the Xilinx ZCU104 development board and that board does the same thing. Maybe some of the Ultrazed board HW/SW was cloned from the ZCU boards?

Mike,

Typically this is not the case.  We tend to design our own boards.  Sometimes there are overlapping features.

If the same MAC is on the ZCU104, and the Xilinx software folk did not program the registers either, then it would behave the same.  Even if it is a different model, you need to tell the part what you want.

Xilinx typically has different design constraints than my group and typically there is some overlap, however we do not straight copy the Xilinx designs.  We have an entire design department specifically for creating these boards and designs.  Of course there are times this seems to be the case, but sometimes there is only 1 way to wire something up (eMMC for example).

--Dan

Yep. Understood. Thanks Dan.