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

Hello everyone, we have discovered a problem with our Jetson device. When using jectPack6, sometimes the RTC time cannot be read; but it may return to normal after restarting:

sudo hwclock
hwclock: select() to /dev/rtc0 to wait for clock tick timed out

The overall problem is the same as in this post: RTC0 doesn't work on Jetpack 6 with battery but it works on Jetpack 5

I checked the code mentioned in the post and found it to be identical.

Research indicates that hwclock needs to wait for the UIE interrupt before calling the RTC_RD_TIME system call to read the RTC time. I then wrote a program that directly calls RTC_RD_TIME and can indeed read the RTC time. So, can we confirm that the cause of this problem is that the UIE interrupt isn’t being triggered?

If it’s a UIE interrupt issue, then why can I sometimes read the time after a reboot? I’m very confused. Is there any solution?

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll try to address the question and provide a comprehensive answer.

The issue you’re facing with the Jetson Orin NX device is related to the Real-Time Clock (RTC) time not being readable sometimes when using JetPack 6. This problem seems to be similar to the one mentioned in the post “RTC0 doesn’t work on Jetpack 6 with battery but it works on Jetpack 5”.

After researching and checking the code, you found that the issue might be related to the UIE (User Interrupt Enable) interrupt not being triggered, which is required for the hwclock command to work correctly. You also wrote a program that directly calls the RTCRDTIME system call and were able to read the RTC time, which suggests that the issue is indeed related to the UIE interrupt.

Now, let’s try to understand why the UIE interrupt might not be triggered sometimes. The UIE interrupt is used to notify the system that the RTC has been updated, and it’s required for the hwclock command to work correctly.

One possible reason for the UIE interrupt not being triggered is that the RTC is not properly configured or initialized. This could be due to a variety of reasons, such as a problem with the device tree configuration, a issue with the RTC driver, or a conflict with another device or driver.

Another possible reason is that the UIE interrupt is not properly enabled or configured in the system. This could be due to a problem with the interrupt controller or the UIE interrupt handler.

Regarding the fact that you can sometimes read the time after a reboot, it’s possible that the system is able to recover from the issue after a reboot, perhaps due to a change in the system’s state or a reinitialization of the RTC.

To confirm the cause of the problem, you can try to:

  1. Check the device tree configuration and ensure that the RTC is properly configured and enabled.
  2. Verify that the RTC driver is properly loaded and initialized.
  3. Check the system logs for any error messages related to the RTC or UIE interrupt.
  4. Try to reproduce the issue and see if it’s related to a specific scenario or condition.

As for a solution, you can try to:

  1. Update the device tree configuration to ensure that the RTC is properly configured and enabled.
  2. Modify the RTC driver to properly handle the UIE interrupt and ensure that it’s triggered correctly.
  3. Implement a workaround to manually trigger the UIE interrupt or update the RTC time.

It’s also worth noting that the Jetson Orin NX device has a different power sequencing mechanism compared to other Jetson devices, which might affect the RTC behavior. You can refer to the Jetson Orin NX Series Product Design Guide for more information on power sequencing and monitoring.

In comparison to other Jetson devices, the Jetson Orin NX has a more complex power sequencing mechanism, which might require additional configuration or handling to ensure that the RTC works correctly.

In summary, the issue you’re facing with the Jetson Orin NX device is likely related to the UIE interrupt not being triggered, which is required for the hwclock command to work correctly. To confirm the cause of the problem, you can try to check the device tree configuration, verify the RTC driver, and check the system logs for error messages. To solve the issue, you can try to update the device tree configuration, modify the RTC driver, or implement a workaround to manually trigger the UIE interrupt or update the RTC time.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

This answer was not helpful

I wrote the following patch for the poll function in dev.c, and it works now. However, I don’t know why it sometimes fails to wait for the interrupt. The code is as follows for your reference. If anyone can analyze the reason why it fails to wait for the interrupt, please leave a message:

static __poll_t rtc_dev_poll(struct file *file, poll_table *wait)
{
	struct rtc_device *rtc = file->private_data;
	unsigned long data;

	poll_wait(file, &rtc->irq_queue, wait);
	data = rtc->irq_data;
	if(data == 0){
		printk("rtc/dev.c: data == 0\n");
	}
	// return (data != 0) ? (EPOLLIN | EPOLLRDNORM) : 0;
	return (EPOLLIN | EPOLLRDNORM);
}

Apply the attached patch to verify.

0001-mfd-clear-interrupt-status-in-probe.patch (844 Bytes)

It seems to be effective

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.