I do not have a data sheet for this chip and could not find one on the Internet. I mean, it is not that I want something special. The ACT-LED is not working out of the box. And telling the customer to fix it himself is not very nice.
Have you solved it?
I am working on it: I have to get a data sheet for the PHY from Broadcom first. They require an NDA and told me it may take a while to get clearance …
regardless what I change in the broadcom.c driver, the LED behavior does not change. Are you sure this is the driver used on TX2?
Please try with my patch.
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index dbcfa1b..b965df8 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -307,6 +307,19 @@ static int bcm54xx_config_init(struct phy_device *phydev)
return err;
}
+ bcm_phy_write_shadow(phydev, BCM89610_SHD_LEDS1,
+ BCM89610_SHD_LEDS1_LED2(BCM_LED_SRC_ACTIVITYLED) |
+ BCM89610_SHD_LEDS1_LED1(BCM_LED_SRC_ACTIVITYLED));
+
+ bcm_phy_write_shadow(phydev, BCM89610_SHD_LEDS2,
+ BCM89610_SHD_LEDS2_LED4(BCM_LED_SRC_ACTIVITYLED) |
+ BCM89610_SHD_LEDS2_LED3(BCM_LED_SRC_ACTIVITYLED));
+
bcm54xx_phydsp_config(phydev);
return 0;
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 38f8648..a430c35 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -175,6 +175,17 @@
+#define BCM89610_SHD_LEDS1 0x0d
+#define BCM89610_SHD_LEDS1_LED2(src) ((src & 0xf) << 4)
+#define BCM89610_SHD_LEDS1_LED1(src) ((src & 0xf) << 0)
+
+#define BCM89610_SHD_LEDS2 0x0e
+#define BCM89610_SHD_LEDS2_LED4(src) ((src & 0xf) << 4)
+#define BCM89610_SHD_LEDS2_LED3(src) ((src & 0xf) << 0)
Thanks WayneWWW!
Almost there - with the patch I get the Activity on the LED1 but LED2 stays dark.
I tried to modify
-
bcm_phy_write_shadow(phydev, BCM89610_SHD_LEDS1, -
BCM89610_SHD_LEDS1_LED2(BCM_LED_SRC_LINKSPD2) | -
BCM89610_SHD_LEDS1_LED1(BCM_LED_SRC_ACTIVITYLED));
but now both LEDs are blinking activity. I wanted LED2 to come on whenever there is a 100BASE or 1000BASE link.
I got the same behavior on our carrier board. One LED is connected to GBE_LINK_ACT#, the other one to GBE_LINK_100#. The one connected to GBE_LINK_ACT# is on after attaching the ethernet cable. The other LED is always off. I also probed the GBE_LINK_1000# and could see the activity signal. So it seems that the signals are available, but on the wrong pins. Could you solve the output of the correct signals?
I think you guys are talking about the issue as I have faced with Jetson TX2 Module.
There are 3 LED outputs from the module:
GBE_LINK_ACT
GBE_LINK100
GBE_LINK1000
When operating at 1000Mbps/1G speed below is LED behavior.
GBE_LINK_ACT —> SOLID ON
GBE_LINK100 —> OFF
GBE_LINK1000 —> BLINKING
When operating at 100Mbps speed below is LED behavior.
GBE_LINK_ACT —> OFF
GBE_LINK100 —> SOLID ON
GBE_LINK1000 —> BLINKING
When operating at 10Mbps speed below is LED behavior.
GBE_LINK_ACT —> OFF
GBE_LINK100 —> OFF
GBE_LINK1000 —> BLINKING
I think somehow the GBE_LINK_ACT & GBE_LINK1000 behavior is swapped. If you do not want to change anything in the software, just swap the GBE_LINK1000 & GBE_LINK_ACT LEDs.
1 Like
I think we are having the same issue. On our custom carrier board we have connected the Ethernet LEDs identical to the developer kit schematics:
GBE_LINK_ACT (E47) => LED1 (GBE_LED0_SPICSB)
GBE_LINK100 (F50) => LED2 (GBE_LED1_SPISCK)
GBE_LINK1000 (F46) => OPEN / TEST POINT
When connected to Gigabit Ethernet I see the following behavior:
GBE_LINK_ACT: Low => LED1 on
GBE_LINK100: High 3V3 => LED2 off
GBE_LINK1000: Activity signal which looks like that:
[url]https://imgur.com/a/bxkLcgM[/url]
So obviously GBE_LINK_ACT and GBE_LINK1000 are swapped. So we have to decide whether we ship our product with the ACT-LED not working or change the hardware to follow the observed rather than the described behavior.
@WayneWWW: Is there any chance that this will be rectified by a future JetPack?
Of course we could adapt our hardware to the current behavior, but therefore we have to be sure that the behavior doesn’t change again in future kernel versions. The current behavior has to be considered as bug because it does not match with the hardware documentation. So either Nvidia fix it or modify the docs. An official statement from Nvidia on this issue would be nice, so that developers can consider it in their hardware designs.
Sorry that I haven’t looked into GBE LED for few months.
May I ask what is the status here? Does it turn out to be a TX2 hardware issue? Because this LED phy is actually set in broadcom driver, so I could only follow the spec from broadcom.
roshan.dsouza summarized the current behavior in post #28. You can reproduce it on the Jetson development kit. Looking at the schematics, GBE_LINK_ACT and GBE_LINK100 is connected to the ethernet LEDs, GBE_LINK1000 to test point 8. When an ethernet cable is plugged in, only one LED is on (I think the GBE_LINK_ACT). Probing the GBE_LINK1000 test point, one can see the activity signal. So these signals are somehow swapped.
I also tested the behavior with different Jetpack versions (3.0-3.3), it is always the same. So it doesn’t seem to be an software issue which was introduced in some release.
Maybe it is really a hardware issue on the Jetson module or a bug in the broadcom driver. Could you check that?
1 Like
MarkusHeß,
Sorry in advance for some questions here.
Is there any universal rules for such eth phy LED programming?
I would suggest to contact Broadcom for the specs and programming the driver to the mode you want.
There are lots of modes in that LED programming guide and I am not sure which one is the one you want.
This user also has some question about the LED modes but it turned out he can program it w/o problem.
https://devtalk.nvidia.com/default/topic/1029103
If this turns out an issue on our hardware design, please let me know.
Thanks.
I think there is no universal rule. But it is written in the Jetson Module Datasheet that Pin E47 is GBE_LINK_ACT# and F46 is GBE_LINK1000#, therefore I would expect that Pin E47 is providing the activity signal and F46 the 1000Gb Link signal by default.
I want to have the mode that gives me the same behavior as it is written in the Jetson Module Datasheet:
GBE_LINK_ACT# - Activity
GBE_LINK1000# - Link 1000Gb/s
GBE_LINK100# - Link 100Gb/s
I will try to get the datasheet from Broadcom. But nevertheless imho it should work by default as specified in the Jetson datasheet. If you don’t want to fix this in the driver, you should at least change the pin names in the development docs to match their function. Otherwise it confuses developers who are designing their custom carrier board.
Unfortunately, no solution is provided in this thread.
We are looking into this issue. Once there is any news, I would let you know.
Thanks.
Thanks!
Btw I tried it yesterday with the TX1. There, the activity LED is working. So the issue only occurs on the TX2.
Yes, actually the interface and chip are different between tx1 and tx2.
Is there any news yet?
So far we can only assume that the documentation (TX2 Series Datasheet, OEM DG;…) is incorrect and pins E47 and F46 are swapped. Also from my plot of F46 (https://imgur.com/a/bxkLcgM) I can see that the signal is actually active-high. The documentation denotes all GBE_LINK signals as active-low (#).
Therefore, the actual pinning on the TX2 module is as follows:
Pin E47 = GBE_LINK1000# (not GBE_LINK_ACT#)
Pin F46 = GBE_LINK_ACT (not GBE_LINK1000#)
Pin F50 = GBE_LINK100# (as described)
So I guess I’m going to wire my RJ45 jack accordingly and include some 0R0 resistors in case this is changed in a future hardware revision (Jetson TX2 4GB / TX2i). Any confirmation or statement from NVIDIA would still be very helpful.
I really don’t understand why this issue isn’t getting resolved. Even the Ethernet link LEDs on the Jetson TX2 DevKit (P2597) aren’t working correctly.
Per checked with internal team. I think we have conclusion here.
-
The pin on devkit is as below setting.
E47: ENET_ACT_L → LED1 of phy, to control LED1 of ethernet connector.
F50: ENET_100_LED → LED2 of phy, to control LED2 of ethernet connector.
F46: ENET_1000_LED, not used -
According to the bcm data sheet of ethernet phy, it would require LED1~4 to fully control the LED status.
Based on these, I think that is why devkit cannot have fully LED status as you want.
Thanks for the update. However, they are different from our observations:
Pin | No Eth | 100Mbit/s | 1000Mbit/s
Name | connected | connected | connected
------------------------------------------
E47 | 3,3V | 3,3V | 0V => 1000Mbit Link
F50 | 3,3V | 0V | 3,3V => 100Mbit Link
F46 | 0V | blinking | blinking => Act-Signal
My conclusion is that F46 is connected to the activity signalling LED of the PHY. E47, despite being named “GBE_LINK_ACT#”, shows status of the 1000Mbit/s connection. Can you confirm that?
The signal descriptions for LED1~4 are not disclosed to me as the BCM54610 datasheet is under NDA. We’ve tried to get it but without success.