Модуль часов реального времени DS3231 для Raspberry Pi

Вот статейка на тему: http://bohdan-danishevsky.blogspot.ru/2014/12/installing-hardware-rtc-ds3132-...

Ты так же делал? Возможно, что бага в драйвере. Дело в том, что I2C не поддерживает одновременно чтение и запись. Может быть только что-то одно. Вероятно, что ntpd постоянно пытается туда писать, а ты пытаешься в это время прочитать. По-хорошему, каждое обращение должно завершаться. В статье, кстати, используется опция -q для ntpd.

Спасибо.

Нет, я делал через device tree overlay, но так, как в статье, тоже пробовал (пуская потом руками ntpd), с тем же результатом (то есть, сразу после запуска ntpd утилита hwclock ругается на некорректную информацию в rtc). Я даже пробовал вообще не трогать hwclock, тогда при ребуте просто выставляется неправильное время. Да, модуль RTC у меня чисто внешне не такой как в статье, а вот такой: http://ru.aliexpress.com/item/DIY-DS3231-Precision-RTC-Clock-Memory-Module-fo....

хм, я сейчас попробовал, запуск ntpd уже не привёл к порче времени в rtc, но при перезагрузке время стало неправильным.

Мне кажется, что разницы нет, какой модуль. Микросхемы-то одинаковые. А вообще странно. ntpd же, по идее, хардварное время не меняет.

А как ты определяешь, что портится время именно в RTC? Есть ли способ сдампить сырые данные с I2C?

Ты, конечно, можешь меня не слушать. Я в этом особо не соображаю.

А не может быть, что конфликтуют ntpd и systemd'шный демон?

А как ты определяешь, что портится время именно в RTC?

С помощью hwclock

А не может быть, что конфликтуют ntpd и systemd'шный демон?

Не, перед запуском ntpd, я отключал systemd-timesyncd.

А вообще странно. ntpd же, по идее, хардварное время не меняет.

А вот, кстати, systemd-timesyncd - меняет, что меня удивило. При чём, не только при отключении, но и периодически в процессе работы.

На то он и Поттеринг, чтобы всё менять :)

Смотри ещё какую инфу нашёл в man hwclock:

The Linux kernel has a mode wherein it copies the System Time to the Hardware Clock every 11 minutes. This mode is a compile time option...
It takes an outside influence, like the NTP daemon ntpd(1), to put the kernel's clock discipline into a synchronized state, and therefore turn on '11 minute mode'. It can be turned off by running anything that sets the System Clock the old fash‐ioned way, including hwclock --hctosys. However, if the NTP daemon is still running, it will turn '11 minute mode' back on again the next time it synchronizes the System Clock.

Я сделал правило в udev

ACTION=="add", KERNEL=="rtc0", RUN+="/usr/bin/hwclock -s"

Вот тут (kernel.org) написано про опцию ядра CONFIG_RTC_HCTOSYS. Она отвечает за то что ядро при загрузке будет устанавливать системные часы по хардварным. Проверить это можно по cat /sys/class/rtc/rtc0/hctosys. Если там 1, то системное время устанавливается по RTC во время загрузки.

Сдаётся мне, что твоё ядро скомпилировано без этой опции.

Ещё там написано:

The driver has built in locking so that only one process is allowed to have the /dev/rtc interface open at a time.

(Но почему-то только для /dev/rtc, /dev/rtcN, скорее всего, тоже блокируется.) Так что с конфликтом доступа к девайсу всё должно быть ok.

Возможно есть какое-то ограничение на максимальную разницу времени между RTC и системными часами, при установке через hwclock, при превышении которого он и ругается. А что он конкретно пишет?

А что он конкретно пишет?

У меня сейчас, к сожалению, не получается воспроизвести ту ошибку. Но зато могу показать другую :-) Она проявляется, когда нет правила в udev, которое я написал выше.

# systemctl enable ntpd
Created symlink from /etc/systemd/system/multi-user.target.wants/ntpd.service to /usr/lib/systemd/system/ntpd.service.
# systemctl start ntpd
# date
Вт мар 22 12:12:25 MSK 2016
# hwclock -w
# hwclock
Вт 22 мар 2016 12:12:46  .328111 seconds
# reboot

# date
Вт мар 22 12:13:38 MSK 2016
# hwclock
Пн 22 фев 2016 17:41:00  .578146 seconds

То, что ядро может само устанавливать время из RTC, это интересно, но есть проблема: поддержка rtc скомпилирована модулем ядра, а как заставить systemd грузить модуль на более раннем этапе (а не с помощью systemd-modules-load.service), я не знаю.

Можно пересобрать ядро, но не хотелось бы этим заниматься ещё и на Raspberry Pi. А так, у меня уже возникают мысли заморочиться с кросскомпиляцией и поставить туда Gentoo. В Raspbian старый софт (со старыми версиями есть проблемы), в Arch (который сейчас стоит) есть другие проблемы, но нет тех, которые вызваны старым софтом.

Оч странно. А если 'hwclock --get'?

То есть, получается, что какая-то зараза переписывает время в RTC после reboot? А dmesg или journalctl что говорят по поводу rtc и драйвера?

А если системдешного демона совсем отключить? Того, который timedated.

В статьях народ ставит запуск 'hwclock -s' в '/etc/rc.local'.

Оч странно. А если 'hwclock --get'?

То же самое.

# hwclock --get
Пн 22 фев 2016 17:41:19  .344474 seconds

То есть, получается, что какая-то зараза переписывает время в RTC после reboot?

Ага, похоже, это делает какой-то кусок systemd.

А dmesg или journalctl что говорят по поводу rtc и драйвера?

dmesg: http://pastebin.com/E0dP9xnV
journalctl -b: http://pastebin.com/B7XnXYL7

Такое время выставляется ещё до начала ведения лога.

В статьях народ ставит запуск 'hwclock -s' в '/etc/rc.local'.

Ну, я то же самое делаю в udev, rc.local - это слишком поздно.

А если системдешного демона совсем отключить? Того, который timedated.

Надо подумать. Хочу понять логику его работы.

Вот интересная запись в dmesg:

[    5.210324] systemd[1]: System time before build time, advancing clock.

Самая первая запись от systemd. Но, судя по исходникам, переводятся только системные часы.

Вообще, судя по тем же исходникам, RTC может поменять только timedated. Больше 'ioctl(fd, RTC_SET_TIME, tm)' в виде функции 'clock_set_hwclock()' ни откуда из systemd не вызывается.

А функция еже-11-минутной установки RTC ядром у тебя закомпилирована? Проверить можно так:

# zcat /proc/config.gz | grep CMOS
CONFIG_GENERIC_CMOS_UPDATE=y

Узнать используется ли эта функция в данный момент можно через

# ntptime | grep status
  status 0x40 (UNSYNC),

То есть, из подозреваемых остаётся только timedated :)

А функция еже-11-минутной установки RTC ядром у тебя закомпилирована?

Не

# zcat /proc/config.gz | grep CMOS
# CONFIG_RTC_DRV_CMOS is not set