Debian on WD My Cloud EX4

A search of WikiDevi for other devices that use the IDT133X series of RTC shows only a couple of CheckPoint devices and an Edgewater device none of which are supported by mainline Linux kernel. The datasheet for the IDT1337 is available at https://www.alldatasheet.com/datasheet-pdf/view/523751/IDT/1337CSRI.html and appears to contain enough information to facilitate writing a driver and/or adding support to a similar RTC driver.

It didn't help, but in the end I managed to get the RTC working :)

First, I managed to understand how RTC\FAN\LCD are controlled in the stock firmware. This is done using utilities:

xmldb
up_read_daemon
up_send_daemon
up_send_ctl

And they need the ttyS1 port activated to work, so I included it in dtsi (I used dts without explicitly defined RTC):

serial@12100 {
status = "okay";
};

Here is an example of use:

#!/bin/sh

touch /tmp/system_ready

xmldb -n config &
up_read_daemon &
up_send_daemon &

#LED:
led hd0 blue off
led hd1 blue off
led hd2 blue off
led hd3 blue off
led power blue on

#FAN:
fan_control -f 2

#RTC:
rtc -s

#LCD:
up_send_ctl SysName HELLO
up_send_ctl DeviceReady

There is a bug for HDD LED with turning on/off all blue diodes at once... Otherwise it works fine.

~ # rtc -r
rtc: RTC time = 2025/6/8 Sun 14:3:57

LCD control example:

/usr/sbin/up_send_ctl SysName WDMyCloudEX4
/usr/sbin/up_send_ctl APREnable
/usr/sbin/up_send_ctl SysIP1 192.168.2.178
/usr/sbin/up_send_ctl SysIP2 192.168.0.33
/usr/sbin/up_send_ctl SysIPBondSet
/usr/sbin/up_send_ctl FirmwareVer 2.13.108
/usr/sbin/up_send_ctl backupDirection 0
/usr/sbin/up_send_ctl DeviceReady
/usr/sbin/up_send_ctl MCUVer
/usr/sbin/up_send_ctl LCDSleepMode 0
/usr/sbin/up_send_ctl APREnable
/usr/sbin/up_send_ctl WOLEnable
/usr/sbin/up_send_ctl ErrStatus 2214 0
/usr/sbin/up_send_ctl ErrStatus 1200 0
/usr/sbin/up_send_ctl ErrStatus 2216 1

By the way, my problem with the inability to read written data by u-boot is no longer relevant - it was fixed after editing .config

Of the minor problems, there are: HDD LED (blue) and Ethernel ("jumping" without using ethtool). I'll try to figure them out too.

Thanks again, bodhi.
You're cool! ;)



Edited 2 time(s). Last edit at 06/08/2025 09:19AM by sym0.

> It didn't help, but in the end I managed to get
> the RTC working :)

Nice work!

> First, I managed to understand how RTC\FAN\LCD are
> controlled in the stock firmware. This is done
> using utilities:
>
> xmldb
> up_read_daemon
> up_send_daemon
> up_send_ctl

That's a work around. Great that it works, but not a real solution. But similar to fan and LED, we don't have GPL source (do we?) to see how they implement theses. So it is the best solution for now.

> And they need the ttyS1 port activated to work, so
> I included it in dtsi (I used dts without
> explicitly defined RTC)

This activated ttyS1 port should be in the DTS, not DTSI, though. Because it might not be applicable to other WD NAS with Kirkwood Socs.

> #RTC:
> rtc -s

This probably the compiled stock driver for the IDT 1337G. So the serial port ttyS1 is the user interface for these tools. Have you tried running this rtc binary without the 2nd serial port activated?

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

bodhi Wrote:
-------------------------------------------------------
> we
> don't have GPL source (do we?)

Unfortunately, this is true.

> This activated ttyS1 port should be in the DTS,
> not DTSI, though. Because it might not be
> applicable to other WD NAS with Kirkwood Socs.

If you help me to form dts\dtsi correctly, I will check them in work.


> > #RTC:
> > rtc -s
>
> This probably the compiled stock driver for the
> IDT 1337G. So the serial port ttyS1 is the user
> interface for these tools. Have you tried running
> this rtc binary without the 2nd serial port
> activated?

As far as I understand, debugging via strace,
rtc is actually a "shell" for some up_send_ctl commands
And it, in turn, already interacts with:
xmldb
up_read_daemon
up_send_daemon
which use /dev/ttyS1
That is, we can sniff commands transmitted to /dev/ttyS1.
I'll try to do this in the near future.

sym0,

> > This activated ttyS1 port should be in the DTS,
> > not DTSI, though. Because it might not be
> > applicable to other WD NAS with Kirkwood Socs.
>
> If you help me to form dts\dtsi correctly, I will
> check them in work.

OK.


> As far as I understand, debugging via strace,
> rtc is actually a "shell" for some up_send_ctl
> commands
> And it, in turn, already interacts with:
> xmldb
> up_read_daemon
> up_send_daemon
> which use /dev/ttyS1

> That is, we can sniff commands transmitted to
> /dev/ttyS1.

I see.

This is kind of similar to many Synology NAS where the ttyS1 is the interface to the microcontroller in the board. The microcontroller actually performs all the LED, Shutdow, Reset. This IDT 1337 chip is on I2C bus, so our understanding of the board hardware is still missing something.

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

Attached is the updated DTB/DTS. Added uart1 node in the DTS.

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

bodhi Wrote:
-------------------------------------------------------
> Attached is the updated DTB/DTS. Added uart1 node
> in the DTS.

It works, thank you.