前回記事のVer1.4 RTC周りの挙動の件、本家 にて対応版がリリースされたので(自分のメモ用として自分でなんとか理解できた範囲で)まとめ。
どうしてこうなった
匿名希望匿名希望 2018/04/13 01:42
この問題はRockchipのRTC不具合対応によるものです。
RockchipのRTCは、11月30日の翌日は11月31日となってしまうという重大な不具合があります。
つまり、RockchipのRTCは1年が1日長いため、毎年1日づつ実際の日付とずれていってしまいます。
今年の12月1日が過ぎると、ずれは2日となるかと思われます。
その対策のため、2017年1月1日を基準として、Rockchip歴とグレゴリオ暦の変換を行っています。
例えば、アプリで2017年12月1日を設定する場合は、RTCには2017年11月31日と設定しています。
Linux上でもRTCドライバを修正してカーネルをリビルドすれば、たぶん解決できるかと思います。
さらに詳しく
本の虫: Linuxカーネル、Rockchip暦に対応
んでもって、
ちょうどkernelにあるrtcドライバのソースを見てるところでした。どうもこのRTCは11月が31日ある計算みたいです。まだ詳しくは見てませんけどそれっぽい修正処理はkernelのソースに入ってますけどねえ。
— ichinomoto (@ichinomoto) 2018年4月13日
この問題に対してLinuxはkernelレベルで対応していた訳ですね。
こんなことがあるんだなぁ・・・。
「なんで24時間なのか」の答え
Rockchip暦（この表現をそのまま使おう）だと2017/11/31が存在するから、そのままRTCを参照して日数計算とかするとおかしくなる。
2017/12/01以降はその多い分(24時間)を引いてやる必要がある。だから、2017/12/01以降にPOMERAで日付を合わせる→LinuxでRTCを確認するとかならず24時間前の日時になっていた。
はじめは24時間だと思っていたけど、実際はかならず24時間ではなくて、Rockchip暦は1年＝366日存在することになるので、2018/12/01以降は2日分(48時間)、2019/12/01以降は3日分(72時間)差が出てしまう。つまり「24時間」固定じゃなく、11/30を超える毎に24時間づつズレが増えていく。
で、
pomeraで時刻変更→linuxでrtc確認と、ブラックボックス的に見てみましたが、
— obally (@obally) 2018年4月13日
2018/12/01→2018/11/30
2019/12/01→2019/11/29
2020/12/01→2020/11/28
となるので、やはりドライバのパッチでやってることをpomera（アプリ）がやっちゃってる感じですね。
ということになる。
このへんを（本来*1は？）Linuxのドライバレベルで対応した物を使わず、アプリ側でやってた、と。
自分が付けたコメントレスより。
oballyobally 2018/04/13 20:10
重要な情報ありがとうございます。
https://cpplover.blogspot.jp/2015/12/linuxrockchip.html
↑ここらへんの話の事でしょうかね。
まさかハードウェアの問題とは・・・まだ深く追っていませんが、おそらくズレの修正は標準ファームウェア(記事中でいうところの「POEMRAアプリ（仮称）」)でやっているはずです。
Linux on Pomeraで置き換わっているkernelの上に「POEMRAアプリ（仮称）」が走っているはずですので、
ドライバを更新→カーネルリビルドした場合、「POMERAアプリ（仮称）」側に影響が出ないかが心配なところです。
Linux on Pomeraと「POMERAアプリ（仮称）」はkernelを共有しているのでkernelに手が入ることによって逆に「POMERAアプリ(仮称)」に（ドライバレベルとアプリレベルで二重に処理することによって）影響が出ないか、と思ったのだけど・・・。
すでにkernelドライバ(drivers/rtc/rtc-rk818.c)にて対応していた(コミットログ)のに、POMERAアプリ側で対処が必要だった。
ということはそもそもPOMERA側はRTCをkernel(ドライバ)を経由せずに直接叩いてるっぽいですね、と。
「なんでそんな(ドライバを経由しない)作りになってるの？」
さぁ・・・？
ただ、組込系だと『なるべくデバイスをローレベルで直接使う』みたいなことは聞いたことがあるので、つまりそういうことなんじゃないかなぁ、と。
それが、
とか、そこらへんはDM200開発者のみぞ知る*2。
まとめ、のまとめ。
こういうことが有るんだなぁ、そして勉強になるなぁ、と。
大元をたどるとRockchip暦の問題は2015年12月に修正が出ているのだけど、まぁこうやってどこかで引っかからない限りまったく気がついてない訳で。
ただ、自分がやっていたように外側からブラックボックス的(日付を変えて読み出してまた日付を変えて〜みたい)に調べていても、そもそもkernelレベルでは実は対応してたんだとかまではたどり着けなくて、「やっぱりkernelソースを読むところにいかないと限界あるよなぁ」というのが正直な感想。
謝辞：
コメントつけていただいた「匿名希望」さん、そして修正版をリリースしていただいた本家の @ichinomotoさんありがとうございました。
