WD MyCloud Mirror Gen2 (BWVZ, GrandTeton)

user1231 Wrote:
-------------------------------------------------------
> Also, I've thrown together a script that downloads
> binaries from debian.org and replaces the ones in
> Carl's initrd, in case you're paranoid about
> running binaries from unknown sources. Not that I
> don't trust Carl, Martin and Fox_exe, but my
> employer doesn't... oh well.
> Let me know if anyone's interested and I'll share
> it here.
>
> Thanks for all the work you guys have put into
> this! Truly awesome!

I would appreciate it, if you can share this script. There is not only "the lack" of trust, with this script, it's easy to keep the binarey up to date.

And by the way with the latest ethernet-patch from bodhi wol works fine with a 4.13 kernel, maybe I should update my github. :-/

-------------------------------------------------------------------------
GitHub https://github.com/cschil

Here's the script. I've only tested it on debian stretch, for debian stretch.
Not much of any error handling in it either.

As someone previously noted, you should modify initrd/bin/resume to use -e instead of -h to find "init", when you're on a linux dist that has init as a regular file instead of a symbolic link. Like stretch.

Hi Carl,

Peacemaker Wrote:
-------------------------------------------------------
> And by the way with the latest ethernet-patch from
> bodhi wol works fine with a 4.13 kernel, maybe I
> should update my github. :-/


I'm trying to put a 4.14 kernel together.

I didn't get WOL working.

Can you elaborate, what you did? Which wakeup tool do you use, with which commandline? Are you setting flags with ethtool? Which patch do you use?

Thanks!

bye
MM

I updated my mcm-daemon repo with patches and configs for newer kernels.

I got 4.14.18 running and fixed the missing ethernet. It was due to needed changes to the dts file.

I also added bodhi's ethernet and LED patch, but WOL still doesn't work for me, the LEDs are not yet tested.

MM Wrote:
-------------------------------------------------------
> I updated my
> mcm-daemon
> repo with patches and configs for newer
> kernels.
>
> I got 4.14.18 running and fixed the missing
> ethernet. It was due to needed changes to the dts
> file.
>
> I also added bodhi's ethernet and LED patch, but
> WOL still doesn't work for me, the LEDs are not
> yet tested.

Thanks MM!

I think if hmartin can get this mcm-daemon to work on the WD My Cloud EX2100, it would be great!

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

MM: I was looking through the commit you did to your repo, 4f949e169b254b78ee76978e2e192525df36f330, which was the LED and WOL patch.
I'm not seeing any WOL based functionality added there, just a few debug prints. So perhaps that's why it's still not working for you?

Br

Yes, that's why I was asking which patch he used. I didn't find anything else.

The LEDs work fine by the way, thanks bodhi!

Hi MM,

The WOL did not really have any patch other than debug prints while we were trying it.

I recall that I've concluded that the network chip has WOL built in and all we need was using ethtools to activate it. So I left the the debug prints in there to see the progress. However, this has not been finalized, WOL still does not work on my NAS326 either.

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

Hey,
I can have a look how I get WOL working within my "old 4.13" build, this weekend.
As it is working fine, after you activated WOL with ethtools.

Cheers Carl

-------------------------------------------------------------------------
GitHub https://github.com/cschil

Hi Carl,

> As it is working fine, after you activated WOL
> with ethtools.

Sounds great! wonder if we have the same chip on your WD box and my NAS326?

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

Hello everyone,
this is my first post and I'm a newbie to the topic of compiling a kernel and working with the arm toolchain.
I've read almost all the topic, the how to by MM and the topic by fox_exe in wd forum about the alternative firmwares.
I actually own a WD MyCloud Mirror Gen2 and I want to update to debian to install openmediavault or anything else better than the buggy and limited WD MyCloud.
I've read also the topic into the WD forum and considered the option to update to DSM, but I feel uncomfortable about the bugs and being a black box because I'll continue to use this device for Backups.

Anyway, I'm a little paranoid, and I would like to build everything by me. Also I want the ability to update when required and I would like to encrypt the drive using the hardware acceleration.
For these reason I think I'll follow the how to from MM trying to get think working.

I'm a bit confused about the dts provided in this forum being different with the one created by fox_exe on wd forum.
Also he provides an easy wd_to_debian binary upgrade and a Stretch rootfs, that I think would fit nicely in the nand but for some reason is fitted in the drive.

To avoid the drives being always on, there isn't any way to prevent the rootfs being written in the hard drives? Cannot fit in the nand? Cannot use an external usbdrive?

There wasn't any update from March. Is this topic abandoned?

In conclusion if the nand cannot contain a minimal debian install, I would like to chain the rootfs in the hard drive to the nand. Than, from the rootfs mount the raid with the password that I'll manually input after every reboot.

Thank you very much for your hard work!



Edited 2 time(s). Last edit at 09/02/2018 01:40PM by CyberPK.

Although there is some free space in the Nand flash I do not think that it is advisable to try to put your whole Debian in flash. The few GB you lose on the disk are not worth the effort.

Someone has described in this forum how to encrypt the whole disk using luks and he stored the pwd in flash. Asking for the password at each boot is problematic because at this stage you have no ssh available. Most probably it would be easy to put the password on an USB stick.

@ CyberPK,

I do agree with LinAdmin about not to put Debian on NAND flash.

However, to me it is more important that when you run your Linux distribution on NAND, it tends to be unsecure. IOW, you will not update your system to get security patches as often as when it is on USB or SATA.

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

Thank you for answering.
As you have understood I'm not an expert.

Do you think is a good idea to run debian from an usb drive? This way I'll avoid the drive spinning all the time?
What about the differences in the dts file by this forum users and the fox_exe version?

At now, I've used the fox_exe binary to convert the wd to debian Stretch and flashed his rootfs. Then I've compiled the kernel 4.14.59 and flashed but can't go over the initrd (only recovery available). I've flashed also the initrd, with the same behaviour.
Initially the problem was the label of the partition was not "rootfs" but "ROOTFS".
Now, if I launch the 'resume' command, I get an error about the /dev is in use and the exec switch_root /mnt/root /sbin/init does not produce the expected result.
Actually the drive has 3 partition in raid: swap, rootfs, data. Maybe the md1 partition cannot be used?

CyberPK,

>
> Do you think is a good idea to run debian from an
> usb drive? This way I'll avoid the drive spinning
> all the time?

Yes. I have several plugs that are running 24/7 with USB rootfs. Some preparation suggestions to make sure the USB drive will not be worn out by constant write access:
https://forum.doozan.com/read.php?2,13702,13704#msg-13704

> What about the differences in the dts file by this
> forum users and the fox_exe version?

I can't comment on that since I did not work on this box. I think you need JanN, MM, and Peacemaker, perhaps others in this thread to chime in.

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

Hello,

I've compiled the kernel by my own, but I cannot boot to debian installer with ssh.
Because I'm not able to find an usb to com adapter, I'm trying to use the network-console initrd modified with the preseed.cfg.
I'm able to boot from usb drive following the instruction from https://themm.net/public/ex2u/start but if I use the network-console initrd with or without the preseed, the wd starts and after about a minute reboots and keep the light flashing red.

These are the commands that I run to generate the uRamdisk:
wget http://ftp.debian.org/debian/dists/stretch/main/installer-armhf/current/images/network-console/initrd.gz
mkdir initrd; cd initrd
gzip -d < ../initrd.gz | cpio --extract --verbose --make-directories --no-absolute-filenames
cp ../preseed.cfg ./
find . | cpio -H newc --create --verbose | gzip -9 > ../initrd_preseed.gz
cd ..
mkimage -A arm -T ramdisk -n "debian stretch installer with preseed" -c gzip -d initrd_preseed.gz uRamdisk

this is my preseed.cfg:
d-i netcfg/disable_autoconfig boolean true
d-i netcfg/get_ipaddress string 192.168.1.42
d-i netcfg/get_netmask string 255.255.255.0
d-i netcfg/get_gateway string 192.168.1.1
d-i netcfg/get_nameservers string 8.8.8.8
d-i netcfg/confirm_static boolean true

d-i anna/choose_modules string network-console
d-i network-console/password password test
d-i network-console/password-again password test

Can you help me?
Keep in mind I cannot access the serial at thi point, otherwise I had already installed debian following themm instructions.

Regards

***EDIT***
The problem was caused by the kernel I've compiled (4.14.59 following the themm wiki). Using the precompiled one the setup has started correctly via ssh



Edited 2 time(s). Last edit at 09/16/2018 05:02PM by CyberPK.

Can I use the files in this topic? https://forum.doozan.com/read.php?2,32146 (Advanced Linux Kernel 4.18.5 MVEBU package and Debian armhf rootfs)

Hi Fran,

> Can I use the files in this topic?
> https://forum.doozan.com/read.php?2,32146
> (Advanced Linux Kernel 4.18.5 MVEBU package and
> Debian armhf rootfs)

Yes. You can use the rootfs (and kernel 4.12.4-mvebu-tld-1 in it) to start.

Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2

The special patches and stuff that people have done this this tread will make it complete for this box (I myself do not provide supports for this box).

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

Here follows my notes on installing debian 10 and omv 5 and are not perfectly refined, but are working without problems.

at this link all the useful script and compiled packages: https://drive.google.com/drive/folders/1kNRCABVaWv6PvDHiqwBxtz0FTcb6dO93?usp=sharing




This post assumes that you are able to connect to the serial interface of the device. Before continuing make sure you have access to it.

Here follows my personal notes to build kernel and debian usb drive.
Thanks to all the user of the forum. I've used a lot of their results to write the following post.

bugs:

- on reboot, the mcm-daemon fails to fix the blue light. After the reboot the box does not sense the DeviceReadyCmd?
- mvneta fails to retrieve the mac address and set a random one. Not a real problem because our device has the custom mac printed on the back of the unit, stored in the ubifs reserved2 partition dinamically loaded at address 0x02000000 at startup

hexdump  -C -s 0x02000000 -n 18 -v /dev/mem

Please download:
rootfs 5.2.9
https://bitly.com/2m2Y7r6
and kernel 5.5.3
https://bitly.com/37ygLsI

we'll use it as base for our mod. Thank you bodhi.

####### U-Boot #######
The stock u-boot has the command setenv disabled. Also, either if it was active, a bug would corrupt the kernel saved into the NAND.
At https://support-en.wd.com/app/products/product-detail/p/137 is possible to download the latest GPL packages and running xbuild.sh is possible to rebuild the uboot for nand and for uart.
Analyzing the sources can be found that in include/configs/armada_38x.h is not defined CONFIG_CMD_SAVEENV for our architecure effectively disabling the enviroment save command saveenv.
So I thinked to use fw_setenv from debian, but I need the parameters for the /etc/fw_env.config, MTD device name, Device offset, Env. size, Flash sector size and Number of sectors
MTD device name and Device offset depends from CONFIG_ENV_OFFSET
Env. size depends from CONFIG_ENV_SIZE
Flash sector size depends from the used NAND witch in our case is 0x20000
Number of sectors = Env. size / Flash sector size

Looking at include/configs/armada_38x.h we can find:

#define CONFIG_UBOOT_SIZE           0x100000
#define CONFIG_SPARE_AREA			0x400000
...
/* Boot from NAND settings */
...
		#define CONFIG_ENV_SIZE                 0x80000                 /* environment takes one erase block */
		#define CONFIG_ENV_OFFSET               nand_get_env_offs()     /* environment starts here  */

nand_get_env_offs() is defined drivers/mtd/nandnand.c

...
blocksize = nand_info[0].erasesize;                          #0x20000
...
offset = CONFIG_UBOOT_SIZE + CONFIG_SPARE_AREA;              #0x100000 + 0x400000 = 0x500000
...
offset = ( (offset + (blocksize - 1)) & (~(blocksize-1)) );  #( (0x500000 + (0x20000 - 1)) & (~(0x20000-1)) ) = 0x500000

so the CONFIG_ENV_OFFSET is 0x500000
Let's take a look to the NAND partitioning

0x00000000-0x00500000 : "U-Boot"
0x00500000-0x00a00000 : "uImage"
0x00a00000-0x00f00000 : "uRamdisk"
0x00f00000-0x0c800000 : "image.cfs"
0x0c800000-0x0d700000 : "rescue fw"
0x0d700000-0x0eb00000 : "config"
0x0eb00000-0x0f500000 : "reserve1"
0x0f500000-0x0ff00000 : "reserve2"

so the parameters to write the Enviroment with fw_setenv to the right location is

echo "/dev/mtd1 0 0x80000 0x20000 4" > /etc/fw_env.config

Obviously the kernel got corrupted once the envs got saved running fw_setenv. At reboot all the variables got successfully loaded by the stock uboot except bootcmd that is overwritten on-the-fly at every startup by the uboot disallowing the mod of the startup procedure.
look at: board/mv_ebu/a38x/mv_main_a38x.c

setenv("bootcmd","nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000");

The stock uboot poweron only the usb2 port. If you use the usb1, the device won't be powered. Why?
In include/configs/armada_38x.h

#if 0 //ALPHA_CUSTOMIZE
	#define ENV_USB_ACTIVE		  "1"
#else
	#define ENV_USB_ACTIVE        "0"
#endif

This variable is used in mv_main_a38x.c

setenv("usbActive", ENV_USB_ACTIVE);

to define which port is enabled in the uboot.

So:
ENV_USB_ACTIVE = 0 -> USB2
ENV_USB_ACTIVE = 1 -> USB1

look at mvCtrlUsbMapGet()@board/mv_ebu/a38x/armada_38x_family/ctrlEnv/mvCtrlEnvLib.c for details


What to do to boot debian from USB, or failover to the original NAND?
PATCH U-BOOT!
1) Set the UBoot Enviroments into the uboot partitioning
2) Remove the bootcmd overwriting at startup

Optional
3) Enable saveenv
4) Enable all the usb at boot

Luckly in the forum can be found the patch and also the compiled version
uboot
A) https://forum.doozan.com/read.php?2,35291,35568#msg-35568
B) https://forum.doozan.com/file.php?2,file=1428,filename=u-boot-a38x-GrandTeton_2014T3_PQ-nand.bin.gz,download=1

patch
C) https://forum.doozan.com/read.php?2,35291,35359#msg-35359
D) https://forum.doozan.com/file.php?2,file=1414,filename=GrandTeton-20170708.patch,download=1

In case you will build your own, consider that the -nand.bin is intended to be flashed to the nand, the -nand-uart.bin is intended to be used for kwboot. Before flashing I advise you to test the boot with kwboot.
In this case you can run the uboot with this command:

./kwboot -f -t -B 115200 /dev/ttyUSB0 -b u-boot-a38x-GrandTeton_2014T3_PQ-nand-uart.bin -s 0 -q 1

Today I'm lazy and I'll use the prebuilt uboot images, already tested and safe to be flashed. How to flash the modified uboot? In the forum was anywhere proposed the use of kwboot.
Instead of using kwboot, boot to debian then flash the partition, I propose a different approach using the builtin command bubt.
We have to prepare an usb drive formatted in Fat32, and extract the uboot at B) link into it and connect to usb port#2.

Connect the device to the serial adapter, poweron the device and start pressing '1' (one) during the boot until you can see the 'Marvell>>' Command Prompt
press ctrl+c
then

usb start
bubt u-boot-a38x-GrandTeton_2014T3_PQ-nand.bin nand usb
reset

N.B.
This uboot power on the usb drive in the port #1

the wd would reboot, and the new uboot is now awailable.
Access again the Command prompt and add the following envs, a modified version of the ones provided by bodhi at this post:
https://forum.doozan.com/read.php?2,35291,35588#msg-35588

This modified version allows to do not overwrite the mac address loaded at 0x2000000 and to try the boot from both the usb ports before giving up and boot the nand.

setenv set_bootargs_stock 'setenv bootargs root=/dev/ram console=ttyS0,115200'
setenv bootcmd_stock 'echo Booting from stock ... ; run set_bootargs_stock; printenv bootargs; nand read.e 0xa00000 0x500000 0x500000;nand read.e 0xf00000 0xa00000 0x500000;bootm 0xa00000 0xf00000'
setenv bootdev 'usb'
setenv device '0:1'
setenv load_image_addr '0x02000020'
setenv load_initrd_addr '0x2900000'
setenv load_image 'echo loading Image ...; ext2load $bootdev $device $load_image_addr /boot/uImage'
setenv load_initrd 'echo loading uInitrd ...; ext2load $bootdev $device $load_initrd_addr /boot/uInitrd'

setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial init=/bin/systemd"'
setenv bootcmd_usb 'echo Booting from USB ...; usb start; run usb_set_bootargs; if run load_image; then if run load_initrd; then bootm $load_image_addr $load_initrd_addr; else bootm $load_image_addr; fi; fi; usb stop'
setenv bootcmd 'setenv fdt_skip_update yes; setenv usbActive 0; run bootcmd_usb; setenv usbActive 1; run bootcmd_usb; setenv fdt_skip_update no; run bootcmd_stock; reset'

saveenv
reset

in the first try, before modifying the vars to allow the boot from both the usb drives, the new uboot, for some reason failed to load any files from my usb 3.0 drive if connected to USB1 (usbActive=1). Once set the usbActive to 0 (USB2), started flawlessly.
so in my case, after the reboot i run

setenv usbActive 0
saveenv
reset

and then the problems vanished.
Please note that this is not required anymore. if the boot process does not continue, simply try the other usb port. If are still present problems, please use another usb drive.

For the ones without the serial interface, there could be another way.
Using the builtin recovery function, can be started the uImage and the uInitrd from an usb drive FAT formatted, connected to port 2. Keeping the reset button pressed, poweron the device and release the reset button once led start blinking. This way the device can be accessed to flash the kernel and uInitrd into the NAND, but it's impossible because the uImage and uInitrd partitions on the NAND are bot 5Mb, and the kernele 5.x is bigger. May fit a 4.x kernel, but the above procedure is preferred.

######## compiling kernel ########
Option 1:
Use the precompiled kernel from bodhi, compile the new DTB from DTSs using the dtc tool

Option 2:
Recompile by my own the kernel with the bodhi patches.

In both cases we need a working dtb.
Option 1 - Stock dtb:
a) We can extract the stock dtb from the stock kernel and reuse it with the kernel?
b) We can generate the dtb from the dts sources in the gpl package
copy somewhere the files in the folder
linux-3.10.39-2014_T3.0/linux-3.10.39-2014_T3.0_GrandTeton/arch/arm/boot/dts/GrandTeton/armada-385-db.dts
linux-3.10.39-2014_T3.0/linux-3.10.39-2014_T3.0_GrandTeton/arch/arm/boot/dts/GrandTeton/armada-385-388.dtsi
linux-3.10.39-2014_T3.0/linux-3.10.39-2014_T3.0_GrandTeton/arch/arm/boot/dts/GrandTeton/armada-38x.dtsi
linux-3.10.39-2014_T3.0/linux-3.10.39-2014_T3.0_GrandTeton/arch/arm/boot/dts/skeleton.dtsi
then run

gcc -I . -E -nostdinc -undef -D__DTS__ -x assembler-with-cpp -o armada-385-wd-mcmg2.dts armada-385-db.dts
dtc -I dts -O dtb armada-385-wd-mcmg2

Option 2 - New dtb:
During the years the dts have been patched upon some bugs, so I would prefer to create a new dts from the most recent sources. But where is it the armada-385-db.dts?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/armada-385-db.dts?id=881a50e47f231fb0185396125234f3188e14c2f3
"The main difference with the Armada 385 is that the 388 can handle two more SATA ports...the Armada 385 DB and Armada 385 RD board have been renamed in the 388 one and now include the armada-388.dtsi file. AS both of them have 4 SATA ports the SoC used on them were wrongly described."
also https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf sais that the only difference between 88F6820 (armada385) and 88F6828 (armada388) is in the number of SATA 3.0 ports. The 88F6820 has 2 SATA 3.0 ports while the 88F6828 has 4 SATA 3.0 ports.

So our base will be the armada-388-db.dts with some changes:
- changing the #include "armada-388.dtsi" in #include "armada-385.dtsi"
- setting the custom bootargs
- set the memory to 512MB (1GB for EX2 Ultra)
- removing the sata@e0000, which is second SATA host which control the 2 other ports.
- removing pcie, which is not available on our board
- adding the right nand layout
- disabling sdhci, because no sd slot
...

using the patch by evgenyz@gmail.com with some minor mods

looking at the stock dts found bm_pnc and trying to figure what is it, I've tracked it to custom network driver (drivers/net/ethernet/mvebu_net) which is not in the mainline kernel. Searching to internet I landed on this page
https://github.com/MarvellEmbeddedProcessors/openwrt-kernel/issues/2
"Hello,

Now I am looking at the Ethernet driver of armada 38x. I have found that there are additional Ethernet driver folder call mvebu_net which is not in the mainline kernel (e.g., 4.1). Could you please give me some information about the drivers in this folder, and whether these drivers are in the other places of mainline kernel ? Thank you."
"This is Marvell's in-house version of kernel that includes changes that are not submitted to vanilla kernel, nor are they upstreamable into mainline.

nitroshift"

I was tring to add this:
soc {
	ranges = <MBUS_ID(0x0b, 0x04) 0 0xf1300000 0x100000>;	/* PNC: PHYS=0xf1300000 size 1M */
	internal-regs {
		/* PnC and BM */
		bm_pnc@c0000 {
			compatible = "marvell,neta_bm_pnc";
			reg = <0xc8000 0xAC 0xb8000 0x48>;
			clocks = <&gateclk 13>, <&gateclk 29>;
			/*neta_cap_bm, bitmap of NETA dynamic capabilities, such as PNC, BM, HWF and PME
			  PNC--0x1, BM--0x2, HWF--0x4, PME--0x8*/
			neta_cap_bm = <0x3>;
			pnc_tcam_size = <1024>;
		};
	}
}

I did not try to add the new driver to the mainline kernel to see if compiles, but appear to pack a lot of functions, like WOL.

found also drivers/crypto/mvebu_cesa/ and drivers/mtd/nand/mvebu_nfc/ (nand controller) which appear to be both implemented in mainline.


########## building the debian usb drive #########
in future i'll try a vanilla build of debian? debian initrd and install to an usb drive?
https://wiki.debian.org/ArmHardFloatPort
https://wiki.debian.org/ArmHardFloatChroot

this time I'll use the bodhi rootfs.
run the script to get it running and updated with the compiled kernel.

Please note, my script updates and install the new kernel using qemu, so the usb drive will be already updated to the latest kernel!

######## run debian ##########

to set persistent mac run once set_persistent_mac_address2 to use the uboot mac, or set_persistent_mac_address3 to use the WD mac. For some reason mvneta retrieve an invalid hardware mac so setup a random one.
The original set_persistent_mac_address slow down the startup to 2 minutes in case a dhcp address is not provided. The following script solves the problem until mvneta bug is fixed, or if the device address is used.

/root/set_persistent_mac_address3
#1) Backup partitions
mkdir backup
cd backup
nanddump --noecc --omitoob -f U-Boot.bin /dev/mtd0
nanddump --noecc --omitoob -s 0x100000 -l 0x80000 -f ubootenv.bin /dev/mtd0
nanddump --noecc --omitoob -f uImage.bin /dev/mtd1
nanddump --noecc --omitoob -f uRamdisk.bin /dev/mtd2
nanddump --noecc --omitoob -f image.cfs.bin /dev/mtd3
nanddump --noecc --omitoob -f rescue_fw.bin /dev/mtd4
nanddump --noecc --omitoob -f config.bin /dev/mtd5
nanddump --noecc --omitoob -f reserve1.bin /dev/mtd6
nanddump --noecc --omitoob -f reserve2.bin /dev/mtd7

reboot

######### INSTALL OMV4########

cat <<EOF > /etc/apt/sources.list.d/openmediavault.list
deb http://packages.openmediavault.org/public arrakis main
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis main
## Uncomment the following line to add software from the proposed repository.
# deb http://packages.openmediavault.org/public arrakis-proposed main
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis-proposed main
## This software is not part of OpenMediaVault, but is offered by third-party
## developers as a service to OpenMediaVault users.
# deb http://packages.openmediavault.org/public arrakis partner
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis partner
EOF

export LANG=C.UTF-8
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
wget -O "/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc" https://packages.openmediavault.org/public/archive.key
apt-key add "/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc"
apt-get update
apt-get --yes --auto-remove --show-upgraded \
	--allow-downgrades --allow-change-held-packages \
	--no-install-recommends \
	--option Dpkg::Options::="--force-confdef" \
	--option DPkg::Options::="--force-confold" \
	install postfix openmediavault-keyring openmediavault


# Initialize the system and database.
omv-initsystem


# Rebuild configurations.
omv-mkconf interfaces
omv-mkconf issue


# Display the login information.
cat /etc/issue

######### INSTALL OMV5########

cat <<EOF > /etc/apt/sources.list.d/openmediavault.list
deb https://packages.openmediavault.org/public usul main
# deb https://downloads.sourceforge.net/project/openmediavault/packages usul main
## Uncomment the following line to add software from the proposed repository.
# deb https://packages.openmediavault.org/public usul-proposed main
# deb https://downloads.sourceforge.net/project/openmediavault/packages usul-proposed main
## This software is not part of OpenMediaVault, but is offered by third-party
## developers as a service to OpenMediaVault users.
# deb https://packages.openmediavault.org/public usul partner
# deb https://downloads.sourceforge.net/project/openmediavault/packages usul partner
EOF

apt update
apt upgrade -y

export LANG=C.UTF-8
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
wget -O "/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc" https://packages.openmediavault.org/public/archive.key
apt-key add "/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.asc"
apt-get update
apt-get --yes --auto-remove --show-upgraded \
	--allow-downgrades --allow-change-held-packages \
	--no-install-recommends \
	--option Dpkg::Options::="--force-confdef" \
	--option DPkg::Options::="--force-confold" \
	install openmediavault-keyring openmediavault


# Populate the database.
omv-confdbadm populate


# Display the login information.
cat /etc/issue

#############################################

# Install OMV Extras

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

##### Bonus 1 #####
just in case, the gpl packages contains the partition to be flashed directly to the nand in the folder firmware/merge/

flash_erase /dev/mtd0 0 0
nandwrite -p /dev/mtd0 u-boot.bin

flash_erase /dev/mtd1 0 0
nandwrite -p /dev/mtd1 uImage

flash_erase /dev/mtd2 0 0
nandwrite -p /dev/mtd2 uRamdisk

flash_erase /dev/mtd3 0 0
nandwrite -p /dev/mtd3 image.cfs

In case something goes wrong, as long as exist the stock uboot (or the modified version used in this post) and the rescue_fw partition was not corrupted, can be deleted uImage to allow the rescue mode to start. Power on the device appear the rescue web interface accepting the original firmware, and all the partition get restored automatically.

##### mount ubifs image #####

mkdir test
modprobe nandsim first_id_byte=0xAD second_id_byte=0xDA
cat /proc/mtd | grep -i "NAND Simulator"
modprobe ubi
flash_erase /dev/mtdX 0 0
ubiformat /dev/mtdX -y -f config.bin
ubiattach -p /dev/mtdX
mount -t ubifs ubiX test

####### mount ubifs partition #####

nanddump --noecc --omitoob -f config.bin /dev/mtd5
nanddump --noecc --omitoob -f reserve1.bin /dev/mtd6
nanddump --noecc --omitoob -f reserve2.bin /dev/mtd7

mkdir config reserved1 reserved2
ubiattach -p /dev/mtd5ro
ubiattach -p /dev/mtd6ro
ubiattach -p /dev/mtd7ro

mount -t ubifs ubi0_0 config
mount -t ubifs ubi1_0 reserved1
mount -t ubifs ubi2_0 reserved2

tar -zcvpf config.tar.gz config
tar -zcvpf reserved1.tar.gz reserved1
tar -zcvpf reserved2.tar.gz reserved2

umount config reserved1 reserved2
ubidetach -p /dev/mtd5ro
ubidetach -p /dev/mtd6ro
ubidetach -p /dev/mtd7ro

flash_erase /dev/mtd5 0 0
flash_erase /dev/mtd6 0 0
flash_erase /dev/mtd7 0 0

nandwrite -p /dev/mtd5 config.bin
nandwrite -p /dev/mtd6 reserve1.bin
nandwrite -p /dev/mtd7 reserve2.bin

####### envs utils ######

how to read, and edit the ens from debian?

echo "/dev/mtd0 0x100000 0x80000 0x20000 4" > /etc/fw_env.config

then use fw_printenv and fw_setenv

The env can be fully dumped with the following command:

nanddump --noecc --omitoob -s 0x100000 -l 0x80000 -f ubootenv.bin /dev/mtd0

and restored:

nandwrite -p /dev/mtd0 -s 0x100000 ubootenv.bin

or wiped:

flash_erase /dev/mtd0 0x100000 0x80000

Just in case you want to flash the uboot from debian, the dts marked the first partition as read only. You have to edit the DTS removing the read only flag.

mtd_debug info /dev/mtd0

returns

mtd.flags = MTD_CAP_ROM

meaning that the partition is readonly.
To be writeable from debian it should return

mtd.flags = MTD_CAP_NANDFLASH

#### controlling the MCU ####
it's installed the MM daemon, but if you want to send commands diretcly to the mcu can run:

#run twice#
stty -F /dev/ttyS1 raw speed 19200
stty -F /dev/ttyS1 raw speed 19200

# instart poweroff
echo -n -e '\xfa\x03\x03\x01\x00\x00\xfb' > /dev/ttyS1
or
echo -n -e '\xfa\x03\x03\x01\x01\x01\xfb' > /dev/ttyS1

# instart restart
echo -n -e '\xfa\x03\x03\x02\x00\x00\xfb' > /dev/ttyS1
or
echo -n -e '\xfa\x03\x03\x02\x01\x0a\xfb' > /dev/ttyS1


#FAN
#speed is encoded in 4th byte from 0 to 255
# for minimum fan speed
echo -n -e '\xfa\x02\x00\x00\x00\x00\xfb' > /dev/ttyS1

# for maximum fan speed
echo -n -e '\xfa\x02\x00\xff\x00\x00\xfb' > /dev/ttyS1

for all commands see https://github.com/c-MM/mcm-daemon/blob/master/mcm.h


# read gpio input:

cat /dev/input/event0
evtest /dev/input/event0
cat /sys/kernel/debug/gpio
ls /proc/device-tree/keys/

### bonus 1 creating an autobooting FAT16 usb drive ###

export STICK=sdb
echo -e "1 100M 0xb\n,4000M" | sudo sfdisk /dev/$STICK
sudo mkfs.vfat -F32 /dev/"$STICK"1
sudo mkfs.ext4 /dev/"$STICK"2
sudo mount /dev/"$STICK"1 /mnt/
sudo mkdir /mnt/boot
sudo cp output/uImage uRamdisk /mnt/boot
sudo umount /mnt

sudo mount /dev/"$STICK"2 /mnt/
sudo cp output/uImage uInitrd-wd385 mcm-daemon_1.03_armhf.deb output/modules.tgz /mnt
sudo umount /mnt

insert on port with label 2

### bonus 2 - modding the debian inirtrd to enable network console! ###

wget http://ftp.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/initrd.gz
mkdir $INITRD_INSTALLER
cd $INITRD_INSTALLER
gzip -d < ../initrd.gz | cpio --extract --verbose --make-directories --no-absolute-filenames

cat > preseed.cfg <<EOL
d-i anna/choose_modules string network-console
d-i preseed/early_command string anna-install network-console
d-i network-console/password password test
d-i network-console/password-again password test
d-i network-console/start select continue

d-i netcfg/disable_autoconfig boolean true
d-i netcfg/choose_interface select eth0
d-i netcfg/get_ipaddress string 192.168.10.100
d-i netcfg/get_netmask string 255.255.255.0
d-i netcfg/get_gateway string 192.168.10.1
d-i netcfg/get_nameservers string 8.8.8.8
d-i netcfg/confirm_static boolean true
#d-i netcfg/get_hostname string NAS
d-i netcfg/get_hostname string WDMyCloudMirrorGen2
d-i netcfg/get_domain string 
EOL

rm -rf lib/modules/
find . | cpio -H newc --create --verbose | gzip -9 > ../initrd_preseed.gz
cd ..
mkimage -A arm -T ramdisk -n "debian installer with preseed" -c gzip -d initrd_preseed.gz uRamdisk

insert on port with label 2

You can try to use the so created ramdisk to boot debian from an usb drive (as described in bonus 1) and patch the uboot and his env from debian without using the serial adapter, using an ssh shell.
###
# using the serial shell
# press 1 until marvell>> shell appear
# ctrl+c

usb reset; fatload usb 0:1 0xa00000 boot/uImage; fatload usb 0:1 0x2000000 boot/uRamdisk; bootm 0xa00000 0x2000000

###

the setup will miss the kernel modules
once the setup start, press esc go to the shell and run

mkdir /media/drive
mount /dev/sda2 /media/drive
ln -s /media/drive/lib/modules/ /lib/modules
exit

setup as normal. The setup could be slower, be patient.
n.b.
After the selection of the mirror a message will alert that the module are missing from the repository. Ignore it.
set the partition name to rootfs

When asked for a kernel to install select none.
after the installer has finished the installation do not reboot but press <Go Back> to return to the menu.
Select Execute a shell.


##### useful links #####
MarvellEmbeddedProcessors Linux Porting Guide
https://github.com/MarvellEmbeddedProcessors/linux-marvell/wiki/Linux-Porting-Guide

Linux Kernel 5.5.3 MVEBU package and Debian armhf rootfs
https://forum.doozan.com/read.php?2,32146

My Cloud Mirror Gen2 u-boot
forum.doozan.com/read.php?2,35291

WD MyCloud Mirror Gen2 (BWVZ, GrandTeton)
https://forum.doozan.com/read.php?2,28939,69759

USB's lifetime
https://forum.doozan.com/read.php?2,13702,13704#msg-13704

Daemon to control the Weltrend MCU in a WD MyCloudMirror Gen2 and EX2 Ultra NAS device
https://github.com/c-MM/mcm-daemon

Debian jessie on the WD MyCloud EX2 Ultra
https://themm.net/public/ex2u/start

Promising patch?
[PATCH 0/5] Add support for WD MyCloud EX2 Ultra (+ versatile UART-based
https://lkml.org/lkml/2019/7/22/1050
https://lore.kernel.org/lkml/cover.1563822216.git.evgenyz@gmail.com/
https://gitlab.com/evgenyz/wtmcu
http://git.mis.ks.ua/Excalibur/openwrt/commit/a24a15e1ee79bcbb9da9997b1bccab020978003a

https://community.wd.com/t/my-cloud-pr4100-pr2100-information/200873/265

install OMV4
https://forum.openmediavault.org/index.php?thread/21234-install-omv4-on-debian-9-stretch/

install OMV5
https://forum.openmediavault.org/index.php?thread/25062-install-omv5-on-debian-10-buster/

*** edited to remove some typos ***



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

Thanks CyberPK!

That's a lot of great info.

Could you also post:

dmesg
cat /proc/mtd

and state at the top of your post that OMV5 version is the one being installed. And also

uname -a
cat /etc/debian_version

After that, I can add this to the Wiki thread.

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

bodhi Wrote:
> Could you also post:
>
>

> dmesg
> cat /proc/mtd
>

I'm working to the dts to add the sata HDD sensing, so may be containg wring informations. I'm just finishing some mods, to test if the DTS works good, or I've to move the sata triggers to the rc.local
If you want the dmesg as is, I can send it.

root@debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00500000 00020000 "U-Boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 00500000 00020000 "uRamdisk"
mtd3: 0b900000 00020000 "image.cfs"
mtd4: 00f00000 00020000 "rescue fw"
mtd5: 01400000 00020000 "config"
mtd6: 00a00000 00020000 "reserve1"
mtd7: 00a00000 00020000 "reserve2"

bodhi Wrote:
>

> uname -a
> cat /etc/debian_version
>

root@debian:~# uname -a
Linux debian 5.5.3-mvebu-tld-1 #1.0 SMP PREEMPT Sat Mar 28 01:45:13 CET 2020 armv7l GNU/Linux
root@debian:~# cat /etc/debian_version
10.3

Keep in mind, I've maintained your naming convention for the kernel. If required, I can add some edits to avoid confusion.

CyberPK,

> I'm working to the dts to add the sata HDD
> sensing, so may be containg wring informations.
> I'm just finishing some mods, to test if the DTS
> works good, or I've to move the sata triggers to
> the rc.local
> If you want the dmesg as is, I can send it.

It's OK. Please post that when you're done and think it will be useful.

>
>

> root@debian:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00500000 00020000 "U-Boot"
> mtd1: 00500000 00020000 "uImage"
> mtd2: 00500000 00020000 "uRamdisk"
> mtd3: 0b900000 00020000 "image.cfs"
> mtd4: 00f00000 00020000 "rescue fw"
> mtd5: 01400000 00020000 "config"
> mtd6: 00a00000 00020000 "reserve1"
> mtd7: 00a00000 00020000 "reserve2"
>

>
>
> bodhi Wrote:
> >

> > uname -a
> > cat /etc/debian_version
> >

>
>

> root@debian:~# uname -a
> Linux debian 5.5.3-mvebu-tld-1 #1.0 SMP PREEMPT
> Sat Mar 28 01:45:13 CET 2020 armv7l GNU/Linux
> root@debian:~# cat /etc/debian_version
> 10.3
>

>
> Keep in mind, I've maintained your naming
> convention for the kernel. If required, I can add
> some edits to avoid confusion.

Yes. Please add a postfix to the kernel version. Such as (anything to avoid confusion). Also note if you've changed any kernel parameters from config-5.5.3-mvebu-tld-1.
Example:

5.5.3-mvebu-tld-1-cpk-1

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

bodhi Wrote:
-------------------------------------------------------
> Yes. Please add a postfix to the kernel version.
> Such as (anything to avoid confusion). Also note
> if you've changed any kernel parameters from
> config-5.5.3-mvebu-tld-1.
> Example:
>

> 5.5.3-mvebu-tld-1-cpk-1
>

Ok, I will make this change in next days.
I've changed some parameters, but they are in the script I've provided in my shared folder. (build_kernel and build_drive).
I'll report the changes also here.

Hi bodhi,

I need your help.

I'm making some trial on the DTS to obtain the same led behaviour as in stock software, but I cannot obtain what a I need.
Let me explain.

I would like to have the blue led powerup when a sata disk is inserted, and blink on activity.
Unfortunately it seems that the same led/gpio cannot be connected to more than 1 trigger. Any idea?

I have also tried to have blue led to poweron on disk presence, and red led to blink on disk activity. The problem is that the gpio trigger cannot be connected to the gpio pin to monitor from the DTS. I have managed to set it only from command line. Any idea?

Also, do you know any implementation of a monitor to trigger the red light on events from hdd, or temperature? I would image an mcm-daemon to make the red light blink on overheating, or stay full red on disk failing.

Regards

CyberPK,

> I'm making some trial on the DTS to obtain the
> same led behaviour as in stock software, but I
> cannot obtain what a I need.
> Let me explain.
>
> I would like to have the blue led powerup when a
> sata disk is inserted, and blink on activity.
> Unfortunately it seems that the same led/gpio
> cannot be connected to more than 1 trigger. Any
> idea?

GPIO cannot be used for more than 1 trigger. That's normal operation. Inversely, multiple GPIOs can be assigned to the same trigger.

For example, in my custom kernel build, I created 2 separate triggers for SATA1 and SATA2 (mainline code does not differentiate between ports). So a mainline kernel trigger would be disk-activity for all ports. This required me to do a little bit of coding to change the driver to differentiate between 2 ports, and I also added the definition to the DTS

root@tldDebian:~# cat /sys/class/leds/n2350\:white\:sata1/trigger

Quote

none usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport timer oneshot disk-activity disk-read disk-write [ide-disk1] ide-disk2 mtd nand-disk heartbeat gpio default-on flash torch panic f1072004.mdio-mii:01:link f1072004.mdio-mii:01:1Gbps f1072004.mdio-mii:01:100Mbps f1072004.mdio-mii:01:10Mbps

And in the DTS, Sata1 and Sata2 have 2 different GPIOs. Each hooks to a port.

>
> I have also tried to have blue led to poweron on
> disk presence, and red led to blink on disk
> activity. The problem is that the gpio trigger
> cannot be connected to the gpio pin to monitor
> from the DTS. I have managed to set it only from
> command line. Any idea?

If the command line works, then use that for the DTS and also set a default value, if you don't want to add code to /etc/rc.local (I usually do it in /etc/rc.local because it is a good demonstration of how to control the LED trigger, for users who want to know the inner working of the triggers, i.e /sys/class/leds...)

To add default trigger to DTS, here is an example:

root@tldDebian:~# cat /usr/src/linux-5.5.1-tld/arch/arm/boot/dts/kirkwood-goflexhome.dts | grep -5 ide-disk1

gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
               };
               misc {
                       label = "status:white:misc";
                       gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
                       linux,default-trigger = "ide-disk1";
               };
	};
	regulators {
		compatible = "simple-bus";
		#address-cells = <1>;

> Also, do you know any implementation of a monitor
> to trigger the red light on events from hdd, or
> temperature? I would image an mcm-daemon to make
> the red light blink on overheating, or stay full
> red on disk failing.
>

There was an effort to get this box mcm-daemon working. See the release thread info, and also look at posts from MM and Peacemaker in this thread:

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

Credits:
...
- Thanks to MM and Peacemaker who have developed and tested the mcm-daemon in: WD MyCloud Mirror Gen2 (BWVZ, GrandTeton). I plan to investigate and make use of MM and Peacemaker works, hopefully for all of WD Mycloud boxes.
....

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



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

Thank you, already understood your patch and the inner working.

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

As you can see, I set the trigger on gpio mode to light up the blue led, but cannot understand how to set the gpio to check against changes.
The only way I managed to obtain that result is to set gpio property of the led, once the device has started.
Any idea?

If you're looking for the behavior to change when a drive is inserted you could create a udev rule that changes the trigger. You could create a corresponding one for when it's removed for that matter.

If this device has drive-detect GPIOs you could also use that to signal the change.

perhaps easier than both of the above would be writing a daemon script that checks for a drive every few seconds and changes the trigger appropriately.

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

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.