Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 342 subscribers
  • Views 852 views
  • Users 0 members are here
Related

Ethernet LEDs constant on and not blinking

Former Member

I seem to have the problem described in section 3.4 of http://zedboard.org/sites/default/files/documentations/MicroZed_RevBCF_Errata_140523a.pdf.  "Ethernet LEDs constant on and not blinking".  Once my Ethernet LEDs go on, they never go off (nor do they blink).

I have a Rev F board, but it must be one of these early ones.

The solution in the errata is to use MicroZed_Linux_sd_image_v1_1_131212.zip.  However, I want to use my own custom design.  How do I implement the fix in my design?  Where do I make the change?  Is there a hardware fix I should make?  Any guidance would be appreciated.

Thanks.

Parents
  • 0

    Hi asigint,

    The software fix is rather straightforward, we applied a change to the Linux devicetree reg-init string for Marvell PHY@0 so that the "LED[2:0] Polarity Control Register" is used in an alternate drive mode due to the addition of the isolation FETs added MOSFET buffer circuits noted in the MicroZed errata document.

    My best advise is that you can confirm the change yourself by comparing the two devicetree source files.  Here is the original reg-init string:

    marvell,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x0a>;

    As you pointed out per the errata for Rev. F boards, we changed over to using the MicroZed_Linux_sd_image_v1_1_131212.zip archive.  If you look within the devicetree-microzed-sdio125mhz-4gbram-PHY-LED.dts file included in the archive you will see the following reg-init string:

    marvell,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x00>;

    My apologies about being rather vague about this but unfortunately, the information that was used to formulate the fix (AKA the Marvell datasheet) is under material NDA.  If you need access to that datasheet, you will need to get the same NDA established with Marvell.  Your local Avnet/Silica FAE should be able to assist you with setting up the NDA.

    Regards,

    -Kevin

Reply
  • 0

    Hi asigint,

    The software fix is rather straightforward, we applied a change to the Linux devicetree reg-init string for Marvell PHY@0 so that the "LED[2:0] Polarity Control Register" is used in an alternate drive mode due to the addition of the isolation FETs added MOSFET buffer circuits noted in the MicroZed errata document.

    My best advise is that you can confirm the change yourself by comparing the two devicetree source files.  Here is the original reg-init string:

    marvell,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x0a>;

    As you pointed out per the errata for Rev. F boards, we changed over to using the MicroZed_Linux_sd_image_v1_1_131212.zip archive.  If you look within the devicetree-microzed-sdio125mhz-4gbram-PHY-LED.dts file included in the archive you will see the following reg-init string:

    marvell,reg-init = <3 16 0xff00 0x1e 3 17 0xfff0 0x00>;

    My apologies about being rather vague about this but unfortunately, the information that was used to formulate the fix (AKA the Marvell datasheet) is under material NDA.  If you need access to that datasheet, you will need to get the same NDA established with Marvell.  Your local Avnet/Silica FAE should be able to assist you with setting up the NDA.

    Regards,

    -Kevin

Children
  • 0 in reply to zedhed

    Kevin,

    Thanks!  That was it.  A really subtle change.  I did look through the new device tree but I completely missed that difference.  I applied that change and now the yellow light is flashing.

    Are the meaning of the lights documented somewhere?  The green light is now very weak (hard to be sure it is on), whereas without this change is was bright and solid (and clearly wrong).  So I'm now wondering if something else isn't quite right.  Can you point me in a direction to debug that?

    Thanks.

    Jerry