WD MyCloud Mirror Gen2 (BWVZ, GrandTeton)

Quote

Yes, the device has a drive-detect gpio, but in the dts I cannot understand how to set the gpio to monitor.

Quote

sata1-blue {
label = "wdmcmg2:blue:detecthdd1";
gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "gpio";
linux,default-inverted = "1";
};

Try only default-trigger. If you used my patch:

		
Quote

sata1-blue {
			label = "wdmcmg2:blue:detecthdd1";
			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "ide-disk1";
		};

or if you did not use my patch:

linux,default-trigger = "disk-activity";

And make sure the active state is really GPIO_ACTIVE_HIGH. Some time it is GPIO_ACTIVE_LOW.

Quote

Typically I've seen those GPIOs configured as gpio-buttons in the device-tree. Once you have that setup you can cause them to trigger things using triggerhappy or similar.

Button should be a separate GPIO number. And I don't think it can be hooked to disk LED.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 03/31/2020 06:11PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
>

Quote

Yes, the device has a drive-detect gpio,
> but in the dts I cannot understand how to set the
> gpio to monitor.

>
>
>

Quote

sata1-blue {
> label = "wdmcmg2:blue:detecthdd1";
> gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
> linux,default-trigger = "gpio";
> linux,default-inverted = "1";
> };

Yes, already done, but is needed an additional parameter, the gpio pin raising the trigger that would change the led status.
The led itself is gpio1 21 (mpp53), the gpio to be monitored that will raise the trigger is gpio48 (gpio1 16).

I cannot set it in the DTS, but once the system boot I can enable the trigger running this command:

root@debian:~# echo 48 > /sys/class/leds/wdmcmg2\:blue\:hdd1/gpio

any hint?

CyberPK,

Quote

Yes, already done, but is needed an additional parameter, the gpio pin raising the trigger that would change the led status.
The led itself is gpio1 21 (mpp53), the gpio to be monitored that will raise the trigger is gpio48 (gpio1 16).

Ah. I believe this is the worst about using MCU in these boxes (probably to save a few bucks for the manufacturer), it makes things more complicated.

See the patch I have for the Kirkwood boxes

https://forum.doozan.com/read.php?2,12096

Quote

linux-5.5.1-kirkwood-tld-1.patch

The Zyxel NAS series has this clock. For example:

NSA325 (similar in NSA320 DTS):

Quote

pmx_mcu_data: pmx-mcu-data {
marvell,pins = "mpp14";
marvell,function = "gpio";
};

pmx_led_usb_green: pmx-led-usb-green {
marvell,pins = "mpp15";
marvell,function = "gpio";
};

pmx_mcu_clk: pmx-mcu-clk {
marvell,pins = "mpp16";
marvell,function = "gpio";
};

pmx_mcu_act: pmx-mcu-act {
marvell,pins = "mpp17";
marvell,function = "gpio";
};

So that's just an idea to try in your box. GPIO poke just not accepted when the clock is not also manipulated. If you can do it succesfully in the commandline, it means the clock was already raised.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Sorry, maybe I did not understand.

What I miss is only the way to add gpio48 (gpio1 16) in this snippet

> sata1-blue {
> label = "wdmcmg2:blue:detecthdd1";
> gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
> linux,default-trigger = "gpio";
> linux,default-inverted = "1";
> };

otherwise I have to set it in the rc.local

root@debian:~# echo 48 > /sys/class/leds/wdmcmg2\:blue\:hdd1/gpio

Exist any linux,default-gpio = "48"; ?

> Exist any linux,default-gpio = "48"; ?

No. That is the trigger name which is a text field. 48 means the GPIO1 16.

Try:

sata1-blue {
   label = "wdmcmg2:blue:detecthdd1";
   gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
   linux,default-trigger = "ide-disk1";
};

I think you should post the entire DTS here for review.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 04/02/2020 05:26AM by bodhi.

Sorry, I have not explained the problem well.

The disk activity through ide-disk1&2 is working good with your patch.
The above gpio is to sense the presence of the disk.

The expected result is to have the blue led poweron when the drive is inserted, and blink the red on disk activity

CyberPK ,

> The expected result is to have the blue led
> poweron when the drive is inserted, and blink the
> red on disk activity

OK I just took a look at the box front LEDs let me restate it in a way that I thought

Top to bottom:

Power/System LED
Sata1 LED
Sata2 LED

For Sata1 LED.

gpio1 21 (mpp53) is RED -- disk activity
gpio1 16 (mpp48) is BLUE -- disk present

The behavior of the stock Sata1 LED: it is always solid BLUE if there is an HDD inside on that slot, otherwise it is OFF. When there is disk activity, it flashes RED.

Did I describe it correctly?

If you could, post the entire DTS here or PM that file.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 04/02/2020 07:08PM by bodhi.

Top to bottom:

Power/System LED
Sata1 LED: Blue(mpp53), Red(mpp43)
Sata2 LED: Blue(mpp55), Red(mpp52)
in addition, disk1 present(mpp48) disk2 present(mpp58)

STOCK:
SataX led
BLUE: disk presence
BLUE blinking: disk activity
RED: Disk crashed

because I cannot drive the blue led with two trigger, decided to have Blue led triggered by the disk present gpio, and the red red triggered by disk activity

SataX led
BLUE: disk presence
RED blinking: disk activity

the problem is the gpio trigger for disk presence. I cannot set it in the DTS but I can in the rc.local

sata_leds: sata-leds {
					marvell,pins = "mpp43", "mpp52", "mpp53", "mpp54", "mpp48", "mpp58";
					marvell,function = "gpio";
				};

gpio-leds {
		compatible = "gpio-leds";
		pinctrl-names = "default";
		pinctrl-0 = <&sata_leds>;

		sata1-red-led {
			label = "wdmcmg2:red:hdd1";
			gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "ide-disk1";
			panic-indicator;
		};
		sata2-red-led {
			label = "wdmcmg2:red:hdd2";
			gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "ide-diks2";
			panic-indicator;
		};
		sata1-blue-led {
			label = "wdmcmg2:blue:hdd1";
			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "gpio";
			//linux,default-gpio = "58";
			linux,default-inverted = "1";
			//trigger-sources = <&gpio1 26 GPIO_ACTIVE_LOW>;
		};
		sata2-blue-led {
			label = "wdmcmg2:blue:hdd2";
			gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "gpio";
			//linux,default-gpio = "48";
			linux,default-inverted = "1";
			//trigger-sources = <&gpio1 16 GPIO_ACTIVE_LOW>;
		};
	};

Thank you!

CyberPK,

As I said, please post the entire DTS :)

The reason is the pin control. I want to see your pin control.

I usally asked users to post the entire serial console log. Not because I wanted to see their system info, I just need to see all info to be able to troubleshoot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/02/2020 10:12PM by bodhi.

Sorry, here you are and thank you

// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
 * Device Tree file for Western Digital My Cloud Mirror Gen 2
 * (BWVZ/Grand Teton)
 *
 * Copyright (C) 2020
 *
 * Based on the code from:
 *
 * Copyright (C) 2019 Evgeny Kolesnikov <evgenyz@gmail.com>
 * Copyright (C) 2016 Martin Mueller <mm@sig21.net>
 * Copyright (C) 2013 Gregory CLEMENT <gregory.clement@free-electrons.com>
 * Copyright (C) 2014 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 *
 */

/dts-v1/;
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>
#include "armada-385.dtsi"

/ {
	model = "WD MyCloud Mirror Gen 2 (BWVZ/Grand Teton)";
	compatible = "wd,mcmg2", "marvell,armada385", "marvell,armada380";

	chosen {
		stdout-path = "console=ttyS0,115200 root=LABEL=rootfs earlyprintk";
	};

	memory {
		device_type = "memory";
		reg = <0x00000000 0x20000000>; /* 512 MB */
	};

	soc {
		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000        /* CESA0: PHYS=0xf1100000 size 64K */
			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000        /* CESA1: PHYS=0xf1110000 */
			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000       /*    BM: PHYS=0xf1200000 size 1M */
			  MBUS_ID(0x0b, 0x04) 0 0xf1300000 0x100000>;     /*   PNC: PHYS=0xf1300000 size 1M */

		internal-regs {
			timer@c200 {
				status = "okay";
			};

			i2c@11000 {
				status = "disabled";
			};

			i2c@11100 {
				status = "disabled";
			};

			uart0: serial@12000 {
				status = "okay";
			};

			/* Connected to Welltrend 6703F-OG240WT MCU
			 * which controls power, fan and other things
			 */
			uart1: serial@12100 {
				status = "okay";
			};

			poweroff@12100 {
				compatible = "uart-poweroff";
				reg = <0x12100 0x100>;
				clocks = <&coreclk 0>;
				baud = <19200>;
				cmd = [fa 03 03 01 00 00 fb];
				status = "okay";
			};

			restart@12100 {
				compatible = "uart-restart";
				reg = <0x12100 0x100>;
				clocks = <&coreclk 0>;
				baud = <19200>;
				cmd = [fa 03 03 02 00 00 fb];
				override;
				status = "okay";
			};
			
			pinctrl: pinctrl@18000 {
				xhci0_vbus_pins: xhci0-vbus-pins {
					marvell,pins = "mpp26";
					marvell,function = "gpio";
				};

				xhci1_vbus_pins: xhci1-vbus-pins {
					marvell,pins = "mpp27";
					marvell,function = "gpio";
				};

				sata0_pins: sata-pins-0 {
					marvell,pins = "mpp55";
					marvell,function = "gpio";
				};

				sata1_pins: sata-pins-1 {
					marvell,pins = "mpp56";
					marvell,function = "gpio";
				};

				sata_leds: sata-leds {
					marvell,pins = "mpp43", "mpp52", "mpp53", "mpp54", "mpp48", "mpp58";
					marvell,function = "gpio";
				};

				btn_pins: btn-pins {
					marvell,pins = "mpp50";
					marvell,function = "gpio";
				};
			};

			usb0: usb@58000 {
				status = "okay";
			};

			eth2: ethernet@34000 {
				status = "okay";
				phy = <&phy0>;
				phy-mode = "sgmii";
				buffer-manager = <&bm>;
				bm,pool-long = <0>;
				bm,pool-short = <1>;
			};

			mdio: mdio@72004 {
				phy0: ethernet-phy@0 {
					/* Init ETH LEDs */
					marvell,reg-init = <3 16 0 0x101e>;
					reg = <0>;
				};
			};

			cesa: crypto@90000 {
				status = "okay";
			};

			rtc: rtc@a3800 {
				status = "okay";
			};

			ahci0: sata@a8000 {
				pinctrl-names = "default";
				pinctrl-0 = <&sata0_pins>, <&sata1_pins>;
				status = "okay";
				#address-cells = <1>;
				#size-cells = <0>;

				sata0: sata-port@0 {
					reg = <0>;
					target-supply = <&reg_sata0>;
				};

				sata1: sata-port@1 {
					reg = <1>;
					target-supply = <&reg_sata1>;
				};

			};

			bm: bm@c8000 {
				status = "okay";
			};

			nand_controller: nand-controller@d0000 {
				status = "okay";

				nand: nand@0 {
					reg = <0>;
					label = "pxa3xx_nand-0";
					nand-rb = <0>;
					marvell,nand-keep-config;
					#marvell,nand-enable-arbiter; //optional
					nand-on-flash-bbt;
					nand-ecc-strength = <4>;
					nand-ecc-step-size = <512>;

					partitions {
						compatible = "fixed-partitions";
						#address-cells = <1>;
						#size-cells = <1>;

						partition@00000000 {
							label = "U-Boot";
							reg = <0x00000000 0x00500000>;    /*   5 MB */
							read-only;
						};

						partition@00500000 {
							label = "uImage";
							reg = <0x00500000 0x00500000>;    /*   5 MB */
						};

						partition@00a00000 {
							label = "uRamdisk";
							reg = <0x00a00000 0x00500000>;    /*   5 MB */
						};
							
						partition@00f00000 {
							label = "image.cfs";
							reg = <0x00f00000 0x0b900000>;    /* 185 MB */
						};

						partition@c800000 {
							label = "rescue fw";
							reg = <0x0c800000 0x00f00000>;    /*  15 MB */
						};
							
						partition@d70000 {
							label = "config";
							reg = <0x0d700000 0x01400000>;    /*  20 MB */
						};
							
						partition@eb00000 {
							label = "reserve1";
							reg = <0x0eb00000 0x00a00000>;    /*  10 MB */
						};
							
						partition@f500000 {
							label = "reserve2";
							reg = <0x0f500000 0x00a00000>;    /*  10 MB */
						};
					};
				};
			};

			usb3_0: usb3@f0000 {
				usb-phy = <&usb3_0_phy>;
				status = "okay";
			};

			usb3_1: usb3@f8000 {
				usb-phy = <&usb3_1_phy>;
				status = "okay";
			};
		};

		bm_bppi: bm-bppi {
			status = "okay";
		};
	};

	gpio-leds {
		compatible = "gpio-leds";
		pinctrl-names = "default";
		pinctrl-0 = <&sata_leds>;

		sata1-red-led {
			label = "wdmcmg2:red:hdd1";
			gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "ide-disk1";
			panic-indicator;
		};
		sata2-red-led {
			label = "wdmcmg2:red:hdd2";
			gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "ide-diks2";
			panic-indicator;
		};
		sata1-blue-led {
			label = "wdmcmg2:blue:hdd1";
			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "gpio";
			//linux,default-gpio = "58";
			linux,default-inverted = "1";
			//trigger-sources = <&gpio1 26 GPIO_ACTIVE_LOW>;
		};
		sata2-blue-led {
			label = "wdmcmg2:blue:hdd2";
			gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "gpio";
			//linux,default-gpio = "48";
			linux,default-inverted = "1";
			//trigger-sources = <&gpio1 16 GPIO_ACTIVE_LOW>;
		};
	};

	gpio-keys {
		compatible = "gpio-keys";
		pinctrl-names = "default";
		pinctrl-0 = <&btn_pins>;
		#address-cells = <1>;
		#size-cells = <0>;

		reset {
			label = "reset";
			linux,code = <KEY_RESTART>;  // Restart=0x198, Power=0x116
			gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
			debounce-interval = <60>;
			wakeup-source;
		};
	};

	usb3_0_phy: usb3_0_phy {
		compatible = "usb-nop-xceiv";
		vcc-supply = <&reg_usb3_0_vbus>;
	};

	usb3_1_phy: usb3_1_phy {
		compatible = "usb-nop-xceiv";
		vcc-supply = <&reg_usb3_1_vbus>;
	};

	reg_usb3_0_vbus: usb3-vbus0 {
		compatible = "regulator-fixed";
		regulator-name = "usb3-vbus0";
		pinctrl-names = "default";
		pinctrl-0 = <&xhci0_vbus_pins>;
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		enable-active-high;
		regulator-always-on;
		gpio = <&gpio0 26 GPIO_ACTIVE_HIGH>;
	};

	reg_usb3_1_vbus: usb3-vbus1 {
		compatible = "regulator-fixed";
		regulator-name = "usb3-vbus1";
		pinctrl-names = "default";
		pinctrl-0 = <&xhci1_vbus_pins>;
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		enable-active-high;
		regulator-always-on;
		gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>;
	};

	reg_sata0: pwr-sata0 {
		compatible = "regulator-fixed";
		regulator-name = "pwr_en_sata0";
		regulator-min-microvolt = <12000000>;
		regulator-max-microvolt = <12000000>;
		enable-active-high;
		regulator-boot-on;
		gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>;
	};
	
	reg_sata1: pwr-sata1 {
		compatible = "regulator-fixed";
		regulator-name = "pwr_en_sata1";
		regulator-min-microvolt = <12000000>;
		regulator-max-microvolt = <12000000>;
		enable-active-high;
		regulator-boot-on;
		gpio = <&gpio1 24 GPIO_ACTIVE_HIGH>;
	};
};

here's a device tree using a drive detect gpio as a button as I described earlier:

https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Buster/device_trees/armada-370-linkstation-ls421d.dts

1000001101000 Wrote:
-------------------------------------------------------
> here's a device tree using a drive detect gpio as
> a button as I described earlier:
>
> https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Buster/device_trees/armada-370-linkstation-ls421d.dts


Thank you, to me it does not trigger the leds, but simply return the hard disk presence as a KEY_PROG1 and KEY_PROG2. I'm missing somethink?

As said before i'm tring to trigger the led poweron on gpio change. I can do it setting rc.local, but cannot directly in the dts

you can use triggerhappy to trigger a script whenever KEY_PROG1 changes. You could then have that script change the LED trigger or perform any other action that you'd like.

....though, thinking about it you'd likely want to run the script at startup as well since triggerhappy will only see when it changes.



Edited 1 time(s). Last edit at 04/03/2020 11:03AM by 1000001101000.

I don't need any script. In rc local I can enable the trigger with

echo 48 > /sys/class/leds/wdmcmg2\:blue\:hdd1/gpio

and the led start to sense the hdd insert

How this parameter can be set in the DTS (in addition to the led own gpio)?



Edited 1 time(s). Last edit at 04/03/2020 06:28PM by CyberPK.

sounds like you already have a working solution then.

I'm not familiar with this trigger but my guess for why it wouldn't work from setting it in the device tree is that the gpio-led module might be loaded before the module for that trigger resulting in the trigger not being set. Either that or there is something wrong/missing with that binding or how it's being used.

I think I ran into the same thing once with specifying a trigger that didn't exist and had a similar result (nothing happening rather than a compile error/etc). I don't recall the details.

CyberPK,

Try this first.

sata1-blue-led {
			label = "wdmcmg2:blue:hdd1";
			gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "default-on";
		};
sata2-blue-led {
			label = "wdmcmg2:blue:hdd2";
			gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "default-on";
		};

And then we'll go from there (probably more need to be done).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 04/03/2020 06:07PM by bodhi.

both blue led ON

CyberPK Wrote:
-------------------------------------------------------
> both blue led ON

Red LED blinking?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

No red blinking.
Please note, gpio48 and gpio58 are IN, not OUT as the other gpio leds. GPIO48 and GPIO58 status changes accordingly to the disk presence/poweron

Also, I did a bit of research and found this:
https://www.at91.com/viewtopic.php?t=25697

So, it appear there is no way to set gpio trigger parameters directly in the dts as I want.

Here what I can do:
1) I can try a kernel patch, mimic the behavior for setting timer and pattern trigger through the parameter "led-pattern", adding also the setup of the gpio trigger;
2) simply setup the led in the rc.local
3) understand how the original wd firmware setups the led. Can't figure how it manage to have the blue led blink during disk activity and stay poweron if the disk is present, or of if disk is not present.

I think I'll go simply for the 2) setting the led on default-status = keep.

Tomorrow I'll update my script accordingly



Edited 1 time(s). Last edit at 04/03/2020 09:10PM by CyberPK.

CyberPK,

> Please note, gpio48 and gpio58 are IN, not
> OUT as the other gpio leds. GPIO48 and
> GPIO58 status changes accordingly to the disk
> presence/poweron

>
> Also, I did a bit of research and found this:
> https://www.at91.com/viewtopic.php?t=25697
>
> So, it appear there is no way to set gpio trigger
> parameters directly in the dts as I want.

Not without a patch.

> Here what I can do:
> 1) I can try a kernel patch, mimic the behavior
> for setting timer and pattern trigger through the
> parameter "led-pattern", adding also the setup of
> the gpio trigger;

Not there. Should be in SATA driver.


> 2) simply setup the led in the rc.local
> 3) understand how the original wd firmware setups
> the led. Can't figure how it manage to have the
> blue led blink during disk activity and stay
> poweron if the disk is present, or of if disk is
> not present.
>
> I think I'll go simply for the 2) setting the led
> on default-status = keep.

I think it is simpler to do it in rc.local, too. There is no pre-defined trigger for SATA port activation in the kernel (my patch was for disk activity, so it constantly triggers the LED per read/write). To do it right, it must be a trigger where the SATA link is detectedto be up.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've created the attached patch to enable the gpio trigger set by DTS

So:

1) done with the attached patch and "1 -" DTSs. Tested working;
2) done with the attached "2 -" DTSs and rc.local. Tested Working;
3) any idea? I've extracted the original DTB and translated to DTS but no clue. Analyzed the kernel source, but cannot find any clue. Analyzed the root searching for script or sysfs setting, but did not found anything. Maybe I've missed something useful.

So now the SATA BLUE led will power on or off on disk presence and the RED led will trigger on disk activity with your patch.

The original behavior (BLUE led static on or off on disk presence + blink on disk activity) maybe will obtained with a new patch or understanding how WD have done in his firmware as said in point 3)



Edited 1 time(s). Last edit at 04/05/2020 10:20AM by CyberPK.

CyberPK,

> So now the SATA BLUE led will power on or off on
> disk presence and the RED led will trigger on disk
> activity with your patch.

I am glad it works for you! But I think it is the wrong approach to change the GPIO trigger. This is only related to disk GPIO trigger.

The correct approach is either:

1. Add 2 new LED triggers to handle disk present, and they are separate from the ide-disk1 and ide-disk2 triggers.
or

2. Change the behavior of ide-disk1 and ide-disk2.

Quote

> The original behavior (BLUE led static on or off
> on disk presence + blink on disk activity)

2nd is a better approach than 1st . Because while 1st is easier, but adding 2 more triggers just for this seems too "cookie cutter" and overkill.

It is good to have the LED lit up solid. Right now, at a glance, we can't see where the HDD 1 or 2 are active until either one has disk activity and then flashing. I did not think of this much back when I changed the HDDs triggers. Usually people want the HDD LED to turn off until there is activity. But now I think about this more, I think it should be lit, and if we don't want to see it we can still turn it off in /etc/rc.local.


So I have started working on a patch on the 2nd approach (It has not worked yet).

I hope to add this for the next release of Kirkwood and MVEBU kernels.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> I am glad it works for you! But I think it is the
> wrong approach to change the GPIO trigger. This is
> only related to disk GPIO trigger.
I've added a missing function to the DTS setup. It was really strange to have GPIO available but not settable in DTS!
In fact timer, one-shot, and pattern are all configurable trough led-pattern parameter. This patch can be useful also for other thinks.

> 2nd is a better approach than 1st . Because while
> 1st is easier, but adding 2 more triggers just for
> this seems too "cookie cutter" and overkill.
To me too. My ideas were:
1) "copy" the gpio trigger function to the ide-disk1/2 and use it to invert the ide-disk1/2 logic (too much device dependent?)
2) add the inverted function to the ide-disk1/2 to invert the logic and somehow attach the gpio to the inverted parameter.

I did not try neither the approaches because the required effort is not cost-effective to me, so i preferred to "sacrifice" an additional led.
But if you want to add this function, we can collaborate!

> So I have started working on a patch on the 2nd
> approach (It has not worked yet).
>
> I hope to add this for the next release of
> Kirkwood and MVEBU kernels.

Wonderful!
In this case, please use my DTSs + poweron/off patch to have a new release compatible also with WDMCG2 and WDEXU2. They are the same, changes only the ram amount!

Please, note that the "2 -" DTSs I've uploaded contains an error. Substitute keep with "keep" (add quotation marks).

I'm refining my notes to make a new resuming post containing the compiled kernel (-cpk-1) the full dts, the patches, and the edits I made to the kernel config.

Thank you so much for your help!

CyberPK,

> To me too. My ideas were:
> 1) "copy" the gpio trigger function to the
> ide-disk1/2 and use it to invert the ide-disk1/2
> logic (too much device dependent?)
> 2) add the inverted function to the ide-disk1/2 to
> invert the logic and somehow attach the gpio to
> the inverted parameter.

I think the above is too specific. Triggers should work for all boxes. The right way to enable a trigger for a specific box is to bind it with a GPIO, and set the state to whatever appropriate behavior for that box.

So to follow the current kernel design, when there is a disk present that was detected by the kernel, a function X in the SATA driver will invoke ledtrig_disk_activity() to set the LED and/or some state. The code change is thus encapsulated in the appropriate functions.


> In this case, please use my DTSs + poweron/off
> patch to have a new release compatible also with
> WDMCG2 and WDEXU2. They are the same, changes only
> the ram amount!

That would be great. However, the RAM change is really not necessary (u-boot will override that settings in DTS). Whatever DTS patch you have is OK for this box. But Power On/Off should be looked at to make sure it applies to this box only. Other Armada boxes should not be effected by that.

A critic on using the Red LED: this color usually indicates a fault condition. So that should be reserved to be used in that case. Blue solid or Blue flashing is much better indicator of the disk present or disk activity.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 04/06/2020 06:50PM by bodhi.

Apparently @kingyond trashed their recovery partition and is looking for an mtddump (they sent me a PM):

Quote
kingyond
I don't konw if i make the "rescue fw" mtd part corrupt. it cannot boot into rescue mode. would you please dump the mtd part and send me the bin file. thanks very much.

I don't own this device, but maybe someone here could assist?

kingyond,

I don't have this box either.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

thank you, bodhi and hmartin.
this forum is very usful for me.
i will try to install kernel 5 fom my WDMCG2.

I finnally get the download link from WD forum.
https://fox-exe.ru/WDMyCloud/WDMyCloud-Mirror-Gen2/Dev/WD-Recovery/

@hmartin thank you very much

For future reference, I needed a serial console connected and found some old instructions at https://web.archive.org/web/20210124130711/https://themm.net/public/ex2u/start

Hello,

After long days and nights and following many posts in this forum, I wanted to install Debian and run OMV in mycloud WD Ex2 Ultra (1GB of DRAM).
So far I have:
- Installed new uboot: u-boot-a38x-GrandTeton_2014T3_PQ-nand.bin in my nand (Downloaded from https://forum.doozan.com/file.php?2,file=1428,filename=u-boot-a38x-GrandTeton_2014T3_PQ-nand.bin.gz,download=1)
- Built rootfs in a USB 3 flash drive.
- Set enviroments to boot from the USB3 and launch Debian.
- Run OMV

Everything is running correctly. However my unit is reporting 512MB of DRAM instead of 1GB. After further investigation, I believe that the u-boot-a38x-GrandTeton_2014T3_PQ-nand.bin has been built with a DTS for 512MB units (like the WD Ext2).

I'm still learning Linux and I after so many trial and errors, I'm a bit scared of building my own bin file. has anyone already built one for the EX2 Ultra with 1GB configuration ready? I believe I also mac address not persistent and I haven't even yet checked the Leds. but most important issues to fix are RAM and keep Mac address persistent.