Debian on WD My Cloud EX4

Hello again,

I had a bit of a boost in energy this evening and thought I would do some digging into the firmware, I found two binaries of interest, /usr/sbin/fan_control and /usr/sbin/led, "fan_control" controls the fan as you would expect you can turn it on and off and set speed and get the fan RPM, "led" allows me to set the power led status (on, off, blinking, red or blue) as well as each of the four hard drive LED's (again, red, blue, blinking, etc), I'll attach each binary as well as the help text for each, I looked at them in Ghidra (I am by no means good as reverse engineering haha) and from what I can see for the led control anyway it seems to directly set a CPU register of some sort, I don't know if that seems probable or not but that's my best guess, as for the LED screen on the front, that seems like a much bigger feat and I don't know if that would be possible to get working under debian but I'll keep looking to see how it's controlled in the stock firmware,

Thanks!

> I found two binaries of interest,
> /usr/sbin/fan_control and /usr/sbin/led,
> "fan_control" controls the fan as you would expect
> you can turn it on and off and set speed and get
> the fan RPM, "led" allows me to set the power led
> status (on, off, blinking, red or blue) as well as
> each of the four hard drive LED's (again, red,
> blue, blinking, etc), I'll attach each binary as
> well as the help text for each,

If these were scripts, it would be much more helpful. Binaries, not so much. So I would recommend searching the GPL source instead.

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

Sadly the fan control and led tools are supplied in their binary form even in the GPL, there are no other references to led's or fan control anywhere else in the GPL so that may be a no go unfortunately.

> Sadly the fan control and led tools are supplied
> in their binary form even in the GPL, there are no
> other references to led's or fan control anywhere
> else in the GPL so that may be a no go
> unfortunately.

Sometime this happens with a company that intentionally implemented a malicious compliance to GPL. Instead of disclosing how they control a piece of hardware like everybody else, they close source that piece of code because they can and not violating GPL.

Normally LEDS and fan are controlled by GPIOs. In some cases, by serial TTY (like in some Synology NAS). Most comapanies provide patches (GPIOs) or scripts (TTYs) in their GPL sources.

We can just copy these binaries to the rootfs and run it. If those were static binary then there would be no problem. If these were dynamic binary then some old shared library on stock OS also need to be repackaged so we can run them in modern Debian system.

Find out what are they:

file <fancontrol binary>
file <LED control binary>

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

They are dynamically linked

fan_control: 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
led:         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

@ConcentratedCancer,

Go ahead copy the fan_control and led binaries to your rootfs /tmp.

And try running it

cd /tmp
./fan_control
./led

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

@ConcentratedCancer,

In the kernel 6.14.6-kirkwood-tld-1 release, I've changed the name of the DTB to kirkwood-wd-mycloud-ex4.dtb.

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

I've been away on vacation so I haven't had a chance to run the fan and led control binaries on the debian system.
I am back now though so I will give that a try and report back!

Hi, bodhi.

I want to thank you for creating dts\dtsi files for this device.
I recently purchased it and am planning to make a convenient installer for installing current versions of Debian and Gentoo distributions.

However, I encountered some problems:

- NAND:

1) I had to change the "chip-delay" value from 25 to 35, because during boot, errors were pouring into dmesg for 10 seconds:

[ 11.134010] Bad eraseblock 2013 at 0x00000fba0000
[ 11.138778] Bad eraseblock 2014 at 0x00000fbc0000
[ 11.143558] Bad eraseblock 2015 at 0x00000fbe0000
[ 11.148327] Bad eraseblock 2016 at 0x00000fc00000
[ 11.153107] Bad eraseblock 2017 at 0x00000fc20000
[ 11.157875] Bad eraseblock 2018 at 0x00000fc40000
[ 11.162657] Bad eraseblock 2019 at 0x00000fc60000
[ 11.167424] Bad eraseblock 2020 at 0x00000fc80000
[ 11.172206] Bad eraseblock 2021 at 0x00000fca0000
[ 11.176972] Bad eraseblock 2022 at 0x00000fcc0000
[ 11.181753] Bad eraseblock 2023 at 0x00000fce0000
[ 11.186521] Bad eraseblock 2024 at 0x00000fd00000
[ 11.191301] Bad eraseblock 2025 at 0x00000fd20000
[ 11.196070] Bad eraseblock 2026 at 0x00000fd40000
[ 11.200849] Bad eraseblock 2027 at 0x00000fd60000
[ 11.205617] Bad eraseblock 2028 at 0x00000fd80000
[ 11.210397] Bad eraseblock 2029 at 0x00000fda0000
[ 11.215166] Bad eraseblock 2030 at 0x00000fdc0000
[ 11.219985] Bad eraseblock 2031 at 0x00000fde0000
[ 11.224758] Bad eraseblock 2032 at 0x00000fe00000
[ 11.229527] Bad eraseblock 2033 at 0x00000fe20000
[ 11.234308] Bad eraseblock 2034 at 0x00000fe40000
[ 11.239076] Bad eraseblock 2035 at 0x00000fe60000
[ 11.243856] Bad eraseblock 2036 at 0x00000fe80000
[ 11.248624] Bad eraseblock 2037 at 0x00000fea0000
[ 11.253404] Bad eraseblock 2038 at 0x00000fec0000
[ 11.258174] Bad eraseblock 2039 at 0x00000fee0000
[ 11.262953] Bad eraseblock 2040 at 0x00000ff00000
[ 11.267722] Bad eraseblock 2041 at 0x00000ff20000
[ 11.272549] Bad eraseblock 2042 at 0x00000ff40000
[ 11.277322] Bad eraseblock 2043 at 0x00000ff60000
[ 11.282104] Bad eraseblock 2044 at 0x00000ff80000
[ 11.286871] Bad eraseblock 2045 at 0x00000ffa0000
[ 11.291650] Bad eraseblock 2046 at 0x00000ffc0000
[ 11.296419] Bad eraseblock 2047 at 0x00000ffe0000
[ 11.301210] 7 fixed-partitions partitions found on MTD device orion_nand

This has been corrected.

2) The original MTD markup has 7 sections, not 2:

[ 1.872494] Creating 7 MTD partitions on "orion_nand":
[ 1.877661] 0x000000000000-0x000000100000 : "u-boot"
[ 1.883559] 0x000000100000-0x000000600000 : "uImage"
[ 1.889383] 0x000000600000-0x000000b00000 : "ramdisk"
[ 1.895303] 0x000000b00000-0x00000d800000 : "image"
[ 1.901590] 0x00000dd00000-0x00000ec00000 : "rescue firmware"
[ 1.908170] 0x00000ec00000-0x000010000000 : "config"
[ 1.914026] 0x00000d800000-0x00000dd00000 : "reserve"

This has been corrected.

3) When trying to write to NAND from kernel 6.14.8 (+ your patches) I encounter a problem where u-boot cannot read the written data:

Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0

NAND read: device 0 offset 0x100000, size 0x500000

reading NAND page at offset 0x100000 failed
5242880 bytes read: ERROR

I tried different versions of flash_eraseall, flash_erase and nandwrite, but the result is the same... At the same time, nanddump returns a binary identical to the original file dump when reading.
On the native firmware, writing works fine.

- RTC:

[ 3.369970] rtc-mv f1010300.rtc: internal RTC not ticking

I found out that the board uses IDT 1337G (photo). However, in the iomem output for 6.14.8 I do not see any mentions of rtc-mv and mv64xxx_i2c (perhaps they are called differently?).

- SERIAL:

I haven't tested it extensively yet, but I noticed that dmesg and iomem for 3.2.40 mention /dev/ttyS0 and /dev/ttyS1:

serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A

f1012000-f10120ff : serial8250.0
f1012100-f10121ff : serial8250.1

And for 6.14.8 only /dev/ttyS0 is mentioned:

f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 29, base_baud = 12500000) is a 16550A

f1012000-f10120ff : serial

- ETHERNET:

Just like ConcentratedCancer, the network is constantly "jumping":

[ 6.476947] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 6.810093] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 6.816443] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 7.850168] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 7.856153] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 8.890206] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 8.896186] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 9.930164] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 9.936155] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 10.970066] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 10.976421] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[ 11.391877] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

But with ethtool this can be bypassed, so it is not a significant problem.

--------------------------------------------------------------------------------------------------------------

I'll figure out the functionality of LCD, FAN and LED in the coming days.

I'll be glad to help. If additional tests are needed, I'll do them. Thanks in advance)

Additional attachments

Additional attachments 2

Additional attachments 3

Hi sym0,

Thanks for your contribution! they are very good.

> - NAND:
>
> 1) I had to change the "chip-delay" value from 25
> to 35, because during boot, errors were pouring
> into dmesg for 10 seconds:

Yes. This happens frequently with Kirkwood boxes, and we need 35 or 40 chip-delay.

> 2) The original MTD markup has 7 sections, not 2:
>

> [    1.872494] Creating 7 MTD partitions on
> "orion_nand":
> [    1.877661] 0x000000000000-0x000000100000 :
> "u-boot"
> [    1.883559] 0x000000100000-0x000000600000 :
> "uImage"
> [    1.889383] 0x000000600000-0x000000b00000 :
> "ramdisk"
> [    1.895303] 0x000000b00000-0x00000d800000 :
> "image"
> [    1.901590] 0x00000dd00000-0x00000ec00000 :
> "rescue firmware"
> [    1.908170] 0x00000ec00000-0x000010000000 :
> "config"
> [    1.914026] 0x00000d800000-0x00000dd00000 :
> "reserve"
> 
> This has been corrected.

Cool!

>
> 3) When trying to write to NAND from kernel 6.14.8
> (+ your patches) I encounter a problem where
> u-boot cannot read the written data:
>
> NAND read: device 0 offset 0x100000, size
> 0x500000
>
> reading NAND page at offset 0x100000 failed
> 5242880 bytes read: ERROR

We are running stock u-boot, so I don't think we can rely on it.

> I tried different versions of flash_eraseall,
> flash_erase and nandwrite, but the result is the
> same... At the same time, nanddump returns a
> binary identical to the original file dump when
> reading.
> On the native firmware, writing works fine.

But inside Linux, it should work.

> I found out that the board uses IDT 1337G (photo).
> However, in the iomem output for 6.14.8 I do not
> see any mentions of rtc-mv and mv64xxx_i2c
> (perhaps they are called differently?).

Interesting. Let me take a look at the DTS (please do the same). The RTC must be specified in the i2c node in the DTS.

> - SERIAL:
>
> I haven't tested it extensively yet, but I noticed
> that dmesg and iomem for 3.2.40 mention /dev/ttyS0
> and /dev/ttyS1:
>
> serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33)
> is a 16550A
> serial8250.1: ttyS1 at MMIO 0xf1012100 (irq = 34)
> is a 16550A
>
> f1012000-f10120ff : serial8250.0
> f1012100-f10121ff : serial8250.1
>
> And for 6.14.8 only /dev/ttyS0 is mentioned:
>
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq =
> 29, base_baud = 12500000) is a 16550A
>
> f1012000-f10120ff : serial

Yes. That's how is usually is, only one ttyS0. Unless the board has some specific usage for ttyS1, we don't worry about it.

> Just like ConcentratedCancer, the network is
> constantly "jumping":

> But with ethtool this can be bypassed, so it is
> not a significant problem.

Nice!

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



Edited 1 time(s). Last edit at 06/04/2025 03:43PM by bodhi.

Quote

> I found out that the board uses IDT 1337G (photo).
> However, in the iomem output for 6.14.8 I do not
> see any mentions of rtc-mv and mv64xxx_i2c
> (perhaps they are called differently?).

Interesting. Let me take a look at the DTS (please do the same). The RTC must be specified in the i2c node in the DTS.

Yes, we are missing this RTC.

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

Thanks for the quick reply ;)

I'm attaching my DTB.



Edited 1 time(s). Last edit at 06/04/2025 04:01PM by sym0.

Thank you sym0 for your contribution!

Unless you already tested it I'll run the fan and led binaries on the debian system tonight to see what results I get!

Thanks :)

ConcentratedCancer Wrote:
-------------------------------------------------------
> Thank you sym0 for your contribution!
>
> Unless you already tested it I'll run the fan and
> led binaries on the debian system tonight to see
> what results I get!
>
> Thanks :)

And thank you too :)
I tried to figure out a little about LCD, LED, FAN. I debugged the binaries using the strace utility, but there wasn't enough information yet...
I think we should do this in parallel in order to achieve success sooner)

Some thoughts.

The fan might be on the i2c (if not an GPIO fan), as well as the RTC chip.

I don't think the IDT 1337G driver is supported in the kernel. It is on i2c bus.

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



Edited 1 time(s). Last edit at 06/04/2025 07:19PM by bodhi.

- I2C:

Here is the I2C bus information in 3.2.40:

root@WDMyCloudEX4 /root # ./i2cdetect -l
i2c-0 i2c mv64xxx_i2c adapter I2C adapter

root@WDMyCloudEX4 /root # ./i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
70: -- -- 72 -- -- -- -- --

root@WDMyCloudEX4 /root # ./i2cdump -y 0 0x64
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
10: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
20: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
30: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
40: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
50: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
60: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
70: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
80: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
90: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
a0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
b0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
c0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
d0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
e0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....
f0: 00 07 62 00 00 00 00 00 00 07 62 00 00 00 00 00 .?b......?b.....

root@WDMyCloudEX4 /root # ./i2cdump -y 0 0x72
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: f0 ff 00 0f XX XX XX XX XX XX XX XX XX XX XX XX ?..?XXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

On 6.14.8 it doesn't find the I2C adapter...

I also tried to compile kernel 3.2.40 with the "modular" driver mv64xxx_i2c (it does not load automatically).
The boot log had typical errors, but RTC worked fine (I checked it via /usr/sbin/rtc). So I am not sure that RTC is tied to I2C.

- LED:

With the led utility (/usr/sbin/led) you can control the diodes on 6.14.8 (except for a small bug).
For the utility to work, you must first create an empty file /tmp/system_ready

- RTC:

Managed by the rtc utility (/usr/sbin/rtc) and depends on xmldb processes in stock firmware.
Continuing to figure it out...



Edited 1 time(s). Last edit at 06/05/2025 02:04PM by sym0.

> On 6.14.8 it doesn't find the I2C adapter...
>
> I also tried to compile kernel 3.2.40 with the
> "modular" driver mv64xxx_i2c (it does not load
> automatically).

Don't need to do that. The kernel should already have i2c. We just need to enable it.

> The boot log had typical errors, but RTC worked
> fine (I checked it via /usr/sbin/rtc). So I am not
> sure that RTC is tied to I2C.

This IDT 1337G chip must be on i2c bus. But there is no kernel driver to support it. Let's see if I can find a compatible driver.

Please try the attached DTB or compile the attached DTS.

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



Edited 1 time(s). Last edit at 06/05/2025 03:54PM by bodhi.

The following line has been added to iomem:

f1011000-f101101f : f1011000.i2c i2c@11000

But I2C busses does not find:

/tmp # ./i2cdetect -l
/tmp #

sym0,

Perhaps you should install and run my kernel linux-6.14.6-kirkwood-tld-1. See if there is any difference.

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

Yes, you were right. The problem was in my .config . In an attempt to fit the kernel into ~3.5 MB, I cut out the unnecessary stuff (after some edits, it worked too)... I will do all further tests on your kernel ;)

Now i2c-0 sees:

/tmp # ./i2cdetect -l
i2c-0 i2c mv64xxx_i2c adapter I2C adapter

/tmp # ./i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
70: -- -- 72 -- -- -- -- --

But the log still says:

[ 6.325302][ T1] rtc-mv f1010300.rtc: internal RTC not ticking

I think that first we need to try to understand the mechanism of interaction with RTC on 3.2.40. Because there is not even an RTC device in the system:

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
...
*** get Time from rtc and set it into system ****
rtc: RTC time = 2025/6/4 Wed 18:37:19

> I think that first we need to try to understand
> the mechanism of interaction with RTC on 3.2.40.

It is well defined in the modern kernel, we just need to do the right thing in the DTS. Since this box uses the external RTC we need to disable the internal RTC in the SoC..

Attached is the updated dtb/dts.

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

Thanks again for your help, bodhi.

There is no RTC information in dmesg now.

The kernel does not have driver for IDT 1337G chip (quite common for older chips that nobody has tried to mainline). Hopefully we can use the Dallas/Maxim ds1307 driver, which was known to work for some other chips other than Dallas/Maxim's.

Attached is the updated dtb/dts.

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

Looks like no luck...

~ # ls /dev/rtc*
ls: /dev/rtc*: No such file or directory

/sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64
/sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/compatible
/sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/reg
/sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/name

UPD:
I didn't immediately notice that the driver is being built as a module:
CONFIG_RTC_DRV_DS1307=m
I'll try to load it now.



Edited 1 time(s). Last edit at 06/07/2025 03:39PM by sym0.

What's the content of:

cat /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/compatible
cat /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/name

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

bodhi Wrote:
-------------------------------------------------------
> What's the content of:
>

> cat
> /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/compatible
> cat
> /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/name
>

/tmp # cat -n /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/compatible
1 rtc-ds1307
/tmp # cat -n /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/name
1 rtc

After loading the module, I tried to execute the command (I'm not sure if this is necessary. I just checked.):

echo ds1307 0x72 > /sys/class/i2c-dev/i2c-0/device/new_device

and after her appeared:

/tmp # ls /dev/rtc0
/dev/rtc0

However, in dmesg:

[ 92.619165][ T176] rtc-ds1307 0-0072: registered as rtc0
[ 92.625677][ T176] rtc-ds1307 0-0072: hctosys: unable to read the hardware clock
[ 92.633382][ T176] i2c i2c-0: new_device: Instantiated device ds1307 at 0x72

and in hwclock:

/tmp # ./hwclock --debug
hwclock from util-linux-ng 2.13.1.1
Using /dev interface to clock.
Assuming hardware clock is kept in local time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
RTC_RD_TIME: Invalid argument
ioctl() to /dev/rtc0 to read the time failed.

The x64 address is not registered:

[ 140.151109][ T176] i2c i2c-0: Failed to register i2c client ds1307 at 0x64 (-16)



Edited 1 time(s). Last edit at 06/07/2025 04:02PM by sym0.

@sym0,


> registered as rtc0
> [ 92.625677][ T176] rtc-ds1307 0-0072: hctosys:
> unable to read the hardware clock
> [ 92.633382][ T176] i2c i2c-0: new_device:
> Instantiated device ds1307 at 0x72

OK that's good to know.

Now try: Boot with serial console connected. Interrupt count down and set the date

date      # or help date
date <current time>  # whatever the current time is in the format that the date command expect (shown by date command above).

And continue booting into Debian. If it does not work, repeat what your test did

echo ds1307 0x72 > /sys/class/i2c-dev/i2c-0/device/new_device
....
....

======

If that's still not successful, recompile the DTS with this change.

&i2c0 {
        status = "okay";

        /* IDT 1337G is not supported, use Dallas ds1307 driver */
        rtc@72 {
                compatible = "rtc-ds1307";
                reg = <0x72>;
        };
};

Rebuild uImage with the updated DTB, and reboot. Interupt u-boot countdown and set the date again. Continue booting.

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