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

2018/04/20

[]ここ、移転します

といっても・・・

ここ「はてなダイアリー」から「はてなブログ」への移行だけど。

行き先はこちら:http://obally.hatenablog.com

理由などについては移行先にて。

この記事をもってこっちは一旦更新停止します。

過去記事は移転先にエクスポートしてあるので、問題が無ければこちらは最終的には廃止の方向で。

よろしくお願いします。

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」がわりとありそうなパターンかなぁ、とは思ったり思わなかったり

2018/04/12

[][]DM200 ver1.4でRTC関連が変更?

取り急ぎ。

2017/04/16追記:本家にて対応版kernelがリリースされています。

そこらへんをうちでまとめた記事がこちら

今回の状況について

  • DM200で「Linux on Pomera DM200 (人柱版その2)」をメインに使っており、通常のPomeraとして使っていない人は影響を受けない。
  • DM200のファームウェアがVer.1.3までの人(Ver1.4にアップデートしていない人)は影響を受けない。
  • もちろんLinux on Pomera DM200を使わずに通常のPomeraとして使っているだけの人も無関係。
  • PomeraLinux on Pomera を行き来するたびに毎回時刻合わせをする」という運用が苦にならない人も問題ないだろう。

影響をうけるのは、自分のように通常のPomeraを使いつつ時々Linux on Pomeraを起動する人。


念のため再度注意

あくまでDM200 ファームウェアVer1.4で普通にPOMERAとして使う分にはなんの問題も発生しない。

間違っても本件についてキングジムに問い合わせたりすることの無いようくれぐれもよろしくお願いします。

また、今回の現象について Linux on Pomera 提供者の @ichinomoto さんにはなんの責任も無いことを改めて記します。

今更書く必要はないと思うが、「Linux on Pomera」 は我々の自己責任っていうのはみんな判ってるよね?

俺たちは自己責任で遊んでるってこと、みんな判ってるもんね?


状況

DM200 Ver.1.4から、内部的な時刻の取り扱いが大幅に変わっている?ように見えた。

@obally

  1. Pomera側で時刻設定 例「2018/4/6(金) 14:00」
  2. Linux on Pomeraで起動。(起動時にはWiFi自動接続しない→NTP時刻合わせせず
  3. sudo timedatectlでHWクロック(RTC)の時刻確認
  4. 結果→RTCの時刻が「2018/04/5(木) 14:03」

JSTでも+−9時間でもなく、-24時間。

なぜ今更気がついたかというと、tmuxを導入してstats-lineに時刻を表示するカスタムを加えていて「あれ?」と。

この件について(たまたまこのタイミングでうちの記事をtweetしてくださった) @ytakeda さんに追試していただいた(なんか巻き込んでしまってすみません)

@obally →

@ytakeda ←

@obally →

@ytakeda ←

ということで、確定。

Pomeraだけ使う人やLinuxだけを使う人には問題ないんだろうけど、Pomera側とLinux側を行き来する自分にはやっかいな状態になってしまった。

対処法を考えてみたが・・・

  1. なんとか頑張ってみるよ派
    1. [素人の思いつき案]:TimeZone関連をゴニョゴニョして無理矢理「+24時間」で動作させる。
      • TimeZone定義として「UTC+24:00」という『オレオレTimezone』をでっち上げるという力業。
      • TimeZone関連をちょっと調べてみたけど、前提として範囲が「UTC-12時間〜UTC+12時間」であって「24時間」ってのはTimeZoneの想定範囲外になるはず。
      • 「オレオレTimeZone」定義が作れて、これを適用できたとしても、他の時刻関連ライブラリに与える影響が未知数。
      • WebAPIを呼ぶスクリプトなども微妙に怖い。
    2. [もっと知識が深ければできそう案]
      • Linux on Pomera側で、時刻周りの管理(timedatectlとか)よりもっと下層レベルで「RTC+24時間の下駄履かせる」処理を噛ませる。
      • すんません俺にはどこから覗けばいいのかすらわかんねぇです。
  2. もう諦めるよ派
    1. [アップデートなんていらんかったんや案]
    2. [Linux側寄り妥協案]:POMERA上では「RTC=時刻はつねに+24時間」として諦める。
      • POMERA上では一日速い」を許容する運用。
      • 今まで通りの設定でNTPでの時刻合わせが使えるのが利点。
      • DM200の標準機能「ポメラSync」が多分怪しくなる(タイムスタンプ基準で判定してるようなので)。
    3. [POMERA側寄り妥協案]:Linux上では「RTC=時刻はつねに-24時間」として諦める。
      • 逆に「Linux上では一日遅れ」を許容する運用。
      • NTP時刻合わせが使えない(RTCを書き換えてしまうから)。
      • タイムスタンプを判定に利用するようなWebAPIを呼ぶスクリプトも使えないだろうと思われる。

正直、現状でこれぐらいしか思いつかない。

とりあえず「2-3. [POMERA寄り妥協案]」で、意図せずRTCが変更されないようにntp同期外しておいた。

それにしても・・・

なぜに24時間なんだ?

  • JST(+9:00)なら「ああ、TimeZone=Asia/Tokyo準拠にしたんだ」となる。むしろありがたい。
  • (-9:00)なら「ああ、TimeZone=Asia/Tokyo準拠にしようとしてどっかミスったんだ」となる。
  • それ以外の+-12時間以内のズレなら「ああ、TimeZone準拠にしようとして間違えて全然別のTimeZone適用しちゃったんだ」となる。

ソースは俺(全部自分でやらかしたことがあるからw)。

意図的にずらしているにしては24時間ずらす意味が見いだせないので不具合かと思ったのだが、POMERAのシステム上ではつじつまが合っている(ファイルの書き込み時間なども問題なくPOMERAで設定した時刻で書き込まれている)ので、本来の使い方(DM200をPOMERAとして使う場合には)不具合とまでは言うことはできない。

引用:本家 no title :「聞かれそうな質問と回答」より。

Q. 内蔵のATOKは使えるのか

A. DM200標準のソフトは、よく使われるコマンド以外は画面描画処理も含めて基本的に1つのプロセスで動作しているようです。ATOKもそのプロセス内部で動いている(個別のプロセスとして存在しない)ようなので外から使うのは難しそうです。(以下略)


  • DM200上でLinuxOSが走り、その上層で1プロセスとして、ATOK等も含めた「POMERAアプリ(仮称)」が走っている。
  • POMERAアプリ(仮称)」ではすべて "RTC+24時間"で動作・完結している。
  • なので通常どおりPOMERAの動作としてはつじつまが合っている(ようにみえる)。
  • 前回の記事の通り、Ver1.3→Ver1.4では素のkernelやinitramfs周りでの変更は無かった。
  • ということは、もっとアプケーション寄りのところで何かしらの変更があった、と考えられる。

オリジナルのファームウェアのうち、kernelと「POMERAアプリ(仮称)」の間の層で何かが変わっているが解れば、こうなった理由がわかるのだろうか?

うーん・・・

まとめ

前回、「Ver1.4で問題無し!どや!」などと大手を振って公開してしまった手前非常にばつが悪いのだけど、ここにきてこんな状況だとは。まさか時刻関連でこんな変更があるなんて思ってもいなかった。

現状で解決策が思いつかない以上、Ver1.3 → Ver1.4へのアップデートを気軽にお勧めできなくなってしまった(いや、そもそも明確にお勧めしてたわけじゃないけども)。

なにかブレイクスルーが見つかるまでは保留とする。


謝辞: @ytakedaさんご協力ありがとうございました。

2018/04/01

[]DM200 Ver1.4アップデート、そしてLinux on Pomeraの再設定。

年明けから今年度対応でクソ忙しくてやってらんなかったけど、なんとか落ち着いたのでそろそろ再開したい。

とりいそぎ、このネタだ。


DM200のアップデートが出てた。

「ポメラ」DM200 ソフトウェアアップデートのご案内 | ダウンロード | ファイルとテプラのキングジム

ATOKの更新、カレンダー表示関連の強化、通信関連の使い勝手向上、御約束の「軽微な修正」。

結論から言うと・・・

Linux on Pomera DM200 人柱版その2」はバージョン1.4でも動作する。

バージョン1.3で使っていたSDカードもそのまま使える。

免責

本記事を参考にいろいろやってお持ちのDM200が文鎮化しても当方は一切知ったことではないのでそこんところヨロシク。

DM200 Ver1.3 → Ver1.4 アップデート

用意した物:microSDカード(東芝製、16GB、class10、手持ちが無かったのでコンビニで購入)

まず既存環境のバックアップ

ファクトリーモードによるとファームウェアバージョンは「Ver1 4 59」。

アップデートファイルのファイル名と一致する。

本体ストレージ上のデータで欠損などは特にないことを確認。

通信関係の安定化とか含まれているらしいが、今回検証は置いておく。


バックアップと準備と予想

Ver1.3でできていたように、「Linux on Pomera DM200 人柱版その2」が起動できるか、試すための準備と調査。

まず新しくなった純正eMMC NANDをバックアップする。

次に、純正ver1.3と1.4の比較。

本家より引用。

簡単な動きの説明

インストーラでは内蔵eMMC NANDのリカバリkernelリカバリinitramfs領域を書き換えます。

書き換え後に起動手順を行うと書き換えたkernelとinitramfsを使って、SDカードの2番目のパーティションに置いたrootfsのDebian(jessie)が動きます

「DM200 NAND backup/restore tool」に含まれるreadme.txtより引用。

2. SDカード上にrestoreフォルダを作成し、中にバックアップ時に取得したmmcblk0p14.imgとmmcblk0p15.imgを名前を変えずに入れてください。

注: 標準ではdebianインストーラを使用した場合に書き換える領域のみリストアします。

つまり、「mmcblk0p14.img」「mmcblk0p15.img」がDebian起動にかかわるkernelとinitramfsの部分であり、インストール時に書き換えられる。

やってることは、起動中にsdカード上のrootfsにシーケンスを切り替えるだけのはず。

なので、Ver1.3とVer1.4のそれぞれのNANDイメージファイルを比較する。

手っ取り早くWindows機を起動していたのでcompコマンドを使用。

C:\diff>comp .\v1.3\mmcblk0p14.img .\v1.4\mmcblk0p14.img 
.\v1.3\mmcblk0p14.img と .\v1.4\mmcblk0p14.img を比較しています... 
ファイルに違いはありません 

ほかのファイルを比較しますか (Y/N)? n 

C:\diff>comp .\v1.3\mmcblk0p15.img .\v1.4\mmcblk0p15.img 
.\v1.3\mmcblk0p15.img と .\v1.4\mmcblk0p15.img を比較しています... 
ファイルに違いはありません 

ほかのファイルを比較しますか (Y/N)? n 

ということで、この二つのブロックに差異は無い、つまりv1.3とv1.4で同じ。

まぁ、アップデート履歴を見る限り起動に関する修正は入ってないから、おおよそ予想通りではある。「軽微な修正」があるので確信できなかったけど。

普通にv1.4+DM200 on linuxいけるんじゃねぇの?

基の純正ファームウェアのこれらが同等であれば、DM200 on linux も問題なくインストール、起動できる?


ver1.3+linuxインストール後のファームウェアイメージを取っておいてver1.4にアップデートに該当ファイルだけリストア(mmcblk0p14.imgとmmcblk0p15.imgの書き戻し) すれば手間少なく復帰できただろうな。とっとけば良かった・・・。


Ver1.4 に Linux on Pomeraインストール

なにはともあれ、ここまでやったのだからゼロからインストール

純正Ver1.4 に 「Linux on Pomera DM200 人柱版 その2」をインストール

ファームウェアVer1.4にて「linux on Pomera DM200 人柱版その2」のインストール動作確認完了。

eMMC側からrootfsを起動できる体制がととのったので、以前(Ver1.3)使ってたSDイメージ内のrootfsが起動できるか確認。

ファームウェアVer1.4にて、Ver.1.3で使用していたSDカードの継続使用が可能であることを確認。

WiFi接続もまったく今まで通り問題なし。Bluetoothについてはそもそも使っていなかったので参考にならず。

一応確認

比較してみる。

C:\diff>comp .\before\mmcblk0p14.img .\after\mmcblk0p14.img 
.\before\mmcblk0p14.img と .\after\mmcblk0p14.img を比較しています... 
OFFSET 4 で比較エラーがあります 
ファイル1 = 18 
ファイル2 = E8 
OFFSET 5 で比較エラーがあります 
ファイル1 = 1C 
ファイル2 = 8D 

(中略)

OFFSET 2BC で比較エラーがあります 
ファイル1 = 30 
ファイル2 = 0 
不一致の数が 10 に達しました - 比較を終了します 

ほかのファイルを比較しますか (Y/N)? n 

C:\diff>comp .\before\mmcblk0p15.img .\after\mmcblk0p15.img 
.\before\mmcblk0p15.img と .\after\mmcblk0p15.img を比較しています... 
OFFSET 4 で比較エラーがあります 
ファイル1 = 39 
ファイル2 = AA 
OFFSET 5 で比較エラーがあります 
ファイル1 = BD 
ファイル2 = DB 

(中略)

OFFSET 13 で比較エラーがあります 
ファイル1 = BD 
ファイル2 = 58 
不一致の数が 10 に達しました - 比較を終了します 

ほかのファイルを比較しますか (Y/N)? 

ってことだ。

というか・・・

インストーラはイメージ内のvfat領域の下にある「kernel.img」とinitramfs.imgを書き込んでいるんなら、インストーラのイメージ内から実SDカードにコピーしてインストーラとして起動すればeMMC側に再インストールされるんじゃないだろうか。

もっというと、v1.4ファームウェアアップデータが差分のみ書き込むのなら、v1.3にDM200 on linux導入済なら、ファームウェアアップデータを適用しても何事もなく起動するような気がする。 つまり、

  1. Ver1.4にアップデート
  2. SDカード上からインストーラを削っている場合はインストーラのイメージから取り出してSDカードのvfat上に配置)
  3. インストーラを起動

たぶんこれが一番手順が少ない、んじゃないか、な?

・・・が、またeMMCをリカバリしてチェックするのめんどくさいので、Ver1.3でLinux on Pomeraを使っていた方はお試ししてみれば?

おまけ:tmux

Linux on Pomera へ、端末マルチプレクサのtmuxを追加してみた。

初見で「screenよりわかりやすそう」と思ったけど、意外とそうでも無かった。だが、見栄えは良いのでぼちぼちためしていこうと思う。

2017/10/18

ネタ無しでまた日が空いてしまったので記録メモ。

[][] ハンドルアップスペーサ

Firestorm用のハンドルアップスペーサを譲ってもらった。

5年ほど前にバイク屋の常連の別のFirestorm乗りが、買い換えるときに外した物をもらう約束になっており、バイク屋が保管していた。

そのまま「倉庫のどっかにある」状態で行方不明だったのだが、「最近倉庫を整理したらタイミングで外したノーマルパーツなどと一緒に出てきた」とのことで、そのまま譲渡の運びとなった。

f:id:obally:20171019013938p:image

ハリケーンの 「ハンドルアップスペーサH13」だが、この名前で検索するとFirestorm用しか出てこないので、他の車種用は(13mmアップの物は)無いんだろう。


セコハンもらい物なのでパッケージも何も無し。

  • 13mmアップ。
  • アルミ削り出し。
  • カウルの加工が不要、ブレーキクラッチ・電装関連を延長しなくてもそのまま付けられる。

いざ交換。

まずは右側のハンドルから。

既設ハンドルのクランプの六角ボルトを緩めて「上から抜けば外れる」とのことだった。

が、なにか引っかかってる。

フォークチューブ上端に、薄い出っ張りみたいなものがあって、引っかかって抜けない。

というか、そもそもこれが「抜け止め」になってるんだろう。

ボルトを抜いて広げられるだけ広げてみてもどうしてもこの出っ張りが引っかかってしまう。

ふと、ハンドルの左をよく見ると、

f:id:obally:20171019013939p:image

出っ張りに隙間がある。これCリング(スナップリング)なのね。

ということでハンドルを緩めた状態でCリングを外す。

f:id:obally:20171019013940p:image

上から抜けば・・・こんどはケーブルが伸びきって抜けない。

右のハンドルで伸びきってるのは(前)ブレーキレバーだった。たどっていくと・・・

f:id:obally:20171019013941p:image

ここのボックス?に行き当たる。ブレーキラインはここから左右両側のフロントキャリパーに振り分けられるのだが、これがブリッジにナットで固定されている。

ハンドルバークランプが抜けるまであとちょっとだけなので、この固定を外してやると・・・

f:id:obally:20171019013942p:image

無事抜けた。

次にスペーサを挿入。ハンドル側のストッパーの突起と同じ位置にスペーサのストッパーが来る。

f:id:obally:20171019013943p:image

同じ位置にハンドルクランプ側のストッパーが入るようになっている。つまり、ハンドル角度はそのままで上下位置だけ上にくる。

ナットを締めて固定。ブレーキラインのボックスを忘れずに戻しておく。

f:id:obally:20171019013944p:image

左側は特にラインが伸びきるような部分も無く、そのまま抜ける。

f:id:obally:20171019013945p:image

こちらも同じように。


カウルとのクリアランス

f:id:obally:20171019013952p:image

f:id:obally:20171019013946p:image

f:id:obally:20171019013947p:image

ハンドルの角度は同じで上に13mm上がるだけなのでタンク側と干渉することは無い。

問題はアッパーカウルとの干渉。おそるおそるいっぱいにハンドルを切ると・・・

f:id:obally:20171019013949p:image

右側。やはりスレスレか。それでもカウルの端がグリップの位置に来ないので手に当たることは無いだろう。

f:id:obally:20171019013948p:image

左側。こちらもやはりスレスレ。パッシングスイッチは操作できないかと思う。

もっとも、走行中にハンドルをいっぱいに切ること自体はそうはあり得ないので、そのときはそのときと割り切ってもいいだろう。

f:id:obally:20171019013951p:image

ハンドルクランプが上に上がった分、フォークチューブの上に飛び出してるんだが・・・前のオーナーもそうやって使っていて特に問題があったとは聞いてないので、まぁ様子見だな。

実走テスト・・・は、しない。

どうせなら多少でも距離を走って感触を見たいところだけど、今回はちょっと時間が無くて走行テストはできなかった。

現時点での不安要素としては、ハンドルクランプの抜け止めを外してしまったことだが、ぼちぼち様子・増し締めしながら様子見するしかない。というか今回はネジロック材を投入していない。このポジションが気に入らなければ、最悪元に戻すことも考えているので、ネジロック材はポジションに納得してからだ。Cリングも捨てずに保管。

f:id:obally:20171019013950p:image

12月にNM4の車検があって、そのあいだFirestorm名古屋に戻らなくてはいけないので、否が応でも乗ることになる。

ということでレビューはそのうち。