NORフラッシュの書き込みにこれほど苦労するとは思いもよらず。
相変わらず不調なので、やっている事まとめその2です。
resetする時に
Trying to use configured scan chain anyway...
なんて出るのはchainの設定がまずかったようで、openocd.cfgで明示的に
set _CPUTAPID 0x07926041
としてあげれば良い模様。
…
NORフラッシュに書き込めないのは、多分周辺が初期化されていないからだと予想。
ごちゃごちゃやっていたせいで、現在NORフラッシュの中は空っぽなのです。それは”flash erase_bank 0 0 63″したせいなのだけれど、この時点で”0x00″で初期化されているはずなのに、ダンプすると0xffで出てくるわけで。
“flash info 0″した時に”protected”なんて出てくるのも良く分からない。OpenOCDのソースを眺めるとCFIドライバの中ではIntelチップ以外はハードウェア的にプロテクトを掛けられないようだし。
一方39VF020のデータシートを見ると”WE#”なんて信号線があるから、書き込むときに操作しないといけないはずなんだけれど、どうやればいいのかも不明。
# 基板を見ると怪しいスルーホールがあるのですが、何ですかねこれは。
IBM PC/AT互換なんて代物だとこういうのはBIOSがやってくれるはずなのだけれど、そういうのが載っていない情況では自分でやらないと駄目ですよって訳で。
ちなみに、SheevaPlug用のcfg見てみると
arm mcr 15 0 0 1 0 0x00052078 mww 0xD0001400 0x43000C30 # DDR SDRAM Configuration Register mww 0xD0001404 0x39543000 # Dunit Control Low Register mww 0xD0001408 0x22125451 # DDR SDRAM Timing (Low) Register mww 0xD000140C 0x00000833 # DDR SDRAM Timing (High) Register mww 0xD0001410 0x000000CC # DDR SDRAM Address Control Register mww 0xD0001414 0x00000000 # DDR SDRAM Open Pages Control Register mww 0xD0001418 0x00000000 # DDR SDRAM Operation Register (snip)
なんて事をしている。こんな感じで初期化してあげないと、今の状況を抜け出せないんだろう、多分。
SheevaPlugもMarvellのSoC使っているようだけれど、88F5281では無いようだし、当然基板も違うのでそのまま同じ事をしても無駄なはず。
とはいえ、88F5281のデータシート読んでも、その辺の記述は一切無いので基本的にはお手上げ。ぐぐると、アドレス的に0xd0000000以降が関係するレジスタらしいのは分かるのだけれど。
…
素の状態から一応操作できるようになるのだったら、そいつは初期化処理をしているはず。
であればu-bootのソースコード見れば分かるんじゃないかとは思ったものの、BuffaloのGPLサイトにはu-bootのコードが無い。玄人志向のGPLサイトはURL分からずorz。
BuffaloのGPLサイトにはLinuxのカーネルコードはあるんですけどね。今の段階でカーネルなんか読みたくないし。
実際にはMarvell版のu-bootを使っているようなので、
git clone git://git.denx.de/u-boot-marvell.git
してコードを眺める事に。
多分だけれど、
u-boot-marvell\arch\arm\cpu\arm926ejs\orion5x\
にあるような事をしてあげれば良いんじゃないかと、ちまちまとソースを追っかけ中。
“lowlevel_init.S“辺りで”0xd0000000″以降になにやら書き込んでいますねぇ。つかアセンブラっすか(汗)。
おいら、80286辺りで止まっているので仕様書探して来ないと…。いや～、面白くなってきましたよぅorz。
# ちなみにカーネルソースだと”arch\arm\mach-mv88fxx81\“辺りがそうなのかな。
コメント