Tag Archives: debian

Debian on WD EX2100

The Western Digital My Cloud EX2100 is a dual-bay NAS based on the Marvell Armada 385 dual core ARMv7 CPU first released in 2015.

In terms of NAS devices available in 2017, it isn’t very special. I would say the only major differences between most other devices in the 2 bay category are:

  • Dual Gigabit Ethernet
  • Screwless and trayless hard drive installation

The dual GigE interfaces are what attracted me to the device over competitors like the Zyxel NAS326 and Western Digital’s own MyCloud EX2 Ultra.

Unlike some other NAS bundles, it’s possible to buy the EX2100 without drives, so you can add your own preferred 3.5″ SATA hard drives. I bought a refurbished unit for 110€, which seems typical for a device with these features. For some reason the resale price of these units has skyrocketed since I bought mine in mid-2017. I personally would not pay more than 150€ for such a device. If you get into the higher price range of these SOHO devices, you’re almost always going to get better value for your money building your own NAS using standard x86 components (such as the HP MicroServer G7/Gen 8/Gen 10) and a distribution like FreeNAS or OpenMediaVault.

Since the vendor supplied firmware is almost always a pile of unsightly hacks, I set to work investigating into how to put a better operating system on the EX2100. If you stick around to the end, you’ll see this particular product also has its share of unfortunate hardware design decisions…

Before we get into anything about u-boot or the operating system, we need to talk about kwboot.

kwboot stands for “Kirkwood boot”

Kirkwood is an ARMv5 SoC from Marvell around 2008-2009 that started out in the SheevaPlug (what single board computers were before the creation of the Raspberry Pi) and sooner or later found its way into a lot of NAS devices like the D-Link DNS320 and the Zyxel NSA320.

Coming back to the near-past (2015), and we have the Western Digital EX2100/4100 which use the Marvell Armada 385/388 CPU, which is a dual-core ARMv7 design. However it was known that the Armada SoC could boot from serial because of the SolidRun ClearFog. But the ClearFog uses DIP switches to set the boot source, and most (all?) consumer devices lack these.

ClearFog Pro boot source selection DIP switches

It turns out it is possible to kwboot consumer devices based on the Armada 38x, however you need to apply this patch to kwboot to parse the response from the Armada CPU, which differs from the Kirkwood response. Unfortunately the patch broke Kirkwood compatibility, and was seemingly never merged into u-boot mainline. However, you can still apply it to the kwboot source in u-boot and compile kwboot for use with Armada CPUs.

Once you have patched kwboot, you can use it to test new versions of u-boot via a USB to uart adapter:
$ ./kwboot -f -t -B 115200 /dev/ttyUSB0 -b u-boot-uart.bin -s 0 -q 1

There are some synchronization issues with the magic sequence, so it often takes several attempts before successfully loading via kwboot. A dead giveaway that you need to power cycle the device and try again is when you immediately see u-boot output in the console instead of “Sending boot image…”

A successful attempt should look similar to the following:
$ ./kwboot -f -t -B 115200 /dev/ttyUSB0 -b u-boot-a38x-Yosemite_2014T3_PQ-nand-uart.bin -s 0 -q 1
Sending boot message. Please reboot the target...-�$�"Ufw�$�"U����$
Dfw�$�"U�\�$�"U����$�DUf�$�"Uw��"U����$4"U���$�"Uw�$�"U���$�DUf|fD�&T���$�"U�E�$�"Df3DD�DU�E7$�"U����$4"U���$�"U�E�4"U�/[email protected]� ��$DUw�$�"U����$�DUff�$�"D��fD$U��
Sending boot image...
0 % [......................................................................]

Once kwboot works, you can safely proceed to testing u-boot modifications without the risk that you brick your device, as kwboot runs code in memory without modifying the contents of NAND.

Unfortunately mainline u-boot doesn’t support this device, although similar devices are supported, such as the Turris Omnia (Armada 385) and Solidrun Clearfog Pro (Armada 388). It’s no surprise that attempting to kwboot a build of mainline u-boot for these targets on the EX2100 doesn’t work. So currently we have no choice but to use the u-boot source from Western Digital’s GPL archive.

The stock u-boot on the device does not support saveenv. Without modifying NAND, it is possible to boot Linux from USB, however this requires using the uart console and manually entering the boot parameters on each boot.

Naively modifying the WD u-boot source to enable the saveenv command results in corruption of the kernel uImage since someone at WD set the environment offset to 5MB and this is beyond the u-boot partition, corrupting the uImage.

However it is possible to modify the WD u-boot source to save environment variables within the 5MB allocated for u-boot. This requires reflashing u-boot to the device. Before you replace the stock u-boot on your device, you should take a backup of the u-boot region of flash. This can be done from within the Western Digital firmware, but requires a USB to UART adapter and a header soldered to the PCB:
# nanddump --noecc --omitoob -f mtd0.bin /dev/mtd0

Remember to copy this file somewhere off-device, such as a USB key, for safe keeping!

The general steps to replace the stock u-boot are:

  1. kwboot a modified u-boot which saves environment variables within u-boot region
  2. Inside u-boot, run saveenv
  3. Boot Debian from USB or SATA
  4. Dump u-boot env to a file (using nandread)
  5. Erase u-boot portion of mtd0 (using flash_erase)
  6. Flash new u-boot (using nandwrite)
  7. Restore u-boot environment variables (using nandwrite)
  8. Reboot

Dump the u-boot env to a file:
# nanddump -s 0x100000 -l 0x80000 -f ubootenv.bin /dev/mtd0

Erase the u-boot portion of mtd0 and flash the new u-boot to NAND:
# flash_erase /dev/mtd0 0 8
# nandwrite -p /dev/mtd0 u-boot-a38x-Yosemite_2014T3_PQ-nand.bin

Restore u-boot environment variables:
# nandwrite -p /dev/mtd0 -s 0x100000 ubootenv.bin

Integrated MCU
Western Digital decided to use an external microcontroller to handle certain system management functions such as fan control, LED control, and power on/off.

Sadly the microcontroller uses a proprietary and undocumented protocol for communication, and as it turns out this protocol can differ even between Western Digital products!

For the Western Digital EX2100 and EX4100, the integrated microcontroller communicates on ttyS1 at 115200n8, unlike other Western Digital NAS products whose microcontroller communicates at 19200n8.

Thankfully, some of the commands are common, so once communication with the microcontroller has been established, fan control and temperature monitoring are functional. Fan control and temperature monitoring are available through a userspace daemon called “mcm-daemon” (MyCloud Mirror daemon). I have forked the mcm-daemon repository on GitHub and made modifications to support the EX2100/4100.

LED control and power on/off are still a work in progress as the reverse engineered commands used on other WD products do not work on the EX2100/4100.

The user bodhi at Doozan forums does a great job of providing pre-built Debian images for a variety of Marvell Armada based NAS devices.

Usually I would link to the excellent instructions bodhi normally writes for installing Debian, but since they don’t have the EX2100, writing the instructions fell to me.

But sadly I haven’t got installation instructions written because I’ve bricked my EX2100.

Weltrend WT61P8
Let’s revisit this mystery microcontroller in charge of so many tasks in the EX2100.

Well, after reading that Western Digital My Cloud products contained a backdoor and multiple vulnerabilities I thought I would go and update the WD firmware before continuing to write the Debian installation instructions. The WD firmware resides on the built in 512MB of EMMC, while Debian lives on a USB device, so the installation of Debian does not replace the original WD firmware.

During the WD update process I noticed that it was also updating the firmware of the Weltrend:

16479 root 6624 S /var/www/cgi-bin/system_mgr.cgi
16480 root 2560 S sh -c cd /usr/local/upload/;upload_firmware -a -n 'nas-new-firmware' >/dev/null;cd /
16481 root 4544 S upload_firmware -a -n nas-new-firmware
19436 root 49120 R mcu_upgrade -r -f /tmp/uP_0.bin
19552 root 2720 R ps ax

How curious! Since the Weltrend is very undocumented I was eager to learn more about the firmware it runs.

I found out a good deal more than I’d expected. Firstly, the mcu_upgrade binary contains some interesting strings. Here is a short sample of strings in the binary:

Enable ISP
Page Erase
Set Address High Byte

The MCU firmware also has some very interesting strings. Here is a short sample of strings in the firmware:

nick 1111
nick 2222
nick 3333
nick 4444
Cannot Copy
from Camera
Cannot Move
Almost Full
Limit Reached
nick pwr on
nick pwr off 1
nick pwr off wol
Welcome to
RTC_ALARM pwr on

Googling the part number “WT61P8” lead to a very interesting datasheet (PDF) describing the microcontroller in detail.

What I found from the datasheet was… not anything I expected to find.

It’s a Turbo 8052 CPU with ~48KB of built-in EEPROM (this is my guess based on the part number and size of firmware mcu_upgrade was sending) and it’s a “Flat Panel Display Control Sub-MCU”

Most information about Weltrend microcontrollers is on Russian language forums dedicated to TV repair. The most common use of this MCU is in Samsung TVs for power management, since it includes an IR receiver and HDMI CEC capabilities.

They do support ISP (In-system Programming) via I2C, if you have the right hardware. There are quite a few Russian articles and YouTube videos on how to program these chips in TVs.


After reading about WD’s numerous firmware vulnerabilities and a back door, which were also present in D-Link NAS products (implying a shared code base or same third party contractor), and then learning that the microcontroller in charge of power management for the EX2100 (and other My Cloud products) was intended for power management in LCD TVs:

My final $0.02: this thing is an utter bodge job in both hardware and software! Don’t buy one of these. It doesn’t matter that can be persuaded to run Debian, it’s terrible value for the price.

You’re far better off getting an older PC and running FreeNAS or OpenMediaVault. Older corporate tower PCs with 2nd or 3rd gen Intel processors like the Dell Optiplex line can easily be purchased for under $150 from places like eBay.

If power consumption is really important to you, then I would recommend something like the Rock64 which has Gigabit Ethernet and excellent USB 3.0 performance with Armbian. It also comes with more RAM than the EX2100 (1/2/4GB while EX2100 has only 1GB) and is a quad core aarch64 instead of dual core armv7!

Best of all, an older PC or Pine64 is going to be cheaper than the EX2100 (or ludicrously more expensive 4 bay EX4100) anyway.

If I ever manage to restore the Weltrend firmware rest assured there will be a follow up article with both the journey of unbricking and instructions to install Debian. Until then, I’m going to take the HDDs I planned to use in the EX2100 and build a FreeNAS in an old PC. ✌️

Building the Arietta G25 Kernel

I’m using the Arietta G25 for a project of mine. Earlier I described how to build a bootloader for the 256MB version of the board.

Today I’m going to describe how to build the kernel for the Arietta G25. I needed ADC support as well as modules for some USB to ethernet adaptors that weren’t included in the kernel image ACME Systems provides.

First off you will need to install the toolchain to build armel binaries. ACME Systems has a page describing how to install the ARM9 toolchain. Here’s the short summary:

$ sudo apt-get install emdebian-archive-keyring libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi gcc-arm-linux-gnueabi g++-arm-linux-gnueabi u-boot-tools libncurses5-dev

Once you have the environment setup it’s time to checkout the kernel and build. This is the Jenkins script I use to build the Arietta G25 kernel:

if [ ! -d "linux-3.14.7" ]; then
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.7.tar.xz -O linux-3.14.7.tar.xz
tar xvfJ linux-3.14.7.tar.xz
cd linux-3.14.7
wget http://www.acmesystems.it/www/compile_linux_3_14/acme.patch -O acme.patch
patch -p1 < acme.patch

wget https://watchmysys.com/blog/wp-content/uploads/2014/08/linux-at91.config -O .config
wget https://watchmysys.com/blog/wp-content/uploads/2014/08/arietta_256m_ikconfig.patch -O arietta_256m_ikconfig.patch
patch -p1 < arietta_256m_ikconfig.patch
cd linux-3.14.7
make ARCH=arm clean
CPUS=$(cat /proc/cpuinfo | grep -c "processor")

wget https://watchmysys.com/blog/wp-content/uploads/2014/08/acme-arietta-adc.dtb -O arch/arm/boot/dts/acme-arietta.dtb
make -j$CPUS ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage
make modules -j$CPUS ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
make modules_install INSTALL_MOD_PATH=./modules ARCH=arm
mkdir -p modules/boot
cp arch/arm/boot/zImage modules/boot/
rm linux-3.14.7-arietta.tar.bz2
tar -C modules -cjvf linux-3.14.7-arietta.tar.bz2 lib/ boot/

The above commands are available in a bash/Jenkins script at the bottom of this post.

Installation is fairly simple, you need to mount the sdcard /boot and / partitions on your computer and then run:

tar -C /path/to/sdcard -jxvf linux-3.14.7-arietta.tar.bz2

My kernel configuration includes the Atmel ADC driver as a module (at91_adc) so you can unload/reload it (possibly to save power). It also includes the dm9601 and sr9700 modules for the Davicom DM96xx USB 2.0 10/100M Ethernet Adaptor, which is an inexpensive USB to ethernet adaptor available online (such as this one).

If you want to generate your own dtb (for instance enable PWM instead of the ADC) you can do that at this ACME Systems page.

Build script: linux-at91.sh
Kernel and modules: linux-3.14.7-arietta.tar.bz2
Kernel Config: linux-at91-3.14.7.config

Building the Banana Pi LeMaker Kernel

I recently bought a Banana Pi because I wanted something more powerful than a Raspberry Pi (and because I had store credit to use up).

I wanted to run Debian on it, but not the Raspbian distribution provided by Lemaker because I find it’s too resource heavy for what I will be using my Banana Pi for. I followed Christian Bock’s excellent blog post on how to build a Debian rootfs for the Banana Pi.

More pre-built SD card images are coming out for the Banana Pi, but I wanted to use a spare 1GB microSD card and no one provides images that small, so I went and built my own.

As Christian noted in his blog post, the sunxi kernel sources do not work well on the Banana Pi as they contain a broken sunxi ethernet driver. The NIC is unstable when running at gigabit speeds (my testing showed approximately 60% packet loss). A definite deal-breaker if you need reliable network access. LeMaker was a bit slow in releasing their kernel source, but after users complained it was released on github.

Prerequisites for building the kernel are outlined in LeMaker’s wiki page. Basically you need the following packages:

build-essential u-boot-tools uboot-mkimage binutils-arm-linux-gnueabihf gcc-4.7-arm-linux-gnueabihf-base g++-4.7-arm-linux-gnueabihf gcc-arm-linux-gnueabihf cpp-arm-linux-gnueabihf libusb-1.0-0 libusb-1.0-0-dev git wget fakeroot kernel-package zlib1g-dev libncurses5-dev

This is the Jenkins script I use to build the LeMaker kernel for the Banana Pi:

if [ ! -d "linux-bananapi" ]; then
git clone -b bananapi-3.4 https://github.com/LeMaker/linux-bananapi.git
cd linux-bananapi
git pull
wget https://watchmysys.com/blog/wp-content/uploads/2014/08/linux-bananapi.config -O .config
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- clean
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=output modules_install
mkdir -p output/boot/
cp arch/arm/boot/uImage output/boot/
tar -C output -cjvf ../linux-bananapi-3.4.90.tar.bz2 boot/ lib/

I’ve included the above commands in a script at the end of this post. I’ve added additional comments explaining the what and why for people who don’t arbitrarily trust strangers on the internet.

Installation is fairly simple, you need to mount the sdcard /boot and / partitions on your computer and then run:

tar -C /path/to/sdcard -jxvf linux-bananapi-3.4.90.tar.bz2

This will extract /boot/uImage and the kernel modules to /lib/modules/3.4.90-00261-gb3b7287

My kernel configuration includes the sunxi ethernet driver as a module (sunxi_gmac) so that you can unload/reload it if necessary. This means you need to use both the uImage and the modules provided or you will not have network connectivity.

Build script: bash/Jenkins build script
Kernel and modules: linux-bananapi-3.4.90.tar.bz2
Kernel Config: linux-bananapi-3.4.90.config

ACME Systems Arietta G25 bootstrap

I’m using the ACME Systems Arietta G25 256MB model for a project I’m working on, but their website only provides a bootstrap for the 128MB version. Let’s build a bootstrap for the 256MB version.

The instructions on their website are for Ubuntu 13.10, but I run Debian so these instructions are for Debian 7.

As per their instructions you need to enable the emdebian repository:

[email protected]:~$ sudo -i
[email protected]:~# apt-get install emdebian-archive-keyring
[email protected]:~# echo "deb http://www.emdebian.org/debian/ squeeze main" > /etc/apt/sources.list.d/emdebian.list
[email protected]:~# echo "deb http://ftp.us.debian.org/debian/ squeeze main" >> /etc/apt/sources.list.d/emdebian.list

Even though I’m running Wheezy the repositories in /etc/apt/sources.list.d/emdebian.list are for squeeze. This is necessary due to unavailable packages on Wheezy which are present in squeeze. Please see the Emdebian page for an explanation.

[email protected]:~$ sudo apt-get install libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi u-boot-tools libncurses5-dev gcc-4.4-arm-linux-gnueabi cpp-4.4-arm-linux-gnueabi g++-4.4-arm-linux-gnueabi

Clone the bootloader from ACME Systems:

[email protected]:~$ git clone git://github.com/linux4sam/at91bootstrap.git
[email protected]:~$ cd at91bootstrap
[email protected]:~/at91bootstrap$: git checkout origin/at91bootstrap-3.x -b at91bootstrap-3.x
[email protected]:~/at91bootstrap$: wget http://www.acmesystems.it/www/compile_at91bootstrap/acme.patch -O acme.patch
[email protected]:~/at91bootstrap$: patch -p1 < acme.patch
[email protected]:~/at91bootstrap$: make mrproper
[email protected]:~/at91bootstrap$: make acme_ariettasd_linux_zimage_dt_defconfig
[email protected]:~/at91bootstrap$: wget https://watchmysys.com/blog/wp-content/uploads/2014/07/256mb.patch_.txt -O 256mb.patch
[email protected]:~/at91bootstrap$: patch -p1 < 256mb.patch
[email protected]:~/at91bootstrap$: make CROSS_COMPILE=arm-linux-gnueabi-

Now copy the generated zimage to the boot partition on the sdcard (/dev/sdX1, mounted here at /tmp/arietta/boot):

[email protected]:~/at91bootstrap$: sudo cp binaries/acme_arietta-sdcardboot-linux-zimage-dt-3.6.2.bin /tmp/arietta/boot/boot.bin

Boot the Arietta G25. You should have 256MB of RAM available now.

The 256mb.patch does two things to the at91bootstrap:
1) Changes the size of the memory initialized from 128MB (0x8000000) to 256MB (0x10000000)
2) Changes the Kernel command line to mem=256M so the additional memory is utilized by the Linux kernel

If you aren’t interested in setting up a build environment, you can find the 256MB boot.bin: here. WordPress does not allow .bin files, so you will need to rename boot.bin_.zip to “boot.bin” before copying it to the sdcard boot partition.

Additionally if you want to automate building the bootstrap with Jenkins, here is a shell script you can put into a new Jenkins project to automatically build the zimage. You will need to manually install the toolchain (described above).