How to use PMIC RTC intead of i.MX51 RTC

[#1]

In i.MX51 platfrom the PMIC 13892 also has a internal RTC.

We can use this RTC instead of the i.mx51 SRTC.

Attached was the implementation of it.

[mbp]

Qinrong,

Is Android running on the i.Mx51 also subjected to occasional reset of the RTC on power down?    Does the Android R10.4 use the Mx51 RTC and not the PMIC RTC?   If not, are there any work-arounds to the Android Release to resolve/prevent random RTC resets (back to 1/1/1970)?

Thanks,

mike

[justin_jiang]

Hi Mike,

This patch only for WINCE6. In Android we use the MX51 internal RTC.

About the RTC reset issue, it may caused by the power sequence.

As we have a errata about it for iMX53. You can check it from freescale website.

B.R

Justin

[mbp]

Can you point me to your referenced errata?  ...to ensure I've seen your specific suggestion.

thanks

mike

[justin_jiang]

ENGcm10267 SRTC: Possible status loss when peripheral power resumes if SRTC in fail state.

Description:

There is the possiblility of a loss of SRTC failure status upon peripheral supply voltage (the HP

section) power up.

The SRTC incorporates a System State Retention Register (SSRR) that stores system parameters

during system shutdown modes. This register and all SRTC counters are powered by dedicated

supply rail NVCC_SRTC_POW that remains active, allowing all other supply rails to shut down.

The SSRR also stores the system security state. If a security violation occurs, the SSRR marks the

event as a security violation indication.

The SRTC is split to two supplies: LP and HP. The LP section is powered by NVCC_SRTC_POW

and always remains active, whereas the HP section is powered by VCC rail and can be shut down.

As long as the SRTC LP section remains active with its separate power supply and clock inputs, it

continues to detect and record security violations when the HP section and the rest of the chip are

powered down. When power is restored to the HP section, any security violation detected during

power down becomes visible to the rest of the system through a security monitor alarm and the

SRTC register interface. In particular, software can examine the LP status register to observe the

LP Failure state and status bits indicating which security violation occurred.

In rare cases, an erroneous reset of the LP section has been observed during HP power-up when a

security violation was recorded during HP section power down. This causes the LP to move to

Initialize state rather than Failure state, and erases all record of the security violation.

Please note that this scenario can occur only if SRTC LP has gone into failure state when the

peripheral supply power (HP) is off. The unintended SRTC reset does not occur while the SRTC

LP remains in the Valid state.

Projected Impact:

This issue is relevant for systems supporting DRM (digital rights management) and other

applications requiring a secure clock or monotonic counter. If the SRTC failure status is lost as

above, then a system which has been tampered while the main power was off may appear

indistinguishable from a system which has a SRTC that is not violated. If software is then permitted

to provision the LP time and monotonic counters insecurely, this could mislead the application

relying on the SRTC.

Note that this issue does not permit the SRTC LP clock and monotonic counters to be modified

directly without leaving the Valid state. In order to complete the attack, there is a need to execute

malicious or insecure software that tries to reconfigure the SRTC after it is reset. The system can

be protected against such software by code signing and authentication methods.

Work Arounds:

None. However, this issue can be mitigated by ensuring that the LP time and monotonic counters

are securely reprovisioned. One approach is to authenticate all provisioning software using HAB

(high-assurance boot) and to lock the LP time and monotonic counters against further changes

before allowing unauthenticated software to execute.

[mbp]

Thanks - will look at these items.

You commented earlier in this thread that,"....In Android we use the MX51 internal RTC." but I see in the android_def config;

#

# on-CPU RTC drivers

#

# CONFIG_RTC_MXC is not set

# CONFIG_RTC_DRV_MXC_V2 is not set

# CONFIG_RTC_DRV_IMXDI is not set

CONFIG_RTC_MC13892=y

CONFIG_DMADEVICES=y

...am I missing something?

[justin_jiang]

You are right, in Android it also switch to PMIC RTC from the config file.