コグノスケ

Device Treeを試したらハマった

ARM Linuxのブート方法は3種類あって、一番古い方式はもう使われていません。自作エミュレータの内蔵ブートローダで使っているのは2番目に新しい、ATAGSと呼ばれる方式です。

最新の流行はDevice Treeを使う方式らしいので、内蔵ブートローダを改造して試してみました。が、なぜかカーネルが異常なアドレスにアクセスして死にます。アドレスを調べても、仕様書にないレジスタです。

発動条件を調べるとDevice Treeを有効（CONFIG_MACH_VERSATILE_DTを有効にする）にして、Device Treeを使ってブートするとハマるようです。

Linuxカーネルのコードを見てもATAGSで起動したときと、Device Treeで起動したときに実行されるコードがなぜか違うし、どういう意味なんだこれ…。

怪しいレジスタアドレス

Linuxカーネルのコードに出てくるレジスタ名で調べていたら、どうもmach-integratorにあるコードと同じレジスタアドレスを使っているように見えます。

下記がIntegratorのレジスタアドレス定義です。

#‎define IRQ_STATUS 0
#define IRQ_RAW_STATUS 0x04
#define IRQ_ENABLE 0x08
#define IRQ_ENABLE_SET 0x08
#define IRQ_ENABLE_CLEAR 0x0C

#define INT_SOFT_SET 0x10
#define INT_SOFT_CLEAR 0x14

#define FIQ_STATUS 0x20
#define FIQ_RAW_STATUS 0x24
#define FIQ_ENABLE 0x28
#define FIQ_ENABLE_SET 0x28
#define FIQ_ENABLE_CLEAR 0x2C

で、下記がDevice Treeで起動したときのVersatile PB/ABのレジスタアドレス定義です。コピペだと思えるくらいに似ています。

#define IRQ_STATUS 0x00
#define IRQ_RAW_STATUS 0x04
#define IRQ_ENABLE_SET 0x08
#define IRQ_ENABLE_CLEAR 0x0c
#define INT_SOFT_SET 0x10
#define INT_SOFT_CLEAR 0x14
#define FIQ_STATUS 0x20
#define FIQ_RAW_STATUS 0x24
#define FIQ_ENABLE 0x28
#define FIQ_ENABLE_SET 0x28
#define FIQ_ENABLE_CLEAR 0x2C

#define PIC_ENABLES 0x20 /* set interrupt pass through bits */

こちらが正しいレジスタアドレス定義です。ATAGSで起動した場合はこちらのアドレスが使われます。

#define SIC_IRQ_STATUS                  0
#define SIC_IRQ_RAW_STATUS              0x04
#define SIC_IRQ_ENABLE                  0x08
#define SIC_IRQ_ENABLE_SET              0x08
#define SIC_IRQ_ENABLE_CLEAR            0x0C
#define SIC_INT_SOFT_SET                0x10
#define SIC_INT_SOFT_CLEAR              0x14
#define SIC_INT_PIC_ENABLE              0x20    /* read status of pass through mask */
#define SIC_INT_PIC_ENABLES             0x20    /* set interrupt pass through bits */
#define SIC_INT_PIC_ENABLEC             0x24    /* Clear interrupt pass through bits */

私もそんなに詳しいわけではありませんが、Versatile AB/PB (DUI0225D) とIntegrator CP (DUI0159B) は全く別のボードだと思うので、恐らくDevice Treeに対応した人が間違えたのでしょうね…。

バグってるっぽい

気になったのでqemuで試してみましたが、やはりエラーが出ます。もしかして動作確認してないのかなあ？？

しかしqemuさんは強い子でして、明らかに未定義領域にwriteされたのに警告を出すのみで、とにかく先に突き進んでくれます。それで結果的に動くからスゴイですよね…。

$ qemu-system-arm -kernel linux-4.1.13/arch/arm/boot/zImage \
 -dtb linux-4.1.13/arch/arm/boot/dts/versatile-pb.dtb \
 -M versatilepb \
 -append 'console=ttyAMA0' \
 -nographic -serial mon:stdio

Uncompressing Linux... done, booting the kernel.
vpb_sic_write: Bad register offset 0x2c★★★エラー出てる★★★
Booting Linux on physical CPU 0x0
Linux version 4.1.13 (katsuhiro@vbox) (gcc version 4.9.2 (GCC) ) #4 Sun Dec 6 01:46:36 JST 2015
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
CPU: VIVT data cache, VIVT instruction cache
Machine model: ARM Versatile PB

★を付けたところ（vpb_sic_write〜 と出ている部分）がqemuの警告です。

Facebookにも意外と書いていた

Facebookでの2013〜2014年辺りの書き込みを、この日記にも転記しておきました。

大した数ではないだろうと甘く見ていたら意外と数が多くて、結局50個近くのエントリを作る羽目になりました。うーん、疲れた……。

さようならnottv

ドコモ、NOTTV／モバキャスを2016年6月に終了　周波数は返還 - ITmedia Mobileを読んで。

ニュース見てnottvの開始時期いつだっけ？と思って調べたら2011年でしたから、約5年で終わってしまったんですね。

テレビ放送は放送局の都合で番組が流れるだけですが、VoDなら見たい番組をすぐに見ることができるわけで。どちらも有料なら、テレビ放送は選ばないですよね…。

メモ: 技術系の話はFacebookから転記しておくことにした。

ARM向けクロスコンパイラを自分でビルド

目次: GCC

自作ARMエミュレータでLinaroのクロスコンパイラで作ったバイナリを動かすまでは道が遠すぎて（ARMv6, Thumb-2, ARMv7の実装が要る）、すぐに出来そうにないので、

ARM9用のgccとglibcをビルドすれば良いんじゃねー？と軽い気持ちで始めたのですが、エラー大量発生＆何を変えたら直るかさっぱりわからず、悪戦苦闘でした。

一応libc付き＆スタンドアローンで動作するARM用クロスコンパイラが作れましたが、疲れましたね…。

Linaroはcrosstool-NGを使っているようです。次はこれも試してみようと思います。自前でやって苦戦した今だからこそ、ビルド自動化ツールのありがたさが理解できるはずです。

GitHubに怒られた

適当にgccとlinuxのソースtarballをGithubに叩き込んだら、Githubに「デカいファイル置くな」って怒られた…。

remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com/
remote: warning: See http://git.io/iEPt8g for more information.
remote: warning: File gcc-shared/gcc-4.9.2.tar.bz2 is 85.77 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: File linux-headers/linux-3.18.11.tar.xz is 77.21 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: File gcc-shared/gcc-4.8.4.tar.bz2 is 82.23 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB

メモ: 技術系の話はFacebookから転記しておくことにした。

日記のPermanent Link先

このサイトの日記には「permalink」というリンクを出していて、リンク先はあらかじめ保存しておいたHTMLファイルへのリンクとなっています。

内容は同じですが、動的に生成するトップページに比べ、permalink先は単なるHTMLファイルですので表示が速いはずです。実はきちんと測ったことないので、どれくらい速いかまでは知らないですけど…。

で、permalinkのリンク先であるHTMLファイルは、今まで記事を書くごとに手動で更新していたわけです。しかし面倒だし良く忘れてリンク切れになるし、ロクなことがないので、自動更新するように変えました。

現状は自宅サーバから更新を掛けており、昼と夜の1日2回更新です。たしかSakuraのサーバでもcrontabを設定できたはずですが、書き方が悪いのか動かなかったので放棄しました。