(OSD3358) RTC

Embedded Linux Discussions
1

Hi,
Custom board using Ocavo Systems OSD3358-BAS, barebox 2021.03, linux 5.11.10 and custom devicetree. I am having trouble with the RTC (hwclock).
snippet from dmesg

/root # dmesg | grep "rtc"
[    1.595450] omap_rtc 44e3e000.rtc: registered as rtc0
[    1.595560] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01T00:00:00 UTC (946684800)
/root #

command results

/root # hwclock --systohc --verbose --adjfile /etc/adjtime
hwclock from util-linux 2.36.2
System Time: 1626093302.555349
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1625848034 seconds after 1969
Last calibration done at 1625848034 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
RTC type: 'omap_rtc'
Using delay: 0.000000 seconds
missed it - 1626093302.559947 is too far past 1626093302.000000 (0.559947 > 0.001000)
1626093303.000001 is close enough to 1626093303.000000 (0.000001 < 0.002000)
Set RTC to 1626093304 (1626093302 + 2; refsystime = 1626093302.000000)
Setting Hardware Clock to 12:35:04 = 1626093304 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because the --update-drift option was not used.
New /etc/adjtime data:
0.000000 1626093302 0.000000
1626093302
UTC
/root # 
/root # hwclock --hctosys --verbose --adjfile /etc/adjtime
hwclock from util-linux 2.36.2
System Time: 1626093318.301291
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1626093302 seconds after 1969
Last calibration done at 1626093302 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed
/root #

Setting the RTC (–systohc) reports successful but reading (–hctosys) fails because the ‘clock tick timed out’.
My best guess is that ‘clock tick timed out’ means the RTC is enable (I can communicate with it) but it is not ‘ticking’.
My board does have a 32.768 xtal connected to OSC1_IN, OSC1_OUT of the RTC.
My board does not have an external battery. I will be setting the date/time remotely.
The TI OMAP Real Time Clock is enabled in the kernel.
Here is snippet from my DT

&rtc {
	clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
	clock-names = "ext-clk", "int-clk";
	//system-power-controller;
};

What is the meaning of ‘clock tick timed out’ and how do I fix?

Thank you,

2

Just use an external “battery” backed up RTC… Without a Battery the internal RTC is pretty useless, it’s main purpose is for shutdown/etc…

RTC clock must be pre-set in “u-boot”…

/* 3: SEL_32KCLK_SRC 0: internal, 1: external */

On the PocketBeagle/BeagleBoneBlue there is no 32Khz so we set it zero… (Blue’s is broken…)

Regards,

3

RCN,
You mention that to add a battery. My board is powered through VIN_AC or VIN_USB but never VIN_BAT.
I confirmed with an o-scope that the 32Khz oscillator is running when my board is powered up.

Q. Does the RTC ‘tick’ only when there is a battery connected?

I am using barebox for my boot loader. I like that barebox can use my custom device tree. I know that later versions of u-boot can use a DT but, I moved away from u-boot because of the EEPROM ID requirement and the need to modify the ‘board’ files. Barebox doesn’t need an EEPROM.

I would think that there are DT settings that do what the rtc32k_enable() function is doing.

Q. Do you have a DT example that unlocks the RTC, sets bit-3 and bit-6 in the RTC_OSC_REG?

Thank you,

4

I only keeps track of Time with a battery connected. I’ve never personally seen an am335x based board with a fully working internal RTC. Lots of users using i2c/spi based RTC’s external to the BeagleBone…

That RTC Clock register is special and get’s locked up early in u-boot, so the main Linux kernel is not allowed to change it…

Regards,

5

RCN,
Thank you for you information about not seeing a fully working internal RTC and about an eternal RTC. That does make sense to me.

Q. Do you mean that during u-boot board init, u-boot unlocks the RTC clock register, sets bit-3 and bit-6 then locks the register so that the kernel cannot change it?

Q. Is that done during MLO or Proper?

Thank you again,

6

Correct… Last i looked, the linux driver for the RTC, would not try to touch/unlock it…

Proper…

Edit: i wonder if it works now:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-omap.c#n786

Regards,

7

RCN,

I have been studying the rtc-omap.c file and the DT bindings for rtc-omap.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/rtc/rtc-omap.txt

of_id = of_match_device(omap_rtc_of_match, &pdev->dev);

I am guessing that line 738 want to match something in the device tree.
Q. What in the DT is the line trying to match?

The DT binding mentions ‘system-power-controller’. I don’t have ‘system-power-controller’ in my DT because I don’t know what it does. I was concerned that adding it to my DT would cause problems during boot.

Q. What does ‘system-power-controller’ do?

Thank you,

8

To all,
I have found my problem why the RTC time was not incrementing. I had installed an ‘optional R-bias’ 1Meg ohm resistor across the crystal in the OSC1 circuit of the OSD3358-BAS. The resistor was causing the 32.768Khz oscillator to fail to start/run.

Refer to this link for details.

Look at Figure 3 in the linked document and note that R25 is labeled DNI (Do Not Install).

Before removing the resistor the oscillator was not running correctly causing the RTC to not increment. The ‘hwclock --show’ command would fail with error ‘timeout while waiting for clock tick’.
After removing the resistor, the oscillator runs correctly. The ‘hwclock --show’ command returns date/time stored in the RTC.

I hope someone finds this information useful.
Thank you,