I thought I would finally get around to permanently using Debian on my EX2100. This means fixing up the DTB to support the dual gigabit NICs, and getting the mcm-daemon running to make the fan quiet.

Unfortunately, I cannot get either to work! Here the is networking config on the EX2100:

Load WD Yosemite Serdes Config:
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  06   |  SATA0	|
 |   1    |  05   |  PCIe0	|
 |   2    |  06   |  SATA1	|
 |   3    |  05   |  USB3 HOST1	|
 |   4    |  05   |  USB3 HOST0	|
 |   5    |  00   |  SGMII2	|
 --------------------------------
PCIe, Idx 0: detected no link
High speed PHY - Ended Successfully
...(later)
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x00     |
| egiga1 |   RGMII   |   In-Band    |
| egiga2 |   SGMII   |     0x01     |

The EX2U DTB posted here works with the SGMII NIC, but neither RGMII NIC works if you change the status from "<disabled>" to "<okay>":

send_packet: Network is down
dhclient.c:2255: Failed to send 300 byte long packet over eth1 interface.
receive_packet failed on eth1: Network is down

Also, it seems that the MCU is not connected via serial@12100? mcm-daemon doesn't work at all:

# /usr/bin/mcm-daemon -f -c /etc/mcm-daemon.ini 
mcm-daemon[2737]: Server startup success on port 57367
mcm-daemon[2737]: Got no stop magic, but read 1 bytes!
mcm-daemon[2737]: Got no stop magic, but read 1 bytes!
mcm-daemon[2737]: Got no stop magic, but read 1 bytes!
mcm-daemon[2737]: Got no stop magic, but read 1 bytes!
mcm-daemon[2737]: Error sending DeviceReady command, exit!

Doesn't really make much sense, since it seems that WD are writing to serial 1 in u-boot to communicate with the MCU.

board/mv_ebu/a38x/mv_main_a38x.c:

        printf("Enable HD1\n");
        serial2_putc(0xfa);
        serial2_putc(0x6);
        serial2_putc(0x1);
        serial2_putc(0x0);
        serial2_putc(0x1);
        serial2_putc(0x1);
        serial2_putc(0xfb);

board/mv_ebu/common/USP/mv_serial.c:

#if 1   //ALPHA_CUSTOMIZE
void serial2_putc(const char c)
{
#if defined(CONFIG_MV_SMP) || (defined(MV78XX0) && defined(MV78200))
        if (c == '\n')
                mvUartPutc((whoAmI())%2, '\r');

        mvUartPutc((whoAmI())%2, c);
#else
        if (c == '\n')
                mvUartPutc(1, '\r');

        mvUartPutc(1, c);
#endif
}
#endif

I've confirmed that uart 0 is connected to the debug header on the board, writing to that kills your uart session. It seems that uart 1 might not be connected to the MCU, or the MCU isn't responding?

@bodhi: any ideas about the above?

I've also re-built u-boot to save environment to 0x100000 and to not overwrite bootcmd on boot as WD's source so kindly does. Find the kwboot and nand versions attached.

Edit: looks like my mcm-daemon woes might be because the MCU has lost its firmware :-(

Even the stock WD firmware cannot communicate to it:

root@WDMyCloudEX2100 / # up_send_ctl PowerStatus
root@WDMyCloudEX2100 / # up_send_ctl MCUVer

That would explain why the power LED is always flashing blue and the fan never shuts up even in the stock firmware.

Does anyone know how to update/restore the MCU firmware?



Edited 2 time(s). Last edit at 08/07/2017 03:41PM by hmartin.

Interesting. Perhaps the commands for this MCU are different from the ones noted for the mcm-daemon.

I can't explain why it isn't working quite as expected, but I modified u-boot with the following commands just after "Enable HD1" and "Enable HD2":

  printf("Make Power LED flash orange\n");
  serial2_putc(0xfa);
  serial2_putc(0x26);
  serial2_putc(0x00);
  serial2_putc(0x22);
  serial2_putc(0x00);
  serial2_putc(0x01);
  serial2_putc(0xfb);
  for ( i=0;i<5;i++)
                udelay(1000000);

  printf("Make the fan shut up\n");
  serial2_putc(0xfa);
  serial2_putc(0x02);
  serial2_putc(0x00);
  serial2_putc(0x50);
  serial2_putc(0x00);
  serial2_putc(0x00);
  serial2_putc(0xfb);
  for ( i=0;i<5;i++)
                udelay(1000000);

The power button light does not change colour, but the fan does shut up. So it seems the MCU is alive after all...

Also bodhi here is the relevant part about NICs during the WD firmware boot:

port #0: is_sgmii=0, is_rgmii=1, phy_addr=0
  o Loading network interface(s) for port #0: cpu_mask=0x3, tx_csum_limit=9800

  o Port 0 is connected to Linux netdevice
    o egiga0, ifindex = 2, GbE port = 0
	giga p=0: mtu=1500, mac=00:50:43:XX:XX:XX (platform)

port #2: is_sgmii=1, is_rgmii=0, phy_addr=1
  o Loading network interface(s) for port #2: cpu_mask=0x3, tx_csum_limit=2048

  o Port 2 is connected to Linux netdevice
    o egiga1, ifindex = 3, GbE port = 2
	giga p=2: mtu=1500, mac=00:50:43:XX:XX:XX (platform)

Edited 1 time(s). Last edit at 08/07/2017 03:59PM by hmartin.

hmartin,

There is a separate fan_control binary in stock OS: /usr/sbin/fan_control. See:

http://forum.doozan.com/read.php?2,34103,35954#msg-35954

Regarding the LEDs, they should be GPIOs.

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

Thanks for the tips, I think there is something wrong with my u-boot build for EX2100 though. It seems that Linux cannot communicate with the MCU.

The Western Digital firmware is not correctly reading the system temperature, cannot set the fan speed, and does not properly shut off:

sysinfod: Disk2(sda) detected.
sysinfod: inform: Disk1 failed on.
sysinfod: inform: Disk1 non-healthy on.
sysinfod: inform: all drives status=Fault.
UBIFS: un-mount UBI device 0, volume 0
UBIFS: background thread "ubifs_bgt0_0" stops
MODEL:WDMyCloudEX2100
egiga0: link down
egiga0: link up, full duplex, speed 1 Gbps
egiga1: link down
egiga1: link up, full duplex, speed 1 Gbps
send cmd to micro-p to shutdown
The system is going down NOW!
Sent SIGTERM to all processes
Requesting system poweroff
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
xhci-hcd f10f8000.usb3: remove, state 1
usb usb5: USB disconnect, device number 1
xhci-hcd f10f8000.usb3: USB bus 5 deregistered
xhci-hcd f10f8000.usb3: remove, state 1
usb usb4: USB disconnect, device number 1
xhci-hcd f10f8000.usb3: USB bus 4 deregistered
xhci-hcd f10f0000.usb3: remove, state 1
usb usb3: USB disconnect, device number 1
xhci-hcd f10f0000.usb3: USB bus 3 deregistered
xhci-hcd f10f0000.usb3: remove, state 1
usb usb2: USB disconnect, device number 1
xhci-hcd f10f0000.usb3: USB bus 2 deregistered
Shutting Down Marvell Ethernet Driver
Shutting Down Marvell Ethernet Driver
System halted.

The unit does not power off. Power light stays flashing, fan at full blast, but the WD firmware is off.

I could imagine the DTB for the EX2U being incorrect and leading to problems on the EX2100, but the fact that the Western Digital firmware is not working properly anymore rules that out. I can only guess that there is some issue in the u-boot sources Western Digital has provided, which prevents the OS from communicating with the MCU.

Unfortunately I was an idiot and lost the backup of the original u-boot that was on my unit, so I cannot restore it. But I do recall that the fan used to quiet down when I booted into WD's firmware, and around the time I started kwbooting this behaviour stopped.

I will have to dig more into my modifications to u-boot to see if I have somehow managed to mess up MCU communications. The strange thing is that it works from within u-boot, I can make the fan run at 50% speed by sending the command to the MCU via serial2_putc()

hmartin,

> lost the backup o
> f the original u-boot that was on my unit, so I ca
> nnot restore it.

Ouch! I guess you can get it from the WD FW release tarball and flash that version back. And this u-boot has a USB restore mechanism. What I got from reading the code: If you put the FW release in USB and press a button (not sure where) during boot, it will restore the OS to stock. I don't know what's in that FW release blob, whether it also upgrades u-boot.

And it is not unsual for the GPL to be different source than the one they flashed in the FW release. They are not legally obligated to release the same exact source code GPL as the binary they install in the FW. I've seen this before.


> I will have to dig more into my modifications to u
> -boot to see if I have somehow managed to mess up
> MCU communications. The strange thing is that it w
> orks from within u-boot, I can make the fan run at
> 50% speed by sending the command to the MCU via se
> rial2_putc()

I think, perhaps it means that we are not done with the DTS. It probably does not have enough to set the box MCU to a default state when the kernel comes up.

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

Quote
bodhi
And it is not unsual for the GPL to be different source than the one they flashed in the FW release. They are not legally obligated to release the same exact source code GPL as the binary they install in the FW. I've seen this before.

Really? I thought the GPL required them to release the source code of the firmware version running on the device. Otherwise what's the point?

Quote
bodhi
I think, perhaps it means that we are not done with the DTS. It probably does not have enough to set the box MCU to a default state when the kernel comes up.

I had that thought as well, but it doesn't explain why the stock firmware running from flash also cannot communicate with the MCU anymore. If it was an issue with the DTS, you would expect it to function in the stock firmware but not in Debian. This is sadly not the case.

There are some additional commands in the u-boot source which are not documented in the mcm-daemon.

Here they are (transferred into the format of mcm.h):

char EnableHd1Cmd[]		= {0xfa, 0x06, 0x01, 0x00, 0x01, 0x01, 0xfb};
char EnableHd2Cmd[]		= {0xfa, 0x06, 0x01, 0x01, 0x01, 0x01, 0xfb};

There is a strange comment about powering off the NAS ("power off nas") which I don't understand why this would be in u-boot and definitely does not result in the NAS powering off...

char PwrOffCmd[]		= {0xfa, 0x03, 0x11, 0x00, 0x00, 0x00, 0xfb};

Edited 1 time(s). Last edit at 08/08/2017 12:50PM by hmartin.

I fixed the EX2100 dts to work with both onboard Ethernet interfaces! MCU communications still broken in Linux.

hmartin,

Quote

I fixed the EX2100 dts to work with both onboard Ethernet interfaces!

Cool! I think this should be applied to the EX4100 too.

Quote

Really? I thought the GPL required them to release the source code of the firmware version running on the device. Otherwise what's the point?

Only the Linux kernel needs to be. They have a whole bunch other userland binaries running in stock OS that are important, but those are not required to provide source code. They are treated like graphics binary blobs that we have in the kernel.

Quote

I had that thought as well, but it doesn't explain why the stock firmware running from flash also cannot communicate with the MCU anymore. If it was an issue with the DTS, you would expect it to function in the stock firmware but not in Debian. This is sadly not the case.

I think it means some MCU states are persistent. So even stock OS did not reset it correctly. Have you tried removing the RTC battery?

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

Quote
bodhi
I think it means some MCU states are persistent. So even stock OS did not reset it correctly. Have you tried removing the RTC battery?

I have not removed the RTC battery yet. As far as I know it's buried somewhere deep inside the EX2100, which I haven't disassembled.

I'm not convinced this is an issue with the MCU, given that u-boot is still able to successfully communicate with the MCU to change the fan speed and power up the hard drives.

Quote
hmartin
I have not removed the RTC battery yet. As far as I know it's buried somewhere deep inside the EX2100, which I haven't disassembled.

I was able to remove the RTC battery. It doesn't make any difference. The issue is not that the MCU is stuck in some invalid state.

I have more details to add. I found the uart debug header of the Welltrend microcontroller. It's JP3 on the EX2100.

The pinout is as follows (pin 1 is facing the front of the device, toward the RTC coin cell):
1: Tx (connect to uart Rx)
2: NC
3: VCC?
4: GND
5: Rx? (doesn't seem to listen)

The UART baud rate seems to be 115200.

Here is the output through a stock boot to WD firmware:

Yosemite Uart test
nick 2222
nick pwr on
Check_SYSTEM_Command=11
PwrOnCause=10
Check_SATA_POWER_Command=0001
Check_SATA_POWER_Command=0101
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16
Check_SYSTEM_Command=16

Unfortunately, commands inside the WD firmware still don't work after boot. BUT if you run up_modify_baudrate again (it's already run during boot by the script hardware_init.sh) then all of a sudden lots of things start happening!

Check_SYSTEM_Command=16
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=05
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
 1 read SPI=01
-------------FF
Check_SATA_STATUS=0F
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=02
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6A
Check_SYSTEM_Command=01
Check_SYSTEM_Command=05
Check_SYSTEM_Command=06
POWER_LED=0100
Check_SYSTEM_Command=06
POWER_LED=0000
Check_SYSTEM_Command=06
POWER_LED=0201
Check_SYSTEM_Command=06
POWER_LED=0100

The power LED changes colour and parts of fan_control work (like reading the system temperature):

root@WDMyCloudEX2100 / # fan_control -g 0
Current temperature is 34
hd0 temperature=0
hd1 temperature=0
CPU temperature=63

Unfortunately, there is no source code published for up_modify_baudrate. It's provided as a binary by Western Digital. Additionally, it seems to be armel so I cannot run it on bodhi's Debian firmware (which is armhf):
up_modify_baudrate: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped

I don't have IDA Pro, so I cannot disassemble ARM binaries. I don't know if this binary is only changing the baudrate of ttyS1, or if it is also sending a special command to the microcontroller. Once the baudrate is changed, I believe up_read_daemon and up_send_daemon handle communication with the microcontroller.

So it seems the issue is not within u-boot after all, which is great because WD's u-boot source is really terrible to work on.

If someone can figure out what up_modify_baudrate does, maybe we can get the microcontroller supported in Debian too.



Edited 1 time(s). Last edit at 10/01/2017 09:41AM by hmartin.

Oh also I noticed that the assignment of ethernet ports in the dts are reversed from what is written on the back.

eth0: port labelled "2" (bottom port)
eth1: port labelled "1" (top port)

Sorry for any confusion this caused people.

Have you looked at the sources of the mcm-daemon for the mcm2 / ex2u?
Its doing same things: setting the baudrate of ttyS1
Sendung hex commands for e.g fan, temp, powercontrol.

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

Peacemaker Wrote:
-------------------------------------------------------
> Have you looked at the sources of the mcm-daemon
> for the mcm2 / ex2u?
> Its doing same things: setting the baudrate of
> ttyS1
> Sendung hex commands for e.g fan, temp,
> powercontrol.

Yes, I have. mcm-daemon doesn't work on the EX2100 for some reason.

Even the stock OS has no working communications with the MCU unless you run their up_modify_baudrate twice after boot. There's something a bit strange about their GPL u-boot, but I haven't been able to determine what.

After some further investigation I have determined the MCU in the EX2100 communicates at 115200n8 not 19200n8 as on other devices.

Using strace, I was able to find what up_modify_baudrate was doing. Big suspense, it's not modifying the baud rate...

open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_LARGEFILE) = 3
ioctl(3, TCFLSH, 0)                     = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
write(3, "\372", 1)                     = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\3", 1)                       = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\26", 1)                      = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\0", 1)                       = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\0", 1)                       = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\0", 1)                       = 1
nanosleep({0, 10000}, NULL)             = 0
write(3, "\373", 1)                     = 1
nanosleep({0, 10000}, NULL)             = 0
nanosleep({0, 300000000}, NULL)         = 0
socket(PF_LOCAL, SOCK_STREAM, 0)        = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0

The hardware_init.sh script in the WD firmware just seems wrong.

#modify MCU baudrate
if [ -e /usr/sbin/up_modify_baudrate ]; then
        echo "change baudrate to 19200"
  up_modify_baudrate
fi

There are some other differences too, like the MCU not always replying with the expected ACK sequence. I modified mcm-daemon to work on the EX2100. If anyone else wants to work on this, or you think it might help on the EX4100, you're welcome to modify the code on GitHub (on branch ex2100).

I also attach mcm-daemon binary for bodhi's debian firmware to this post for anyone else with EX2100 who wants to test.

mcm-daemon[3381]: Bind name to ls.
mcm-daemon[3381]: Listen on ls for connections.
mcm-daemon[3381]: Server startup success on port 57367
mcm-daemon[3381]: Try number: 1
mcm-daemon[3381]: mcm-daemon startup complete, going to FanControl mode
mcm-daemon[3381]: found 2 ata ports
mcm-daemon[3381]: setFanSpeed 80
mcm-daemon[3381]: Clearing Serial Port...
mcm-daemon[3381]: Try number: 1
mcm-daemon[3381]: Returning 1 read bytes
mcm-daemon[3381]: Try number: 1
mcm-daemon[3381]: Read system temperature: 33 °C
mcm-daemon[3381]: Returning 1 read bytes
mcm-daemon[3381]: Try number: 1
mcm-daemon[3381]: Read fan rpm: 0
mcm-daemon[3381]: fan not running with speed 80
mcm-daemon[3381]: setFanSpeed 82
mcm-daemon[3381]: Try number: 1
mcm-daemon[3381]: system temp: 33 fan rpm: 0
mcm-daemon[3381]: query disk 1 temperature
mcm-daemon[3381]: query disk 2 temperature
mcm-daemon[3381]: system tempOld: 33, temp: 33, fanSpeed: 82, fanRpm: 0
mcm-daemon[3381]: setFanSpeed 0
mcm-daemon[3381]: Try number: 1

It's very helpful to have soldered the uart debug header for the MCU as I described in my previous post. Without it, you do not know if the MCU is receiving or responding to the commands.

Check_SYSTEM_Command=08
TemperatureValue_MAIN=6D
Check_FAN_Command=00
fan speed=00
Check_FAN_Command=00
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6D
Check_FAN_Command=00
fan speed=00
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6D
Check_FAN_Command=00
fan speed=00
Check_SYSTEM_Command=01
Check_FAN_Command=50
Check_SYSTEM_Command=08
TemperatureValue_MAIN=6C
Check_FAN_Command=00
fan speed=00
Check_FAN_Command=52
Check_FAN_Command=00

Hoping this helps someone.

hmartin,

> After some further investigation I have determined
> the MCU in the EX2100 communicates at 115200n8 not
> 19200n8 as on other devices.

Other devices uses 19200n8, do you mean WD NAS devices?

> Hoping this helps someone.

Absolutely will be great to be able to control the fan.

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

Quote
bodhi
Other devices uses 19200n8, do you mean WD NAS devices?

I guess since mcm-daemon is only for WD devices, yes I mean other WD NAS devices use 19200 and the EX2100 uses 115200 for MCU baud rate.

Quote

hmartin Wrote:
-------------------------------------------------------
>

Quote
bodhi
> Other devices uses 19200n8, do you mean WD NAS
> devices?
>

>
> I guess since mcm-daemon is only for WD devices,
> yes I mean other WD NAS devices use 19200 and the
> EX2100 uses 115200 for MCU baud rate.

Argh :) that's just thoughtless WD. Glad you've figured that one out.

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

Quote
bodhi
Argh :) that's just thoughtless WD.

Probably a different contractor/engineer designed this product. But very annoying they don't even bother to update their own hardware_init script.

I took some measurements today with an optical tachometer, the fan speed on 100% duty cycle is 4800 RPM. I updated the fan RPM calculation to reflect this. Updated binary is attached, no other changes except fan RPM calculation.

Really annoying that Sunon doesn't offer a datasheet for this fan (PF70251VX-Q02U-S99), it seems it must be a custom model ordered specifically by WD.

It has just been revealed that there are numerous, serious vulnerabilities and a backdoor present in the stock firmware from Western Digital:
http://gulftech.org/advisories/WDMyCloud%20Multiple%20Vulnerabilities/125

These vulnerabilities affect all WD MyCloud products running the Western Digital firmware. For the EX2100, WD firmware below 2.30.172 is vulnerable (PDF release notes).

I will try to have installation instructions for Debian completed ASAP for the EX2100 so anyone wishing to run Debian can do so immediately.



Edited 1 time(s). Last edit at 01/06/2018 01:14AM by hmartin.

hmartin Wrote:
-------------------------------------------------------
> It has just been revealed that there are numerous,
> serious vulnerabilities and a backdoor present in
> the stock firmware from Western Digital:
> http://gulftech.org/advisories/WDMyCloud%20Multiple%20Vulnerabilities/125
>
> These vulnerabilities affect all WD MyCloud
> products running the Western Digital firmware. For
> the EX2100, WD firmware below 2.30.172 is
> vulnerable
> (PDF
> release notes).
>
> I will try to have installation instructions for
> Debian completed ASAP for the EX2100 so anyone
> wishing to run Debian can do so immediately.

Thanks hmartin!

feas reported here too:
https://forum.doozan.com/read.php?8,46994

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



Edited 1 time(s). Last edit at 01/06/2018 02:05AM by bodhi.

I was updating my EX2100 to the newest WD firmware to resolve the vulnerabilities discovered (not that I ever plan to use the WD firmware, just thought I should update it now while it's on my mind) and I noticed during the firmware update process that it also updates the firmware on the Weltrend:

19436 root     49120 R    mcu_upgrade -r -f /tmp/uP_0.bin
19552 root      2720 R    ps ax

First for the good news, I now have what I believe is a copy of the firmware for the Weltrend (uP_0.bin, saved from the WD update process) and also the mcu_upgrade binary they use to update the firmware.

The bad news is that in my attempt to reverse engineer the functionality of the mcu_upgrade binary, I corrupted the firmware on the Weltrend and now I have a fancy brick. Plug it in and the fan spins but no life on the Armada. I'm guessing the Weltrend is responsible to bring the Armada out of reset and without a functional firmware it's not doing that.

The Weltrend used seems to be identical to the WT61P 48-pin LQFP chip specified here:
http://monitor.espec.ws/files/wt61p802_421.pdf

It's an 8052 microcontroller designed for "Flat Panel Display Control" (??!), even more crusty than I had guessed (something ARM).

I've managed to map the two PCB headers on the EX2100 near the Weltrend to specific pins:
JP3:
Pin 1: Uart Tx (P32)
Pin 5: Uart Rx (P31)

JP4:
Pin 1: DSCL1 (P23)
Pin 5: DSDA1 (P22)

I'm going to make an educated guess that TXD0 (P16) and RXD0 (P17) head to the Armada uart1.

According to people online, it's possible to ISP the Welltrend via I2C, so I guess this is my next step to try and recover the device.

Well, good news, bad news.

I was able to locate software (Postal2) that can enable ISP mode on the Weltrend. After reading the contents of the Weltrend's EEPROM, I was able to determine that mcu_upgrade erased the firmware portion of the Weltrend's flash. But, due to some issue it didn't write the new firmware, so all the Weltrend had was its bootloader and nothing else. This explains why I had a brick and no output from the Weltrend over UART.

I was able to re-flash the Weltrend with the uP_0.bin file I saved from the EX2100 during the firmware update process. Now the Weltrend has a valid firmware and the Armada CPU is brought out of reset. This is the end of the good news.

The bad news is, as expected by now, the uP_0.bin firmware I grabbed from the EX2100 is not the correct firmware for the Weltrend in the EX2100. Of course, why would WD ship the firmware for the Weltrend in the EX2100 with the EX2100 software update?

From the strings in the firmware file, it seems the Weltrend firmware I have a copy of is for the "MyCloudDL2000" (even though no such product with this name exists). As such, when u-boot executes on the Armada and tries to communicate with the Weltrend, it doesn't get the response it is expecting and the boot process hangs in u-boot.

So the next step for me is seeing if I can patch out all the communication to the Weltrend in u-boot so I can at least get to booting Linux.

What a utter pile of s***.

Sorry to hear that Hal! yes, WD firmware and GPL is beyond bad, full of crappy legacy design issues.

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

Well, just my luck. I patched out the wake on lan portions u-boot was puking on and I was able to boot the WD firmware.

Even more lucky for me, there is a new update to be installed. I installed the update, and now it seems the firmware on the Weltrend is back into a reasonable state. It's still not what was shipping on my unit because I'm missing the "Yosemite uart test" output, but at least it's no longer preventing u-boot from starting successfully.

nick 2222
nick pwr on
Check_SYSTEM_Command=11
PwrOnCause=10
Check_SATA_POWER_Command=0001
Check_SATA_POWER_Command=0101

I'll dump the firmware from the Weltrend for my archives and get on with writing the Debian installation instructions.