LX2162A clearfog SFP+ optical transceivers not working

NXP LX2160
1

Hey!
I’m using LX2162A SOM (rev 1.1) + LX2162A Clearfog board (rev.2). So these are the most recent HW revisions for this time.
I connected and configured DAC cable to dpmac.5 and dpmac.6 (due to article https://solidrun.atlassian.net/wiki/spaces/developer/pages/199131187/ClearFog+LX2162A+Quick+Start+Guide) - and everything works ok. Both ethernet interfaces are up and running.
Then I did the same with SFP+ optical cable - linux was not able to read EEPROM inside SFP+ modules and the link was down:

[  504.572693] sfp sfp-at: please wait, module slow to respond
[  560.864692] sfp sfp-at: failed to read EEPROM: -6

I’ve found 2 HW bugs with LX2162A clearfog board:

  1. Low 3.3 voltage on the board. I got only 2.6V instead of 3.3V.
    Due to schematics 3.3V is passed through BAT54C diode D48 which has about 800mV forward voltage drop at 100mA:
    image
    So i have 3.3V at point 1 and 2.6V at point 3. This is extremely low for EEPROM inside SFP+ transceivers - thats why EEPROM is not functional. Also this 3.3V (2.6V in fact) is feeding usb hub + marvell phy chip (haven’t tested them yet).
    I’ve shorted points 1 and 3 on diode D48 and got true 3.3V on the board. After that linux was able to read EEPROM inside SFP+ module.
    But link was still down.

  2. TX_DISABLE (AT_TX_DIS) pin on SFP+ connector is left floating (not connected to anywhere).

    2
    21107×891 84.7 KB

This means that SFP+ transceiver is turned off. I tied this pin to ground and after that i got fully functional SFP+ optical connection.

@jnettlet - please address these bugs.

2

Your post has been forwarded to the hardware team.

3

Hello everyone.

I got into what it seems the same issue but with SFP28 DACs (10Gtek 25G SFP28 DAC 3-m). I looked into the board and SOM and found no printed hardware versions. I couldn’t find that information on u-boot either. No labels were found on the shipping box which have that information.

Once the OS is running, the voltage on the D48 pin 3 is around 2.6 V and I get the same error messages on dmesg and no connection (voltage drops to around 2.58 V). If I add a power supply on the ATX 3.3 V pin to raise the 3.3 V rail voltage to 2.7 (before attaching the SFP28), the error messages are gone (voltage drops to around 2.62 V) but I still get no comms. I also tested an optical transceiver, just to get the voltage reading and it reported 0.0 V. The same transceiver, on a PC, it reported 3.3 V. (ethtool -m ethX)

On the board I cannot find the path of TX_DISABLE to ground it and test. However, on u-boot, I am able to perform DHCP requests and those are received on a PC. On that state, the 3.3 V rail voltage is around 2.7 V (without power supply on ATX 3.3V hack) and I see two options for TX_DISABLE:

  • Current draw is lower than during OS runtime and the noise collected by the “open” TX_DISABLE path is low enough to make it to be evaluated as 0 (grounded);
  • The TX_DISABLE path is connected actually to some controller (GPIO/…) and it is incorrectly set by the OS.

I have a few questions:

  • Were this two issues solved on newer hardware releases?
  • It is actually shortening the pins 1 and 3 of D48 the correct way to move forward?
  • Solution for the TX_DISABLE path to get the SFP28 working correctly?
  • Where to get the hardware versions from?

Thanks.

4

Here is an errata from SolidRun with instructions and pictures

5

Actually, I will use this opportunity to suggest https://dev.solid-run.com/. We have worked hard to make it a much nicer documentation experience than the old atlassian site.