RTC0 doesn't work on Jetpack 6 with battery but it works on Jetpack 5

[naxty]

Hi,

on our custom carrier board with jetpack 6 (36.3) we can’t get RTC0 with battery working. Every time we are reading from our board with a battery attached we get a timeout. If we are removing the battery we can read. Only when it’s inserted we can’t read from it. It’s a 3V battery.

# jetpack 6 (36.3)
$ sudo hwclock --show --rtc=/dev/rtc0
hwclock: select() to /dev/rtc0 to wait for clock tick timed out

If we are switching back to jetpack 5 we can successfully read from it and the time is stored on it after removing it from power.

# jetpack 5
$ sudo hwclock --show --rtc=/dev/rtc0
2024-07-04 15:52:05.404443+00:00

When comparing dmesg outputs I have noticed that it takes long for jetpack 6 to register rtc0 even though it times out when reading. Compared to jetpack 5 it’s much faster.

# Jetpack 6 dmesg
[   31.925652] nvvrs-pseq-rtc nvvrs-pseq-rtc: registered as rtc0
[   31.926737] nvvrs-pseq-rtc nvvrs-pseq-rtc: setting system clock to 1970-01-01T00:24:34 UTC (1474)

# Jetpack 5 dmesg
[    4.534433] nvvrs-pseq-rtc nvvrs-pseq-rtc: registered as rtc0

I have attached the device trees and I personally can see minor difference between jetpack 5 and 6 but I’m not sure what to change. How can this be fixed? It’s quite time critical for us because this is the last step for us to move to production. We can’t do a downgrade for production to jetpack 5 due to some dependencies regarding jetpack 6.

device_tree_jetpack_5_dts.txt (428.5 KB)
device_tree_jetpack_6_dts.txt (324.5 KB)
dmesg_jetpack_5.txt (62.9 KB)
dmesg_jetpack_6.txt (53.6 KB)

[ShaneCCC]

Does default device tree without any modification get the same result?

Thanks

[naxty]

Yes, it’s the same default device tree that it is coming with the Jetpack versions. We haven’t modified the device tree.

I’m not sure if it’s related but we also have trouble to dynamically set GPIOs in Jetpack 6. In Jetpack 5 everything is working fine but with Jetpack 6 this is also an issue. We haven’t modified pinmux yet. Can this issue be related to pinmux? If so that is really strange because our board is very similar to the dev board itself.

[shgarg]

This issue was there in JP6.0 DP (R36.2) but it is fixed in JP6.0 R36.3
Can you confirm that you are using R36.3 only ?
and you have following changes in driver:

drivers/rtc/nvvrs-pseq-rtc.c:
static irqreturn_t nvvrs_rtc_irq_handler(int irq, void *data)
{
int ret;
struct nvvrs_rtc_info *info = data;

dev_dbg(info->dev, "RTC alarm IRQ: %d\n", irq);

ret = nvvrs_rtc_disable_alarm(info);
if (ret < 0)
	dev_err(info->dev, "Failed to disable alarm: ret %d\n", ret);

rtc_update_irq(info->rtc_dev, 1, RTC_IRQF | RTC_AF); // Check if this is present

return IRQ_HANDLED;

}

[naxty]

I can confirm that I’m using R36.3 - I will check the driver