1999-06-27 apbus probe。TLB miss
ぐつぐつと apbus の attach をさせるべく書く。
なんか、pmax って異様に整ってるなぁ....というわけで、
bus まわりはこっちを見本にして加えてゆく。
あとは clock を綺麗に分離しなきゃなぁ。newsmips は clock.c で直接
I/O 叩いてるし...。これも pmax を参考にして、そのうちやろう。
てなわけで ap0 at mainbus0 のメッセージを拝む。
次は apbus についてる device。
ROM モニタの管理してる sysinfo 構造体から APBus についてる device がわかるから、
それを元に config_found していきゃいいのね。きっと。
で、ふにふにと link を辿って、とりあえず config_found せずに
device 構造体を print するようにして、様子見。make。実行。
がー。
ap0 at mainbus0 panic: TLB out of universe: ksp was 0x800bcd18 8008b1d4+54 (800bb000,0,0,0) ra 8001b928 sz 24 8001b8ac+7c (100,38,0,0) ra 8000280c sz 32 800027f0+1c (100,38,0,0) ra 0 sz -4096 User-level: pid 0 halted.
やはりこれは 0xFFF00000 問題か。
#ってなにげに初 panic だったりする。:)
#printf がちゃんと動くってなんて幸せなことなんだろう...
ROM モニタが設定してくれる APBUS のデバイス情報は
0xFFF????? にあって、0xFFF????? は
先日にも書いた通り、メモリの高位 1M に
TLB で map されているのだが、とうぜん NetBSD 的にはこんな MAP しておらず、
TLB miss でそのまま死ぬ、と。
これは mips/mips/pmap* をいじらなきゃダメってことですか?
0xfff00000 = 0x03f00000 (メモリ64Mな場合) な page table entry をちゃんと作るか、
NetBSD 的には、実装メモリサイズ - 1M分に見せてやって、
TLB routine をいじって runtime に生成してやるかのどちらかだな。
後者の方が楽?
前者の方が綺麗?
もしくは、kernel を load した直後に、ROM が管理している 0xfff00000 〜
にある情報を全て取り込んでしまって、あとはもう二度とROMワークは参照しない、
という手もあるかな。負けた気分だけど。
でもその場合、ちゃんと halt して ROM モニタに戻れるかどうかが謎だ。
とりあえず今日はここまで。
他の仕事やんないと...
EOF