コグノスケ

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を設定できたはずですが、書き方が悪いのか動かなかったので放棄しました。

外の世界

自作エミュレータに外部とのアクセス手段を足そうと思い、ARM Versatileに載っており、かつLinuxのドライバが存在するハードを調べてみたら、

• NORフラッシュ
• MMC（SDカードみたいなもん）
• Ethernet

NORフラッシュなら簡単かなーと思って調べ始めたら、ちょっと甘かったです。

Versatileのメモリコントローラの仕様書には16bitフラッシュの型番が載っていて「対応してる」と書いてあります。つまり16bitフラッシュをエミュレーションすれば良いはずです。

NORフラッシュにはコマンドという概念があって、特殊なアドレス＋特殊なデータをwriteすると、コマンドとして解釈されます。コマンドによって、容量とか8bitなのか16bitなのか調べたり、ブロックをEraseしたりできるわけです。

試しにLinuxのドライバを動かして、CFIというJEDECの規格に載っているQueryコマンド（CPUからFlashへ、容量やらビット幅を尋ねるコマンド）を送るとき、どんな動きをしているか見ると、

• CPUからは32bit幅でアクセスされる
• コマンドのアドレスは32bit品か、16bit品のものを2倍した値（0x000154 = 0xaa << 1）
• コマンドのデータは16bit品のものだが、上位16bitと下位16bitに同じデータが入る（0x00980098）
  32bit用であれば0x00000098でなければならない

このように一見32bitに見えて、コマンドのデータが全然違う値なので、最初はさっぱり意味がわかりませんでした。

もしデータ幅と同じ32bitフラッシュが接続されているのであれば、下記の図のように接続されていて、使用するコマンドは32bitフラッシュ用のデータになるはずです。

32bit NORフラッシュの接続例

しかし仕様書にはどう見ても16bitフラッシュの品番が書いてありますし、実際に発行しているコマンドも16bitフラッシュ用のデータです。

ハードに詳しい方はお気づきかもしれませんが、おそらくCPUとNORフラッシュの間にいるメモリコントローラが一枚噛んでいて、下記の図のように16bitフラッシュに2発同時アクセスして、32bitデータを扱えるようにしていると思われます。

16bit + 16bit NORフラッシュの接続例

アドレス線は共通（ただし下位1bitは捨てる）で、データはコントローラ側で分割（Write時）、結合（Read時）される仕様です。

CPUから見ると1度に32bitのデータを扱えるように見えますが、あくまでも接続されているのは16bitフラッシュですので、アドレスとデータは16bitフラッシュ用のものにしなければなりません。1つ目のフラッシュと2つ目のフラッシュ双方にデータを送る必要があるため、上位bitと下位bitの両方にデータを入れていた訳です。

とまあ、こんな具合でreadは簡単（？）に出来ましたが、writeを調べたらerase, writeのパターンが多くて、ちょいと大変そうです…。

余談

Flash ROMのハードウェア仕様上のアドレスは、ワードアドレス（つまり2バイトでアドレスが1増える）ですが、仕様書のコマンドの説明はバイトオフセットで書いてありました。少なくともIntelとMicronの仕様書は。

従ってエミュレーションする際はバイトアドレスを使った方が、仕様書と数字が一致して読みやすいです。ハードウェアのアドレス線がどうなっていようが、ほとんど気にする必要はありません…。