RTC malfunction on A20-OlinuXino-Micro

[Youri]

Hi,
In the processor A20 datasheet is written, that for the RTC at pin K8 (RTC VDD) should be not less than 3V. In the current version of the A20-OlinuXino-Micro pin LDO1SET of AXP209 is grounded, so this voltage is only 1.3 V.
I removed the resistor R120 and joined pins 26 (VINT) and 27 (LDO1SET) of AXP209. Now the voltage is 3,3V, but in spite of this RTC still do not work.
I checked with an oscilloscope (with low-capacitance divider 1:10) signals on the RTC (Q2, 32768 Hz) crystal and saw no generation.

Anyone checked the CPU RTC on the A20-OlinuXino-Micro board?

[dave-at-axon]

I have two A20 boards here for development and I was originally using the RTC of the A20 but it was useless as there was no battery backup when power was removed. It was OK when in sleep mode but full power off reset it to zero.

I ended up using an external DS1338 and now I have a battery backed RTC.

BUT it was working with the built in before I did this. It just wouldn't hold the time across power on/off.

[Youri]

At the time until power is supplied to the core as a real-time clock used another timer.
If I understand Linux correctly, data from RTC retrieved and stored back only when starting and stopping the operating system. Therefore, the fact that the clock work properly while the Linux runs not confirm the real time clock operation. About the same talk and messages during a system shutdown:

[  404.135053] sunxi-rtc sunxi-rtc: actually set time to 2014-2-3 10:16:26
<3>sunxi-rtc sunxi-rtc: Warning: RTC time is wrong!

...and during the system starting:

[    2.352643] sunxi-rtc sunxi-rtc: Warning: RTC time will be wrong!
<6>sunxi-rtc sunxi-rtc: rtc core: registered rtc as rtc0

I'm interested in is the CPU RTC, so if anyone checked them, or if anyone knows how to troubleshoot, please answer.

[dave-at-axon]

In that case the built in RTC to the CPU will be a waste of time as it is not battery backed so time will be lost if you remove power. 

If you need RTC on power up, I would suggest an external one. Some have managed to get the Olimex UEXT RTC to work but it requires the driver to be built in to the kernel so that it get read on power up.

[Youri]

The fact of the matter is that even in the case when the RTC is powered by a LiPo battery, after restarting the operating system time is not saved. I formed the opinion that the RTC is not physically works even when the main power present or, alternatively, that the kernel driver does not start the RTC.
I do not want to install additional device, and it was not about a few extra dollars price. I design the device on the A20, and I need to know whether it is possible in principle to use the built-in RTC.
If the processor has an RTC, it should be possible to use them, especially since the AXP209 allows to backup it.
Unfortunately, I have a single A20-OlinuXino board, so I have nothing to compare.

[ych]

Post on this topic to left notice to someone how also stick with RTC on A20.

First of all I need to mention that I use A20-SOM-EVB. In A20-SOM rev D Olimex add new additional extension GPIO-6 connector (thank you Olimex ), which give possibility to connect external 3,3V battery to AXP_BACKUP pin, so APX keep 1,3V on VDD_RTC without external power.

But event after external battery connect, on boot I got next kernel log:

Jan  1 00:00:09 a kernel: [    2.278811] sunxi-rtc sunxi-rtc: Warning: RTC time is wrong!
Jan  1 00:00:09 a kernel: [    2.289769] sunxi-rtc sunxi-rtc: rtc core: registered rtc as rtc0

and after checking files in /sys/class/rtc/rtc0/ seems that drive doesn't work.

I can overcome this strange behavior only after look in rtc-sun4i.c. If on first read time operation driver get incorrect/default value from RTC it print previous mention warning and hold itself. To untold it we need just do write time operation!
So after execute next commands RTC start work as expected:

root@a:# hwclock -w
hwclock: select() to /dev/rtc0 to wait for clock tick timed out: No such file or directory
root@a:# hwclock -w


P.S.
I think that hwclock fail first time because of it internal implementation, when it expect that RTC value always changes (but in case of hold it doesn't).