[Letux-kernel] Re: Where does RTC actually work

H. Nikolaus Schaller hns at goldelico.com
Wed Feb 1 17:59:12 CET 2017

> Am 01.02.2017 um 07:36 schrieb Andreas Kemnade <andreas at kemnade.info>:
> Hi,
> I tried further with that 4.7.0 kernel and the letux3704:
> setting the clock in linux and then power down the system by pressing
> the power key for 10 seconds also gives the wrong hour at least in the
> new uboot.
> But only after first update (=writing 1 to GET_TIME in
> In an old uboot I did read out the time correctly on the same device and
> had also correct
> Booting into a shell with init=/bin/bash indicates only the same wrong
> hour which I already have seen in uboot.
> Fully booting into the kernel with such a wrong hour results in
> having the year 2066 in the hw clock.
> So probably this might be a combination of several things:
> - MSECURE might not be handled correctly at every time.

I have checked and pinmux is initialized by u-boot to be a gpio with pullup "1".
And echo 22 >export and reading gpio22/value also returns "1".

So unless either this pinmux setting is not executed by u-boot although it
is in the code or some other component overwrites (maybe not even intends to)
the pinmux it should remain "1" all the time. So the clock should always be

> - something mixes up i2c registers and
>   - messes with the clock and/or
>   - some oscillators

Well, it might be something with the supercap, but I had measured the
voltage and it goes up to 3.2V during operation and it takes ca. 45 seconds
after powering down and removing the battery to make it go down to 3.0V.

So I assume it buffers the RTC for at least 1-2 minutes.

> - something does not like the extra hours and sets tho clock to
>  2066.

Maybe a year 2000 fix which triggers at 1st jan 2017 :)

> So that might help to analyze the code.
> Well the fix is not to fix the hours but to add that extra hours to
> the time available for open source development. ;-)

(2066 - 2017) * 365.2425 * 24 = 429k hours.

That should suffice to solve every problem we know about :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170201/c64402d8/attachment.asc>

More information about the Letux-kernel mailing list