My Cloud PR4100/PR2100 Information

@dswv42,

Have you seen this thread on doozan.com ?

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

It looks like they have made some significant progress on the EX4100 and EX2100 series of NAS to get Debian working. They do have the same issues though that you mentioned around LED and Fan control.

Cheers,

JediNite

@dswv42,

Just looked on the EX4100 and the same binary exists on it as well.

Cheers,

JediNite

@dswv42,

There are a few different ones of these on the NAS:

 root@WDMyCloudEX4100 / # find . -name *thermal.xml -print
./usr/local/modules/etc/wd/BVBZ-thermal.xml
./usr/local/modules/etc/wd/BWAZ-thermal.xml
./usr/local/modules/etc/wd/BWVZ-thermal.xml
./usr/local/modules/etc/wd/BWZE-thermal.xml
./etc/wd/BVBZ-thermal.xml
./etc/wd/BWAZ-thermal.xml
./etc/wd/BWVZ-thermal.xml
./etc/wd/BWZE-thermal.xml

The contents of these look similar to what you published for the PR4100.

Cheers,

JediNite

@dswv42,

None of the stuff in this post exists on the EX4100 :frowning:

Cheers,

JediNite

Found this as a running process.

root@WDMyCloudEX4100 root # ps -aef | grep wdtms
root      4153     1  0 Nov04 ?        00:02:50 /opt/wd/bin/wdtms -config=/etc/wd/BWZE-thermal.xml

The file referenced is identical to the ones you are referring to in /usr/local/modules/etc/wd however, the EX4100 does not have a thermal_config.xml file. Instead has the following:

root@WDMyCloudEX4100 root # ls -al /usr/local/modules/etc/wd/
drwxrwxr-x    2 root     root           111 Apr  1  2016 .
drwxr-xr-x   10 root     root           158 Nov 14  2015 ..
-rwxrwxr-x    1 root     root         23923 Apr  1  2016 BVBZ-thermal.xml
-rwxrwxr-x    1 root     root         23873 Apr  1  2016 BWAZ-thermal.xml
-rwxrwxr-x    1 root     root         23923 Apr  1  2016 BWVZ-thermal.xml
-rwxrwxr-x    1 root     root         23876 Apr  1  2016 BWZE-thermal.xml

The Product Model is returned as YELLOWSTONE and the following libraries are referenced:

 <library name="/opt/wd/lib/libredhawk_hwlib_temperature_source.so" source_name="system" type="1" count="1" log_variance="5.0" read_interval="5" />
 <library name="/opt/wd/lib/libredhawk_hwlib_temperature_source.so" source_name="cpu" type="6" count="1" log_variance="5.0" read_interval="5" />
 <library name="/opt/wd/lib/libredhawk_hwlib_temperature_source.so" source_name="drive" type="7" count="4" optional="2" log_variance="5.0" read_interval="60" />
 <library name="/opt/wd/lib/libsprite_hwlib_fan_controller.so"     source_name="system_fan" type="1" count="1" scale_factor="1" initial_value="80" fan_check_retries="3" />
 <library name="/opt/wd/lib/libsprite_alert_interface.so" />
 <library name="/opt/wd/lib/libsprite_syslog_alert_interface.so" />
 <library name="/opt/wd/lib/libsprite_command_alert_interface.so" >

If there is value in getting the whole file, I can attach it but looks very similar to the one you’ve shared.

Cheers,

JediNite

Are you still using acpi_enforce_resource=lax as GRUB option? It helps detecting the sensors.

To dig deeper in the hardware, you might like this article: https://lwn.net/Articles/367630/
It explains how to decode the ACPI tables and even how to write a driver :slight_smile:
But some source code would be more helpful here. We shall see what the future brings.

DSDT.txt (321.9 KB)
Here is the decoded DSDT table.
Now we just need to be able to talk to the I2C devices.

I don’t get data from most of the I2S busses but /dev/i2s-8 is a bit different.

addr data
0x30 0xFF
0x31 0xFF
0x4c 0x20
0x50 0x55
0x51 0x55

To get this data, I used python with pip install smbus2

import smbus2

b = smbus2.SMBus(8)

for d in range(128):
    try:
        data = bus.read_byte(d)
        print hex(d), hex(data)
    except:
        pass

The last 2 addresses are changing occasionally.

Readings with SMBus on i2c-8 on address 0x4c:

for j in range(16): print ' '.join('%02x' % bus.read_byte_data(0x4c, j*16+k) for k in range(16))

1f 21 80 00 06 55 00 55 00 00 06 55 00 55 00 00
60 00 00 00 00 55 00 00 00 55 55 00 00 00 00 00
55 0a 70 23 a0 0f 0f 12 12 c0 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
06 07 07 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 63 a0 00 00 00 00 00 00 2b 92 26 50
20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 21 5d 03

This confirms the suspicion from sensors-detect: this is the SMSC 1073, based on the last 3 bytes.
http://ww1.microchip.com/downloads/en/DeviceDoc/1073_1074.pdf

LM-sensors doesn’t have a driver yet, but that seems a nice project for this weekend :slight_smile:

Reading the internal chip temperature

bus.read_byte_data(0x4c, 0x00)
31

Reading the external diodes temperature

bus.read_byte_data(0x4c, 0x01)
33
bus.read_byte_data(0x4c, 0x23)
35
bus.read_byte_data(0x4c, 0x2a)
0      (no sensor connected)

Cool beans.

It looks like the EMC1073 uses the EMC1403 lookup code, but the driver is to-be-written.
See here

However the datasheets are almost completely the same (when comparing the registers), except for 1 extra feature in the EMC1403: it has beta compensation.
All registers are the same, except for 0x25 and 0x26 is reserved for the beta compensation params in the EMC1403.

page 27 - http://ww1.microchip.com/downloads/en/DeviceDoc/1073_1074.pdf
page 29 - http://www.mouser.com/ds/2/268/20005272A-468064.pdf

The EMC1403 has a driver - emc1403 and it doesn’t use the beta compensation

So you can just use this driver for the temperature chip, this can be done in the lm-sensors config file.
Next step is the fan.

EMC1073 and EMC1403 have the exact same supplier code and model number, but there’s 4 years between the datasheets and SMSC was bought by MicroChip.

Sensors-detect stops on the first match, which results in the detection of EMC1073… but I’m quite sure it’s the EMC1403.
I’m certain that there is an I2C device connected on the bus (the ST micro), it measures the temperature and it’s one of these 2 devices (as all the registers match).

The results are shown in WD’s fan_control program (it shows 4 + 4 + 1 temperature measurements), but debian’s sensors doesn’t show the disk temperatures due the missing driver.
This is fixed by adding emc1403 to /etc/modules.

The fan is controlled by the BIOS. Here is the best overview I could find. I don’t know how to get access to the RPM value.

# cat /sys/class/thermal/cooling_device0/type
Fan

# cat /sys/class/thermal/cooling_device0/device/uevent
DRIVER=acpi-fan
MODALIAS=acpi:PNP0C0B:

I had a look at GPL/kernel/linux-4.1.13/drivers/acpi/fan.c provided by WD. It has the commands to get the fan speed.
I’m a python guy, so I’d borrow some idea’s here and use that to talk to /var/run/acpid.socket

strace on wdhws

nanosleep({1, 0}, 0x7ffc21ad6a10)       = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

no info yet on the other services.

This post has some valid reasons to slow down RAID rebuild: https://superuser.com/questions/625722/reducing-linux-software-raid-rebuild-speed

checker.txt (549 Bytes)

Rename to .py and run it with python2.7
I forgot to remove the unused imports, if you lack any, just remove them.

Note that the WD tool adds the header in-place, so it’s best to make a copy of the original file.

I forgot my battery charger so I can’t go much deeper today. Maybe tomorrow :slight_smile:

Similar section on the EX4100 as well, but don’t think it actually does anything.

# To protect from user _easily_ accessing reserved part7 and part8,
# we remove the device nodes.
# Anyone who want to access them must create the nodes itself.
for dn in `blkid | grep wdnas_reserve | awk -F ":" '{ print $1 }'`; do
        rm -f $dn
done

In /dev/ have the following devices:

root@WDMyCloudEX4100 /dev # ls -al mt* ubi*
crw-rw----    1 root     root       90,   0 Nov 15 06:47 mtd0
crw-rw----    1 root     root       90,   1 Nov 15 06:47 mtd0ro
crw-rw----    1 root     root       90,   2 Nov 15 06:47 mtd1
crw-rw----    1 root     root       90,   3 Nov 15 06:47 mtd1ro
crw-rw----    1 root     root       90,   4 Nov 15 06:47 mtd2
crw-rw----    1 root     root       90,   5 Nov 15 06:47 mtd2ro
crw-rw----    1 root     root       90,   6 Nov 15 06:47 mtd3
crw-rw----    1 root     root       90,   7 Nov 15 06:47 mtd3ro
crw-rw----    1 root     root       90,   8 Nov 15 06:47 mtd4
crw-rw----    1 root     root       90,   9 Nov 15 06:47 mtd4ro
crw-rw----    1 root     root       90,  10 Nov 15 06:47 mtd5
crw-rw----    1 root     root       90,  11 Nov 15 06:47 mtd5ro
crw-rw----    1 root     root       90,  13 Nov 15 06:47 mtd6ro
crw-rw----    1 root     root       90,  15 Nov 15 06:47 mtd7ro
brw-rw----    1 root     root       31,   0 Nov 15 06:47 mtdblock0
brw-rw----    1 root     root       31,   1 Nov 15 06:47 mtdblock1
brw-rw----    1 root     root       31,   2 Nov 15 06:47 mtdblock2
brw-rw----    1 root     root       31,   3 Nov 15 06:47 mtdblock3
brw-rw----    1 root     root       31,   4 Nov 15 06:47 mtdblock4
brw-rw----    1 root     root       31,   5 Nov 15 06:47 mtdblock5
brw-rw----    1 root     root       31,   6 Nov 15 06:47 mtdblock6
brw-rw----    1 root     root       31,   7 Nov 15 06:47 mtdblock7
crw-rw----    1 root     root      250,   0 Nov 15 06:48 ubi0
crw-rw----    1 root     root      250,   1 Nov 15 06:48 ubi0_0
crw-rw----    1 root     root      249,   0 Nov 15 06:48 ubi1
crw-rw----    1 root     root      249,   1 Nov 15 06:48 ubi1_0
crw-rw----    1 root     root      248,   0 Nov 15 06:48 ubi2
crw-rw----    1 root     root      248,   1 Nov 15 06:48 ubi2_0
crw-rw----    1 root     root       10,  60 Nov 15 06:47 ubi_ctrl

@dswv42,

Let me clarify my post above. I don’t believe the command does anything because I don’t see labels defined on any of the remaining devices, so follows that they are probably not using labels at all. However, I just looked on my NAS and the “entware-ng” version of “blkid” produces the following:

root@WDMyCloudEX4100 root # blkid
/dev/dm-1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/dm-0: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/md1: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7"
/dev/loop1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/sdd4: UUID="a084a048-6978-450e-a326-bd82ab81785a"
/dev/sdc4: UUID="cb05b2ed-2555-4ac0-a8c3-1fb38c952c10"
/dev/sdc2: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7"
/dev/sdb4: UUID="35d44091-85fe-4f0a-8a0b-7f29d717c8da"
/dev/sdb2: UUID="5f42d319-6fb3-4ac0-b710-23292db2f778"
/dev/sda4: UUID="62e2a499-e3d8-4ce7-b67c-2b37a505fbcd"
/dev/ram0: UUID="42f62123-de52-447c-a5b9-335168f0f750"
/dev/mapper/docker-9:1-80347142-b0cf4a948d6e1744d31feab8a471a604cdc87583ff9b5d7fc676eed5e359f292: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/mapper/docker-9:1-80347142-pool: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"

Here is the results from the stock version of blkid::

root@WDMyCloudEX4100 / # /usr/local/modules/bin/blkid
/dev/ubi2_0: UUID="21e2b22d-facd-45c6-a6b5-d2c4ed2d9201" TYPE="ubifs"
/dev/ubi1_0: UUID="7f2ffc37-f41c-4db4-a6db-0916da6130dd" TYPE="ubifs"
/dev/ubi0_0: UUID="0a896697-098b-48b8-9a65-39cc54496495" TYPE="ubifs"
/dev/loop0: TYPE="squashfs"
/dev/loop1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"
/dev/sda1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="62425411-2600-46ea-9c7f-50f41ace1ff7"
/dev/sda2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="ce102707-dba4-065a-64d7-ea9e44e1da5a" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="453fb6fb-9246-4773-b03e-4519b60f2b39"
/dev/sda4: UUID="62e2a499-e3d8-4ce7-b67c-2b37a505fbcd" TYPE="ext4"
/dev/sdb1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="64e425f3-c936-4301-8fe1-aaad5de10486"
/dev/sdb2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="18145e0e-44c5-5571-c750-f01e6b8832e2" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="12426d19-8608-4cea-8f7d-f9299cc95d29"
/dev/sdb4: UUID="35d44091-85fe-4f0a-8a0b-7f29d717c8da" TYPE="ext4"
/dev/sdd1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="e51a267e-f2be-4202-a3ef-ee338968350d"
/dev/sdd2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="ad6e31ff-4002-22b2-79a5-f66ca815ee1a" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="4074e139-fba8-466f-bb63-e6e01827b5d2"
/dev/sdd4: UUID="a084a048-6978-450e-a326-bd82ab81785a" TYPE="ext4"
/dev/sdc1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="07a98576-7fee-4944-9464-42b1b93edd9b"
/dev/sdc2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="abb832fe-2b2d-6faa-f4b7-b696224cb8b0" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="28b5df5a-b06e-4509-a024-57e13fd59787"
/dev/sdc4: UUID="cb05b2ed-2555-4ac0-a8c3-1fb38c952c10" TYPE="ext4"
/dev/md0: UUID="d18442c4-1816-46f2-9efa-6ceb4d642da6" TYPE="swap"
/dev/md1: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7" TYPE="ext4"
/dev/mapper/docker-9:1-80347142-pool: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"
/dev/mapper/docker-9:1-80347142-b0cf4a948d6e1744d31feab8a471a604cdc87583ff9b5d7fc676eed5e359f292: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"

Cheers,

JediNite

I wasn’t having a go or anything :slight_smile: Sorry if I came across a bit harsh.

So basically 2/5ths of f#$% all and pretty much what was in the Release Notes only. Pretty disappointing :frowning: