コグノスケ

意外と知らない日本語の一面

電車で隣に座った親子がしりとりをずっとやっていました。幼稚園くらいのお子さんは言葉が枯渇気味になったようで、お父さんに「あ」で始まるなら思いつく…とリクエストをしていました。

そのときお父さんは「た」だったので「た」で始まり「あ」で終わる単語が思いつかず、ずっと悩んでいたそうです。

…という話を、電車を降りたときに奥さんがするもんだから、「よっしゃ、俺らも考えるべし」と挑戦したものの、

• タスマニア
• タンザニア

くらいしか思いつかず何だかイマイチ…。くやしいので家帰ってから辞書引いたら、

• ターヘルアナトミア
• ターミナルケア
• タウンウェア

などがありましたが、外来語しかありません。

そんなバカなと思って「あ」で後方一致かけても、「あ」で終わる単語のほぼ全てが外来語です。

「あ」で終わる日本語って無いんですね。意外でした。

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

Androidは巨大な壁

自作エミュレータ、ARM9とはいえ、一応ARMをエミュレーションしているわけだし、いつかAndroidも動かせるだろうか？と思って、試しにAOSPをビルドしてみました。

生成されたイメージファイルを見てみると、アプリも何も入れていないのにsystem.imgが1.6GBもあります。

ちなみにVersatile PBのNANDは最大でも64MBですので、全くお話になりませんでした。eMMCに期待ですかね…。

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

光で測る

レーザー距離計（メーカーのサイトへのリンク）を買ってみました。BOSCHのGLM 50Cです。Amazonで1万5000円でした。もっと安い機種もありますが、どうせならスマホとつながった方が面白いだろうと思いBluetooth対応機種を選びました。

メタルの巻き尺と比べると、

• 断然早い、1秒で計測
• 自分から見えるところならどこでも測れる
• 天井などの手が届かない高さも測れる
• 角度計、水平器の代用もできる
• 測定値を書き写す必要がない

測定値は本体に記録され、Bluetoothでスマホに飛ばして写真上に値を書き写すこともできます（要、専用アプリ）。

引っ越しや、新たに家具を買う時に非常に便利そうです。活躍の機会は遠いと思いますけどね…。

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

Flash ROMのエミュレーション

自作エミュレータ（リンク）にFlash ROMのエミュレーションを実装しました。

未実装だらけですが、mkfsしてmountするくらいなら、とりあえず動いています。今はリセットすると中身が消えますが、ファイルに読み書きするように変更したら、ストレージとして使えそうです。

バースト書き込みモードがあって高速と思われるIntelのNOR Flashをエミュレーションしていますが、速度的には残念な感じです。

$ dd if=/dev/zero of=/dev/mtdblock0 bs=262144 count=10
10+0 records in
10+0 records out
2621440 bytes (2.5MB) copied, 17.980000 seconds, 142.4KB/s

ただ、これはエミュレータ自体が遅いのも原因ではあります。

$ dd if=/dev/zero of=/tmp/aaa bs=262144 count=10
10+0 records in
10+0 records out
2621440 bytes (2.5MB) copied, 0.830000 seconds, 3MB/s

最速でもこれくらいにしかならないはずです。

作ってみて感じたこと

Flash ROMをエミュレーションしていて思ったのは、単純なだけに書き込みに関してはかなり非効率的なデバイスだということです。

Flash ROMは独立したコマンド線を持ちません。CPUはコマンドもデータも混ぜてバスにWriteします。WriteされたデータはFlash ROM側の状態によってコマンドと解釈されたり、データと解釈されたりする仕組みです。

書き込みの際は、出来る限りデータだけ送る方が効率が良いですが、Flashの場合は仕様上コマンドWriteやステータスReadを必ず挟まなければならないため、効率が悪いです。

Flashの宿命として部分的な書き換えが出来ませんので、書き換えの際は必ずErase -> Writeが行われます。Eraseは256KBなどの大きな単位なのに、書き込みは最大でも128バイトしか書けません。これも効率が悪い原因でしょう。

将来への展望

次に何か足すとしたら、eMMCにチャレンジしてみようと思います。ストレージ専用のI/Fならば断然効率が違う…はずです。たぶん。

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

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個近くのエントリを作る羽目になりました。うーん、疲れた……。