I have two outlying issues that would be really cool to solve.
Going by the schematics, the RTC is integrated into the DA9063 power management device.
This topic got me curious about the RTC …
From the Unmatched schematics you can see the DA9093 is connected to i2c bus 0, and from the DA9063 datasheet you can see it’s default address is 0x58. If you install i2c-tools you can use i2cdetect 0 to see that it actually detects a device at address 0x58:
unmatched # i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: -- -- -- -- 54 -- -- -- 58 -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- According to the DA9063 datasheet the seconds are stored at register address 0x40, and you can actually query it:
unmatched # while true; do i2cget -y 0 0x58 0x40; sleep 1; done
0x83
0x84
0x85
0x86
0x87
0x88
^CThis looks like a second counter 
From this point it shouldn’t be too difficult to write a shell script to load/store the date in the RTC, and i guess a kernel driver wouldn’t be too difficult either.
I just noticed there actually is a driver for the DA9063 in the linux kernel, somehow it just doesn’t work 
The configuration options are CONFIG_MFD_DA9063 and CONFIG_RTC_DRV_DA9063.
Maybe we need something in the device tree?
It works with proper CONFIG_* options and DT changes for PMIC. RTC works fine IIRC, WDT also works, but can only trigger shutdown.
This hasn’t been enabled in the default configuration in meta-sifive.
Can you share what those options and changes are?
I enabled CONFIG_MFD_DA9063 and CONFIG_RTC_DRV_DA9063 and my dmesg now shows:
[ 6.131729] da9063 0-0058: Device detected (chip-ID: 0x61, var-ID: 0x73)
[ 6.154297] da9063-watchdog: Failed to locate of_node [id: -1]
[ 6.154444] da9063-onkey: Failed to locate of_node [id: -1]
[ 6.154579] da9063-rtc: Failed to locate of_node [id: -1]The first line seems to indicate that the device is found on the i2c bus, but there is still something missing to make it work.
so my 2012 batteries came today. have you tried probing the timer with the battery in? I don’t have linux installed, so I’m looking for other results.
even with battery in. dmesg still report:
[ 6.154297] da9063-watchdog: Failed to locate of_node [id: -1]
[ 6.154444] da9063-onkey: Failed to locate of_node [id: -1]
[ 6.154579] da9063-rtc: Failed to locate of_node [id: -1]
You need to enable PMIC sub-functions within DT, something like this:
+ rtc {
+ compatible = "dlg,da9063-rtc";
+ };
+
+ wdt {
+ compatible = "dlg,da9063-watchdog";
+ };
+
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ };
+
Make sure (just in case) that regulators values are according to the specification (see public schematics).
Modify defconfig, something like this:
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+CONFIG_RTC_SYSTOHC=y
+CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
+# CONFIG_RTC_DEBUG is not set
+CONFIG_RTC_NVMEM=y
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+# CONFIG_WATCHDOG_NOWAYOUT is not set
+CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
+CONFIG_WATCHDOG_OPEN_TIMEOUT=0
+CONFIG_WATCHDOG_SYSFS=y
+CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
+CONFIG_SOFT_WATCHDOG=m
+
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=m
+
+CONFIG_MFD_CORE=m
+
+CONFIG_INPUT_DA9063_ONKEY=m
+CONFIG_MFD_DA9063=m
+CONFIG_REGULATOR_DA9063=m
+CONFIG_RTC_DRV_DA9063=m
+CONFIG_DA9063_WATCHDOG=m
My advice would be try to see with regulators disable. Right now default defconfig in FUSDK/meta-sifive doesn’t enable DA9063 and don’t control anything. DA9063 works from what is configured in the firmware. Remember that it’s a power management IC thus I would be careful with it.
After that RTC will be working:
root@unmatched:~# timedatectl
Local time: Sun 2021-03-21 17:51:48 UTC
Universal time: Sun 2021-03-21 17:51:48 UTC
RTC time: Sun 2021-03-21 17:51:48
Time zone: Universal (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
WDT will work too, but can only shutdown the board (not reboot on failure):
root@unmatched:~# wdctl -s 131
Timeout has been set to 131 seconds.
Device: /dev/watchdog0
Identity: DA9063 Watchdog [version 0]
Timeout: 131 seconds
Pre-timeout: 0 seconds
FLAG DESCRIPTION STATUS BOOT-STATUS
KEEPALIVEPING Keep alive ping reply 1 0
SETTIMEOUT Set timeout (in seconds) 0 0
The regulator is already enabled in the Ubuntu kernel configuration. It prints an error message.
May 27 08:10:00 riscv64 kernel: DA9063_BPRO: Failed to set current constraint, -22
May 27 08:10:00 riscv64 kernel: da9063-regulators da9063-regulators: Failed to register DA9063_BPRO regulator
May 27 08:10:00 riscv64 kernel: da9063-regulators: probe of da9063-regulators failed with error -22
IIUC that’s because the driver doesn’t support it properly yet. Vincent Pelletier is working on DA063 driver changes and Unmatched DT modificiation. These patches are on a public mailing list, but not yet approved.
I’ve built Vincent’s 5.13.1 kernel with the Ubuntu configuration. Real-time clock is now working, but power off is not. wdctl reports no device is available. I’m getting an error message that may be related.
Jul 15 17:52:01 riscv64 kernel: poweroff-gpio gpio-poweroff: gpio_poweroff_probe: pm_power_off function already registered
Jul 15 17:52:01 riscv64 kernel: poweroff-gpio: probe of gpio-poweroff failed with error -16
@vpelletier Any comment?
The startup log is pretty clean now. The only other warnings are:
Jul 15 17:52:01 riscv64 kernel: da9063-rtc da9063-rtc: DMA mask not set
Jul 15 17:52:02 riscv64 kernel: da9063-onkey da9063-onkey: DMA mask not set
Here are the .debs for others to try.
https://www.w6rz.net/linux-image-5.13.1_5.13.1-1_riscv64.deb
https://www.w6rz.net/linux-headers-5.13.1_5.13.1-1_riscv64.deb
https://www.w6rz.net/linux-libc-dev_5.13.1-1_riscv64.deb
Note that you have to manually extract the .dtb files from linux-image-5.13.1_5.13.1-1_riscv64.deb (with dpkg-deb -xv) and put them in /lib/firmware/5.13.1/device-tree/sifive/ before you install so that /boot/extlinux/extlinux.conf gets updated properly.
First, a quick disclaimer: I’m not a regular kernel contributor, so my repository may contain daft stuff as I’m learning along the way. Also, I’m push-force’ing branches on this repository, so it is unstable ground - in a quicksand sense. But beyond this, happy that it can be useful.
About shutdown & reboot support, my understanding is that part of the needed support comes from SBI level. From memory the support was added in SBI spec v0.3.
Then , opensbi will have to implement this API, and the kernel to use it. I have not yet rebuilt the u-boot and opensbi which came with the board, so I do not know the current status.
FWIW, here is my /etc/modules, as for some reason not all applicable modules get automatically loaded:
sf-pdma
mmc-spi
spi-nor
pmbus
da9063_wdt
Not everything may be necessary.
Lastly on the topic of the source code, I completely neglected .config generation. My basis is Debian sid’s kernel config (which itself is not bootable on the unmatched), plus bits from the one of the kernel on the board’s sdcard (/proc/config*), plus what I put my hands in. I guess I should look into adding bits to defconfig.
About the errors:
I have not looked into the gpio-poweroff error message: my guess is that something outside of devicetree is already registering that GPIO, duplicating a declaration present in the devicetree.
I looked a tiny bit into the DMA mask not set errors, but they make no sense to me:
Documentation/devicetree/bindings, which do not mention DMA.so I’m not sure what direction the fix should go.
Thanks for the reply. Putting da9063_wdt in /etc/modules was a very helpful tip and that’s now working. da9063_wdt is blacklisted in /usr/lib/modprobe.d/blacklist_linux-riscv_5.11.0-1012-generic.conf
However, power off seems backwards now. sudo shutdown -r does power the board down, but sudo shutdown -h does not. Kooky!
I’m using a modified Ubuntu config. It’s a big kernel with a ton of drivers, but it does boot. I use make ARCH=riscv olddefconfig to fix it up. It can be downloaded here.
https://www.w6rz.net/config-5.11.0-1012-generic
BTW, I did go over your commits and they seemed fine. I was a little apprehensive of the regulator changes, but decided to let it rip. For others, the repository is here.
Thanks for the info @davidlt, i got the rtc going … a bit 
It is found by the kernel now, and i can query it with hwclock --show, but i can do that only once. After that it just times out, maybe i’ll have to try a newer kernel (using 5.12.11 now).
The CR1220 battery format seems a bit unusual here, it’s hard to find.
Hey all, I think some boards might be using a newer silicon revision of the DA9063 chip, the “AE” revision. Mine printed on dmesg:
[ 4.067260] da9063 0-0058: Device detected (chip-ID: 0x61, var-ID: 0x83)
[ 4.073195] da9063 0-0058: Chip variant not supported for DA9063
This is apparently a newer revision of the “A*” line… the current driver only supports “AD” revision.
I’ve patched the driver to add it to the case:
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 783a14af18e2..a8895ee1c600 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -391,6 +391,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
&da9063_bb_da_volatile_table;
break;
case PMIC_DA9063_DA:
+ case PMIC_DA9063_EA:
da9063_regmap_config.rd_table =
&da9063_da_readable_table;
da9063_regmap_config.wr_table =
@@ -416,6 +417,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
&da9063l_bb_da_volatile_table;
break;
case PMIC_DA9063_DA:
+ case PMIC_DA9063_EA:
da9063_regmap_config.rd_table =
&da9063l_da_readable_table;
da9063_regmap_config.wr_table =
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index fa7a43f02f27..1da6c66f98da 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -36,6 +36,7 @@ enum da9063_variant_codes {
PMIC_DA9063_BB = 0x5,
PMIC_DA9063_CA = 0x6,
PMIC_DA9063_DA = 0x7,
+ PMIC_DA9063_EA = 0x8,
};
/* Interrupts */
This detected the chip and I’m able to use the RTC and watchdog. Now I get in dmesg:
[ 4.071184] da9063 0-0058: Device detected (chip-ID: 0x61, var-ID: 0x83)
[ 4.092605] DA9063_BPRO: Failed to set current constraint, -22
[ 4.097694] da9063-regulators da9063-regulators: Failed to register DA9063_BPRO regulator
[ 4.105854] da9063-regulators: probe of da9063-regulators failed with error -22
[ 4.113422] da9063-onkey da9063-onkey: DMA mask not set
[ 4.124478] input: da9063-onkey as /devices/platform/soc/10030000.i2c/i2c-0/0-0058/da9063-onkey/input/input0
[ 4.133762] da9063-rtc da9063-rtc: DMA mask not set
[ 4.152618] da9063-rtc da9063-rtc: registered as rtc0
[ 4.158085] da9063-rtc da9063-rtc: setting system clock to 2021-07-26T18:55:42 UTC (1627325742)
[ 4.225733] da9063-watchdog da9063-watchdog: DMA mask not set
I’ve applied the reboot patch from @marcus hosted on dpaste: Kernel patch for working reboot command on HiFive unmatched (remember to enable CONFIG_MFD_DA9063) and it is rebooting correctly.
I’m looking for some DA9063 docs to update and maybe send a patch.
Edit: Fixed the patch with correct chip revision and no reboot problems
The patches that Vincent did for the DA9063 fix the regulator error messages. He made a lot of changes, but I’ve been running them for almost two weeks now with no issue.
See the link for Linux 5.13.1 three posts up.
What are the markings on the chip? The documentation is available via the link in the second post in the thread, but it doesn’t mention the differences between the different silicon revisions at all. You’ll probably have to ask Dialog directly about those.
Edit: Based on old LKML posts, the AD silicon is an old pre-production version. If there is a new revision, it’s not likely to use the AD register maps.
Edit the 2nd: The “name” of variant 8 is probably EA.
The markings on my chip are:
DA9063
EA
2021ECAF
I’ve sent an email to Dialog to confirm this info. With this, I understand the EA is the production revision from DA so it’s behavior might be the same.
I’ve updated the patch and by using the same registers as DA revision, reboot also works with the linked patch.