Hi, has anyone run into RTC trouble with Rock 3a?

#22

You don’t need an overlay, I think (not really sure) the RTC is on i2c5:

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

Just reboot after hwclock -w and check dmesg again.

#23

yes, now it works after reboot.
If I shut down and restart from the button on the board, everything is fine.
also in check dmesg.
but if I turn off the power on usb-C for a minute, the date goes back on reboot. So it seems that it is not maintained, as if the battery power is not there,
do I have to close some jumper somewhere?

Thanks

#24

03
WhatsApp Image 2022-03-15 at 15.31.03.jpeg1512×2016 325 KB

I got it like this without jumpers!

#25

Err, I did the same here and the date is back to 2017.
Maybe someone needs to have a look at hwclock and check why it is not really saving in the correct registers ( I suppose ). If I recall correctly, odroid have a special hwclock for one of their board (EOL).

The jumpers are for SPI/recovery : https://wiki.radxa.com/Rock3/hardware/3a

Update (possible fix = NO!):
We need sudo hwclock -s to read from HW rtc and set the system date at boot time.

#26

I get a glimpse of hwclock, looks like the rtc backup battery is not working as expected.

hwclock -w, is indeed writing to kernel:

openat(AT_FDCWD, "/sys/class/rtc/rtc0", O_RDONLY|O_CLOEXEC) = 4
openat(4, "name", O_RDONLY|O_CLOEXEC)   = 5
fcntl(5, F_GETFL)                       = 0x20000 (flags O_RDONLY|O_LARGEFILE)
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
read(5, "rk808-rtc rk808-rtc\n", 4096)  = 20
ioctl(3, RTC_SET_TIME, {tm_sec=46, tm_min=35, tm_hour=21, tm_mday=15, tm_mon=2, tm_year=122, ...}) = 0

and reading from kernel:

openat(AT_FDCWD, "/dev/rtc0", O_RDONLY) = 3
ioctl(3, RTC_RD_TIME, {tm_sec=16, tm_min=37, tm_hour=21, tm_mday=15, tm_mon=2, tm_year=122, ...}) = 0

Maybe rk808-rtc can’t sense the backup battery.
Firefly boards use HYM8563 chip instead of RK808.

1 Like
#27

I tried, and on pin 8 of the HYM8563 IC we get 3.2 V so I would say it is not the battery, since I have the same fixed voltage with or without 12V power supply.
Now if I configure the rtc, everything works when switching off and on with the Power button, and so far everything is fine.

If I remove the power supply for less than a minute, I eliminate the voltage to the board but there are always 3.2 V. As soon as I insert the power supply the board starts and the time is wrong.
The only thing that comes to mind is that at boot linux sends some command to reset rtc, so it brings it back to 2017, if I didn’t send this command I should find the stored date.

Does anyone know at boot where the rtc is loaded to see what commands it executes?

#28

I am not into the hardware thing, so you found HYM8563 IC on 3A, then it is just DT missing the node.

#29

I have added an entry for HYM8563, now I have this:

[    0.862464] rk808-rtc rk808-rtc: registered as rtc0
[    0.864243] rk808-rtc rk808-rtc: setting system clock to 2017-08-04 09:00:06 UTC (1501837206)
[    2.448750] rtc-hym8563 5-0051: rtc core: registered hym8563 as rtc1

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

Now i have to figure how to tell ditro to use rtc1 instead of rtc0.

#30

Just in case someone would like to know the fix:

The ugly way (without compiling the kernel):

  1. Decompile the dtb file (in my case is rk3568-rock-3-a.dtb)

  2. Find i2c5 node and add the HYM8563 entry

    &i2c5 {
    status = “okay”;
    pinctrl-0 = <&i2c5m0_xfer>;

    hym8563: hym8563@51 {
    status = “okay”;
    compatible = “haoyu,hym8563”;
    reg = <0x51>;
    #clock-cells = <0>;
    rtc-irq-gpio = <&gpio0 27 2>;
    clock-frequency = <32768>;
    };
    };

  3. recompile the dtb

  4. boot with this new dtb

  5. hwclock tries to use /dev/rtc , and /dev/rtc -> rtc0 , try to change it to rtc1
    https://unix.stackexchange.com/questions/246605/how-can-the-link-target-of-dev-rtc-be-changed

  6. sudo hwclock -w

  7. sudo reboot or sudo shutdown -h now and unplug the power cord

  8. After boot (without wifi or ethernet plugged in), check date again: sudo hwclock -r

  9. that’s it!

The good way (recompile the kernel)

  1. Disable RTC RK808
    # CONFIG_RTC_DRV_RK808 is not set

  2. Add the HYM8563 entry

  3. rebuild the kernel

  4. install the new kernel and follow 6,7,8,9

That’s it, folks.

#31

Yes, but because not all peripherals are tested before putting it on the market.
You have to make all this mess.

#32

i have the same rk3568-rock-3-a.dtb file, but my decompilation is different, i have an alias to i2c5 and if i add what you entered i get error.

i2c@fe5e0000 {
compatible = “rockchip,rk3399-i2c”;
reg = < 0x00 0xfe5e0000 0x00 0x1000 >;
clocks = < 0x1f 0x150 0x1f 0x14f >;
clock-names = “i2c\0pclk”;
interrupts = < 0x00 0x33 0x04 >;
pinctrl-names = “default”;
pinctrl-0 = < 0xcd >;
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
status = “okay”;
phandle = < 0x19a >;

            hym8563: hym8563@51 {
            status = "okay";
            compatible = "haoyu,hym8563";
            reg = <0x51>;
            #clock-cells = <0>;
            rtc-irq-gpio = <&gpio0 27 2>;
            clock-frequency = <32768>;
    };

Output:
/boot/dtbs/4.19.193-33-rockchip-g5add69115a1c/rockchip/rk3568-rock-3-a.dtb: ERROR (phandle_references): /i2c@fe5e0000/hym8563@51: Reference to non-existent node or label “gpio0”

ERROR: Input tree has errors, aborting (use -f to force output)

how come in my file I often have rk3399? Is it compatible with rk3568?

Thanks for any help

#33

Ouch, sorry, you don’t have i2c5 enabled.

Restore it and add this to the end :

&i2c5 {
status = “okay”;
pinctrl-0 = <&i2c5m0_xfer>;

hym8563: hym8563@51 {
status = “okay”;
compatible = “haoyu,hym8563”;
reg = <0x51>;
#clock-cells = <0>;
rtc-irq-gpio = <&gpio0 27 2>;
clock-frequency = <32768>;
};
};

just before the:

&i2s0_8ch {
status = “okay”;
};

&i2s1_8ch {
status = “okay”;
rockchip,clk-trcm = <1>;
pinctrl-names = “default”;
pinctrl-0 = <&i2s1m0_sclktx
&i2s1m0_lrcktx
&i2s1m0_sdi0
&i2s1m0_sdo0>;
};

then recompile it.

But you should have it:

#34

I don’t know what image you are using.
I use Debian Buster, and as you can see the decompiled script is different from yours, there is no “&” character, also Rock 3A has no DT-Overlay on i2c5, perhaps because it is already active and for internal use.
I finded this: https://patchwork.kernel.org/project/linux-watchdog/patch/20210428135002.22528-1-cl@rock-chips.com/#24146885

does anyone have a Debian image for Rock 3A with rtc enabled?

#35

Ok, i used an intermediate dts as the example, my bad.

Just use the attached dtb and you are good to go. Just make a backup of your current dtb just in case.
rk3568-rock-3-a.dtb.zip (23.9 KB)

#36

The previous dtb was for the 5inch panel, here is the one for hdmi only, sorry for the confusion.
have fun.
rk3568-rock-3-a.dtb_hdmi.zip (23.6 KB)

#37

Then I started creating .dtsi and .dtbo files too, but nothing.
Your first file isn’t good, my 7 inch LCD doesn’t work, and neither does the ethernet port.
With the second file _hdmi, the peripherals work again and I saw that taking out the dts, there is hym8563 inside.
In fact I find myself:

rock@rock-3a:~$ ls -al /dev/rtc*
lrwxrwxrwx 1 root root 4 Feb 14 2019 /dev/rtc -> rtc0
crw------- 1 root root 251, 0 Feb 14 2019 /dev/rtc0
crw------- 1 root root 251, 1 Feb 14 2019 /dev/rtc1

Even changing /dev/rtc -> rtc1, I find myself again /dev/rtc -> rtc0 on reboot
But following this guide, I solved:

now on reboot even if it resets rtc0, it goes to point the kernel = rtc1 and even 10 minutes off, it returns me the correct date.
I just don’t understand why we have to have two clocks, we can’t use rtc0 directly. Maybe because it is already being used by the CPU?

Anyway I would like to thank avaf for your help, we hope that in the future it is already included in the release, or at least they add a dt-overlay for rtc to be enabled, so it will be easier

Thanks a lot

#38

Ok, I also tried another method and it works, without using your edited .dtb file.

So, I took my old image, or a clean image, and checked that the rtc wasn’t working.

  1. I created a hym8563.dts file with this content:
    / dts-v1 /;
    / plugin /;

/ {
compatible = “rockchip, rk3568”;

fragment @ 0 {
target = <& i2c5>;

overlay {

address-cells = <1>;

                     # size-cells = <0>;

hym8563 @ 51 {
status = “okay”;
compatible = “haoyu, hym8563”;
reg = <0x51>;
# clock-cells = <0x00>;
rtc-irq-gpio = <& gpio0 27 2>;
clock-frequency = <0x8000>;
phandle = <0x19b>;
};
};
};
};

  1. then
    sudo dtc -O dtb -I dts -o rk3568-i2c5-hym8563.dtbo hym8563.dts

  2. in
    overlays = rk3568-fiq-debugger-uart2m0 rk3568-can1-m0 rk3568-pwm8-m0-fan rk3568-i2c5-hym8563

and I get rtc1
rock@rock-3a:~$ ls -al /dev/rtc*
lrwxrwxrwx 1 root root 4 Feb 14 2019 /dev/rtc -> rtc0
crw------- 1 root root 251, 0 Feb 14 2019 /dev/rtc0
crw------- 1 root root 251, 1 Feb 14 2019 /dev/rtc1

  1. In /lib/udev/hwclock-set comment out the lines below

#if [ -e /run/systemd/system ]; then

exit 0

#fi
#if [ -e /run/udev/hwclock-set ]; then
#exit 0
#fi

then change the HCTOSYS_DEVICE=rtc0 line to be HCTOSYS_DEVICE=rtc1

  1. In /lib/udev/rules.d/50-udev-default.rules change the SUBSYSTEM==“rtc” line to:
    SUBSYSTEM==“rtc”, KERNEL==“rtc1”, SYMLINK+=“rtc”, OPTIONS+=“link_priority=-100”

  2. In your hwclock udev rule make sure you have (/lib/udev/rules.d/85-hwclock.rules):

KERNEL==“rtc1”, RUN+="/lib/udev/hwclock-set $root/$name"

I am attaching the rk3568-i2c5-hym8563.dtbo file if anyone wants to do first
rk3568-i2c5-hym8563.zip (484 Bytes)

#39

Hi, here you didn’t mention about attaching a HYM8563 device, does this mean that rock3a already has a HYM8563 device?

#40

https://wiki.radxa.com/Rock3/Ubuntu (RTC section)

#41

@Stephen
Hi, this doesn’t solve the problem. Even after link rtc to rtc1 with udev rules.
According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785445, the default rtc device to use is set at compile time:

That’s right, the kernel optionally reads an RTC into the system time at
boot (CONFIG_RTC_HCTOSYS) and the name of the RTC to use is also part of
the kernel configuration (CONFIG_RTC_HCTOSYS_DEVICE).

So, may be changing the compile parameter when officially release new kernel is the best solution.

Hi, does rock3a have debian bookworm upgrade?