Request for info about LED on Linksys MX4200

innovara · December 11, 2024, 10:27am

The short story is that I am looking for fellow Linksys MX4200 owners who can provide a few bits of info about their devices for an issue with the LED I am troubleshooting.

You'd need to install i2c-tools with apk add i2c-tools or opkg install i2c-tools and post the output of;

i2cdetect -y 0
strings /dev/mtd20 | grep modelNumber
ls /sys/class/leds/

and whether it's a v1 or a v2 and if it's OEM or ISP-provided. Lastly, if the LED shows any other color apart from blue on OpenWrt. For example, it should go green when you are upgrading the firmware.

For example:

Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                                                 
10:                                                 
20:                                                 
30: -- -- -- -- -- -- -- --                         
40:                                                 
50: -- -- -- -- -- -- -- -- 58 -- -- -- 5c -- -- -- 
60:                                                 
70:

modelNumber=MX42BF-EU

ls /sys/class/leds/ shows nothing

I have an MX4200v2 ISP-provided. The model on the label is SPNMX42. The LED is always blue on OpenWRT and it's never shown any other color. It works normally on OEM firmware. I have another MX4200 with modelNumber=MX42CF-EU and the rest is the same.

The longer story is that it seems that the reg address used on target/linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8174-mx4200.dtsi for the pca9633 led controller is incorrect and it should be 0x58. Apart from the output of i2cdetect, and the fact that there are no leds under /sys/class/leds/, there are more clues on Linksys firmware to corroborate that theory. I am trying to establish if all MX4200 variants use this address on the i2c bus for the led controller, and the fix would apply to all, or it would need to be applied per variant.

When I use the address 0x58 the LEDs appear under /sys/class/leds/ but the led stays blue for around 35 seconds and then it goes off, seemingly when the router has fully boot up. It might be some OpenWrt configuration, I need to investigate that, but I would be grateful if you could share the above info with me. Thanks.

lytr · December 11, 2024, 11:32am

Nothing detected on MX8500:

root@MX8500:~# i2cdetect -a -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                                                 
10:                                                 
20:                                                 
30: -- -- -- -- -- -- -- --                         
40:                                                 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60:                                                 
70:

innovara · December 11, 2024, 11:44am

Is it possible that there are more than 1 i2c bus on the MX8500? ls /dev/i2c-*

NOTE: i2cdetect -a -y 0 was a copy/paste mistake, I meant to use i2cdetect -y 0

dannil · December 11, 2024, 12:15pm

I have a OEM MX4200V1 that I can run this on later today.

lytr · December 11, 2024, 1:46pm

Only one bus:

root@MX8500:~# i2cdetect -l
i2c-0	i2c       	QUP I2C adapter                 	I2C adapter

Output without -a is the same.

lytr · December 11, 2024, 2:05pm

Maybe you have a different controller?

 * LED driver for the PCA9633 I2C LED driver (7-bit slave address 0x62)
 * LED driver for the PCA9634/5 I2C LED driver (7-bit slave address set by hw.)

I can dump data after unload leds_pca963x driver:

root@MX8500:~# i2cdump -y 0 0x62 b
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 10 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
10: 10 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: 90 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
90: 90 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
a0: b0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
b0: b0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
c0: d0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
d0: d0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
e0: f0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX
f0: f0 21 00 ff 01 00 80 08 00 e2 e4 e8 e0 XX XX XX    ?!..?.??.????XXX

dannil · December 11, 2024, 2:49pm

I flashed 24.10.0-rc2 from the currently running SNAPSHOT r27687-b62e6f5beb (resetting to factory defaults) and almost immediately after I confirmed in LuCI, the pattern went:

LED started to blink green (from solid blue) for about 20-25 seconds
LED started to blink blue (from blinking green) for about 10 seconds, with the first 2 seconds of this duration blinking VERY FAST
LED went back to solid blue and LuCI refreshed itself after about 5 seconds

I then flashed 24.10.0-rc2 again (resetting to factory defaults) and the same pattern repeated, so at least on my OEM MX4200V1 the LED seems to behave correctly.

root@OpenWrt:~# i2cdetect -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

root@OpenWrt:~# strings /dev/mtd20 | grep modelNumber
modelNumber=MX42-EU

root@OpenWrt:~# ls /sys/class/leds/
blue:status   green:status  red:status

Also, here's the output of ubus call system board if it's needed. This is a spare unit so if more info is needed just holler, I can retest/reset/reflash it as many times as needed.

root@OpenWrt:~# ubus call system board
{
        "kernel": "6.6.63",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "Linksys MX4200v1",
        "board_name": "linksys,mx4200v1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.0-rc2",
                "revision": "r28161-ea17e958b9",
                "target": "qualcommax/ipq807x",
                "description": "OpenWrt 24.10.0-rc2 r28161-ea17e958b9",
                "builddate": "1733226068"
        }
}

lytr · December 11, 2024, 3:41pm

@innovara Can you try this config:

&blsp1_i2c2 {
	status = "okay";

	led-controller@62 {
		compatible = "nxp,pca9634";
		#address-cells = <1>;
		#size-cells = <0>;
		reg = <0x58>;
		nxp,hw-blink;

		led_system_red: led@0 {
			reg = <0>;
			color = <LED_COLOR_ID_RED>;
			function = LED_FUNCTION_STATUS;
		};

		led_system_green: led@1 {
			reg = <1>;
			color = <LED_COLOR_ID_GREEN>;
			function = LED_FUNCTION_STATUS;
		};

		led_system_blue: led@2 {
			reg = <2>;
			color = <LED_COLOR_ID_BLUE>;
			function = LED_FUNCTION_STATUS;
		};
	};
};

?

innovara · December 11, 2024, 7:48pm

Thanks for the output and the kind offer of further testing. Mine doesn't do any of that and it stays blue all the time. It seems that the MX4200v2, or at least the ISP-provided version SPNMX42, uses another controller. I am currently investigating this.

Yes, I think it's another controller and the PCA9634 is my first suspect at the moment.

Yeah, I've already tried that and a few combinations with PCA9634 (as well as PCA9633) but so far it's not working.

From what I can see in some of the scripts from OEM's firmware, it's possible that this controller has 8 LEDs which would support the speculation that it is the PCA9634. In /etc/leds/lib_nodes_hw.sh

# Nodes HW has following

LedColors="red green blue purple yellow cyan white rgb"

On those scripts they use i2cset extensively to set up the LED colors, pulse and so on. In fact I have been able to change the color using those. They don't do that on the firmware for MX4200v1.

The fact that they use i2cset on the MX4200v2 for a lot of the stuff instead of /sys/class/leds/ like they do on the MX4200v1 makes me wonder if they are using something that is not available upstream and they resorted to write directly to the controller.

Anyhow, I'll keep investigating and report back. I still would like to see the results of an OEM MX4200v2.

lytr · December 11, 2024, 10:27pm

It could be ST LED1202 controller: https://patches.linaro.org/project/linux-leds/patch/20241121165829.8210-4-vicentiu.galanopulo@remote-tech.co.uk/

v2 LED controller:
MX4200v2

v1 LED controller:
MX4200v1

innovara · December 11, 2024, 11:37pm

Possibly by the looks of it and also from the datasheet: https://www.st.com/resource/en/datasheet/led1202.pdf

Two different slave address types are available:
• Global address 5Ch (7-bit)
• Local address 58h to 5Bh and 5D to 60h (7-bit)

Which would match:

root@MX4200v2:~# i2cdetect -y 0
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                                                 
10:                                                 
20:                                                 
30: -- -- -- -- -- -- -- --                         
40:                                                 
50: -- -- -- -- -- -- -- -- 58 -- -- -- 5c -- -- -- 
60:                                                 
70:

innovara · December 12, 2024, 12:19pm

I've taken one of my MX4200v2 apart and the writing on the controller is Y347 1202 LED, so it is the ST LED1202.

The LED is RGB with red in the centre and green and blue at each side. You can individually turn them on with:

# red
i2cset -f -y 0 0x58 0x02 0x02
# green
i2cset -f -y 0 0x58 0x02 0x01
# blue
i2cset -f -y 0 0x58 0x02 0x04

The other colours that are seemingly predefined are obviously combinations of those three.

# purple
i2cset -f -y 0 0x58 0x02 0x06
# yellow
i2cset -f -y 0 0x58 0x02 0x03
# cyan
i2cset -f -y 0 0x58 0x02 0x05
# white-ish
i2cset -f -y 0 0x58 0x02 0x07

There are other addresses at the controller to manage power, patterns and whatnot. Rather advanced for a router I would say.

I'll investigate further the driver under development.