IMX6 RTC

I’m being a tad lazy here, not trawling through the source code, so appologies for that.

I’m using an EDM1-FAIRY carrier board with a WandboardQuad SOM. The FAIRY has a battery backed rtc and with suitably arranged jumpers it works fine, providing the OS clock is set to manual configuration.

If I set the OS to update the clock via NTP this also works, but, if on boot the board is not connected to the network, the clock is incorrectly set. Connecting to the network solves the problem as does configuring the clock back to manual.

Just wondering where, in the source code, is the logic that sets the clock?

At some point(s) during ROM initialisation, OS_ResyncTime will be called, which will then call the RTC module, which will then call the RTC driver in the HAL.

At some point(s) during ROM initialisation, OS_ResyncTime will be called, which will then call the RTC module, which will then call the RTC driver in the HAL.

Can’t help thinking that the initialisation and boot sequence isn’t really the time to start altering saved values in the RTC rather than waiting until the system has a known good time from NTP or a presumed good time from the RTC.

OS_ResyncTime doesn’t write to the hardware RTC.

So what is setting the time wrong for Mike?

If you have the time set to ‘from network’ but there is no network available on start up, then the initial clock setting of ‘last time RISC OS was tidily shut down’ will persist until the network appears.

If time is set to ‘manual’ then the same thing happens (apart from anything network related) except that very early on the time is set to whatever the hardware RTC produces whether sensible or not.

If you have the time set to ‘from network’ but there is no network available on start up, then the initial clock setting of ‘last time RISC OS was tidily shut down’ will persist until the network appears.

The “last time RISC OS was tidily shut down” is only a feature of the Pi version of RISC OS. On other platforms you should either get (a) the time as specified by the hardware RTC, or (b) January 1970. Or possibly © the correct time but the wrong year if the RTC doesn’t provide enough year information and you don’t have CMOS for the OS to get the missing year information from.

The only way that NTP should affect things is that if NTP is enabled then once the network time has been obtained it may override the time if the clock is significantly out of sync.

The “last time RISC OS was tidily shut down” is only a feature of the Pi version of RISC OS.

One day we’ll have to document this. I trust the User Manual is clear on this, must look. Edit: It isn’t, correction submitted.

Don’t believe everything I say!

I just checked and it looks like the last shutdown time will be taken from the timestamp of the CMOS file, if SDCMOS is able to locate it and there is no hardware RTC. So it requires:

1. A version of SDCMOS which is configured to store the CMOS in a file (I think R-Comp’s official IMX6 ROMs are configured to store the CMOS at a specific disc address, so that won’t qualify since there’s no timestamp for the raw data)
2. No hardware RTC fitted (or some other failure case which will cause SWI RTC_Features to return an error). An RTC with a flat battery will count as having an RTC fitted, so won’t trigger the last-shutdown-time logic.
3. No CMOS HAL device is present (i.e. no hardware CMOS is fitted), otherwise SDCMOS will go dormant
4. The SD card that the CMOS is located on must be accessible during ROM initialisation (or whenever SDCMOS initialises, if you’re softloading it for some reason)
5. Current year as reported by kernel is 1970 (i.e. nothing else has attempted to set a correct time)

And of course the last shutdown needs to have been a clean one for SDCMOS to have written the updated CMOS file to the card.

Is there an off-the-shelf RTC module for the Wandboard that works under RISC OS?

I’m having the same issues as Mike with a standard Wandboard Quad, because sometimes the NTP server just says “busy” and doesn’t set the time. I have a little app to check the year is set to 2018 so it alerts me if it’s still set to 1970, but an electronic solution would be better.

You could, you know, get in touch with us (since we develop the i.MX6 port and associated hardware). The boards we sell have CMOS and battery-based RTC.

Just because we’ve honoured our responsibilities to feed code back doesn’t mean we’ve stopped developing the i.MX6 port, nor lost interest in enhancing it.

You could, you know, get in touch with us (since we develop the i.MX6 port and associated hardware). The boards we sell have CMOS and battery-based RTC.

And I can only apologise for not having thought of that – momentary aberration!

I’ll at least give you the weekend off, and contact you directly on Tuesday.