Watchdog device on RK3328 (Rock64)

[berturion]

Here is my boot.txt (I only changed root parameter to have my rootfs on a USB disk partition, everything else is the default config):

$this->bbcode_second_pass_code('', '
# After modifying, run ./mkscr

# MAC address (use spaces instead of colons)
setenv macaddr da 19 c8 7a 6d f4

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs console=ttyS2,1500000 root=LABEL=rootfs rw rootwait earlycon=uart8250,mmio32,0xff130000
setenv fdtfile rockchip/rk3328-rock64.dtb

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/Image; then
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt resize
fdt set /ethernet@ff540000 local-mac-address "[${macaddr}]"
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi
')

[summers]

Try:

$this->bbcode_second_pass_code('', '# After modifying, run ./mkscr

# MAC address (use spaces instead of colons)
setenv macaddr da 19 c8 7a 6d f4

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs console=ttyS2,1500000 root=LABEL=rootfs rw rootwait earlycon=uart8250,mmio32,0xff130000
setenv fdtfile rockchip/rk3328-rock64.dtb

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/Image; then
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt resize 1024
fdt set /ethernet@ff540000 local-mac-address "[${macaddr}]"
fdt set /watchdog@ff1a0000 status "okay"
fdt resize
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi')

I've changed the "fdt resize" to make it a bit safer. The watchdog command should set it operation - now wether that helps or not i don't know. Oh yes - I can't check this. e.g. I not sure the okay needs quoting - as it a standard option, but I could be wrong .... If it doesn't work can you pull the disk, e.g. is it on a sdcard? If so then you can correct when it doesn't work ...

[berturion]

Thanks, I am at work right now, I could try it through ssh but if it goes wrong, I will lost my web server for the day. I will try that as soon as I am back at home.

Also, my rootfs is daily mirrored on the sdcard and vice versa so it is easy to switch if necessary.

[berturion]

I did the changes. Is it normal that there are two lines with "fdt resize" ?
The machine boots. What do I have to check to see if it worked ?

[summers]

hi, when I read the code about uboot, I read the "ftd resize" code, as it isn't mention much.

When uboot loads the device tree, it sets aside memory for it so IIRC it goes up next 4KB, so it sets aside a multiple 4kB. Now how the tree is stored not clear to me, probably as a blob. So the is between 0-4kB free space. So you can add things to device tree, but when you get down to 0, you get an error.

Now "ftd resize X" reserve at least X bytes, so if necessary it grows by a multiple of 4kB. With no X then it sizes it with no extra size.

so "ftd resize 1024" says give me at least 1kb of space - which should be enough for the next two commands, the final "ftd resize" then just says if there is more than 4kB free, which there may be, then give up the excess.

So without the second "ftd resize" it should boot fine, but maybe some space wasted. Without the first "fdt resize 1024" it will usually work, but occasionally you get an error - which is annoying ...

So did the change work? What is in $this->bbcode_second_pass_code('', '/proc/device-tree/watchdog@ff1a0000') is status there? if yes and it contains "okay" then is "/dev/watchdog" there? And if so does it work?

[berturion]

Here are some commands:

$this->bbcode_second_pass_code('', '
# ls -al /proc/device-tree/
total 0
drwxr-xr-x 60 root root 0 Sep 15 02:07 .
drwxr-xr-x 3 root root 0 Sep 15 02:07 ..
drwxr-xr-x 2 root root 0 Sep 20 08:27 adc@ff280000
-r--r--r-- 1 root root 4 Sep 20 08:27 '#address-cells'
drwxr-xr-x 2 root root 0 Sep 20 08:27 aliases
drwxr-xr-x 3 root root 0 Sep 20 08:27 amba
drwxr-xr-x 2 root root 0 Sep 20 08:27 arm-pmu
drwxr-xr-x 2 root root 0 Sep 20 08:27 chosen
drwxr-xr-x 2 root root 0 Sep 20 08:27 clock-controller@ff440000
-r--r--r-- 1 root root 30 Sep 20 08:27 compatible
drwxr-xr-x 7 root root 0 Sep 20 08:27 cpus
drwxr-xr-x 2 root root 0 Sep 20 08:27 dwmmc@ff500000
drwxr-xr-x 2 root root 0 Sep 20 08:27 dwmmc@ff510000
drwxr-xr-x 2 root root 0 Sep 20 08:27 dwmmc@ff520000
drwxr-xr-x 6 root root 0 Sep 20 08:27 efuse@ff260000
drwxr-xr-x 2 root root 0 Sep 20 08:27 ethernet@ff540000
drwxr-xr-x 3 root root 0 Sep 20 08:27 ethernet@ff550000
drwxr-xr-x 2 root root 0 Sep 20 08:27 external-gmac-clock
drwxr-xr-x 2 root root 0 Sep 20 08:27 gpu@ff300000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2c@ff150000
drwxr-xr-x 3 root root 0 Sep 20 08:27 i2c@ff160000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2c@ff170000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2c@ff180000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2s@ff000000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2s@ff010000
drwxr-xr-x 2 root root 0 Sep 20 08:27 i2s@ff020000
drwxr-xr-x 2 root root 0 Sep 20 08:27 interrupt-controller@ff811000
-r--r--r-- 1 root root 4 Sep 20 08:27 interrupt-parent
drwxr-xr-x 2 root root 0 Sep 20 08:27 iommu@ff330200
drwxr-xr-x 2 root root 0 Sep 20 08:27 iommu@ff340800
drwxr-xr-x 2 root root 0 Sep 20 08:27 iommu@ff350800
drwxr-xr-x 2 root root 0 Sep 20 08:27 iommu@ff360480
drwxr-xr-x 2 root root 0 Sep 20 08:27 iommu@ff373f00
drwxr-xr-x 2 root root 0 Sep 20 08:27 memory
-r--r--r-- 1 root root 14 Sep 20 08:27 model
-r--r--r-- 1 root root 1 Sep 20 08:27 name
drwxr-xr-x 8 root root 0 Sep 20 08:27 opp_table0
drwxr-xr-x 2 root root 0 Sep 20 08:27 pdm@ff040000
drwxr-xr-x 61 root root 0 Sep 20 08:27 pinctrl
drwxr-xr-x 2 root root 0 Sep 20 08:27 psci
drwxr-xr-x 2 root root 0 Sep 20 08:27 pwm@ff1b0000
drwxr-xr-x 2 root root 0 Sep 20 08:27 pwm@ff1b0010
drwxr-xr-x 2 root root 0 Sep 20 08:27 pwm@ff1b0020
drwxr-xr-x 2 root root 0 Sep 20 08:27 pwm@ff1b0030
drwxr-xr-x 2 root root 0 Sep 20 08:27 sdmmc-regulator
drwxr-xr-x 2 root root 0 Sep 20 08:27 serial@ff110000
drwxr-xr-x 2 root root 0 Sep 20 08:27 serial@ff120000
drwxr-xr-x 2 root root 0 Sep 20 08:27 serial@ff130000
-r--r--r-- 1 root root 4 Sep 20 08:27 '#size-cells'
drwxr-xr-x 2 root root 0 Sep 20 08:27 spdif@ff030000
drwxr-xr-x 2 root root 0 Sep 20 08:27 spi@ff190000
drwxr-xr-x 2 root root 0 Sep 20 08:27 __symbols__
drwxr-xr-x 5 root root 0 Sep 20 08:27 syscon@ff100000
drwxr-xr-x 3 root root 0 Sep 20 08:27 syscon@ff450000
drwxr-xr-x 3 root root 0 Sep 20 08:27 thermal-zones
drwxr-xr-x 2 root root 0 Sep 20 08:27 timer
drwxr-xr-x 2 root root 0 Sep 20 08:27 tsadc@ff250000
drwxr-xr-x 2 root root 0 Sep 20 08:27 usb@ff580000
drwxr-xr-x 2 root root 0 Sep 20 08:27 usb@ff5c0000
drwxr-xr-x 2 root root 0 Sep 20 08:27 usb@ff5d0000
drwxr-xr-x 3 root root 0 Sep 20 08:27 usb@ff600000
drwxr-xr-x 2 root root 0 Sep 20 08:27 vcc-host1-5v-regulator
drwxr-xr-x 2 root root 0 Sep 20 08:27 vcc-host-5v-regulator
drwxr-xr-x 2 root root 0 Sep 20 08:27 vcc-sys
drwxr-xr-x 2 root root 0 Sep 20 08:27 watchdog@ff1a0000
drwxr-xr-x 2 root root 0 Sep 20 08:27 xin24m
')

$this->bbcode_second_pass_code('', '
ls -al watchdog\@ff1a0000/
total 0
drwxr-xr-x 2 root root 0 Sep 20 08:27 .
drwxr-xr-x 60 root root 0 Sep 15 02:07 ..
-r--r--r-- 1 root root 12 Sep 20 08:31 compatible
-r--r--r-- 1 root root 12 Sep 20 08:31 interrupts
-r--r--r-- 1 root root 9 Sep 20 08:31 name
-r--r--r-- 1 root root 4 Sep 20 08:31 phandle
-r--r--r-- 1 root root 16 Sep 20 08:31 reg
-r--r--r-- 1 root root 5 Sep 20 08:31 status
')

$this->bbcode_second_pass_code('', '
# cat watchdog\@ff1a0000/status
okay
')

So status is "okay" as expected but there is no/dev/watchdog...

Is there anything else we can try or do we have to conclude watchdog is not supported by the kernel yet

EDIT: Thanks for your "ftd resize" explanation

[summers]

That you've got "status" and its "okay" says the changes we made to the device tree worked!

That you don't have /dev/watchdog, says probably it hasn't come up. check dmesg - I expect you still have $this->bbcode_second_pass_code('', ' [ 8.941841] dw_wdt: probe of ff1a0000.watchdog failed with error -2').

Its probably not a kernel problem. the dw_wdt code looked mature. You could check with @TheSaint of this forum, he has a Tinker Board S, which is a RK3288 device - which also should use dw_wdt. hence if he has a /dev/watchdog then the code is basically working.

If I was to hazard a guess, its that the hardware is not totally explained in the device tree. That the watchdog didn't have a "status" link makes me suspicious that the description isn't solid. You could ask Liang Chen <cl at rock-chips dot com> what the status is, he wrote that bit of the device tree. Maybe the rock chip maintainer Heiko Stuebner <heiko at sntech dot de>

https://github.com/torvalds/linux/commit/52e02d377a7282ae57052c222cdaacf45ddc4c5d

And probably check the data sheet / trm for the rk3328 ...

If I had to guess - its missing a "clocks" node - but how that is wired on the rk3328 I don't know ...

[berturion]

Yes you're right I still have

$this->bbcode_second_pass_code('', '[ 11.611373] dw_wdt: probe of ff1a0000.watchdog failed with error -2')

I will contact them to ask what you suggest. Thank you for your help.

[berturion]

This is my e-mail sent to Liang Chen and Heiko Stuebner on Thu, 20 Sep 2018 14:00:07 +0400, no answer since then.

$this->bbcode_second_pass_quote('', '
')Hello Rock64 contributors,

I am a Rock64 happy owner and, with the help of Arch Linux Arm team
members, we tried to enable the watchdog device of the board.

Our thread is here :
viewtopic.php?f=67&t=13087&p=59556#p59555

Forcing a status "okay" in the watchdog entry in the device tree using
u-boot script didn't make appear the device (/dev/watchdog absent).

I wanted to know what was the status of this feature ? Will it be
possible in a future to use the watchdog of Rock46 ?

Thanks.

[summers]

Its a fair question, but look at who sent to:

Liang Chen is the Rockchip employee that submitted the original rk3328 device tree. Now how the watchdog is configured is in the main rk3328 chip - so rockchip are the people that know. This said what is Liang Chen remit in Rockchip, we don't know. Maybe he was only getting a device tree out there so they can run android on the chip, and that done he is on another project? Maybe he is the linux facing employee. Anyway its hard to say how interested he would be.

Heiko Stuebner is the linux kernel rockchip maintainer - and actually he does alot. Check: http://lists.infradead.org/pipermail/linux-rockchip/2018-September/thread.html and he is active. But I also suspect he is busy, and so probably focused on where he knows he can make a difference. E.g. on my Tinker Board S device tree submission he has helped a huge amount; but then again we already had the various ingredients we needed - so it was just a case of doing a suitable kernel patch. Even so, it has taken 4 patch attempts - and this is where we knew what we were doing ...

Now on the watchdog, suspect to get a reply we need to be *very* focused. Me I'd start from https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi the rk3328 device tree is malformed:
$this->bbcode_second_pass_code('', ' wdt: watchdog@ff1a0000 {
compatible = "snps,dw-wdt";
reg = <0x0 0xff1a0000 0x0 0x100>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};')
Compare this to another snps,dw-wdt device, the rk3288 : https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288.dtsi it has:
$this->bbcode_second_pass_code('', 'wdt: watchdog@ff800000 {
compatible = "rockchip,rk3288-wdt", "snps,dw-wdt";
reg = <0x0 0xff800000 0x0 0x100>;
clocks = <&cru PCLK_WDT>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};')
It may be worth checking other snps,dw-wdt devices, to see how they are defined. Now Heiko is close enough to the kernel, that he can also probably look at the rk3328 and see that the raw device tree is incomplete. Now he can't solve that himself, he needs to know how the chip is wired, that may be in data sheets, but I can't find it - and yes I did go and look. Only really rockchip can solve.

Now look at the rk3288 device, obvious change is the "clocks = <&cru PCLK_WDT>;" Now that is defined in https://github.com/torvalds/linux/blob/master/include/dt-bindings/clock/rk3288-cru.h and the clock is defined as $this->bbcode_second_pass_code('', '#define PCLK_WDT 368'). Now what you can find on the TRM for the rk3328 is that it has a PCLK clock: http://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf, so check the clocks defined in the kernel: https://github.com/torvalds/linux/blob/master/include/dt-bindings/clock/rk3328-cru.h and the only PCLK are:
$this->bbcode_second_pass_code('', '/* pclk gates */
#define PCLK_GPIO0 200
#define PCLK_GPIO1 201
#define PCLK_GPIO2 202
#define PCLK_GPIO3 203
#define PCLK_GRF 204
#define PCLK_I2C0 205
#define PCLK_I2C1 206
#define PCLK_I2C2 207
#define PCLK_I2C3 208
#define PCLK_SPI 209
#define PCLK_UART0 210
#define PCLK_UART1 211
#define PCLK_UART2 212
#define PCLK_TSADC 213
#define PCLK_PWM 214
#define PCLK_TIMER 215
#define PCLK_BUS_PRE 216
#define PCLK_PERI_PRE 217
#define PCLK_HDMI_CTRL 218
#define PCLK_HDMI_PHY 219
#define PCLK_GMAC 220
#define PCLK_H265 221
#define PCLK_MAC2PHY 222
#define PCLK_MAC2IO 223
#define PCLK_USB3PHY_OTG 224
#define PCLK_USB3PHY_PIPE 225
#define PCLK_USB3_GRF 226
#define PCLK_USB2_GRF 227
#define PCLK_HDMIPHY 228
#define PCLK_DDR 229
#define PCLK_PERI 230
#define PCLK_HDMI 231
#define PCLK_HDCP 232
#define PCLK_DCF 233
#define PCLK_SARADC 234')
And none of those look obviously like a WDT clock - so it doesn't have an obvious name.

So we just learn that its not clear, that we don't have a solution.

Just this story above is something like 1h of work, when you know what to follow. Not sure Heiko can afford that amount of time on something that doesn't have a solution.

Now does Liang Chen care? Don't know - maybe he doesn't even see a problem.

So all we get is its a can of worms, down deep in the kernel, probably device tree. And its not clear who can solve.

So I can maybe understand why you don't get an answer, as its not easy to answer ...