passive log storage - 2nd このページをアンテナに追加 RSSフィード Twitter

2018/04/16

[][]DM200 Ver1.4のRTC日時ズレの件、まとめ。

前回記事のVer1.4 RTC周りの挙動の件、本家 にて対応版がリリースされたので(自分のメモ用として自分でなんとか理解できた範囲で)まとめ。

Linux on Pomera DM200 人柱版 その2

どうしてこうなった

前回記事のコメント欄より

匿名希望匿名希望 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暦に対応

んでもって、

この問題に対してLinuxkernelレベルで対応していた訳ですね。

こんなことがあるんだなぁ・・・。


「なんで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時間づつズレが増えていく。

で、

ということになる。

このへんを(本来*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(ドライバ)を経由せずに直接叩いてるっぽいですね、と。


「なんでそんな(ドライバを経由しない)作りになってるの?」

さぁ・・・?

ただ、組込系だと『なるべくデバイスをローレベルで直接使う』みたいなことは聞いたことがあるので、つまりそういうことなんじゃないかなぁ、と。

それが、

  1. 技術的にそうすべきだからそうなっているのか、
  2. 開発に使ってるミドルウェアとか環境がそうだからそうなっているのか、
  3. 文化的(慣例的)にそうだからPOMERAでもそうしているのか、

とか、そこらへんはDM200開発者のみぞ知る*2


まとめ、のまとめ。

こういうことが有るんだなぁ、そして勉強になるなぁ、と。

大元をたどるとRockchip暦の問題は2015年12月に修正が出ているのだけど、まぁこうやってどこかで引っかからない限りまったく気がついてない訳で。

ただ、自分がやっていたように外側からブラックボックス的(日付を変えて読み出してまた日付を変えて〜みたい)に調べていても、そもそもkernelレベルでは実は対応してたんだとかまではたどり着けなくて、「やっぱりkernelソースを読むところにいかないと限界あるよなぁ」というのが正直な感想。


謝辞:

コメントつけていただいた「匿名希望」さん、そして修正版をリリースしていただいた本家の @ichinomotoさんありがとうございました。

*1:「本来は」ってのも微妙な表現で、最終的な結果としてはアプリ側で吸収して正しい動きになっているのだから、『Linux使ってたら自然な形としては』って表現がいいのか

*2:個人的には「2」がわりとありそうなパターンかなぁ、とは思ったり思わなかったり

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/obally/20180416/1523884294