Hi,
I´m using i.MX6 in a custom board and having problems with the RTC.
The SNVS_LPSRTCLR does not increase, freezing the operating system in the function "rtc_write_sync_lp".
static inline void rtc_write_sync_lp(void __iomem *ioaddr)
{
unsigned int i, count1, count2, count3;
/* Wait for 3 CKIL cycles */
for (i = 0; i < 3; i++) {
/* TKT052983: Do consective reads of LSB of counter
* to ensure integrity
*/
do {
count1 = __raw_readl(ioaddr + SNVS_LPSRTCLR);
count2 = __raw_readl(ioaddr + SNVS_LPSRTCLR);
} while (count1 != count2);
/* Now wait until counter value changes */
do {
do {
count2 = __raw_readl(ioaddr + SNVS_LPSRTCLR);
count3 = __raw_readl(ioaddr + SNVS_LPSRTCLR);
} while (count2 != count3);
} while (count3 == count1);
}
}
The registers associated with SNVS (0x58 is LPTAR, 0x38 is LPCR, LPLR is 0x34):
0x00: 0x00000000
0x04: 0x80002100
0x08: 0x00000000
0x0C: 0x00000000
0x10: 0x00000000
0x14: 0x80000B00
0x18: 0x00000000
0x1C: 0x00000000
0x20: 0x00000000
0x24: 0x00000000
0x28: 0x00000000
0x2C: 0x00000000
0x30: 0x00000000
0x34: 0x000003FD
0x38: 0x00000020
0x3C: 0x00000000
0x40: 0x00000000
0x44: 0x00000000
0x48: 0x00000000
0x4C: 0x40000000
0x50: 0x00002A16
0x54: 0x112643A5
0x58: 0x542C224D
0x5C: 0x00000000
0x60: 0x00000000
0x64: 0x41736166
0x68: 0x00000000
0x6C: 0x00000000
0x70: 0x00000000
0x74: 0x00000000
0x78: 0x00000000
0x7C: 0x00000000
0x80: 0x00000000
0x84: 0x00000000
The /proc/driver/rtc:
cat /proc/driver/rtc
rtc_time : 15:48:28
rtc_date : 2014-10-01
alrm_time : 15:48:29
alrm_date : 2014-10-01
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
alarm_IRQ : no
If the battery is removed and replaced the problem is solved ( i had 2 wih this problem, now have only one ).
I do not know what happened to these two boards and not know how to prevent it happening in the next, imagine what would be the tampers, but I understand that they are disabled. Any suggestions?
karinavalencia You can prioritize this thread?
Dear, just to give an update on this request, I am working with the customer to understand this issue.
We now understand the SRTC lock issue is caused by the register SNVS_LPLR being locked, we are now working on different fronts to try capturing when this register is set, and if an internal source could be locking it.
BR,
Bruno