コグノスケ

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

さようなら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から転記しておくことにした。