WD MyCloud Gen2 (Glacier, Armada 375)

Hi

With every little f*** up i learn something new

I found new version of u-boot in gpl source code (binary only) and... got simple flash programmer to fix broken flash ;-)
I don't know if they differ somehow, but there's no setenv but bootargs trick works.

Is it possible to convert u-boot bin to kwb file?
Is it possible to change some internal string values and recalculate (if needed) checksums?

This is the latest released gpl code i could find https://downloads.wdc.com/gpl/WD_MyCloud_GPL_v2.31.204_20191206.tar.gz

> With every little f*** up i learn something new

:)

>
> I found new version of u-boot in gpl source code
> (binary only) and... got simple flash programmer
> to fix broken flash ;-)
> I don't know if they differ somehow, but there's
> no setenv but bootargs trick works.

You meant there is no saveenv?

> Is it possible to convert u-boot bin to kwb file?

Yes. mkimage is used for that purpose in the u-boot make scripts.

> Is it possible to change some internal string
> values and recalculate (if needed) checksums?

Yes, find the checksum location in the header (iirc it is at the end).

> This is the latest released gpl code i could find
> https://downloads.wdc.com/gpl/WD_MyCloud_GPL_v2.31.204_20191206.tar.gz

Cool. I'll take a look some time in the next few days.

BTW, I've built the MVEBU kernel with xz compression and it was shrunk to 4.9M. And it seems to have a side benefit of dealing with a kernel "regression" in uncompression debug (still investigate this issue so not sure what I am seeing is correct yet, but I am very certain that this bug affect the Kirkwood kernel).

So thanks for the suggestion, xz will be used in the next release after I've tested other Armada and Kirkwood boxes.

-bodhi
===========================
Forum Wiki
bodhi's corner

Hi guys, I have a WD MyCloud Gen2 (Glacier, Armada 375) board and I was looking to install a fresh Debian image to it. I have attached a 1TB Sata 3 notebook HDD.

I received this board for a kind of gift, and I'm totally playing with it. My goal is to have a fully working and updated Debian to run samba and qbittorrent (or any arm optimized torrent client).

Following the steps from fox_exe, I was not able to recover WD original firmware. I was reading a lot and finally I got it working sourcing some img files from the original partitions. So I managed to get it working and updated to the latest firmware.

Then I followed the steps to install a debian jessie from fox_exe, and again, it did not worked (I always get yellow led). I have tried to apply the kernel 4.10.plus, I got blue led, nothing. I restored the /boot folder to start with 3.10 again and magically worked out. Green led for me :)
So now I have Jessie working.

I started reading all this thread, which also lead me to https://forum.doozan.com/read.php?2,32146 and my understanding it that currently does not work (I'm wrong?). So, I'm offer my device to make all tests and finally add this device to the list.

I did not soldered pins yet to the board to access UART. Would you need me to do that for testing? I would prefer to not mess with the SPI flash if possible :)

Thanks in advance!

faktorqm,

It should work following what osa did to set up and use this DTS. I have not added this to the kernel, but will do so.

https://forum.doozan.com/read.php?2,94839,95014#msg-95014

I'll compile it for you if you've not sure how.

Note that currently you have to install it using USB.


> I started reading all this thread, which also lead
> me to https://forum.doozan.com/read.php?2,32146
> and my understanding it that currently does not
> work (I'm wrong?).

The older rootfs (Debian stretch) Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 will work.

Quote
https://forum.doozan.com/read.php?2,32146
Updated 23 Aug 2017:

This Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded

But you need a new DTB compiled from osa's DTS as mentioned above.


> I did not soldered pins yet to the board to access
> UART. Would you need me to do that for testing? I
> would prefer to not mess with the SPI flash if
> possible :)

Right. You need UART to install. And you cannot avoid messing with flash, because the set up will involve adding a new u-boot env to get it boot from USB.

So with UART connected, you will need to run kwboot to test the loading of u-boot image (mtd0) over serial. This is the rescue mechanism in case things go wrong.

-bodhi
===========================
Forum Wiki
bodhi's corner

Thanks a lot for your answer!

I would love if you can explain the steps to make this (or pointing me a guide to read) as this will be my first time flashing uboot through UART. As far as I understand this is a kind of standard mechanism across this kind of devices (routers for example)

Besides to this case in particular, I'm interested to learn how uboot works and what is the purpose of that, what uImage file does and so on. So far I got (or at least I think I got which is not the same xD) zImage as the kernel image (same as pc), and root fs as usual file structure.

I will start soldering pins and prepare a trusty serial-usb bridge to start seeing something. Thank you! Regards!

OK so summarizing

- Solder pins to USB and test the serial console (8N1 115200 right?)
- Change uboot -> kwboot (this thread is correct? I don't see this device listed but I assume that one of them could be compatible https://forum.doozan.com/read.php?3,12381 )
- Grab a USB and use 5.3.5-mvebu-tld-1 but with a kernel including the OSA device tree. (however you mentioned Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2 with a new DTB from the DTS provided by OSA, so what should I use? 5.3.5 or 4.12.4?)

Thanks again! Bye bye!

faktorqm,

> - Solder pins to USB and test the serial console
> (8N1 115200 right?)

Right.

> - Change uboot -> kwboot (this thread is correct?
> I don't see this device listed but I assume that
> one of them could be compatible
> https://forum.doozan.com/read.php?3,12381
> )

No, that won't work. Those are Kirkwood SoC u-boots. This box is Armada 375.

There is no u-boot binary for this box available at the moment. So the mtd0 is the binary to use. First you will need to log into stock OS and dump mtd0 to a file. And then that file is used in running kwboot.

> - Grab a USB and use 5.3.5-mvebu-tld-1 but with a
> kernel including the OSA device tree. (however you
> mentioned
> Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2
> with a new DTB from the DTS provided by OSA, so
> what should I use? 5.3.5 or 4.12.4?)

This box has a limitation of 5MB for uImage (that's how stock u-boot boot handle the kernel uImage, as osa found out). Kernel 5.3.5-mvebu-tld-1 uImage is too big. So use Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2.

Later, after you got it working, then upgrade to 5.10.7-mvebu-tld-1 kernel.

> my first time flashing uboot through UART.

No, we will not do that. u-boot image (i.e. mtd0 dump) will be loaded over UART using kwboot to RAM memory, and then will be executed by the box BootROM (automatically). The u-boot image on flash (mtd0) is untouched by this process.

-bodhi
===========================
Forum Wiki
bodhi's corner

root@debian:~# uname -a
Linux debian 5.10.7-mvebu-tld-1 #1.0 SMP PREEMPT Sat Jan 16 19:49:06 PST 2021 armv7l GNU/Linux

Kernel fits into 5MB limit and debian can be installed without serial cable and breaking the case
Stay tuned! Tutorial is coming soon



Edited 1 time(s). Last edit at 02/01/2021 09:51AM by osa.

Thanks osa,

> Kernel fits into 5MB limit and debian can be
> installed without serial cable and breaking the
> case
> Stay tuned! Tutorial is coming soon

That would be great!

-bodhi
===========================
Forum Wiki
bodhi's corner

osa,

> This is the latest released gpl code i could find
> https://downloads.wdc.com/gpl/WD_MyCloud_GPL_v2.31.204_20191206.tar.gz

I could not find where u-boot source is in this tarball. Have you?

-bodhi
===========================
Forum Wiki
bodhi's corner

without serial? those are good news!! I will wait for your tutorial before start soldering pins to uart :)

@faktorqm
Yes, just ssh and some chroot magic ;-)
Serial will be needed only if something went wrong

osa,

> Yes, just ssh and some chroot magic ;-)

Sounds a bit overkill :) usually there is no need to do chroot. Just being root user is most often enough to install from stock OS.

-bodhi
===========================
Forum Wiki
bodhi's corner

It's still work in progress

https://translate.google.com/translate?sl=pl&tl=en&u=http://osowiecki.net/debian-na-wd-my-cloud-2-gen/

I believe all that stuff can be run as a single script so probably easiest way to install.
Now it's time to write recovery manuals ;-)

Comments and suggestions are appreciated



Edited 2 time(s). Last edit at 02/02/2021 08:23PM by osa.

osa,

Well done!

Quote

4. Chroot and the kernel
We jump into the chroot for a moment so that we can follow the guide
mount -t proc none /mnt/HD/HD_a2/proc/
mount -o bind /dev /mnt/HD/HD_a2/dev/
chroot /mnt/HD/HD_a2/
We are in chroot. We issue orders one by one
sed -i '/rootfs/c\/dev/sda2 / ext4 noatime,errors=remount-ro 0 1' /etc/fstab
cd /boot
apt-get remove flash-kernel
dpkg -i linux-image-5.10.7-mvebu-tld-1_1.0_armhf.deb

cp -a zImage-5.10.7-mvebu-tld-1 zImage.fdt
cat dts/armada-375-wd-mycloud-gen2.dtb >> zImage.fdt
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.10.7-mvebu-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.10.7-mvebu-tld-1 -d initrd.img-5.10.7-mvebu-tld-1 uInitrd

sed -i '/mtd1/c\/dev/mtd0 0xf0000 0x10000 0x10000 1' /etc/fw_env.config

fw_setenv bootargs 'root=/dev/sda2 console=ttyS0,115200'

exit

I see why you have this step 4 using chroot. The intent is to install the new kernel at the same time.

Sometime it is easier to avoid chroot and keep the kernel in 5.2.9, if the DTB is already in the basic rootfs . In this case, the DTB is not yet in the 5.2.9 rootfs. So I think it is OK either way.

- To write this step with chroot to install kernel 5.10.7. Like you did.
Or
- to keep it simple, attach the armada-375-wd-mycloud-gen2.dtb to the instruction, so users can do this entire Step 4 while being root user, and use that DTB to create a 5.2.9 uImage.

I usually avoid chroot in the instruction, because this rootfs preparation (Step 4) could be done in a different Linux host while being root (except for the fw_setenv above), which normally how it is created.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 02/02/2021 10:31PM by bodhi.

Hi OSa! excellent job!

I have a question, sorry for bother you

In this step:

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.10.7-mvebu-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.10.7-mvebu-tld-1 -d initrd.img-5.10.7-mvebu-tld-1 uInitrd

It's possible to avoid this step and provide uImage and uRamdisk files? I'm asking because it's what fox_exe did in his recipe, maybe doing a mixing from his instructions and yours the instructions will be limited to copy 3 files and uncompress rootfs.

I'm asking this because I'm thinking in the case that you grab this board without a disk and you need to start from scratch.

Well done Osa! keep in this way!

faktorqm,

> In this step:
>
> mkimage -A arm -O linux -T kernel -C none -a
> 0x00008000 -e 0x00008000 -n
> Linux-5.10.7-mvebu-tld-1 -d zImage.fdt uImage
> mkimage -A arm -O linux -T ramdisk -C gzip -a
> 0x00000000 -e 0x00000000 -n
> initramfs-5.10.7-mvebu-tld-1 -d
> initrd.img-5.10.7-mvebu-tld-1 uInitrd
>
> It's possible to avoid this step and provide
> uImage and uRamdisk files?

Not recommended. You do need to install the kernel so the uImage and uInitrd are consistent with the rootfs. You can run it that way, but the system is not complete.

-bodhi
===========================
Forum Wiki
bodhi's corner

bodhi Wrote:

> so the uImage and uInitrd are consistent with the
> rootfs. You can run it that way, but the system is
> not complete.

Expand further on what I said above.

The rootfs has kernel 5.2.9. So everything is in sync (i.e. initramfs is 5.2.9). Now the only file you need to create after the rootfs was extracted is the uImage.

That should be the new DTB appended to zImage (being root):

cp -a zImage-5.2.9-mvebu-tld-1 zImage.fdt 
cat dts/armada-375-wd-mycloud-gen2.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-mvebu-tld-1 -d zImage.fdt uImage

That's it, now the rootfs is done.

The entire process of creating rootfs can be done on a different Linux host that way.

-bodhi
===========================
Forum Wiki
bodhi's corner

OK I followed the steps with a minor changes. The google translator does not help me too much this time! :S

I logged this steps for two reasons, first to help if someone is using the fox_exe's image as I do as a departure point. Second to show what I did to you in case that this instructions does not work :) (spoiler alert: they did!)

Please check the attached file as the forum showed up an error message "The data that you have submitted to the server have been rejected, because it looks like they were posted by an automated bot."

I'm soooo happy :) Thanks a lot osa and bodhi!

faktorqm,

> I logged this steps for two reasons, first to help
> if someone is using the fox_exe's image as I do as
> a departure point. Second to show what I did to
> you in case that this instructions does not work
> :) (spoiler alert: they did!)

> I'm soooo happy :) Thanks a lot osa and bodhi!

Cool :) glad you got it working, and a well done installation test (thumbs up! or whatever the ASCII emoji for that!).

-bodhi
===========================
Forum Wiki
bodhi's corner

hi guys,

thank you very much for this thread and your hard work. here is my situation: i have 2 of these boxes. both of them were from ebay and i solder the uart pins. one is running fine with the instructions from osa / bodhi, i got bodhi's debian running very well on it.

root@debian:~# uname -a
Linux debian 5.2.9-mvebu-tld-1 #1 SMP PREEMPT Mon Aug 19 12:47:39 PDT 2019 armv7l GNU/Linux

on the other box seems u-boot to be broken. when i start it up, i got the following log over serial:

BootROM - 1.51
Booting from SPI flash
BootROM: Bad header at offset D4000000
BootROM: Bad header at offset D4200000
BootROM: Bad header at offset D4400000
BootROM: Bad header at offset D4600000
BootROM: Bad header at offset D4800000
BootROM: Bad header at offset D4A00000
BootROM: Bad header at offset D4C00000
BootROM: Bad header at offset D4E00000

so i decided to do a nanddump from the running box to boot the broken one with it:

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00010000 "u-boot"

nanddump -f /home/mtd0 /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 65536, page size 1, OOB size 0
Dumping data starting at 0x00000000 and ending at 0x00100000...

and it ended with no errors. i changed the boxes and even try to kwboot the broken one with the dump-file:

kwboot -t -B 115200 /dev/ttyUSB0 -b mtd0 -p
Sending boot message. Please reboot the target...-
Sending boot image...
  0 % [+++++++++++++++++xmodem: Bad message

or without the -p flag

kwboot -t -B 115200 /dev/ttyUSB0 -b /pxe/mtd0
Sending boot message. Please reboot the target.../
Sending boot image...
Bnf  0 % [+xmodem: Protocol error

I tried it several times and with the u-boot dump from osa (from the first page of this thread), too. but i always get these errors. can you help me bring these bricked device back to life, please.

Thx in advance, sLOID.

OK So let's continue with the setup. Following the Updated 10 Sep 2019 Instructions from Bodhi I did:

change root password: passwd

rm /etc/ssh/ssh_host*
ssh-keygen -A

apt-get update

And here I had a problem with date/time. apt-get told me that cannot update because the repositories are in the future. So I went to the ntp config (nano /etc/ntp.conf) and uncommented this lines:

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

then did /etc/init.d/ntp restart but did not solve the problem. I did ntpdate -s ntp.ubuntu.com and that solved the issue, after that I was able to update the repositories.

apt-get update
apt-get upgrade

Warning: Watch the apt-get upgrade progress. If the apt-get upgrade results in a new initramfs, the log would shows this message:

Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-5.10.7-mvebu-tld-1

So I did:
cd /boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.10.7-mvebu-tld-1 -d initrd.img-5.10.7-mvebu-tld-1 uInitrd

Now I got as my MAC address 00:00:11:22:33:44. Fortunately, I keep a record with the former MAC address because I assign the IP statically from the DHCP server according to the MAC address. So to solve this I did

/usr/bin/fw_setenv ethaddr 'XX:XX:XX:XX:XX:XX'

then restart using shutdown -r now and everything works like a charm. After restart the ntp works fine, and apt-get update works as it should.

I don't know how the MAC address is set/calculated on original firmware, but we should let the users know that they will need to take note of the MAC address before proceed with the Debian installation.

Thanks a lot again guys! Have a nice rest of the week!

faktorqm,

> And here I had a problem with date/time. apt-get
> told me that cannot update because the
> repositories are in the future.

You could set the system clock manually wih the date command. That should fix this problem.

>I did ntpdate -s ntp.ubuntu.com and
> that solved the issue, after that I was able to
> update the repositories.

ntpdate has been deprecated, but still available.

-bodhi
===========================
Forum Wiki
bodhi's corner

sLOID,

> so i decided to do a nanddump from the running box
> to boot the broken one with it:

I recall this box has SPI flash, you meant dd the mtd0 pafrtition to a file (nanddump is only for NAND flash).

> nanddump -f /home/mtd0 /dev/mtd0
> and it ended with no errors.

Strange that it gave no error. Are you sure that your box has NAND flash?


> kwboot -t -B 115200 /dev/ttyUSB0 -b mtd0 -p
> Sending boot message. Please reboot the
> target...-
> Sending boot image...
> 0 % [+++++++++++++++++xmodem: Bad message
> [/code]

Whenever you see this "xmodem: Bad message" error, do these 2 things:

1. Check the serial wires and make sure that it is not placed near the power plug or power cord.

2. Recall the kwboot command and execute it again immediately. Try to do this many times as you can until the handshake occurs so the image will be sent.

-bodhi
===========================
Forum Wiki
bodhi's corner

sLOID
I've recently got same error and user OSA provided me with solution .I've used external SPI programmer
get https://downloads.wdc.com/gpl/WD_MyCloud_GPL_v2.41.116_20201117.tar.gz

extract u-boot.bin. WD_MyCloud_GPL_v2.41.116_20201117\firmware\merge\

It's 929388 bytes so we have to glue it to the rest of orginal spi dump :

dd -if=wdc2.dump -of=temp.bin -skip=929388

then add our SPI data like MAC and serial to become fullflash (1MB)

cat temp.bin >> u-boot.bin

Program that u-boot.bin to SPI and will boot fine like mine did

br
nicefile



Edited 1 time(s). Last edit at 02/19/2021 01:27PM by nicefile.

nicefile,

Good job!

However, in this case with kwboot "xmodem: Bad message', it is quite feasible to run kwboot successfully so no need for SPI programmer yet.

-bodhi
===========================
Forum Wiki
bodhi's corner

osa,

Have you finished the Installation Instruction yet? I have a suggestion for step 4 in the above post. But if you'd like to keep it the way you did with chroot inside stock OS, it is OK too.

https://forum.doozan.com/read.php?2,94839,115764#msg-115764

-------

When you've finished, could you post it here (feel free to include a link to your website and state that it is identical). So I can include your Installation Instruction in the kernel 5.10.7 release and the list in the 1st post of

Linux Kernel 5.10.7 MVEBU package and Debian armhf rootfs

Quote

Installation Instruction for specific boxes:

Zyxel NAS326 (Armada 380) Installation: see this thread.
WD My Cloud EX2100 (Armada 385) Installation: see this thread.
GlobalScale Technologies Mirabox (Armada 370) Installation: see this thread
Thecus N2350 (Armada 385) Installation: see this thread.
Synolgy RS816 (Armada 385) Installation: see Installation with USB rootfs (Section I). And see Installation with HDD rootfs (Section II).
Netgear RN102 (Armada 370) Installation: see this thread
Synolgy DS116 (Armada 385) Installation: see Installation with USB rootfs (Section I). And see Installation with HDD rootfs (Section II)
HP Thin Client T5335z and Dell Wyse T10/T50 (Armada 510, aka Dove) Installation: see this thread

WD MyCloud Gen2 (Glacier, Armada 375)

-bodhi
===========================
Forum Wiki
bodhi's corner

Hello, thanks all for the various work, actually i'm on Debian 10 with kernel 4.15.0-rc6 by fox_exe but i just want to update the kernel to the bodhi one (expecially cause of issues with iptables and docker) do you have a faster way for me without fully resetting the drive?

EDIT:
nvm, i tried following faktorq steps, but i messed up something (probably this is not needed as the rootfs (with boot folder) is still on sda3 on the fox_exe debian

fw_setenv bootargs 'root=/dev/sda2 console=ttyS0,115200'

), so started with the recovery USB miniOS by fox_exe and gluing up post around (basically i've chrooted from in the miniOS to generate image) i made a uImage and uRamdisk for the kernel 5.2.9-mvebu-tld-1 that can be used with the bodhi rootfs (and than upgrade to the latest kernel)

PS:
to recover MAC address (fw_printenv ethaddr returns 00:11:22:33:44:55):

ip link set dev eth0 address $(dd if=/dev/mtd0 bs=1 skip=1046528 count=17 2>/dev/null)

and probably also need to edit in the 8th row of /root/set_persistent_mac_address

EDIT:
btw also fully upgraded to 5.11.7 kernel, the max size to look is 5242880 right?

root@debian:/boot# ll | grep uIma
-rw-r--r--  1 root root  5070972 Apr  7 14:44 uImage5.2.9
-rw-r--r--  1 root root  5138284 Apr  7 14:58 uImage5.10.7
-rw-r--r--  1 root root  5156052 Apr  7 14:54 uImage5.11.7

ah, another thing that is written nowere clearly uInitrd must be renamed to uRamdisk on this device.



Edited 4 time(s). Last edit at 04/07/2021 05:37PM by FrancYescO.

Thanks FrancYescO for your insight. The steps added by me, are the steps posted by bodhi (or osa I don't remember) modified in order to work with fox_exe's based image. That worked like as a charm on my device, but sometimes the device order is not exactly the same. As I have some experience in GNU/Linux systems, probably I checked things without posting it on the steps. Doing with chroot from other boot or booting the fox_exe's image, is (almost) exactly the same. you will have the same result. Thank you! Regards!

FrancYescO,

> to recover MAC address (fw_printenv ethaddr
> returns 00:11:22:33:44:55):
>

> ip link set dev eth0 address $(dd if=/dev/mtd0
> bs=1 skip=1046528 count=17 2>/dev/null)
>

> and probably also need to edit in the 8th row of
> /root/set_persistent_mac_address

That's not as good as getting from ifconfig. MAC address can be changed, and the one that is currently used in the NIC is the one should be used.

So one important step in installation is to make sure that the current MAC address is the correct one. If it is not, then correct it permanently in u-boot env.

Sometime you want to change the MAC address to a local MAC address of your own choosing to reduce fingerprint. Set the env ethaddr to that.

-bodhi
===========================
Forum Wiki
bodhi's corner