dingux 続き5
あめりんです。
すみません。dinguxてゆ方向じゃありません(笑
USB_Boot_Tool_Manual_1.4_EN.pdfを読む。
4 USB Boot Tool Commandsにて、リセット状態からブート状態にするため、bootコマンドを打って!と記載されているので、ではbootコマンドて何をしているのかとコードリード。
1.GET_CPU_INFOをコントロール転送
2.SET_DATA_ADDRESSで0x80002000へデータ転送することを通知
3.fw.binを転送
4.PROG_START1でfw.binを走らせる
5.100ms寝る
6.SET_DATA_ADDRESSで(0x80c00000)へデータ転送することを通知
→RAM最後尾から4M戻った場所(意図不明)
7.usbboot.binを転送
8.FLUSH_CACHESをコントロール転送
9.PROG_START2でusbboot.binを走らせる
(途中でちょこちょことGET_CPU_INFOを打つんだけど、恐らくping的な意味合いで利用していると思われます)
なるほどー。rockboxのusbtoolでは、こういったコマンドはないので(コマンド(1)が指定されたアドレスへ指定されたファイルデータを転送し実行という機能)、usageに記載されていた
Example:
usbtool 1 fw.bin 0x80000000
usbtool 2 save.bin 0x81000000 1024
これのusbtool 1 fw.bin 0x80000000て意味あったんだねぇ。てっきりコマンド例かと思ってましたよ。
ちゅうことで、
1.a320(USBデバイス)でB+Reset
2.IPL(BOOT ROM内包)がUSBホストからの待受け状態で起動 [推測]
→B+Resetでないと、NANDまたはNORブート(a320の場合はNANDブート)
→ハード初期化してからIPL起動だと思っていた
→もちベンダリクエスト受付状態
3.USBホストからハードウェア初期化イメージをRAMへ転送/初期化(RUN)
ここまでは良いかなー。昨晩は初期化していなかった。それでもROM DUMPは出来たんだよな。思うに、ROMは恐らくjz4740内のBOOT ROMを指すのでjz4740の初期化は出来ていたんだけど、flashやram初期化(pllもやってないんだけどね)は行っていないので駄目だったて感じ？
にしても、本家のusbtoolとrockboxのusbtoolを比べていると移植てレベルじゃないぞ！ぉい！て感じ。よく分からないのが、本家ではbootでusbtool.binも転送して走らせているじゃないですか。このバイナリにはベンダリクエストハンドラもあるので、IPLを挿げ替えているの？て気分になる。そもそもusbtool.binの転送アドレスがコード上で計算する限り0x8系じゃないのでram転送じゃない風味なんですよね。
あと、本家ではfw.binを0x80002000へ転送してますが、rockboxでは0x80000000(ram先頭)なんですよね。別にram先頭でも良いと思うのですが、なんかメモられているのですかね。不思議です。
ベンダリクエスト
GET_CPU_INFO 0x00
SET_DATA_ADDRESS 0x01
SET_DATA_LENGTH 0x02
FLUSH_CACHES 0x03
PROG_START1 0x04
PROG_START2 0x05
NOR_OPS 0x06
NAND_OPS 0x07
SDRAM_OPS 0x08
CONFIGRATION 0x09
GET_NUM 0x0a
おまけ
usbboot.bin->
boothandler.c L83
int GET_CUP_INFO_Handle()
これで動くんかい！と思ったら、ベンダリクエストを受けるところで、一様にGET_CUP_INFOで定義/制御してあった。んー0x00ならばちゅうことだから、問題ないんだけど恥ずいですよね、こゆの。
□自己見解
・NAND/NORブート時
IPLはFlashの先頭アドレスから8kbのSPLをキャッシュに読み込み実行。ramは当然初期化されていないのでキャッシュを利用する。
SPLは周辺ハードの初期化を行い、システムローダを呼び出す(3段ロケット)。
よって、hw.bin(origin)とかhwinit.bin(dingux)はSPLである。
・USBブート時
IPLはホストからのリクエスト待ちとなる。SPLは呼び出されていない(ちゅうかSPLが存在しない)ので、ホストよりSPL(stage1)を転送し走らせる必要がある(周辺ハード初期化)。またホストからのコマンドを処理するモジュール(usb_boot.bin)をstage2として転送し走らせる必要がある。
□なぞなぞ
usbtoolにてコマンドを処理するモジュールはstage2より有効になるのだが、既にstage1を転送する際に(初期化もされていない)ram先頭へメモりなさいとコマンドを送信する。よって、IPLがコマンドを処理する機能を持っているとしか思えない。現に、GET_CPU_INFOの結果(文字列)は、stage2がロードされている時とされていない時で違う。ホストもこの結果でブート済みか否かを判定していたりする。これはIPLソースを読まない限り謎のまま。
