arch/arm64/boot/dts/freescale/s32g2.dtsi | 4 ++++ arch/arm64/boot/dts/freescale/s32g3.dtsi | 4 ++++ arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi | 6 ++++++ 3 files changed, 14 insertions(+)
S32G RTC is probed after the RTC on RDB (PCA85073A) so the S32G RTC
ends up on /dev/rtc1. This causes the suspend/resume or hwclock to use
the wrong RTC since it takes by default rtc0.
Force the S32G RTC to be assigned rtc0.
Signed-off-by: Andrei Botila <andrei.botila@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/s32g2.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/s32g3.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi | 6 ++++++
3 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
index 51d00dac12de..d538876f3854 100644
--- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
@@ -14,6 +14,10 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ rtc0 = &rtc0;
+ };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
index e314f3c7d61d..713c75c63f94 100644
--- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
@@ -15,6 +15,10 @@ / {
#address-cells = <0x02>;
#size-cells = <0x02>;
+ aliases {
+ rtc0 = &rtc0;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
index 979868f6d2c5..e3e83923b10e 100644
--- a/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
@@ -7,6 +7,12 @@
* Larisa Grigore <larisa.grigore@nxp.com>
*/
+/ {
+ aliases {
+ rtc1 = &pca85073a;
+ };
+};
+
&pinctrl {
can0_pins: can0-pins {
can0-grp0 {
--
2.52.0On Tue, Mar 10, 2026 at 9:50 AM Andrei Botila <andrei.botila@oss.nxp.com> wrote: > > S32G RTC is probed after the RTC on RDB (PCA85073A) so the S32G RTC > ends up on /dev/rtc1. This causes the suspend/resume or hwclock to use > the wrong RTC since it takes by default rtc0. > Force the S32G RTC to be assigned rtc0. We usually prefer to use the I2C RTC as rtc0 because it is battery-backed. What's the exact problem with using the I2C RTC as rtc0? Is the S32G RTC battery-backed?
On 3/10/2026 3:14 PM, Fabio Estevam wrote: > On Tue, Mar 10, 2026 at 9:50 AM Andrei Botila <andrei.botila@oss.nxp.com> wrote: >> >> S32G RTC is probed after the RTC on RDB (PCA85073A) so the S32G RTC >> ends up on /dev/rtc1. This causes the suspend/resume or hwclock to use >> the wrong RTC since it takes by default rtc0. >> Force the S32G RTC to be assigned rtc0. > > We usually prefer to use the I2C RTC as rtc0 because it is battery-backed. > > What's the exact problem with using the I2C RTC as rtc0? > > Is the S32G RTC battery-backed? Hello, S32G RTC is not battery-backed. Regarding the I2C RTC(PCA85073A) commands like hwclock or rtcwake use by default /dev/rtc, /dev/rtc0 so they will try to use PCA and fail. Also from what I could find online PCA85073A is also not battery-backed. Thank you, Andrei
On Tue, Mar 10, 2026 at 10:50 AM Andrei Botila <andrei.botila@oss.nxp.com> wrote: > Regarding the I2C RTC(PCA85073A) commands like hwclock or rtcwake use by > default /dev/rtc, /dev/rtc0 so they will try to use PCA and fail. These commands should not fail. date -s "2026-03-10 11:00:00" hwclock -w Power-cycle the board. Does the "date" command retain the correct time? > Also from what I could find online PCA85073A is also not battery-backed. I haven't checked, but this looks strange. How will the board retain the time then, after a power cycle?
On 3/10/2026 4:02 PM, Fabio Estevam wrote: > On Tue, Mar 10, 2026 at 10:50 AM Andrei Botila > <andrei.botila@oss.nxp.com> wrote: > >> Regarding the I2C RTC(PCA85073A) commands like hwclock or rtcwake use by >> default /dev/rtc, /dev/rtc0 so they will try to use PCA and fail. > > These commands should not fail. rtcwake -s 10 -m mem rtcwake: cannot open /sys/class/rtc/rtc0/device/power/wakeup: No such file or directory rtcwake: /dev/rtc0 not enabled for wakeup events Through this patch what I am trying to do is to get rid of the need of specifying the rtc (-d rtcX). > > date -s "2026-03-10 11:00:00" > hwclock -w > > Power-cycle the board. Does the "date" command retain the correct time? date -> Tue Mar 10 11:12:43 UTC 2026 date -s "2026-03-10 11:00:00" -> Tue Mar 10 11:00:00 UTC 2026 hwclock -w date -> Tue Mar 10 11:00:06 UTC 2026 <Power cycle> hwclock -r -> 2026-03-10 11:00:31.104653+00:00 So looks like it does retain the date between power cycles. > >> Also from what I could find online PCA85073A is also not battery-backed. > > I haven't checked, but this looks strange. How will the board retain > the time then, after a power cycle?
On Tue, Mar 10, 2026 at 12:21 PM Andrei Botila <andrei.botila@oss.nxp.com> wrote: > rtcwake -s 10 -m mem > > rtcwake: cannot open /sys/class/rtc/rtc0/device/power/wakeup: No such file or directory > rtcwake: /dev/rtc0 not enabled for wakeup events You're missing the 'wakeup-source' property for the I2C RTC. > > date -s "2026-03-10 11:00:00" > > hwclock -w > > > > Power-cycle the board. Does the "date" command retain the correct time? > > date -> Tue Mar 10 11:12:43 UTC 2026 > > date -s "2026-03-10 11:00:00" -> Tue Mar 10 11:00:00 UTC 2026 > > hwclock -w > > date -> Tue Mar 10 11:00:06 UTC 2026 > > <Power cycle> > > hwclock -r -> 2026-03-10 11:00:31.104653+00:00 > > So looks like it does retain the date between power cycles. Yes, the I2C RTC is working as expected and is battery-backed. You should use it as rtc0. Instead of relying on random probe order, it is OK to pass an aliases inthe board devicetree to force the I2C RTC to be rtc0. If you use the SoC RTC as rtc0, the time will not be retained.
© 2016 - 2026 Red Hat, Inc.