[ TOP | Recently ]

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