コグノスケ

ARM PC で開発できるか？

最近の ARM 搭載 SoC はかなり速くなっています。もしかして x86 PC の代わりに使えるのではないでしょうか？開発に使うことを想定して、コンパイル速度を比較してみたいと思います。

比較に使うのは Linux Kernel の開発ツリー（linux-next）です。コンフィグはデフォルトを使い、ビルドターゲットは all を指定します。ビルドしているアーキテクチャが違う（Rock64: arm64, AMD A10: x86）ので、時間の単純比較はできませんが、参考にはなると思います。

AMD A10 7800、32GB DDR3-1600 の PC で linux-next x86 の time make -j4 all を実行しますと、

• real 10m33.584s
• user 33m37.811s
• sys 4m7.908s

不遇の Bulldozer 系コア、もはや 4年落ちとなった CPU で、大して速くはありませんが、十分実用的というか、待っていられるレベルです。

Intel Pentium J4205、16GB DDR3L-1600 の PC で linux-next x86 の time make -j4 all を実行すると、

• real 14m45.968s
• user 51m57.967s
• sys 5m47.331s

Pentium J は Atom 系列で遅いと思いきや、予想より何倍も速かったです…。ナメてました、ごめんなさい。

Rock64、Rockchip RK3328、Cortex A53 x 4、4GB DDR3 で linux-next arm64 の time make -j4 all すると、

• real 179m33.126s
• user 266m0.254s
• sys 22m52.046s

PC と比較するとほぼ 1桁遅いです。さすがにこれは待っていられません。Rock64 は普段使いには十分速いですが、開発に使うのは辛そうですね…。

Raspberry Pi 3、Broadcom BCM2837、Cortex A53 x 4、1GB LPDDR2 で linux-next arm の time make -j4 all すると、

• real 146m46.807s
• user 236m43.970s
• sys 10m41.310s

ビルドしているアーキテクチャが違う（Rock64 は arm64、RasPi 3 は arm）ので、単純比較はできませんけど、Rock64 と大差ないですね。

もっと速い ARM SoC は？

今のところスマホ、TV/STB 系 ARM SoC は A72 x 4、A53 x 4 が最強クラスのようです。サーバー系 ARM SoC に目を向ければ A72 x 16（NXP LX2160A）もしくは A53 x 24 や A53 x 48（Cavium ThunderX）といった桁違いメニーコアがありますが、そんなに要らないんですよね…。

中間の製品はありません。買う人いないんでしょうね。

ARM SoC 搭載ボード

今後のお買い物の参考に、ざざっと調べてみました。

Tegra 系

ボード Jetson TX2、Denver x 2、A57 x 4、8GB LPDDR4、$600 日本だと販売店のぼったくりで 10万円。

HiSilicon Kirin 960

ボード HiKey 960、A72 x 4、A53 x 4、3GB LPDDR4、$239 良いんだけど、メモリがもう一声欲しかった…。

Rockchip RK3399

ボード NanoPC-T4、A72 x 2、A53 x 4、4GB LPDDR3-1866、$109 DDR3 ではあるけど、良さそう。

Samsung S5P6818

ボード NanoPC-T3 Plus、A53 x 8、2GB DDR3、$75 可もなく不可もなく？

Amlogic S912

ボードが見当たらない、A53 x 8、どこか発売してくれないかな。

Amlogic S905

ボード ODROID C2、A53 x 4、2GB DDR3、$39 S912 の一世代前ですね。

AllWinner H6

ボード PINE H64、A53 x 4、2GB LPDDR3-1600、$36 安くて素敵だけど、さすがに見劣りしてしまうなあ。

性能だけ求めるなら Jetson か HiKey 960 で、コスパなら NanoPC-T4 ですかね。Jetson なら流行りの AI とか、GPGPU も実験できますね。お値段はべらぼうですけど…。

地震保険

AIG 損害保険から「大阪北部地震で被害を受けた方はご連絡ください」という手紙が来て、地震保険に加入していたことを知りました。ずっと火災保険だと思ってたよ……。

人生初の地震保険です。

保険会社に被害を申請（電話、Web でも可能）すると、調査員さんが家に来てくれます。調査員の方は、かなり積極的に被害としてカウントしてくれます。むしろ、こちらが「いやー、そこは特に被害無かったですね…」と断るような形になるくらいでした。

家財の場合、壊れなくても、地震で倒れたりズレたら被害としてカウントされるそうです。あと、地震保険で特徴的なのは、被害を受けた「種類」が大事なことです。本が 1冊でも 100冊でも、カウントは「本」の 1種類のみですが、棚とテレビと冷蔵庫が地震でズレたり倒れたりすれば 3種類としてカウントされ、被害が大きいとみなされるようです。

地震保険の査定額

地震保険は火災保険と違い損害額ではなく、保険金額（契約時に決めている額面）の何割という形で支払われます（地震保険 | 個人のお客さま | AIG 損保へのリンク）。

我が家の場合、家財の「一部損」判定でした。この場合、地震保険金額の 5%が支払われることになります。契約していた保険金額は 100万円くらいだった（それも知らなかった…）ので、支払われる額は大体 5万円です。

大阪北部在住で、地震保険に加入している人は、とりあえず被害申請をしてみるといいですね。判定結果が一部損（一番低い）でも、地震でグチャグチャにされた部屋の片づけ手間賃くらいにはなると思います。

査定方法

査定は結構面白いです。馬のフィギュアがテーブルから落ちてたら「被害です」、お皿が落ちたり転げたら割れてなくても「被害です」。逆に言うと、壊れた物の金額は勘案しないので、被害の受け方によっては被害額と保険の査定額が全く合いません。

しかし元々そういう保険なんです。火災保険や自動車保険とは仕組みが違うのですね。

保険会社がんばってる

AIG 損害保険の調査員の方曰く、大阪北部地震と 7月豪雨の被害調査を迅速に行うため、全国の調査員が応援に駆けつけているのだとか。今日来ていただいた方も北海道から応援に来ていると言っていました。

最近は特に暑いし、特に豪雨の地域では道路がやられていて、被災地を駆け回るにもとても大変らしいです。頭が下がる思いです。

エディタ

誰しもお気に入りのエディタがあると思いますが、私は割とメチャクチャです。

C 言語系は読むときは Vim + GNU Global、書くときはサクラエディタを使うことが多いです。

Vim はタグジャンプやヒストリが優秀で、検索もしやすいので、コードを読む際にはとても便利だと思います。ログを差し込んだり、コードを多少書き換える程度であれば Vim で済ませます。

しかし 1から全て書くような場合は、サクラエディタが多いです。何ででしょうね？関数表示が便利なのかな？そんなサクラエディタも C++ を書くときはイマイチで、ラムダがまともに表示されず不便です。

GVim で tab と :Tlist を使うとサクラエディタの関数表示に近くて、個人的には良い感じですが、常用には至っていません。何が悪いのかわからない…。

Java は読むことはあまり無いけど Vim ですかね、書くときは IntelliJ IDEA です。スクリプト系は Vim で読むし、書きます。

こうして並べてみると、かなり支離滅裂です。どうしてこうなった…？？

Vim と Emacs の思い出

Vim も Emacs も初めて使ったとき「は？何だこれ……？？」と思いました。どちらも終了方法がわからず、まともに使えませんでした。今は IDE も Vim も適度に使っています。

でも Emacs は完全に使い方を忘れてしまった。ごめんね Emacs…。

久しぶりに自作 ARM エミュレータ

久しぶりに自作 ARM エミュレータ ememu を（ソースコードはこちら）動かそうと思い、Linux 4.4 の latest である、Linux 4.4.146 をダウンロードしました。

この ememu では ARM Versatile PB/AP ボードの一部デバイスと、CPU ARM926EJ-S の一部、アーキテクチャで言えば ARMv5T 相当をエミュレーションしています。

クロスビルドできない

巷で手に入るコンパイラは ARMv5T より新しい命令を出力してしまい、エミュレータで実行できませんので、最初に crosstool-ng で、ARMv5T 向けの gcc 8.1.0 を作成しました。

いざ Linux 4.4.146 をクロスビルドしましたが、エラーになり、コンパイルできませんでした。

エラーの意味が良く分からなかったので、さっくり諦めまして crostool-ng で gcc 7.3 を作成しなおし、ビルドをやり直したところ、無事コンパイルが通りました。

Linux が動かない

Linux 4.4.146 は起動しませんでした。偶然持っていた少し古いバージョン（Linux 4.4.77）に戻したりもしましたが、結果は同じで全く起動しません。

デバッグすると、ドライバの作りが変わったのか AACI と MMCI というハードウェアに対して、今まで叩いていなかったはずのレジスタをガンガン叩いていました。ememu は存在しない I/O レジスタを叩くと、エミュレータが例外で落ちてしまい、動かなくなるんです…。

とりあえずレジスタ定義だけ適当に追加したところ、エラーが出まくりますが、起動はしました。適当でも動いてくれる Linux は強い子です。

buildroot が動かない

しかし今度は buildroot で作成した busybox と愉快な仲間たちが起動しません。/dev/null が無いよ？と永遠にエラーが出続けます。

調べてみると Linux 4.4.146 の defconfig だと CONFIG_DEVTMPFS が n つまり無効なんですね。最近の感覚で devtmpfs はあって当然くらいに思っていたので、盲点でした。コンフィグで devtmpfs を有効にしてカーネル再ビルドしたところ、やっと buildroot が動きました。

端末の色がおかしい

対応していない制御文字を送ってきているらしく、ememu の端末（独自実装です）の色がおかしくなります。

これはすぐ直せそうになかったので、しばらくは変な表示と付き合うことになりそうです。

微妙に壊れてる ThinkPad E480 のキーボード

先日購入（2018年 6月 14日の日記参照）した ThinkPad E480 ですが、キーボードのカーソルキー、しかも上カーソルキーだけが微妙に壊れています。

キーを押すとキーが傾いてしまい、引っかかって戻ってこないときがあります。

キーを分解してみた

何が引っかかっているのか調べるために分解してみました。キートップをてこなどで外すと、パンタグラフが入っています。パンタグラフは 2つの部品からできています。

キーボードのパンタグラフ、分解

2つの部品を組み合わせると、I 字型（畳んでいるとき）もしくは X 字型（開いているとき）になります。

キーボードのパンタグラフ、畳んだ状態

キーボードのパンタグラフ、開いた状態

良く見るとこの部品、軸が折れてしまっています。

キーボードのパンタグラフ、分解、軸が折れている

軸が片側なくなっているため、パンタグラフを開いても綺麗な X 字型にならず、捻じれてしまいます。

キーボードのパンタグラフ、開いた状態、軸が折れているので歪む

これによってキートップが若干傾いてキーボードのフレームに引っかかり、元の位置に戻らなくなるようです。

対策

修理に出そうかどうか迷って、いろいろ押し方を試しているうちに、比較的引っかかりにくい押し方があることを見つけました。今は押し方を工夫することで凌いでいます。

さらに最近は、普通にキーを押しても引っかかりにくくなった気がします。パンタグラフが壊れているのは相変わらずなので、キートップ側が削れたのか、変形したのかな？

車検

先週、大阪スバル（高槻店）にレガシィの車検をお願いしていました。今日は納車です。

JR 高槻駅からディーラーまで歩きましたが、もう、とにかく暑い暑い。暑くてやってられません。将来、車を買い替えるとしたら、夏には絶対、車は買わないぞ、絶対だ。心に決めました。

料金は自賠責＆税金込みで 13万円くらいでした。特に大きな故障もなかったし、そんなもんでしょう。ね。