NetBSD/news68k への道

NetBSD/news68k の可能性を探るページです。

20200531

いまさらですが HTML Validator のチェックをかけてエンコーディングも utf-8 に修正しました。

20031220

ふと、netscape7 ではこのページの表示が変なのに気づいたので久しぶりに内容更新。
うーん。コメントの中に "-" がたくさん書かれてるとうまく解釈できないのか?
html のバグか netscape7 側のバグがよくわからないがひとまずちゃんと表示されるように修正。

ついでに中身もいろいろとメンテナンス。
再度いくつか消滅リンクのうち移動先の判明しているものを修正。
伊藤さんのページや古田さんのページ、 NEWS関連情報のページなどなど。
『そこに山があるからだ』など消滅リンクはあいかわらずそのままです。

そ〜し〜て〜４年の月日がな〜がれさり〜街で中古のNEWSをみ〜かけると〜♪
……などと無意味に感慨に耽けってしまうくらい時は流れてしまったのか。うーむ。
しかし、これを書いてた7か月間を思い返してみると、その後の 4年間はどうしようもなく中途半端だなあ。
マシンの台数ばかり増えたけど、何をやっても news68k の printf() 動作時の感動やマージのときの満足感にはほど遠い。

やっぱりなにかビシッと目標決めて取り掛からないとダメか。
次にやるとしたら EWS4800 なんて言ってたこともありますが……
移植作業だけならともかく、素性のわからないハードの仕様を調べるという作業をする元気は出ないんですよね。
というわけで、マシン自体はすでに十分持ってるので、内部情報のタレ込みお待ちしてます。(ぉぃぉぃ)

20001206

NetBSD-1.5 の release annoucement が出たのを機会に、いくつかの記述内容をメンテしました。

NetBSD/bebox 移植記、『そこに山があるからだ』など一部移動リンク先のうち移動先が判明しているものを修正。
あと一部 html 記述の誤りを修正。
なお、消滅リンクは一部を除いてそのままです。

しかしもう 1年経つんだなあ。はやいもんだ。 1.5 release まで 1年かかるとも思ってなかったけど。
なお、明日以降このページの更新が再開したりはしません。念のため。

19991212

5月から書き続けてきたこの「NetBSD/news68k への道」ですが、一通りの merge 作業が完了した今日をもって区切りをつけたいと思います。
自分でこんなことを書くのも恥ずかしいのですが、「構想から merge までを記録する」という当初の目的は達成できたのではないかと思っています。
もちろん NetBSD/news68k 自体はまだまだ完結していなくて道はこれからも続いていくわけですが、それについてはまた別の形で記録していきたいと思っています。

そもそもこれを書き始めた当初は merge までこんなに早く到達できるとはまったく思っていませんでした。むしろ、いつ壁にぶつかってしまうかという不安を振り払うために作文する毎日でした。
それがここまで来られたのは、機材や情報を提供してくれた方、動作テストをしてくれた方、応援メールを送ってくれた方、そしてこのページを見続けてくれた方、みんなのおかげだと思っています。この場を借りてお礼を申し上げます。ぺこり。
最後に、今日でおそらく 500kbyte を突破してしまったであろうこのページの内容が、今後新たに kernel 移植を志す人たちに対してほんの少しでも参考になれば幸いです。どうもありがとうございました。

19991211

make snapshot 無事終了。黙々と 32Mbyte 余りを ftp.netbsd.org に転送。……でかいな。
適当に /pub/NetBSD/arch/news68k/ あたりに展開。勝手に判断してやってるけどこれでいいんだよな。

ここまでで一度中断して日本橋に出かける。
問題の HDD はあっさり交換してもらえたが、もはや作戦完了済みなので意味無しかも。
ついでにいろいろ買物。 BSD daemon トレーナーとか。

帰ってきて続き。htdocs の関連 page に snapshot の件を追記。んで、えいっと正式 announce を流す。
と、複数の知らない外国の人から "great job!" な mail が届く。やっぱり announce@netbsd.org って重要?
残りの "Adding a new port TODO" はほかの人にまかせておけばいいかな。

19991210

make snapshot しながら boot floppy 動作検証したり。 2台あるってのは遅マシン開発では重要かも。
make してる裏で "Adding a new port" を見ながら作業。いくつかは commit されていたり。どーもです。
htdocs まわりもサクッと作ってがしがし commit。残りは誰かやってくれるの期待。
と、予想通り「announce@netbsd.org に案内流してね」 mail が届く。ま、 snapshot できた後でいいよな。
さ、これで区切りつけたらこのページもそろそろ最終回にしよ。

19991209

えいや、と cvs add して commit。がしがし。
が、なぜか local で練習した時と挙動が違ったりしてややあせる。
それでも特に大きなハマりなく済んだ模様。
なんか抜けてたら mail 飛んでくるだろうから後は様子見か……。

19991208

ふと stand/common/romcalls.S 中にバグ発見。 m68k assembler 知らないのがバレバレですな。
add or import 問題ははっきりとした結論出ず。 add で地道にやるのがいいのかなあ。
が、今日はなんか network 不調。上位の nameserver への ping が 5000ms とか言われてる。
途中で切れたりすると憂鬱だし、今日はやめとくか。
どうせだから htdocs/Ports/news68k/index.html とか先に書いとこうかな……。

19991207

cvs checkout したり cvs import の練習したり。 import でいくか add でいくか……。
news68k も最終確認。 CL* まわりだけ修正。各 m68k arch の vmparam.h に CLSIZE が残ってるけど……。
特に動作は問題なさそう。あとは copyright の記述をちょっと直したり。
さ、これでだいたい準備 OK か?

19991206

いきなり annouce に流れてしまいました。
で、早速おめでとうメールも頂いたり。どうもありがとうございます。

頓挫とか言ってる場合ではなくなったので、先輩 developer 方にいろいろ教わりながら準備を進める。
なんとか今週末には commit できるかな。とか言ってると HDD 交換しに行くの忘れそうだ。

19991205

repository 作成その他各種作業のため、ようやく 20G の HDD の取り付け作業を始める。
……が、なんと初期不良なのか全然まともに動かん。だーっ。
いろいろ試すが、ヘッドがかこんかこん音たてるばかりで全然ダメ。
保証っていつまでだっけ? って、それよりレシート残ってるのか?
部屋内大捜索の末ようやく発見。買ったのは 19991113 で 1か月初期不良交換。って来週までかい。
というわけで作戦第2段階はいきなり頓挫。うー。

作業準備してなにも進まずやめるのもなんなので、 i386 の 2G SCSI を sun3 に移す作業だけする。
i386 と sun3 とそれぞれ中身をちょいちょいと移す。うーん、結構無駄に空いてたんだな。
sun3 では installboot を忘れたりしたが適当に netboot して復旧したりで無事完了。
結局 news68k 作業は何もできず。ま、 current の CL* 定義削除が終わったあたりで先に update するか。

19991204

外出先から戻ったら進行中の作戦の第1段階がいきなり完了してしまっている。う、まだ心の準備が……。
一応問題はなさそう。なんだけど、なにから調べていけばいいのかすらよくわかってなかったり。
しかたがないので Developer Documentation とか読む。
が、眠過ぎてダメ。寝て起きてからまた出直しだな……。

19991203

粋な計らいその2により NWS-1460 が部屋にやってくる。どうもありがとうございます。 _o_
いったいそれで何台目なんだよ、というツッコミは勘弁願います ;-p
ただ HUB の空き port がなくなってしまったのは事実だ(自爆)。

とりあえず動かしてみると例によって NVRAM の電池が死んでいる。ま、これはお約束。
ディスプレーのコネクタは PC と同じ D-sub 3列の 15pin だったのでつないでみるとあっさりと映る。
これで framebuffer support も作業できる環境になったわけだ。いつできるかはわかりませんが。

まずもとから入っている NEWS-OS を起動してみる。
と、 "Enable Internal Inst/Data Cache (with burst)" なんて出てくるではないか。
ちなみに NWS-1750 の NEWS-OS 起動時には "(with burst)" は出てこない。
なのでもとから news1700 は burst 転送をサポートしてないってことなのか。やられた。

ま、それはおいといて別のディスクをつなげて boot floppy と sysinst の動作を確認してみる。
……。おおむねよさそうだが問題点もちらほら。
installboot を /dev/rsd?a に対して行うと boot00 を書く時 Read only filesystem だと怒られる。
/dev/rsd?c に対してだと OK なんだけどなにがいけないんだろ。 LABELSECTOR だからか?

次に、これは MI の問題だが、 *.tgz の展開に一つでも失敗していると途中で作業をやめてしまうこと。
しかも失敗した旨の sysinst/util.c の msg_display(failure_msg) が結構わかりにくい。
最低限必要な kern, base, etc の展開に成功してれば次に進んでもいいような気がする。どうでしょ。
Xserver はないんだから選択肢からなくさないといけないけど、どう直せばいいんだろ。
あと、 console を fb にして NetBSD を起動してみるとダンマリになってしまう。
consinit() で #if NFB > 0 でなければ強制的にシリアルコンソールにすべきかな。直しとこ。

てな具合に一通り確認できたので、中身を取り出してメモリを増設する。
問題の NVRAM はちゃんとソケット使ってあったが対策は後回し。

その件に関しては、現在進行中の作戦につきお答えできません。とか。
prep, news5000 方面に関してはまだなのかな。

19991202

make の変数に MKOBJDIR というのが追加されたらしい。
いつも make obj してる身としては便利になるのかな。どうなんだろ。

ちなみに現在の source のディレクトリはこんな感じ。

% ls -Flag
total 15
drwxr-xr-x   3 tsutsui  wheel   512 Nov 20 22:37 ./
drwxr-xr-x  35 tsutsui  wheel  1024 Sep 12 04:31 ../
drwxr-xr-x   2 tsutsui  wheel   512 Sep 12 04:31 CVS/
-rw-r--r--   1 tsutsui  wheel   142 Sep 12 00:29 Makefile
-rw-r--r--   1 tsutsui  wheel  3982 Sep 12 00:29 cat.1
-rw-r--r--   1 tsutsui  wheel  6345 Sep 12 00:29 cat.c
lrwxr-xr-x   1 root     wheel    22 Nov 20 11:36 obj.alpha@ -> /usr/obj.alpha/bin/cat
lrwxr-xr-x   1 root     wheel    22 Nov 20 09:53 obj.arm32@ -> /usr/obj.arm32/bin/cat
lrwxr-xr-x   1 root     wheel    21 Nov 20 11:26 obj.i386@ -> /usr/obj.i386/bin/cat
lrwxr-xr-x   1 root     wheel    23 Nov 20 11:25 obj.macppc@ -> /usr/obj.macppc/bin/cat
lrwxr-xr-x   1 tsutsui  wheel    24 Nov 20 22:37 obj.news68k@ -> /usr/obj.news68k/bin/cat
lrwxr-xr-x   1 root     wheel    25 Nov 20 21:54 obj.newsmips@ -> /usr/obj.newsmips/bin/cat
lrwxr-xr-x   1 root     wheel    22 Nov 20 21:52 obj.sparc@ -> /usr/obj.sparc/bin/cat
lrwxr-xr-x   1 root     wheel    21 Nov 20 11:42 obj.sun3@ -> /usr/obj.sun3/bin/cat
%

うーむ。我ながらいつの間にかすごいことになってるな。
なお、 OBJMACHINE, USR_OBJMACHINE とも yes 設定。

news68k snapshot は昨日の更新直後に無事完成。といっても中身までは確かめてないけど。
しかしこれって需要あるのかな。どっかに置いてもらったほうがいいのかしら。
お、ふと見ると ftp.jp.netbsd.org の中身が一部おかしかったのが直ってる。
現状の source だと tlp がうまく動かないし、そろそろまた update するかな。

19991201

うーむ。 12月か。年内にはなんとかなるのかしら。
1.4.2 とか 1.5 とかのスケジュールってどうなってるんだろ。

news68k make snapshot は現在 "making man.tgz" 実行中。なのでもうすぐかな。
MD な Makefile は全然いじってないのに、そういうものなのね。感心感心。
さすがに 25MHz with L2cache の威力か sun3 よりはそれなりに速い。あくまでも比較級でだけど。

うーむ、なんとも素早いですね。やっぱり次は mips なマシンかな? 次とか言い出すにはまだ早いが。
とりあえずは news68k の fd.c と fb まわりか。 wscons の作りもちゃんと調べないと……

19991130

news68k は現在 make snapshot 中。 UPDATE=yes 設定なので 3日はかからないかな。
sun3 でも make build 耐久中だったが 75時間経過時点で "panic: bad dir" で死亡。
"sd0(esp0:0:0): cannot allocate scsipi xs" が根源みたいだけど、 memory pool まわりが変なのか?
sun3x pmap の問題なのか MI な問題なのか……。しかし sun3 make build 全然完走できんな。

NEWS の port address ですが、 NEWS-OS の /sys/news/adrsmap.h に書いてあったりしませんか?
news68k ではいろいろ disassemble した後に発見して結構ショックでした。 (←前方参照リンクにつき注意)
一部デバイスは /sys/newshbdev/*.h にもありましたが apbus だとどうなんでしょ。
えーと、 /sys/{newsapbus,newsaps} か。うーん、そのものずばりはないのか。

そういや NEWS-OS の reverse engineering に対する制限ってどうなんだろ。全然気にしてなかったけど。
他の port を見ると hp300/locore.s には "do not ask me, this is how hpux does it" ってあったり。
sun3/dev/fd.c には "This code was reverse engineered from the SPARC bsd_fdintr.s" とか。

19991129

ふぬけてた反動で今度は本業はまりモード復活。うつうつ。
まあ news68k もひと段落ついてるからいいんだけど。あとは待つだけだし。

あ、 cross-mipseb パッチちゃんと動いてますか。よかったよかった。
内山さんの boot message log ですが、 endian が逆になってるときの表示とおんなじ感じですね。
mipseb のパッチですが、本来なら mipsel と共存できるように書くべきところを手抜きしてます。
そもそも gnu/usr.bin/egcs にも mipseb 対応はまだ入ってなかったりします。
cross compiler 作成時にもうまく動くようにするにはどう書けばいいんでしょ。

19991128

だんだん細かいネタにも飽きてきた感じ。とりあえず sysinst 動かしてみたり。
……。 disklabel 書く手前までは一応動いてるみたいだけど binary ないからこれ以上確認できんな。
あとは各 source から不要な include 取り除いたりと地味作業。
fd.c も少しだけ書き始めるが、いいかげんいじるのめんどくさくなっで途中でやめ。

のなかさん内山さんと各所で新たな R4x00 NEWS ユーザーが始動。
いきなり current 化もされてたりしてて、これで NetBSD/news5000 の開発もはずみがつくかな?
newsmips 用クロスコンパイラは cross-mipseb-netbsd のパッチも試してみて欲しいですー。

自分でもちょっとだけ news5000 のソースながめてみる。
が、すでに頭がすっかり m68k になっててわけわかんなかったり。 ;-)
newsmips だと zs.c は software interrupt 使ってないんですねえ、とか。
zs_init_reg[2] って 0 でいいんでしょうか。 4.4BSD/news3400 の scc.c だとなんか書いてるような……。
mips や apbus の割り込みを全然わかってないのでアレですが。 mvme68k の pcc みたいなもんかな。

19991127

今日もちまちまと細かいネタ。
中途半端に放ってあった parity まわりをちゃんと書き直す。 ipl 7 の vectored でいいんだよな。
ついでに割り込みまわりの control register address も変数参照に直して news68k_init() で初期化。
address 即値を使うのがほぼ attach 時だけになったので、再度 IIOV() で address 指定するようにする。
将来的には tt0 は使わないようにしたほうがいいんだろうな。

ちょっと port-macppc でツッコミが入ったので久しぶりに macppc/dev/ofb.c まわりをいじってみる。
とりあえずテキトーに macppc/dev/ofb.c と macppc/pci/ofb_pci.c に分割。
make は通ったけど、 ofb_pci なマシンがないからちゃんとできてるのかどうかわからんな。
んで適当にいじって macppc/dev/ofb_mainbus.c とか書いてみる。
が、 X 起動すると frame buffer memory が map できんと怒られる。
うーむ。 framebuffer の PA が違うのか? それとも attach 時にもっとなにかしないといけないのか。
OF 上で freme-buffer-adr . しても 0 とかぬかすし。わからん。やめ。

19991126

昨日に引き続いて cosmetic 作業。懸案の news68k/dev/si.c から。
bus_space(9) 導入する気力はやはり出ないので sun3/dev/si.c の真似して struct dma_regs とか定義する。
struct si_softc の中に "volatile struct dma_regs *sc_regs;" の member 追加。
んで si_attach() で "sc->sc_regs =(void *)DMAC_BASE;" とかして DMAC の address 設定。
si_dma_start() 等の DMAC access は "dmac->ctl = DC_CTL_RST;" とかに置き換え。

同じように news68k/dev/clock_hb.c も書き換え。
制御 port address を attach 時に変数に set して、割り込みルーチン内ではその変数を使うようにする。
news68k/dev/zs.c の zs_cn{get,put}c() も即値やめて zs_conschan を zscninit() で set するようにする。
こんなもんか? これで即値を使うのが probe/attach 部分だけになったから少しはましかな。
まだ news68k/news68k/machdep.c の中にもいくつか即値 address 指定残ってるけど。

次は fdc かな、ということでいろいろながめてみる。
x68k/dev/fd.c は NEC uPD72065 で DMA 使用。
sun3/dev/fd.c は INTEL i82072 で pseudo-DMA 使用。
news68k は NEC uPD72067 で pseudo-DMA 使用。ちなみに 72067 は 72065 の VFO 内蔵版。
なので x68k のと sun3 のを足して 2で割って何かを掛ければ news68k/dev/fd.c も書けるか?
pseudo-DMA の仕組みがよくわからんが、 "pseudo DMA port" ってので DATA やりとりするのか?

……と、 pkgsrc mozilla の make しなおしてた news68k が panic してる。
"panic: lockmgr: no context" とか言ってるが、原因が MI なのか MD なのかよくわからん……。

19991125

おとなしく寝たせいか、風邪の症状はそれなりにおさまった模様。
なので news68k もちょっとだけ cosmetic 作業。

気になってる intr.h まわりをちょっと見直し。
m68k/include/psl.h を見たら "#define splraise4 splraise(PSL_S|PSL_IPL4)" とか定義してある。うが。
うーむ。 hp300 が splraise?() 使ってないのは単に ipl が固定じゃないからなのね。
あとは softint 関係で変更し忘れてた splx() を "#define splx(s) _spl(s)" に直したり。
しかし arch によって spl*() の定義が intr.h や param.h や psl.h だったりするのはなんとかならんのか。

x68k/dev/zs.c:zshard() の splhigh() ってどれくらい意味があるのかしら。
news68k/dev/zs.c の zssoftpending は alloc_sir() 使うならいらないような気がするなあ。取っちゃえ。
zssoft() の中で spltty() してるけどこれだと splraise5() だから softint の意味があるのかないのか……

si.c の DMAC の address 指定も書き直したいなあ。
どう書くのが一番いいんだろ。 bus_space(9) は大変だから si_softc にアドレス member 追加するか。
でも news1200 は CXD1185 だし sun3x みたいに dmac を別に attach したほうがいいのか?
と、餅の絵かいててもしょうがないけど。どうしたもんでしょ。
parity error 設定とか interrupt status とかの port も device として attach したほうがいいのかしら。

19991124

ふぬけ続けてたせいかどうも風邪をひいてしまったらしい。うぅ頭痛が……。
などと頭おさえつつも、大明神様と相談しながら英作文したり。
news68k の make build も無事終わったようだし、なかなか順調かな。
というわけで今日は薬飲んでとっとと寝ます。おやすみなさーい。

19991123

相変わらずふぬけ中および news68k make build 中につき進展なし。
というわけで久しぶりに日記モード。

swap を disk の先頭に取ってよいかですが、昔やった時は問題なかったような。
たしか 386BSD の FAQ に問題点として載っていて、 NetBSD-1.0 以前で対処されたとかなんとか。
んで /sys/uvm/uvm_swap.c:swap_on() を見ると、先頭 PAGE_SIZE 分だけ使わないようになってますね。
先頭の system 使用領域サイズがマシン依存だとすると machine/disklabel.h になにか定義追加が必要か。
ということであとは tech-kern で議論ですか?
って、 newsmips と news68k でも primary boot の size は disklabel 込みで8kbyte までいいんだっけ。
8kbyte ってのは MI で共通の暗黙指定事項なのかしらん。

www.netbsd.org の index ページスタイルが変更されたようだ。
でも、うちの Netscape 3.04 だと右側の Platforms の表示が変なんですけど……。 font の設定の問題?
ま、 lynx で結構ちゃんとした表示になるのはいいことかな。

ふと sun3 をチェックすると make build 止まってる。
場所は sun3/stand/netboot の下。んー? port-sun3/8471 ではダメなのか?
あれ? 消されたはずの inet_addr.c とか intoa.c とかなんで /sys/lib/libsa/ 以下に残ってるんだ?
調べてみると ftp.netbsd.org では消えているが ftp.jp.netbsd.org では残ってる。
sup の設定が out of sync になってるってやつだろうか。 admin-ja とかに振ればいいのかしら。

19991122

今日もなんだか一日ふぬけ状態。「動いてしまった後どうするか症候群」ってわけじゃないけど……。
なんとなく ARM プロセッサの本を買ってきてながめてみたり。
うーん。始めの章を読んで大学の時はこんな話をやってたなあ、なんて懐かしがったり。

そろそろ snapshot かな、ということで distrib/sets/lists に news68k 用記述書いてみたり。
ついでに distrib/utils/sysinst もながめる。特に news68k specific なとこはないのかな。
ちなみに現在 news68k でも make build 中だが、特に落ちたりはしてないようだ。

ついでに news68k TODO list を見直し。
sun3/include/psl.h とか見ると news68k/include/intr.h ももう少し直した方がいいような。
zs は ipl 5 なんだけど、その場合 spltty() も ipl 5 にすべきなの? kb, ms も ipl 5 なんだけど。
spltty() と splserial() ってどう違うの? そもそも splserial() って MI で使われてるの?
spl(9) の man 見てもいまいちよくわからん。

news68k_calbrate_delay() って書いた方がいいのかしら。
L2 cache があると clock から決めうちはできないかなと思ったんだけど。
でも sun3/sun3/locore2.c とか見ると VAC の sun3/260 も clock で決めうちしてるみたいなんだよな。
そもそも news68k のタイマは特に何も出力してないようなので計りようがないという話もあるが。

CXD1180 対策は……。 MI をいじるのは面倒なのでとりあえず保留。
floppy は uPD72067 のデータシートは入手済みだし、そもそも uPD765 の上位互換のはず。
なので DMA まわりさえわかれば何とかなるだろう。それがわからんのだけど。
fd の DMA が SCSI と同じでいいらしい newsmips からやったほうがいいかも。

fb/kbd/ms はまともな framebuffer 入手してからかな。
全部 newsmips から持ってくるか、それとも最初から wscons 目指すかという選択肢はあるけど……。
COMPAT_NEWSOS はいまだに emulation の構造がよくわかってなかったりする。
4.4BSD には newsos/syscalls.master はあるけどほとんどそれだけ。
source 以外にどっかいい資料ありません? 悪魔本には載ってないのかな。

19991121

朝までに気力使い果たしたため今日は一日怠惰に過ごす。
なので news68k ネタも binary 作成と表のページ更新だけ。
しかしだんだんやる気の出るネタがなくなっていくな。いいんだか悪いんだか。

tar でまとめる前にちょっとだけ source を見直す。
ん? もとの mvme68k だと ssir が char なのに NSIR が 32 だったり zs_sir が u_long だったり。
まあ send-pr するほどでもないか。 news68k では ssir を machdep.c 内で u_long で宣言しておく。
NSIR のほうはなんとなく sizeof(sir) * 8 とする。 softint って他にはどれくらい使うのかな。
そういや AST も lev1intr 使って処理できるみたいなんだけど、どうやればいいんだろ。

19991120

いつものように各マシンで update した source をがしがしコンパイル。
が、 ftp.jp.netbsd.org の更新途中に sup してしまったのかなんか source tree の中身が変。
まるごと update しなおすのは面倒なので 1.4P の本質の RTM_IFINFO まわりだけ手で更新する。

kernel に関しては options SOFTDEP 含めて各マシンとも問題なさそう。
sun3 だけは pmap.c で引っかかったので port-sun3/8830 として報告。
news68k の更新必要箇所も大したことなくて pmap_enter() と trace trap まわり修正のみ。約10分で完了。
動作も特に問題ない模様。userland がまだで tunefs(8) してないので SOFTDEP の効用はよくわからず。

なんかあっさり終わったので一気に software interrupt まわりも書き直す。
が、 softint の意味をまだちゃんと理解してなかったりするので、大昔に調べた資料にもう一度目を通す。
要は割り込み処理のうち緊急度の低い部分は priority level が下がるまで後回しにする、ってことだよな。

news68k の現状の softint 処理は mvme68k から持ってきている。
softint で処理する関数を登録するには allocate_sir() を呼ぶ。
で、そこで割り当てられた bit を kernel 変数 ssir にセットすることで、実際に処理が行われる。
default では setsoftnet() と setsoftclock() が登録されており、 sir_init() で初期化されている。
また、 zs.c で setsoftserial() 相当を使うため後から登録している。

mvme68k の softint emulation では ssir は locore.s の trap0(), rei(), spl0() でチェックされる。
trap0() は syscall。 rei() は各種割り込みから return する時に呼ばれる。 spl0() は全割り込み許可。
要はこれらのタイミングで softint 要求チェックして、必要なら T_SSIR trap 起こして処理をしてる。

これに対し sun3 は software interrupt register を持っていて上記のような emulation はしていない。
softint 処理が必要な場合は該当する softint register の bit をセットする。
そうすると level1〜3 の低優先度割り込みが発生し、そのハンドラ内で必要な処理に dispatch される。

具体的には sun3/sun3/intreg.c 内の関数で処理している。
level 1 は soft1intr() で処理内容は固定されていて netintr() と softclock() を処理する。
level 2,3 は汎用で普通の autovectored な割り込みとして登録する。 sun3/dev/zs.c の zsattach() 参照。

news68k では sun3 ほど高度な機能はなくて、単に level 2 の割り込みを発生させられるだけ。らしい。
単純に isrdispatch_autovec() 使うと netintr() と softclock() とが無条件で呼ばれてしまう。
というわけで sun3 と mvme68k を折衷した実装にしてみる。
softint の登録は mvme68k と同じく allocate_sir() で行う。
softint 要求は ssir の bit をセットした上で CTRL_INT2 をたたいて level 2 割り込みを発生させる。
lev2intr() のハンドラでは ssir を見て各処理に dispatch する。

という案でいいのかどうかよくわかんないが、とにかく書いてみる。
locore.s 中の sir チェック部分をすべて削除。 spl0() は intr.h で _spl0() に define する。
machdep.c に lev2intr() を書いて、現状 trap.c にある dispatcher をそのまま移す。 T_SSIR 部分は削除。
そうなると allocate_sir() と init_sir() だけ trap.c に残るのも変なので machdep.c に移す。
んで vector.s の level 2 interrupt のところに lev2intr() を登録。ざっとこんなもんか?
machdep.c に詰め込むより、割り込み関連で別の file 作ったほうがいいような気もするけどどうだろ。

これまた結構あっさり書けたので早速 make する。特に大きな問題もなくできあがる。で、起動。
……。うーむ。特に変わったところなく立ち上がったけど、ちゃんと動いてるのかしら。
dhrystone とか動かしてみるが特に有意な差は感じられず。そんなもんか?
と、 mozilla を動かしたら "panic: m_copydata" で落ちた。これは /sys/kern/uipc_mbuf.c の中。
こういう MI で落ちるのはまた spl まわりだろうということでチェック。
と、 softint が level 2 になったのに splsoft*() が splraise1() のまま。ということで直す。
……。今度は落ちることなくちゃんと動いてる模様。いまいち確信ないけど。

うー。途中で少し寝ちゃったとは言えもう朝だよ。ふあぁ。
boot floppy 作るには libc まわりも全部作り直さないといけないし、表のページ更新は今晩だな……。

19991119

つばいさんから再度動作レポートを頂く。毎度ありがとうございます。
19991118 の kernel だと以前より 2%ほど遅くなっているようだとのこと。
ただし burst enable の関係か si.c の cache flush のせいかは未確認。

試しに news1700 で si_dma_stop() の PCIA() をはずして動かしてみる。
……。起動までは問題なく動いたが、 kernel make とかしたら Illegal instruction でぼこぼこ落ちる。
というわけでやはり DMA の read 後の L2 cache flush は必須らしい。
しかし、そもそも PCIA() で L1 data cache を flush してるのはなんか変な気がする。
なので DC_CLEAR のコードはずして試してみる。……。特に問題なさそうだけど、どうなんだろ。

ま、なんとなく動いてるので cache はほっといて、おもむろに current source update を始めてしまう。
と、始めたそばから 1.4P に進んでるじゃん。
しかも /sys/conf/osrelease.sh だけ今日の CVS update に間に合ってないし。おいおい。
うー。 update しなおすのもアホらしいから osrelease.sh だけ手で直して気にせず作業続けるか……。

update しながら MD の変更必要箇所をちょっとだけながめてみる。
pmap_enter() の変更は特に大したことなさそう。 SOFTDEP も config まわりだけだし、問題ないな。
update が終わったら次は softintr まわり書き直ししよ。性能的にどう変わるのかよくわかんないけど。

19991118

www.netbsd.org にいつの間にか suggested port なんて項目が作られてる。
おぉ、そういや luna88k なんてのもあったな。実物見たことないけど。
luna68k は載ってないみたいだけど、今はどんな状況なんだろ。
う、いろいろ話題になってたらしい AS/400 も載ってるよ。動いたらいろんな意味で面白いかも。 ;-p

なんとなく IPv6 な kernel を作って試してみる。結構サイズ増えるな。
ん、なんか le0 の表示が変だぞ。と思ったら current ではもう直ってるらしい。
おー、 IPv4 の address を ifconfig すると IPv6 の address も勝手に付けてくれるのか。
それなりに立ち上がったので他のマシンも options INET6 つけてがしがし kernel 作り直す。
んで ping6 したり tcp6 な telnet したり。うーん、あまりにもあっさりと動くな。
というわけで source まとめたり GENERIC.v6 な kernel 作ったりして表のページ更新。

さ、大明神様からも忙しい中急かされたことだし、意を決してメール書くか。

19991117

朝起きて昨晩の結果確認。

10268.985u 1363.217s 3:19:23.42 97.2%   0+0k 3472+7162io 1572pf+0w

ぐは、全然変わってないよ。どうなってんだ。昨日の仮定は間違いか?
と悩んでても仕方ないので、ちゃんとした比較のため昔の PG_CI な kernel 上で kernel make 仕掛けて出社。

んで、帰宅。結果を見ると……

14593.759u 1653.266s 4:37:04.98 97.7%   0+0k 3506+7296io 1577pf+0w

おお、実はちゃんと 28%高速化(当社比)達成してたんじゃん。
いやー、 benchmark はきっちり条件そろえてやんないとダメですね。
しかし電源投入一発目だけ動く、ってのはなんだったんだ。温まるとダメとかそういうことか?
あと、 DC_BE, IC_BE はずすことで L2 cache なしマシンでは性能に影響あるのかしら。

ちなみに i386 上の cross make で計測すると

251.227u 58.573s 6:45.62 76.3%  0+0k 1138+4521io 1680pf+0w

速い分 NFS 待ち時間の影響が大きくなってるが、一応 100倍は違わないらしい。はは。

ついでに意味もなく arm32 上の cross make でも計測。

1024.638u 239.307s 22:09.63 95.0%       0+0k 6628+7849io 2705pf+0w

うーん。こんなもんといえばこんなもんなのかな? もうちょっと速いかと思ったんだけど。
macppc でも計測してみようとしたけど、 vr0 絶不調のため挫折。

というわけでついに "merge into the NetBSD.org source tree" が TODO list の先頭に来たわけだが……。
そろそろ腹を決めて行動開始するか。あ、でも日曜まで曽田さん帰ってこないな。
まあ、その前に機会見てとっとと 1.4O にしないと。それからだな。

19991116

current にお次は soft update まで merge されてしまった。しかし 1.4O ってなんか間抜け。
ますます sup するタイミングを失っていくな。まあ今回はあんまり MD には関係ないけど。
こうなったら Sound Blaster Live! の support が入るまで気長に待ってやろうか。

今日もなんとなく L2 cache まわり調査。ついに禁断の pmap.c に手を入れてみたり。
昨日の copyseg() と clearseg() はなんとなく pmap_copy_page() と pmap_zero_page() とおんなじ感じ。
なので双方で PG_CI マークしてみる。……が、特に変わらず。
DMA のせいかとも思って si.c の si_dma_stop() に cache flush のコード入れるが変化なし。
ま、昔 CACHE_HAVE_VAC 定義しても変わんなかったので、今回これだけで直るはずはないんだけど。

copyseg() の中にはほかに %cacr の DC_BE をクリアしてるところがある。
DC_BE は burst transfer を制御するものらしいが、どの辺まで影響するんかいな。
ひさしぶりに 68030 のマニュアル眺めたり。……もしかしてこれ外部 cache 回路にとって結構重要?

CACHE_CLR とかは m68k/include/cpu.h で定義されてるが、これって実は MD にあるべきなのかしらん。
news68k/include/cpu.h で一度 #undef して、 DC_BE はずして define しなおす。
んで起動。……が、特に変わらず。むむむ。
今度はえいやと IC_BE もはずしてみる。でい。
……おっ。なんか調子よく立ち上がってるぞ。おぉ、 login: まで出てきたよ。

不安と期待とともに dhrystone を動かしてみる。どきどき。えい。

Microseconds for one run through Dhrystone:  127.6
Dhrystones per Second:                      7837.0

おお〜〜、ちゃんと PG_CI のときより速くなってるよ。しかもなぜか前試したときよりも速いし。
load test も兼ねて kernel make もしてみる。わくわく。
……が、どっちにしても遅いことには変わらんな。落ちることはないみたいだけど。
しばらくほっといてゲーム始めてしまったり。……お、やっと終わった。
```
10289.845u 1354.085s 3:20:01.12 97.0%   0+0k 3477+7111io 1590pf+0w
```
う。つばいさんからの PWS-1560 のレポートと比べると全然速くないぞ。なぜだー。
って、さっき pmap_zero_page() と pmap_copy_page() で PG_CI つけるようにしたせいか。
というわけで pmap.c を元に戻して再度挑戦。といっても結果出るのあしたの朝だなこりゃ。寝よ。

19991115

少しだけ NEWS-OS 調査。 %cacr 関連を探る。
……。なんか copyseg() と clearseg() が謎な感じ。
CMAP1 と CMAP2 って PTE のどこか特定の場所か? あ、 CADDR1 と CADDR2 の VA を指してる PTE か。
PG_CI で map してそこに copy やら zero clear やらしてるけどなんなんだ。

NetBSD だと arch/m68k/m68k/copypage.s にある copypage() と zeropage() とがこれに対応してるのか?
あ、でも書き込まれる側のアドレスは PA だよなあ。なんなんだろ。

copyseg() を呼ぶのは vmdup() だけか。
clearseg() は mclear() と page_clear() と startup() から呼ばれてる。
うーむ。怪しいと言えば怪しいんだけど、逆アセンブルだけではなんともならんな。
でも、少なくともある特定の条件では書き込み時 PG_CI しないといけない場合があるってことか。

19991114

今度は libkern 使わず libsa だけで済ませよう計画中止らしい。
うーん。なんか current がバタバタしてるな。いつごろ落ち着くんだろ。
結局 sup するタイミングを失ったまま今日も一日過ぎてゆく。

気負ってた分なにもしないのもなんなのでちょっとだけ細かいネタを試す。
まずは news68k/stand/ 以下をちょこっと修正。まず boot の BSS clear を stand/boot/locore.S に移す。
次に "objcopy -O elf32-m68k" で ELF な kernel を作って boot するか試してみる。
と、現状の boot loader でなんの問題もなく起動。うーむ。こういうところはさすが NetBSD って感じだ。
ただ、現状 LOAD_HDR を off にしてるせいで ELF だと symbol table のアドレスがちゃんと設定されない。
off にしてるのは a.out だと entry よりも前に header を読もうとするので entry が 0 の時おかしくなるから。
でもやっぱり aout_exec() でアドレスチェックをするべきという気もするなあ。どうなんだろ。

次に L2 cache 有無判別方法について考える。
boot loader から渡された boot filename のポインタである d5 で判別するコードを書いてみる。
が、 boot filename を指定しないと /boot の中で "netbsd" に置き換えているのでうまくいかん。むぅ。
よくよく考えると boot loader から渡された情報で機種判別するというのは反則なような気もしてきた。
どうせ news700 対応とか遠い先の話だから IDROM のアドレス決め打ちしてチェックした方がいいのかしら。
でも、回避策に労力をかけるよりは本質の問題を解決したいなあ。

19991113

ドライブも兼ねておもむろに日本橋まで HDD その他買い出し。
途中事故渋滞にハマるが 11時には到着。なんとかパーキングチケットスペース確保。
時間制限があるので急いで見て回る。

Ultra-ATA HDD は 13G の予定が思わず 20G の IBM DJNA352030 17,000円を買ってしまう。
しかしこれって今年の春に 6.4G 買った時と同じ値段じゃないか。うーむ。
ついついほかにいくつかゲームも買ってしまう。あぁまた新たな障壁が……。

買うもの買ったのでとっとと帰宅。
20G HDD は server の arm32 に取り付ける予定。
で、そこで余った ATA 4.3G を i386 にまわして、さらにそこで余った SCSI 2G を sun3 にまわす計画。
なんだけど、作業めんどくさ過ぎ。 i386 は Windows の中身も移さないといけないし……。

とりあえず HDD 交換作業は後回しにして source tree の current catch up 作業を始めることにする。
が、その途端 current-users に "pmap_enter() API change" なんてメールが。ガビーン。一気に萎える。
というわけでやる気なくして買ってきたゲーム始めて今日は終わってしまう。

1.4N はいいけど、そんな面倒なところ変えてくれなくてもいいのに。
え? とっとと merge しとかないからだって?

19991112

なにやら 3日前の激論の余波がいろんなところに広がってるらしい。
ま、それはほっといて、ようやく本業のヤマ二つ目完了。あと二つだ。また増えるかもしれないけど。

また海外から news68k 問い合わせメール。今度は NWS-841 が 2台あるんだけど……ということだそうだ。
"I was very excited to hear about your news68k port" とまで書いてもらって申し訳ないんだけど、 MMU と IOP という Wish List にすら載せてない事情説明の返事を書く。
しかし海外からの方が問い合わせが多いってのもアレだが、なんで IOP マシンばっかりなんだ?
一体 NEWS ってどのマシンがどれくらい出たんでしょ。

libkern 使わず libsa だけで済ませよう計画進行中らしい。
うーむ。わざわざ libsa から libkern に移った関数があるのに、方針変更なのか?
そもそも現在 libkern をどれくらい参照してるのか把握してないけど。
tlp driver の 21143 support も入ったことだし、早いとこ current 最新化しないといけないな。

19991111

昨日の逃亡の報いじゃないけど、今日の帰宅は午前様。
なのでちょっとだけ。

x68k 方面で早速 ELF 化のお手本が。
そうか、 ELF の場合は start じゃなくて _start なのか。
この定義も asm.h の中に入れちゃいたい気がしますけど、どうでしょ。

なんとなく久しぶりに vmunix を逆アセンブル。
……。うーん。 mach_init() でなんかよくわかんないことしてるな。
framebuffer の検出以外になにかやってるのか? あ、なんだ le のメモリの初期化か。
やっぱり謎は locore.o の中なのか? それとも boot loader の中なのか?

19991110

エネルギー切れのため定時で脱走。ぼーっと充電。
なので日記モードすらお休み。

なんとなく召喚なメッセージを書いてみたら期待通りのご神託があったり。
いや、ほんとに mbuf(9) とか DMA 前の memory copy の影響ってどんなもんなのか気になってたんですよ。
network まわりのコードも一度ちゃんと読んで勉強しないといけないなあ。

ちょっとだけ news68k メモ。
つばいさんの報告によると options CACHE_INHIBIT はずすと L2 cache 無マシンで 20%弱速くなるらしい。
sun3/80 との差を見るとちょうどそんなものなのか?
さらに si.c では DMA 後の cache flush をしてなかったりする(ぉぃ)がなぜか動いているらしい。
locore.s で EC_PHYS と EC_NONE の判定して区別した方がよさそうなんだけど……。
自分の NWS-1750 では意味なしなのでいまいちやる気が出ないんだよなあ。すいません。

と、引法にも筆の誤りならぬ大明神にも計算間違いらしい。
とは言っても、速攻の自己フォロー内容はさすがですね。

19991109

なぜか本業のヤマと関係ないところで激論。あー疲れた。ぐったり。
というわけで日記モード。とか続けてると段落アンカー需要がますます増えてしまうのかしら。
あくまでも日記モードは本意ではないので勘弁して下さい。 ;-p

で、 GENERIC の件ですが、 UMAPFS はほとんどの arch でついてたりするんですよねえ。
一方 CODA はそもそも記述がないのがあったり。適当に他の arch の真似で済ますか?
COMPAT_NEWSOS は Wish List から TODO に移してもいいかなあ。できるかどうかは別として。
いまだにエミュレーション機構をよく理解してないけど、 news700 よりは実現性ありそうだし。

/boot の件のほうは BSS clear は必須なので結局 symbol 参照問題は残るのです。
あ、よく考えたら news68k/stand/boot/locore.S 中で _C_LABEL() 使って clear のコード書けばいいのか。
改めて確認すると sparc も sun3 も x68k も BSS clear は *.S の中。うーむ、調査が甘いな。

19991108

ヤマ越え中につきほぼ日記モード。

intrcnt を参照するのは vmstat だけなんでしょうか。
なんとなく news68k で vmstat -i する。と、なぜか lev4 と lev5 しか出ない。 clock はどうなってるんだ?
clock_hb.c みたら intrcnt 更新忘れてる。あれ?
ベースの sun3 見るとこっちもしてない。当然表示も出ない。うーむ。というわけで修正。
ついでに intrcnt その他の locore.s 内関数および変数を cpu.h で宣言するようにする。
いろんなマシンで vmstat -i してみると arm32 は softintr もカウントしてたりで結構いいかげん。

結局 hp300 はすべて autovectored だけど x68k はすべて vectored だから現状でいいのかもしれませんね。
news68k は zs だけ vectored でそれ以外は interrupt register で判別するので悩ましいところですが。

GENERIC ですが、 COMPAT_SVR4 とか COMPAT_SUNOS とか UMAPFS とか CODA とか ISO とかいれるべきでしょうか?
filesystem まわりはだいたい入ってるのかな。 OSI とか XNS とかは微妙だなあ。
また、 options GATEWAY は GENERIC で有効にすべきか否か?
BSS clear の話は kernel でなくて boot の BSS なんですが、やっぱり bootxx でも struct exec 解釈すべき?

isa で IST_LEVEL がまずいってことは特にないんじゃないでしょうか。
netbsd-ml の昔の話だと arch/i386/isa/isa_machdep.c には IST_LEVEL が書いてあるそうですし。
ただ sys/dev/isa/wdc_isa.c だと IST_EDGE 固定なんですね。むむむ。
まあ、実際は割り込みとかアドレス空間とかが本当に ISA なのかそうでないのか、という話になりますが。
ISA slot に本物の ISA wdc つけて IST_EDGE でないと動かないか試すとか。

news68k の GENERIC.v6 コンパイルしてたら typo 発覚。
惚けてると NET が無条件に Net に変換されてしまうらしい。

19991107

リクエストを受けたので news68k の GENERIC な kernel を作って表のページからリンク作成。
意味もなく raid とか有効にしてみたり。
しかし GENERIC にはどこまで機能つっこむべきなんだろ。
あ、 GENERIC.v6 も作らないといけないか?

current catch up するには気力が足りないので、レジスタ名の前に % つける変更だけしておく。
gas.new じゃない古いほうの gas もすでに thorpej 氏が変更して対応してるのでこれだけ持ってくる。
がしがし書き換え。結構めんどいなあ。 hp300/locore.s で crp に % 付いてないのは見落とし?

news68k/stand/ 以下もいくつか書き換え。
が、 ELF 化の準備というのなら symbol 名も ENTRY_NOPROFILE() とか使うようにすべきか?
BSS clear の時の edata と end の symbol はどう参照すべき? それよりも bootxx の中で bzero すべき?

19991106

ようやくひとつヤマ越せそう。あとまだ三つくらい越えないといけないけど。
今日は早めに帰ってきたけど、やっぱり眠くてダメ。

気になるというか、 news68k 書き始めたころに読んでなんでかなー、と思ったもので。
intio の導入後は vector 割り込みはすべて intiotrap() に行くからそこで count できるんじゃないかなと。
そもそも m68k をよく知らないのにこんなこと書くのはアレなんですが。
というわけで速さがどうとかは全然わかりませんです。

本日の news68k ネタ。うーん。 /usr/src で make && make install 完走しました。くらい?
snapshot 作るとしたら etc.news68k とかがいるけど、その前に 1.4M にしたほうがいいよなあ。
どっちにしろ作ったところで需要も置く場所もないけど。

19991105

今日も 25時帰宅。本業の憂鬱を遊びで解消するのはそろそろ体力の限界かも。
しかも明日も出勤日。というわけで news68k ネタどころじゃないんだってば。
とか言いながらちょっとだけ日記モード。どってんばってん。

「x68k が level3」って一瞬何の診断かととまどってしまったり。
あー、たしかにそうですねえ。いろいろながめて一番普通そうなのを選んだような。
news68k はどれも基本的に m68k の中で一番 generic そうなものの真似したのです。
なので Sync すべき対象はそれぞれ別にあるんじゃないかと。
あと x68k で気になってるのは intrcnt が level 別じゃなくて vector 別になってるとことか。
それから locore.s に "Prepare to enable MMU" の hp300 用 comment が残ってるとこかな。

って news68k もとても人のこと言えない状態だけど。
pmap_bootstrap.c の lkptpa って hp300 以外で必要?
DMAC access の address は即値使うより si_softc の中に入れちゃうべき?
news68k でも bus_space(9) 用意すると幸せになれるでしょうか?
le も zs も ncr5380sbc も bus_space(9) 不要なんだけど、他に使いそうなデバイスってあったっけ?

19991104

早出したのに帰宅したら日付変わってた。どうでもいいけど眠いぞー。
というわけで手抜きモード。

あ、どうもありがとうございます。まあ動いてしまうとどうということはありませんでしたね。
さすがに今回は虚脱感よりは達成感の方が上回ってましたけど。
news68k も 7月 8月はほとんど止まってました。復活のトリガは NetBSD BoF でしたね。
で、 PIO で SCSI が動き出したのが 19990924 で boot loader が 19991001 ですね。この辺はわりと快調。
でも DMA 調査が 19991006 なのに実際に書き始めたのは 19991025 か。やっぱりさぼってるな。
なんだかんだいっても内蔵ディスクが動くと結構うれしいです。 prep も次は wdc でしょう。

ずっと仕掛けてた sun3 の snapshot がなんとか完成。ぜんぜんチェックしてないけど。
/usr/src/etc.news68k とか distrib/sets/lists の md 分とかもそろそろ作らないといけないな。
あと md で用意しないといけないファイルってなんだっけ?
IPv6 も動かしてみたいけど、 private network 内で簡単にテストする設定方法どこかにないかしら。

Sound Blaster Live! Linux driver が GPL で公開らしい。
別に audio はならなくてもいいから CD-ROM audio 入力とか外部 AUX 入力が使えるとうれしいかも。
news68k がはまりモードに入ったら見てみようかな。

19991103

無意味にムキになって DMA 動いたはいいけど、眠過ぎ。うぅ。
気力をふり絞って出社。遊びばかりでなく本業も少しは目標達成しないとな。

18時すぎにようやく帰宅。へろ。明日も早出なので今日はやや日記モードと表のページ更新だけ。
日本の移植先駆者沖さんからもリンク頂いちゃいました。
過去の NetBSD/x68k な記述を読むと結構ぐっと来るものがあるんですよね〜。
で、 CISC EWS4800 ですが、さすがに m68k 2つ目というのは気合い入らなさそう。
それなりに面白くてかつそれなりに MI 化されてるというと、やっぱり mips とかになっちゃうのかなあ。
それなりに安いとかいうとまた遅マシンになっちゃいそうだけど。

表のページは更新といっても si.c の WAIT 取ったのと INSTALL の config と intr.h 直しただけ。
さりげなく TODO list も更新したり。 L2 cache 問題なんとかならんかな。
さ、本業の今の状態がヤマを越したらそろそろ行動開始してみるか。

19991102

今日も帰宅は 25時過ぎ。さらに明日も休日出勤だったり。
にもかかわらずムキになって news68k DMA 調査。

panic したときの log をじっと眺めて考える。
実際に panic してるのは kern/subr_pool.c の pr_enter() の中。
この関数は options DIAGNOSTIC のときだけ定義されるので、そもそも想定外の動きをしていることになる。
具体的には pr_enter() したあと pr_leave() せずに再び pr_enter() が呼ばれてる。
こういうことになるのは lock がうまくできてないからか、ということで追ってみる。

dev/scsipi/scsipi_base.c の scsipi_get_xs() で pool_get() するときはあらかじめ splbio() にしてる。
なのに panic log 見ると pool_get() の最中に SCSI の lev4intr() がかかってる。そりゃいかんわ。
news68k/include/intr.h 確認。ぐは、 "#define splbio() _splraise(PSL_S|PSL_IPL3)" になってる。
うーむ、なんでそんな風になってるのかもはや全然覚えてないな。とにかく PSL_IPL4 に直す。
spltty() とか splimp() とかもいくつにすればいいのかよくわかんないが 4 のままにしておく。

で、 make。ほとんどがコンパイルし直しだな……。と、できたので起動。
multi user 上でがしがしと tar してみる。 1回。…2回。…3回。……落ちない。って判断していいのか?
うーむ。まさかこんなしょーもないオチだったとは。なんとも情けない。
なんでこう、いまいち感動がそがれるというか、すっきりしないこと多いかな。
ま、いずれにせよ subr_pool.c の DIAGNOSTIC のコードをきっちり書いた pk 氏と thorpej 氏に感謝! ですね。

19991101

うーん、 11月か。もう半年なんだな。早いもんだ。
って帰宅したの 25時ですでに日付変わってるけど。
にもかかわらずいろいろ余計なメール書いてみたり。

ということで今日は昨日のうちに仕込んでおいたネタでごまかす。
dev/scsipi/scsipi_debug.h を見ると SCSIDEBUG を活用するには sc_link.flags を設定すればよいらしい。
ということで si.c で ncr_sc->sc_link.flags にいろいろ設定して load test 仕掛けておいた。
……のだが、あっさり無事に終了してる。いわゆる kernel における不確定性原理というやつか(ぉぃ)。

sun3 で make snapshot というのも仕込んでおいたんだけど、 distrib/sun3/ramdisk で "make: don't know how to make depend" だと。なんだよそりゃ。

19991031

引続き SCSI DMA 調査。が、結局よくわからないまま。
なんだか先が長そうなので、 source の整理も兼ねて表のページを更新することにする。

source はともかく、 panic する kernel のバイナリを置くわけにもいかないのでいろいろいじる。
sun3/dev/si.c の真似して flags で option の数字を渡して DMA, disconnect 等切替えられるようにする。
で、 INSTALL kernel の config では DMA 使わないようにしておく。
ついでに news68/conf 以下のその他のファイルも cosmetic 修正。

さらに news68k/stand/ 以下の修正をもう一度見直す。
machine -> ${S}/arch/${MACHINE}/include の symlink は i386 の真似をすればいいようなので調べる。
CPPFLAGS に -nostdinc 足したり、 Makefile.inc を .include する順番変えたり。
わけわかんなくなりつつも、どうにかうまく動いた。ような気がする。きっと動いてるに違いない……。

で、ファイルまとめて、 floppy image 作って、さくっと作文して表のページ更新。
なんか Boot Message Log が長いな。まあ説得力あっていいか。
m68k 関連の各種修正は次回 current catch up 時に行いますので御了承下さい。ぺこり。

panic の原因がまさか MI にあったりしないよな、とちょっと心配になったので port-vax をのぞいてみる。
しかし相変わらず流量多いな。いったい使ってる人どこにこれだけいるんだか。
……。いろいろ読んでみるが、特に panic するとかはなさそう。
vax でも 1Mbytes/sec とか出るのか。このへんとかこのへんとか感動がよく伝わってきていい感じ。

わかんないので DMA を考えるのはやめて、 CATS 用の新しい Xserver を試す。
問題なく動く。 USB mouse もちゃんと wsmouse protocol で使える。
これで CATS で "opms at pckbc?" を使えるようにするパッチも不要か。いつごろ merge されるんだろ。
ついでにずっと opms を使ってた i386 も wsmouse 使うように直す。
あっさり pmsi0 at pckbc0 で認識されて動いた。でもスクロールボタンって意味なしなのかしら。

19991030

newsmips boot floppy の動作報告頂いたり、 *BSD Diary Links の各方面から参照されてたり。
思ってたよりここを読んでる人多いのか? まあ、今さら気にすることもないけど。

余っている ARC machine があるのならば、すぐにでも大明神様に寄進するべきです。 ;-)
ちゃんと総本山の掲示にもその旨記載されていますし。

isa でも "hoge* at isa?" を使用可能に、というのは別に構わないのです。
どの程度意味があるかどうかは別として、当時 OpenBSD も同じこと売りにしてましたし。
ただ、「pc98 で isa バス」の部分を見てむむむ、と思ったのでした。
今じゃ無意味な仮定だけど、本物の ISA のついた pc98 があったらどうなるんだろうとか。
NetBSD/pc98 を良くしたい、と言われるとやっぱり "Significant divergence" なのかなと感じます。

遅れ馳せながら BSD magazine を引っ張り出して NetBSD/pc98 の arch/i386/Cbus/ の中身を見てみる。
……。う、そういうことになってるのか。 arch/arm32/podulebus/ みたいなのを想像してたんだけど……。
詳しくは見てないけど、これら全部ここにないとダメなのかしら。
まあ、自分が MI なドライバばかり使って楽してるからそう思うんだろうけど。
でも、頑張って MI に書いていろんなところで使ってもらうのもうれしいんじゃないかなあ。
bus_dma(9) みたいに MI な仕様を考えるのは大変だけど、きっと自分自身のためにもなるはず。

まっとうな feedback なら割と技術的議論ができると思います。 flame はあまり見ない。人にもよるけど。
ただ、妥協も許されないから結論が出ないとそこで止まっちゃうんだよなあ。

以上で日記対応モード終わり。以下 news68k モード。
NEWS-OS バイナリを適当に保存して sd1 → sd0 へのファイル移動を試みる。
……が、何度やっても途中で止まってしまう。うぐぅ。
昨日と同じくダンマリになったり panic したり。でもディスクの中身はちゃんとしてる。
おかしくなっても fsck -p ですぐ直るレベル。なので low level の転送はちゃんとされてるんだよなあ。
9割はまともに動いてるのに、こんなんでは公開できないなあ。何が悪いんだ。

いろいろと症状を観察してみると、止まり方は昨日とまったく同じ。
"panic: pr_enter" か tsleep() で割り込み待ちかのどちらか。
うーん。こういう原因と症状との間が遠そうなのは苦手なんだよなあ。
MD 側の si.c でウェイト入れたり splhigh() 入れたりするが特に変わらず。

時間かかりそうなので先に crash dump が採れない件を調べる。
news68k/machdep.c の dumpsys() や cpu_dump() は特に問題なさそう。というか他の m68k とまったく同じ。
cpu_dump() から conf.c, conf.h と追って dev/scsipi/sd.c の sddump() にたどり着く。
……。どー見ても -Wuninitialized で引っかかりそうなコードが……。
該当部分を変数初期化後に移して作り直して reboot -d してみる。
……。動いた。やたら遅いけど。というわけで kern/8708 として報告。

動いたはいいけど、 si_minphys() でやたらと文句を言われる。
そもそも xx_minphys() で bp->b_bcount を clip したからって printf すべきなのか?
MI 側の kern/kern_physio.c:minphys() 見たら MAXPHYS で clip してる。
DMAC は 512k くらいまで転送できるみたいなので MI の minphys() だけ使うようにする。
が、結局本質はわからないまま。気長に printf debug しかないのか?

ん? がしがし load test してたら "si0: 8697 extra bytes from 0:0" なんてのが出た。
"read error at byte 0, reading 391426139498496 bytes" とか言ってるし。どっか間違えてるか?

19991029

予期してなかったところにつっこみ。 log 見る人なんていないと思ってたのに。
news68k でも x68k と同じく spl0() は config_rootfound() の後です。
が、 thorpej 氏の SCSI の変更後 SCSI device probe は interrupt driven で行われるようになってます。
なので PIO only のとき採った log とそのままでは比較ができなくてちょっとめんどくさかったり。
よくわかりませんが umass の関係なんですかね。

port の名前は最初に動かした人につける権利があると思うのです。
もっとも news68k の場合は始めから予約されてましたけど。
EWS4800 って CISC のもあったんでしたっけ? 覚えてないなあ。
8文字超えちゃうと release のとき ISO9660 の CD-ROM の arch ディレクトリが困るかも。
そういえば、 EWS4800 は実は ARC compliant だったりしないかという話はやっぱりうそ?

DMA まわりのコードを整理。コメント足したり書き方統一したり。
が、まだたまに panic したりダンマリになったりする。
DMA 転送自体には問題なくて、割り込みのかかるタイミングがどこか変らしい。
いろいろと様子見ながら debug printf 消したり wait 削ったり。
intrhand_lev4() で si_intr() を leintr() より前で呼ぶようにしたり。
……。 panic しなくなったような気もするが、確率の問題だろうか。

DMA 使うようにしたら本体前面の DISK LED も点灯するようになった。
以前の PIO では LED が点かないとレポートもらっていたが、どうも DMAC につながってるらしい。

……と、また落ちた。

checking for core dump...
pool scxspl: reentrancy at file ../../../../dev/scsipi/scsipi_base.c line 161
         previous entry at file ../../../../dev/scsipi/scsipi_base.c line 118
panic: pr_enter
Stopped in syslogd at   _cpu_Debugger+0x6:      unlk    a6
db> trace
_cpu_Debugger(2b5000,aded9,2b5078,2b5078,789c64) + 6
_panic(1e846,1e819,aded9,76,1e7f0) + 52
__pool_put(e494c,2b5078,aded9,a1) + 4e
_scsipi_free_xs(2b5078,1) + 60
_scsipi_done(2b5078,b99f8,2b48f2,7,2b4800) + 17e
_ncr5380_done(2b4800) + 158
_ncr5380_actions(?)
_ncr5380_machine(2b4800,80,2b5fd8,789d0c,b9290) + 122
_ncr5380_intr(2b4800,789d1c,a5dbc,0,76) + 36
_si_intr(0) + 1a
_intrhand_lev4(0,0,2b5fe0,1,23000001) + 1e
_lev4intr(?)
__pool_get(e494c,0,aded9,76) + 4
_scsipi_get_xs(2a9880,1009) + f0
_scsi_scsipi_cmd(2a9880,789e0c,6,2c60000,2000,4,ea60,6b6f8c,1009) + 4c
_sdstart(2ae800,2ae8b4,6b6f8c) + 1fe
_sdstrategy(6b6f8c,789e84,8ad76,789ea4,80) + 146
_spec_strategy(789ea4,80,6b6f8c,774274,4) + 24
_ufs_strategy(789ea4) + d6
_bwrite(6b6f8c,789ecc,33068,789ec4,c615c) + f2
_vn_bwrite(789ec4,c615c,6b6f8c,789ee8,37a5a) + c
_bawrite(6b6f8c) + 38
_vflushbuf(774274,1) + 84
_genfs_fsync(789f30) + 18
_sys_fsync(6c0780,789f88,789f80) + 86
_syscall(5f) + 114
_trap0() + e
db>

うーむ。よくわからんが書き込み中に余分な割り込みが入って SCSI phase がわけわかんなくなってるのか?
そういえば現状 crash dump も採れないんだよなあ。ちょっと確認しないと。
の前に NEWS-OS は CD-R に焼いて sd0 に NetBSD 入れ直すか。

19991028

わーい!!

# dd if=/dev/rsd0a of=/dev/null bs=64k
248+1 records in
248+1 records out
16265216 bytes transferred in 16 secs (1016576 bytes/sec)
# uname -m
news68k
# uname -v
NetBSD 1.4L (LIBERO) #557: Thu Oct 28 22:32:31 JST 1999 [...以下略...]

うーん、なんだかんだと言っても動いた時の幸せってやっぱり最高。やっててよかった。
というわけでここまでの顛末。って実はなんにもしてないんだけど。

昨日の log を見てたら DMA 後の si_intr() で sc->sc_state の NCR_DOINGDMA が立ってない。
なので si_dma_stop() が呼ばれずそのあとでずっと待ってるらしい。
si_dma_start() の最後では NCR_DOINGDMA 立ててるつもりなので printf() 足して確認する。
が、今度はなぜか止まらない。それどころか延々と debug message を出し続ける。
で、ついに "Enter pathname of shell or RETURN for sh:" まで出てくる。おいおいどうなってんだ。

納得できないながらも debug printf をはずして起動。
……。どうということもなく single user まで行く。
fsck -pn してみる。……。 seek 音が「こんこんこん」ではなくちゃんと「カリカリカリ」な感じ。まじ?
そのうち error も出ず終了。……というわけでなんとも安直に冒頭の結果となったのでした。
まだどこかおかしくて multi user に行こうとすると止まることがあるけど、あとはなんとでもなるだろう。
てなわけであとは安心して日記モード。

あれ、 /sys/arch/pc98/Cbus ってすでにあるんですか。
じゃあ ne2000_isa.c に対する発言ってどういう意味だったんだろう……。
今は cbus device の attach が "hoge0 at cbus0 port ..." みたいになったんでしょうか? 謎。
「NetBSD/pc98 では isa バスにおいてもアスタリスク形式のデバイスナンバーを使用可能にしました」って記述を見てなんか違う、って思ったこともあるんだけど……。
feedback が全然ないわけじゃなかったようですけど、積極的にされなかった理由ってあるんでしょうかね。

prep の merge は現時点でも全然問題ないと思います。
実は next68k はまだ SCSI support 入ってないそうですし。 wscons は入ってるけど。
次のネタですか。 hppa と arc はすでに assign されてる人がいますからねえ。
Telios (r じゃなくて l だったのね)は WindowsCE 環境がないからつらいかな。
necews はデバイス情報がとかがわかればわりとよさげですね。
大学の研究室に EWS4800/360 があったんですが OS が嫌われてて誰にも使われてませんでした。
なので、代わりに NetBSD 動かせないかしらといつも思ってたんです。
でもその前にこのへんになにやらアヤシい記述が……。

19991027

有閑プログラマってなんだかいい響きですね。
news68k 始めた頃は本業が閑職エンジニア状態だったけど、最近は知恵なし暇なしプログラマだなあ。

今日は再び news68k DMA 仕様を考える。
scsi_1180.o をながめるが、引数を調べようにも pointer 使いまくりらしくてわけがわからん。

ふと思いついて newsmips/dev/scsi_1185.c を見てみる。
#if defined(mips) の記述があるってことは source が news1200 と共有されてた可能性がある。
で、 news1200 は CXD1185 で DMAC_0266 を使ってるようだから何かヒントがあるかも。

sc_dio() あたりを見ながら、 #if defined(mc68030) で書いてあったであろう部分を想像する。
……。 DMAC_MAPENT に書き込む値って physical address じゃなくてページ番号なのか?
その前に、 sc_dio() では Scatter/Gather してないように見えるけど、上位の SCSI ドライバの関係?

とにかく DMAC_MAPENT に書き込む値を "kvtop(addr) >> PGSHIFT" にして試す。

……。うーん。いまいちよくわからん。ので MIN_DMA_LEN=1 にして probe にも DMA 使うようにする。

[...前略...]
sched: select for t/l=0x00
select: have AIP after 0 uSec.
sched: select rv=0
sched: dma_alloc, len=44
si_dma_alloc
dh_addr=0xdc248, dh_len=0x2c
sched: dma_setup, dh=0x2b6c1e
[...略...]
machine: phase=DATA_IN
data_xfer: dma_start, dh=0x2b6c1e
si_dma_start: reset
si_dma_start: set length = 2c
si_dma_start: set offset = 248
si_dma_start: mapent[0] = dc000
si_dma_start: terminate tag
si_dma_start: set tcmd
si_dma_start: set icmd
si_dma_start: set sci_mode
si_dma_start: set DMAC_CTL
si_dma_start: set sci_irecv
si_dma_start: input done.
si_intr:
intr: top, state=1
intr: call machine, cur=0x2b68f2
machine: phase=STATUS
machine: phase=MSG_IN
msg_in: CMDCOMPLETE
[...略...]
machine: wait for DMA intr.
sched: machine done, cur=0x0
scsipi_cmd: sched done, cur=0x0
scsipi_inqmatch: 19/0/0 <HITACHI, DK515C, CP16>
scsipi_inqmatch: 2/0/0 <, , >
sd0 at scsibus0 targ 0 lun 0: <HITACHI, DK515C, CP16> SCSI1 0/direct fixed
scsipi_cmd: new sr=0x2b68f2
[...停止...]

んー? ちゃんと probe できてるってことは一応 DMA でデータ読めてるって思っていいのか?
inquiry のデータって message in か data in かどっちで読まれるんだっけ?
break 送るとちゃんと DDB に落ちる。前と同じく tsleep() で止まってる。
問題は DMA 時の割り込み処理だけなのか? ほんとか?

19991026

今日は CD-RW でお遊び。そんなことやっとる場合かという話もあるけど……。
というわけで news68k はお休み。
昨日の元気はどこへやら。とか言ってると /sys/arch/m68k に修正入ってるしー。
気にせず pkgsrc の cdrecord で試行錯誤。なんとか x6 でもちゃんと書けてるみたい。
Win95 でも試してみる。……が、こちらはなんだか固まりまくり。うーむ。

TX3912 multi user 到達 & tetris(6) High Score おめでとうございます。パチパチパチ。
しかしすばらしいペースで進行してますね。少しは見習わないと……。
Terios だったらお金が余ってたら買ってもいいなあ。ってこれ以上マシン増やしてもしょうがないか。

porting stuff って冗談かと思ったらほんとにそうなってますね。うーん、校正もれ。
そうそう、忘れてましたが /sys/dev/cbus より /sys/arch/pc98/cbus じゃない? というお告げも来てます。
って、誰に対して言ってるってわけでもありませんが。
FreeBSD(98) は source tree はいっしょなんでしたっけ。
共有がどの程度されてるのかはわかりませんが、 release は同時じゃないみたいですね。
FreeBSD/alpha は同時に出てたような気もするけど、よくわかんないな。
3.3R では amd(4) の CAM 対応も入ったって話だから、気が向いたらちょっと見てみよう。

もちろん最終的には merge するつもりです。それが(というかそれだけが)最初からの目標でしたから。
ただ、終わっても普通の日記は書かないと思います。あくまでもこれは news68k のために書いてるわけで。
が、また次のネタで同じように出てくるかはわかりません。 ;-)

19991025

とっとと区切りをつけるべく DMA のコードを書き始める。
決して現実逃避などではないはずだ……。そういうことにしておこう……。
なので COMPAT_LINUX は powerpc な方におまかせします……。

vax/vsa/ncr.c をベースにしていつものように切り貼り。
si_dma_start() と si_dma_stop() とで bounce buffer 転送してるのね。
以前調べたとおりに si_dma_start() をがしがし書く。仮想→物理アドレス変換って kvtop() だっけ。
FIFO とかあるのかしら。 si_dma_stop() はテキトー。
一応 DMA_MIN_LEN は 128 にして attach くらいは PIO でするようにしておく。
30分くらいで書いて、さらに 30分くらい修正して完成。で、起動。
……。 "sd1: no disk label" で "cannot mount root, error = 79" だそうだ。

le0 を root にして single user 起動。
disklabel sd1 してみる。一応動く。が、全然読めてない感じ。
dd if=/dev/rsd1c してみる。いきなり死亡。タイマ LED も点滅しないから割り込みもろとも死んでる。
うーん、予想はしてたけど先は長そうだ。

いろいろと printf() を入れてみる。最初から入れとけという声が上がりそうだけど……。
なんだか症状がいろいろ。 DMAC_CTL の DC_CTL_ENB たたいて DMA 始めた瞬間固まったり。
si_intr() の後 tsleep() しっぱなしだったり。この場合はタイマは生きてる。
何回かやってたら時計が 19700101 になったりした。変なアドレスに転送されてるのか?

うーむ。そもそも動作仕様の推定があってるかどうかすらわからんからなんともならん。
やはり 30分でやった逆アセンブルだけでは無理か。次は何調べりゃいいんだろ。

19991024

今日はおもむろに CD-RW を購入。今回は手持ちの現金が足りなかったのもあって HDD は見送り。
散財部からの助言をないがしろにしたわけじゃないけど、 HDD 購入は容量よりもパーティション構成とか各マシンへの分配とかの問題なので。
が、結局今日は買っただけで動かす暇がなかった。意味なし。

というわけで、昨日腹を決めたのに news68k も進展なし。最近休日に作業してないなあ。
よって日記モード全開。

NetBSD/pc98 は実は使ったことありません。試しに入れてみて挫折したことはありますが。
まともに動かせるマシンがないせいもありますが、やはり source が他のマシンと共有できないとどうも。
普段 MI で悩んでる身としては他の arch に影響あるところに独自改造が入ってるのがどうも納得できない。
MI に作ってあることの恩恵を受けているのに、その MI を MD な部分の都合で書き換えてるようで。
言い方は悪いけど、結局 "based on NetBSD" でしかないんだなあというのが正直な感想。

こういうのを書き始めたきっかけかあ。
前にも書いてますが、私の場合は 1から移植を始めるにあたって、もし壁にぶちあたっても前に進む努力をやめてしまわないように、でした。
が、実際は大きな壁にぶつかるでもなく、でもはっきりとした達成感があったわけでもなく、半端な状態。
まあ、好きで書いてることには違いないけど、区切りつけたら終わるつもり。
news68k 終わったらまた次のネタ探さないとな。まだ気が早いけど。

19991023

う。おめでたいというかそろそろなんとかしろというか……。うーん。
私も似たような状態です。やる気の出ること見つけるのって難しいですよねえ。
リストまで書いてるのにちっとも片付かないのはそういうわけで。
powerpc の COMPAT_LINUX の件は、 MKLinux の netscape が動くようになると結構幸せかも。
と、だいぶ前から思ってはいるけど、 ELF の構造とかをよくわかってないので手をつけてないまま。
NetBSD/pc98 といえば、 /sys/dev/cbus を作って isa と frontend を分離するとか行われてるんでしょうか。

今日も news68k はちょっとだけ 2次キャッシュまわり調査。
以前と同じく、長時間電源を切っておいた直後の起動ではかなりまともに動く。
今日は L2 cache 有効 kernel で login までできたので、比較のため dhrystone を動かしてみる。
```
Microseconds for one run through Dhrystone:  141.7
Dhrystones per Second:                      7057.2
```
げげ。cache 無効の状態と比べて 35%(当社比)も速いのか。こりゃなんとかしないと……。
そのまま kernel compile とか試してみたが、やっぱり途中で panic した。
例によって 2回目以降の起動では全然ダメ。何か別の初期化がいるのかなあ。誰か教えて。

vax の ncr.c にも DMA support が入ったようだ。
早速持ってきて見てみる。だいたい sun3 のと似たような感じか。
si_dma_setup() は何もしないで si_dma_start() だけで DMAC の設定してるな。
struct si_dma_handle って DMA の場合は必ず用意しないといけないのかしら。
ま、 sun3 のよりは generic な感じ。ベースにするならこいつかな。そろそろ腹を決めて書き始めるか。

19991022

MIPS1 の TLB について内山さんのページ#991021 から問い合わせ。 (なのか?)
このへんとかこのへんの変更だと思うんですが、 mail で聞いた話なのでよくわかってないです。
たぶん西村さんに直接聞いて頂いた方が早いでしょう。

一応 source を眺めてみる。 locore.h や mips_machdep.c で切替えてるのはあんまり関係なさそうだなあ。
mips1_ForceCacheUpdate ってどこにもないぞと思ったら MachForceCacheUpdate が使われてないだけらしい。
……と、 mips/trap.c の trap() の中でそれっぽいの発見。
MachTLBUpdate() の呼び方が MIPS1 のみのときだと違うようです。
同じ trap.c 中の #define TRAPTYPE() は CPUISMIPS3 使ってないけどいいのかな。

ときに、内山さんのページの更新時刻は手動で更新してる時間なのだろうか。
最近あんまり他人のこと言えないけど。

news68k は boot loader をちょろっといじる。
kernel を 0xc0000000 に load したり PG_CI はずした kernel をいろいろ試したり。
うーん。一回だけ mountroot() まで行ったけど、あとは copyright の後で止まってしまう。
以前と違い panic() すらしない。条件わからんなあ。
いろいろ試すが、電源切って 2分くらいほっといてから立ち上げると少しは進むがその後はダメ。
結局、前から全然症状変わってないってこと。だめだこりゃ。

と、今日の分更新しようと見てみたら 400kbyte 突破してる。そろそろ冗談では済まないかも。
なんだかんだ言ってペースが復活してるよ。いかん。

19991021

2620 帰宅のため手抜きモード。

うーん、すっかり飽きですねえ。次はなにやりましょうか。
って DMA やんなきゃいけないんだけど。
「活性化エネルギーが足りん」とか後輩と話してたら、「そういうときはトンネル効果ですよ」とか。
……。なんだか眠くて意味不明だなあ。
過去のやることリストはこのへんとかこのへんとかか。済んじゃってるのもあるけど。
とりあえず powerpc の COMPAT_LINUX とかどうです?

うーん、 news68k ネタ。今日は crashme 3時間耐久完走できました。くらいか?

19991020

今度は [thorpej-scsipi] な branch 作成らしい。
昔 thorpej 氏が口にしていた "my ever-growing TODO list" という言葉を思い出す。
聞いた話だと thorpej 氏って自分とおない歳らしいんだよなあ。かなわんな。

なぜか port-newsmips の動きが活発。しかしこんなに海外 user がいたのか。
FAQ かあ。とりあえずいろいろ書いてるイタリアの人にまかせておこう。
mdsetimage(8) で落ちる件だが、options MIPS3 をつけると TLB が従来の動作に戻るということなので試す。
……。 newsmips/dev/fb_sub.c の MachFlushDCache() の prototype 宣言で怒られる。
こいつはもともと mips/include/locore.h 内で define されてるので prototype 宣言削除。
できた kernel で boot して mdsetimage してみる。……動く。というわけで TLB の変更のどこかが変らしい。
とりあえず似たような話が出ていた port-pmax に投げておく。
hpcmips は VR41x1 だから MIPS3 だけみたい。 TX39xx のコードはまだテスト中なのか。

本日の news68k ネタ。 news68k/stand/ 以下その他の修正。
news68k/include/Makefile の INCS から loadfile_machdep.h, romcall.h 等を削除。
machine -> ${S}/arch/news68k/include 等の symlink 作成 rule を Makefile に追加。
が、いろいろ悩ましい問題があるのが発覚。
昨日書いてるように .BEGIN: で記述すると make obj するとき困る。
が、 ${LIBS} や ${PROG} 作成時に作るようにすると、先に make depend するとき作成されない。
うーん。 X みたいに make includes 時に symlink 作るってのが一番まっとうなのかなあ。

19991019

うぅ、あんまりいぢめないでください……。 m68k-netbsdelf 影ながら応援してますから……。
にしても、日本語は正確に使わないといけないなあ。「その他すべて」じゃなくて「その他もろもろ」か。

……と、 source-changes 見てたら fvdl-softdep なんて branch ができたようだ。
ようやく fvdl 氏の作業が始まったのか「誰か暇な人やってよ」なのかはわからないけど。

arch/powerc 以下の WARNS'fy は結構(かなり?)めんどくさい模様です。
一応パッチも作られてましたが、いまだに commit されてないのかしら。
こちらは 13G HDD 買うべきか CD-RW 買うべきか悩んでたり。

今日の news68k ネタ。なんかないかな。うーん。早く書かないといい加減眠いぞ。
${MACHINE}/stand 以下の make では installed header を参照してはいけないって話とか。
loadfile_machdep.h を install しちゃいけないってことは stand/ 以下の各ディレクトリでは必ず machine -> ${S}/arch/${MACHINE}/include の symlink 必要?
news68k でもどうするか迷ったんだけど、やっぱりそうしないといけないのか。
sparc/stand/Makefile.buildboot みたいに ".BEGIN:" の target で symlink 作られると最初に make obj するときに CURDIR に作られちゃうから困る、ってのを send-pr したいけど、どう英語で説明したもんだか……。

19991018

ぐさ。 [見事に投げ返されました]
いや、一応 news68k ネタのないことがないよう努力はしてるんですが……。
『ひとつの source tree ですべての machine を』が信条なので、 source tree の出来は news68k にも影響するのです。って苦し過ぎ。
ちなみに、日記度は news68k 進捗状況のほか本人の気分と本業の状況とに大きく左右されてます。 ;-p
というわけで(?)、今日も日記度高め。

DEC3000/300 ですが、 FreeBSD/alpha の INSTALL.TXT を見ると一応サポートリストに入っています。
FreeBSD/alpha のページはまるでやる気が感じられませんけど。
ちなみに私は oldconfig を知らない人なので、あれが普通だと思ってたり。
そういえば DC-390 の CAM 対応の話ってどうなってるんでしょうねぇ。
sfb な Xserver の話はこのへんに手がかりがあるようなないような……。

うちでは CWARNSFLAGS は -Wall その他すべてつけた上で -Werror はずしてます。
で、簡単に直せそうなものから直すと。今ではもうすべて出ませんけど。

……。うーん、 news68k ネタないなあ。というわけで無理矢理ネタをひねり出してみる。
locore.s と machdep.c を直して cpu_reboot() に RB_POWERDOWN の support を入れてみる。
えい、この、くそっ、と 10分ほどいじって RB_POWERDOWN, RB_HALT, RB_AUTOBOOT とも OK。よし、寝よ。

19991017

ふと見ると sun3 の kernel make が Debugger() まわりでエラーになっていたので send-pr する。
確認のため GENERIC を compile すると MI SCSI 変更まわりで別のエラーが出た。
sun3 って誰も current 使ってないのか? こっちも send-pr しておく。
そしたら port-sun3 でいろいろ訊かれてしまう。うー、そんなの最初に書いた人にきいてくれー。

更新をさぼっていた各マシンの /etc 以下のファイルも新しくする。
rc.conf を rcsmerge でごぞごぞするほかは特にこれといった作業はなし。特に問題なく起動。
いつの間にか dhclient(8) も netstart 中で起動されるようになったのね。
もっとも、 sysconfd(8) が起動してないとかでいろいろ怒られるのは相変わらずだけど。

……と、各マシンの boot message 見てたら news68k では ddb_init() が呼ばれてないのに気づく。
てなわけで consinit() で ddb_init() 呼ぶように修正。
端末から break 送って DDB に落として trace して確認。ちゃんと symbol 出てるな。よしよし。
今まで DDB で symbol が出なかったのはそういうわけなのね。
ついでに調べてみると、ベースにした newsmips でも呼ばれてないようだ。 pmax は呼んでる。
そもそも newsmips/stand/boot/boot.c では symbol 情報渡してないけど、まだ書いてないだけなのかしら。

19991016

昨日はここを書いてる最中に寝てしまって更新が朝になってしまった。敗北。

深い意味もなく 1.4L の source tree を import。
うーん、 CVS って便利だ。いろいろパッチあててること忘れそう。

kernel その他を作り始める前に、以前つばいさんから質問のあった port-newsmips/8451 の件を見直す。
内容は newsmips/stand 以下で make obj してるとうまくいかないというもの。
が、 PR した patch では objdir が /usr/obj へのシンボリックリンクの場合しかうまく動かない。
news68k も newsmips のマネしてるので同じようにダメ。

sun3/stand とか gnu/usr.bin/binutils とか参考にしてファイルの構成を直す。
news68k/stand/common を作ってそこで libsa, libz, libkern を作るようにする。
ついでに bootxx, boot のそれぞれで使う putchar() と romcalls.S も stand/common 以下に移動。
で、bsd.obj.mk の print-objdir のターゲットを使ってリンク時の lib*.a の PATH を指定してやる。
objdir あるなし等いくつかの状態でテスト。うん、問題ないな。
newsmips に対しても同様な変更のパッチを作ってつばいさんに送っておく。
いろいろ見てたら、 sun3/stand/netboot がうまく make できない問題もすぐ直せるのが判明。
ということで port-sun3/8471 に patch を append しておく。

次に各マシンで kernel make。といっても大きな変更はないので特に問題なし。
news68k も MI SCSI の変更に伴う ncr5380sbc.c の変更だけ。
boot floppy 作り直して source まとめて表のページを更新。

……と、 arm32 が sb_isapnp.c で Error。 MPU まわりの変更のせいか?
調べてみる。 CATS の config で "midi* at sb?" があるのに "mpu* at sb?" がないのが原因か?
というより sb_isapnp.c の 135行目の "#if NMIDI" は "#if NMPU" であるべきなような気がしないでもない。
MPU まわりはよくわかんないなあ。伊藤さん、確認しといてもらえません? (投げやりモード)

19991015

今日は自分の書いた部分のデバッグでハマリモード。
結局原因は全部 typo だったという情けないオチ。ああはずかしい。

今のところ linux しかないから linux って人も多いんじゃないでしょうか。
逆に news68k の場合、 NEWS-OS 4 はわりとまともな BSD なので乗り換えてもらうのは大変かも。

cardbus サポートも入ったみたいなのでなんとなく sup かけてみる。
あ、 update script 作ってあったのに忘れてた。まあ明日手で cvs import しよ。

19991014

昨日早く帰ったせいじゃないけど、本業は順調にハマリモード。うつうつ。
5時間調べて結論が「接続相手の動作が記載仕様と違う」とかでもうぐったり。
ふだん人が仕様もロクにわからんもの相手に格闘してるってのに。

うーん、どうでしょう。台数だけなら news68k のほうが多いかもしれませんが、需要はどうだか。
他からもフォローあると思いますが、 port maintainer は release binary 作るって大仕事があると思います。
repository のアクセス権その他には違いはないんでしょうけど。

news68k の DMA の設定も Scatter/Gather させてるわけです。 pcscp(4) その他もみな同じ。
NetBSD だと bus_dmamap_load(9) で bounce buffer 操作も含めて仮想アドレスが dm_segs[] の物理アドレスの複数セグメントに変換されるので楽。そのぶん bus_dma(9) の実装は大変ですけど。
データ転送以外にパラメータの変数等も DMA で渡す場合は bus_dmamem_alloc(9) で DMA safe なメモリを確保して bus_dmamem_map(9) で kernel 空間に map しておく。
で、転送前後に bus_dmamap_sync(9) して bounce buffer の転送や cache の invalidate 等を行う、と。
PCI だと DMA でパラメータを渡す場合 little endian で書いとかないといけないとかいうのがあったけど、これってどう対処するのが reasonable なのでしょう? #if BYTE_ORDER やむなし?

もっとも、 pcscp(4) 書いてたときはこれらを理解するのに 1か月もかかっちゃいました。
bus_dma(9) には説明あるんですが、当時はまだ VM と Scatter/Gather の関係がよくわかってなくて。
ネットワークカードの DMA は mbuf(9) とかがよくわかってないのでいまだに不明。
各物理メモリセグメントがページ境界に来ないから Scatter/Gather の機能が貧弱だとダメだとか云々。
大明神様の日本語による解説講座があるといいのに。 ;-p

19991013

さすがにもう扇風機の季節ではないので 19時すぎに仕事場から脱出して電源ファンを買いに行く。
で、帰ってきて早速取り付け。ごそごそ。おし、風量も増えていい感じ。
音量も増えてるかもしれないけど、こんだけマシンがあったら関係ないので気にしない。

なにやら昨日の分を書いてる最中に裏でいろいろと怪しげなメールが飛び交ってたらしい。
うーむ。どうも大明神のお怒りに触れてしまったようだ(誤報)。
しかしこれで一つだけわかったことがある。 prep は news68k よりも 100倍は需要があるらしい。
って今さら言うまでもなくあたりまえ。マイナー扱いなんかしちゃってごめんなさい。
ということで引き続きここは日記モード継続。 (結局それかい)

分散・統合ってのはたぶん Scatter/Gather のことでしょう。つまり DMA 転送のこと。
昔読んだ本には「拡散・収集」とか書いてあってますますわかりませんでした。
やっぱり kernel が怪しい動きをしたときは make cleandir なんでしょうか。

RS/6000 な方からのタレコミによると PReP で MCA なマシンはないと思います、とのこと。
うーん、そーだったのかー。苦し紛れに拾ったネタってダメですね(ぉぃ)。
あと、うちの sendmail.cf の設定は某ページに書いてますが、今見たら思いっきり古いままだな。いかん。
最近 DTI の mail はいろいろ制限があるみたいですが、よくわかってないです。
って、こんなところにも hoge.co.jp なんて記載例が……。確かに存在しないらしい(笑)。

タグ付加どうもありがとうございます。早速いくつかリンク修正。
しかし Ruby (←リンク間違い) ですか。エセプログラマの私は perl も awk も C もままなりませんです。
bebox の boot は macppc でも参考にしたけど、あの頃はまだ MI の loadfile() はなかったような……。

19991012

今日も引き続き扇風機冷却中。マシンは冷えるがこれからの季節人間も冷やされるのはちょっとアレだ。
というわけで今日からしばらくは日記モード。 (←言い訳)

<a id="1999xxxx"> に href= を足すくらいならすぐできるかな、ということで sed で変換してみる。
……。 10分ほど試行錯誤してようやくできた。偉い人たちだとこういうのも 3秒で書けるんだろうなあ。
というわけで NetBSD/bebox porting note にも name タグつけません?
cross のほうはそのうち ;-p send-pr します。 mipseb の使用レポートも来ないしー。
developer がイヤ、なんてことは全然ないですが、先に news68k 区切りつけたいっす。止まってるけど。

DEC3000/300 であってたのかー。シリアルコンソールのことが書いてなかったから違うかと思ったのに。
大明神のお告げがあればそのへんの抜かりはないということですね。
で、やっぱり TC の 100BASE-TX とか PCI の FDDI とか FDDI-Ether switch とか探すのでしょうか。

さらにぐるぐる。お、 NetBSD/i386 の MCA support がついに merge に向けて動き出したのか?
てことはいつか NetBSD/prep で MCA が使えるようになる日もやってくる?

19991011

連休最終日なのになんだかいまいちやる気出ず。ぼーっと本読んだり街を出歩いたり。
平日にコード書いて休みにさぼってちゃ何しとるんだと言われそうだけど……。

なんとなくぐるぐる。これって機種当てクイズなのかしら。
うーん。ヒントからすると AlphaStation 200 4/100 ってとこかな?
Hub はうちはまだ 100BASE-TX と 10BASE-T が一つずつ空いてるな。
もっとも MAU が必要なマシンが 4台ってあたりがかなりダメだけど。

どうも DMA コードを書き始めるだけの活性化エネルギーが出てこない。
ふにふに感もへろへろ感もだいぶ収まってるのに。
書き始める前から「動いてしまった後どうするか問題」を危惧してるわけじゃないけど……
そんな心配する以前に、動かなかったときも十分憂鬱だしなあ。
pcscp(4) のときも動き始めるまでに半年、その後もかなりディスクの中身飛ばしたし。
うーん。テストは floppy から md root な kernel をブートしてやるほうがまだ安全なのかしら。
それとも、ダメなら probe からして動かないから変に壊れることはないか? 同期転送もないし……

……と、ふと i386 マシンに手を置いたらケースがチンチンに熱い。うお?
あわてて後ろに手をかざすと電源ファン止まってる。うわ、やばっ。
緊急停止して内部点検。……。そんなに時間は経ってなかったらしく、ハードディスクは問題なさそう。
やや安心して次は電源分解。う、なにやらヤバそうなにおいが……。
予想どおり電源ファンほこりまみれ。これはベアリング逝っちゃってるかな。
一応掃除してみるが、ヘロヘロとしかまわらない。だめだこりゃ。
とりあえず、ケースのふた開けっぱなしにしてとなりに扇風機を置いておく。 (なんてひどい)

うーむ。ノーブランドケースの電源ファンの寿命は 2年半ってとこなのか。
昼間に気づいてたらおでかけついでに買ったのに。 NetBSD で遊んでないでまじめに仕事しろということか?

19991010

祝! tetris(6)動作(じゃなくって) single user 到達おめでとうございます。
……って、あれよあれよという間に multi user まで行っちゃいましたね。すばらしい。
無責任だけに役に立たないコメントだったようでどーもすいません。
ちなみに自分の経験からすると、こういう時の寝不足はあとからジワジワ効いてきます(笑)。
でも、この「動いた瞬間の喜び」があるからこそ、こういうことが続けられるんですよねー。

あと、余計なお世話かもしれませんが diskless の場合の swap は dd で /swap 等を適当なサイズで作って
```
/swap none none sw 0 0
```
を /etc/fstab に書くのが一番手っ取り早いです。
まあ、メモリが 72MB もあれば swap なんてほとんど使いませんが……。
diskless は Sun で勉強し始めたので bootparam しか詳しくないですが……
exports(5) の -alldirs は mount point の top のディレクトリでないと指定できなかったような。(うろ覚え)

news68k でも dhrystone 走らせてみる。

Microseconds for one run through Dhrystone:  192.1
Dhrystones per Second:                      5206.7

うーむ。 PowerPC 604e 100MHz と比べても 40倍遅いのか。
ちなみに K6-2 350MHz と比べるとマジで 100倍以上遅いんですねえ、これが。
news1700 で L2 cache 効くようになったらどれくらい変わるんだろ。
そういや今は PG_CI してすべて cache disable してるけど L2 cache の有無で動作変えたほうがいいのかしら。
boot 時の d5 の stack の address の上位 8bit で判別してしまっていいのか?

参考に sun3/80 でも動かしてみる。

Microseconds for one run through Dhrystone:  187.6
Dhrystones per Second:                      5330.5

むぅ。クロックは NWS-1750 が 25MHz で sun3/80 は 20MHz なのに sun3 のほうが速い。
ってことはたとえ 256bytes しかなくても L1 cache は十分意味あるのか?

19991009

ふにふにな気分を払拭すべく、ひさしぶりにまた泳ぎに出かける。
一気に 1000m をふにふに(ぉぃ)と泳いで、ついでにそのまままた 150km ほどドライブ。
……。ふにふにな感じはだいぶ改善されたけど、なんだか今度はへろへろ。 (←あたりまえ)

てなわけで今日は news68k はお休みして NetBSD/prep のタレコミメール書いてみたりソース眺めたり。
PCI の設定なんて全然知らないけど、野性の勘だけでコメントしてみようかな。
MPC105 の config register 以外は out32rb(), in32rb() ではなく out32(), in32() 使えばよいのでは。
bebox porting note その0 の下から 12%くらいのところ ;-p のコメントってそういうこと……ですよね?
dev 18 と dev 22 で処理が同じなのはそういうものなのかな。
取り付けるスロット変えるとなにか変わったりするでしょうか?

ってコメントするだけって楽だなあ。無責任になっちゃっていけませんね。
news68k のことも頭の中で考えるだけ考えてみる。

以前書いたように、 news68k のことだけ考えるなら si_dma_alloc() ではなにもする必要はない。
しかし、仮に bus_dma(9) を使うのが必須だとすれば si_dma_alloc() で bus_dmamap_load() する必要がある。
で、その後 si_dma_setup() 内で bus_dmamap_t の dm_segs[] を使って DMAC を設定する、と。
しかし bus_dma(9) するつもりのない news68k でそこまでする必要があるのだろうか。
そもそも ncr5380sbc や ncr53c9x は bus_dma(9) ができる以前に MI 化されてるので DMA hook が不自然。
が、 aic7xxx 等とは違って DMAC は各マシンで違うから MI で bus_dma(9) を call するのは無理?
isp(4) の isp_sbus.c と isp_pci.c とか見ると ncr5380sbc の hook もそんなに変というわけではないのか?
たとえ可能性がゼロでも news68k に vme な ncr5380sbc がついたりする事態も想定しないといけないのか?
うーん。 consistent ってむずかしい。まさに "quite time consuming" だなあ。

19991008

本家のページからリンク張られると、適度にプレッシャーがかかってよいです。 ;-)
マイナーなマシン ;-p だと変にせかされることもなく応援してもらえますし。
ひとまずこちらから abs@netbsd.org さん宛にメールしときましょうか?
あと、日本語ページの所在情報は曽田大明神様からのお告げです。
英語のページもないか探してみたんですが見当たりませんね。

name tag 入れるとますますサイズが大きくなっちゃうし、ますます日記モードになっちゃうし……
……正直に言います。単にめんどくさがってるだけです。すいませんすいません。
asahi-net は 50M まで web backup ;-) できるんでしたっけ。
DTI は標準 5M までなのでもうほとんど一杯で困ったもんです。

修正どうもありがとうございます。
そろそろまた sup かけてみようかな。

何回かテストして cross-mipseb-netbsd のパッチを公開。大丈夫だよな。
そういえば config/mips/netbsd.h の mipseb 対応パッチってまだ main trunk にも入ってないな。
cross の場合はどう書くのがスマートですかね。どうしたもんでしょ。 netbsd-[lb]e.h に分ける?
ついでに cross-m68k-netbsd な package も再度作り直してみる。
なんだ、 BINUTILS_GNUTARGET を m68k-netbsd じゃなくて a.out-m68k-netbsd にすればよかったのね。
gas, ld が binutils のだからそのままじゃ PIC は作れないけど、 kernel cross compile にはこれで十分。
m68k のほうは特に patch も必要ないみたいだし send-pr しようかな。
それとも坂本さん入れといてもらえません? (横着モード)
PIC も作りたい場合は伊藤さんの cross のページを参照。

19991007

今日はなんだか一日中ふにふにな気分。ふにふに仕事してふにふに帰宅。
loadfile() の件をふにふにと send-pr。って www.netbsd.org の perl が変だよ。ふに。
数少ない newsmips user 支援を兼ねてふにふにと cross-mipseb-netbsd な compiler package 作成。
……。cross/binutils で make deinstall したら m68k 用の cross egcs まで消えちゃったよ。ふにゅう。
……。動いたみたいだけどどこを修正したのかよくわかんなくなっちゃったよ。ふにー。

news68k もふにふになネタ試す。
sun3/sun3/leds.c とか見ながら LED 点滅コード追加。
……。これで NEWS-OS に一つ追いついたぞ(ぉぃ)。
sparc の options BLINK みたいなことしようかとも思ったけどめんどいのでやめ。

SCSI DMA もふにふにと調査。
ncr5380 でまともに DMA 使ってるの sun3 だけか? DVMA とかわけわからんぞ。
DMA 用 hook は alloc/free/setup/start/poll/eop/stop とあるけどどこで何すりゃいいんだろ。
DMA に特にメモリはいらないから alloc, free は DMA 中フラグをセットするだけか?
setup でページのアドレスセットして start で開始のレジスタたたけばいいのか?
poll ってなんだろ。 eop はなくてよさそう。 stop も適当だな。
ん? broken とは書いてあるけど sparc/dev/si.c は一応 bus_dma(9) 使ってるのか。
こいつは alloc 中で bus_dmamap_load() してるなあ。
DMAC への転送アドレス書き込みはどこでやるべきなんだろ。

と、ふにふにしながらほげほげを見たら 曽田大明神 の呼び名が一般公開されてるじゃないですか。
これからはここでも偉い人じゃなくて大明神様と呼ばせていだだきますです ;-p

19991006

NetBSD/prep も順調に進んでるようですねえ、と見てたら表のページ ;-) もあるじゃないですか。
せっかくですから本家のページからリンク張ってもらうようにしません?
"Current Status" がわかれば載せるのには十分、ってことらしいですし。
あと、某偉い人からも伝言来てます。
そーいえば、のなかさんの話、知ってたのに BSD Magazine に書き忘れているじゃん。すいませんすいませんすいません。
だそうです。
そういう私も、のなかさんのターゲットマシンの素性を知らなくて書けませんでした。すいませんすいません。

了解です。実は 4.x は Win でも UNIX でも使ったことないんです。
移行しようかなあとは思いつつ、まだ mule-1.1 使ってたりするし……。過去にひきずられちゃダメなのに。

……このままではまた日記モードオンリーだなあ。 news68k DMA も調べよ。
NEWS-OS の scsi_1180.o とか dmac_0266.h とか眺めてみる。
scsi_1180.o の中の sc_dma() でいろいろやってる。
dmac_0266.h はかなりコメントが親切。いいねえ。
……。うーん。この 2つ見た限りでは、実は非常に素直な作りをしてるような。
転送する領域の物理アドレスを 4k page 毎にタグとともに登録すればいいようないい感じ。
以下推定手順。

DMAC_CTL の DMAC_CTL_RST を上げ下げして reset。
DMAC_TCNT に転送バイト数を write。
DMAC_OFFSET に転送開始アドレスのページオフセットを write。
DMAC_TAG に 0から始まるタグを、 DMAC_MAPENT にページの物理メモリアドレスを繰り返し write。
すべてのページのアドレスを書いたら最後に DMAC_TAG に 0を write。
これで準備は完了で、あとは read/write に応じて CXD1180 の tcmd, icmd, mode の各レジスタをセット。
最後に DMAC_CTL_MOD で転送方向設定して、 dma_send たたいて、 DMAC_CTL_ENB を 1にして転送開始。

って思いっきりあてずっぽだけど。ほんとかいな。
これならば pcscp(4) とか macppc の esp(4) とかとほとんど同じ処理でいけるはず。
次は MI 側の ncr5380sbc ドライバの DMA hook がどうなっているか調査か。

19991005

しばらく遊びまくったツケがついに限界にきて本業はまりモード再開。
なぜか C のソース見ながらアセンブラのコード書いたり。
最近逆アセンブルやり過ぎなせいで変にこだわってしまい敗北したり。

例によって帰ってまで news68k いじる元気は出ずぐるぐる。む、期待どおり(?) 捕捉されてたり。
ええと、本文は問題なく読めてますけど、背景って 3.x でも出ます?
こちらでは Win でも BSD でも出ないんですけど、なんか間違えてるのかなあ。

NWS-1450 について追加レポートを頂く。ありがとうございます。
NWS-1750 とは違い stack が 0xc00xxxxx を指してないので調べて頂いたが、そういう設定はなさそう。
ただしメモリイメージの見え方は news1700 と同じようだとのこと。
NEWS-OS の /sys/ 以下を見ると実は news1400 と news1700 では kernel が違う。
何が違うかは確認してないが、いずれの kernel も 0xc00xxxxx を明示的にアクセスしてる部分がある。
最初の vbr とか sp の設定とか fdc_set_dma の中とか、怪しいといえば怪しい。
が、 network まわりその他でも 0xc00xxxxx 指定してるところがある。 2次キャッシュに関係あるのか?

19991004

なんとなく sun3 から X 一式持ってきていろいろ動かしてみる。
もちろん client だけだけど、遅いのを除けばどれもふつーに動く。
それならば、ということで昔作った mozilla を起動してみる。
ちなみにこれはコンパイル済みのものでなくて昔 sun3 で 2日くらいかけて作ったもの。
…………。kterm 上で mozilla と打ち込んでから待つこと 10分(笑)ようやく最初の Window が出てくる。
ボタン押すごとに 10秒以上待たされたりする。そんなもんか。
でも、一度 font や言語等を設定してしまえばなんとか耐えられなくはない程度に動く。うーむ。
こういうときだけは uname(3) が MACHINE_ARCH じゃなくて MACHINE を返すのがうれしいかもとか思ったり。
Netscape 3.x では表示されないものも多いんですねえ。宴のしすぎ、とか ;-p

そうこうしてると NWS-1450 でも boot floppy 動作 OK と報告を頂く。ありがとうございます。
というわけで表のページのリストに追加。

tech-kern の方は伊藤さんからフォローが入る。どうもどうも。
って、 port-news68k list はまだ気が早いでしょう。たぶん。 ;-p
SCSI DMA が動くようになったら……とは思ってますが、先長そう。
が、ふと ftp.netbsd.org を見るとなぜか最初の message に "NEWS (68k & MIPS)" って書いてある。なぜ?
まあそれはおいといて、 loadfile.c は誰も直してくれなかったらどうしましょ。
x68k が MI loadfile() に switch するには……ちょっといろいろ複雑みたいですね。

19991003

loadfile() で NMAGIC が読めないのが気になって夜も眠れない(ウソ)のでもう少し調べてみる。
の前に、そもそも OMAGIC とか NMAGIC とかの違いをよくわかってないので a.out(5) の man とか読んでみる。
OMAGIC だと text, data, bss をすべて前から順にベタで配置する。
NMAGIC だと text と data 以降(bss 含む)が別のページになるように配置する。らしい。
要は text のみを read only にできるようにするためらしい……と、ここで重要なことに気づく。

news68k のベースにした hp300 pmap だと、 pmap_bootstrap.c で text を PG_RO に、 data 以降を PG_RW に設定している。
てことは OMAGIC だと data の先頭の一部が PG_RO になってしまう。なのに今までなんで動いてるんだ?
調べてみると、実は data の先頭は locore.s 中の temporary stack になってて、後ろのほうしか使ってなかっただけらしい。

てなわけで、結局 kernel を NMAGIC にするのは必須みたいなのであらためて loadfile() をチェック。
NMAGIC を使ってる mvme68k/stand/libsa/exec_mvme.c とか見ながら違いを確認。
……。どー見ても aout_exec() の text load 後の alignment あわせのコードは間違ってるような……
が、いまいち自信がないので以前の疑問とともにエセ英語で tech-kern に質問してみる。

並行して自分でも確認してみる。……が、 alignment 部分を直してもちゃんと load されない。げげ。
相変わらず string table が変らしい。 LOAD_SYM を外してみるが今度はダンマリになる。
実は早とちりしたか、とややあせりながらどうなってるのか調べる。
……と、読み込まれた symbol table の中身がどうも 32バイトほどずれているような気がする。
さらに見てみると data の先頭部分に text の最後の部分が読み込まれてる。
ってことは text が a.out header 長だけ読み込み足りないってことか?

もう一度 mvme68k のと比べてみる。
あれ? NMAGIC でも header 長は text に含まれないのが正しいのか?
MI loadfile() の aout_exec() のコメントはウソ?
とにかく試してみる。 NMAGIC でも text から header 長を引かないようにして、再度 installboot して起動。
……。動いた。しょーもな。 tech-kern ほっといて send-pr したろか。

などと「動いてしまった後どうするか症候群」にはまりかけてたら NWS-1450 を持ってるという方からメールを頂きました。どうもありがとうございます。
今までいろいろメールを頂いているが、実機を持っている方からは実はつばいさんに引続きまだ 2件目。
というわけで実機持ってらっしゃる方は表のページの bootable floppy だけでも動くかどうか確認してもらえるとうれしいですー。ぺこり。 _o_
って、置いてあるのまだ OMAGIC のままですね。これでも一応動きますのでそのうち作り直します……。

19991002

起きて news68k の状態を確認。が、あえなく error で止まってる。くぅ。
ramdiskbin.mk 作成時に OBJDIR が正しく認識されてないような。
調べてみる。ぐあ、 crunchgen.c の中で MACHINE 直接参照してるじゃねーか。
そう、今は手抜きしてほとんど sun3 のバイナリを使ってたのでした。
make(1) みたいに uname(3) 使ってくれないと……とぶつぶつ言いながら news68k 上で作り直す。
いや、 setenv MACHINE news68k すれば動くんですけど、やっぱりねえ。

再度 make。 ramdisk の下はよさそう。が、 bootfloppy の下の installboot で怒られる。
よくわからんが /dev/rvnd0a じゃなくて /dev/rvnd0c だと書けるのでそうする。
もう一度 make。"gzip -9 netbsd.tmp" が遅い……。と、完成。なんか ramdisk スカスカだなあ。
いつものように i386 上で floppy に dd して news68k で起動。
……。無事 sh の prompt 登場! 当たり前だが ifconfig も disklabel もなんでも OK。 ;-)
というわけで表のページを更新。 source と FD image と boot message log をつけておく。

ちょっとだけ L2 cache 問題がどうなっているか PG_CI 外して様子を見てみる。
……。以前ほどひどくはないが、おかしいのは変わらないようだ。
毎回同じ場所で panic したり error message 出たりするみたいだし、前よりは調査しやすいかも。
ま、どーせこれは根が深いだろうからひとまず置いといて、次は SCSI DMA だな。

19991001

内容からして同人誌みたいなものでしょう。 ;-p
あ、こんなこと言ったら他の筆者の方々に失礼か。

なにやらまた thorpej 氏が MI SCSI をいじってるみたいだけど……
そんなに MD には影響ないのかな。 ncr5380sbc.c だけか。
thorpej 氏の別のメール "yet another chip-designers-and-manual-writers-disagree" にちょいウケ。
マニュアルがありゃいいってもんじゃないんだろうけど、ないよりはいいよね。

で、 boot loader 4日目。平日の深夜作業のみだからペースはこんなもんか。
昨日のダンマリの原因をぼーっと考える。
……と、よく考えたら locore.s で physmem を d4 から渡すようにしてたのに boot.c 変更してないじゃん。
というわけで hp300/stand/common/machdep.c とか見ながらレジスタに値渡すように修正。
再び floppy の boot から hd(1)/netbsd を読ませてみる。
……。おし、 copyright 出て無事起動。いやー、間抜けなオチだ。いかんな。

あれ? PROM は bootdev の MAGIC に 0xa を渡すのに newsmips/autoconf.c だと 0x5 見てるな。
news68k でも NEWS-OS の /boot は 0x5 渡すようだ。
よくわからんが今回作成の /boot でも 0x5 渡すようにしておく。

順番どおり次は installboot にとりかかる。
つばいさんによれば current の sparc のは MI loadfile() を使うようになってるらしい。
ちょっと見てみるが、 newsmips ベースのほうが変更少なそうだし loadfile() 不信気味なので見送り。
1.4R の sparc のを参考に a.out 用のコードを復活させて make。あっさりできあがる。
entry point 間違えたり sd0 と sd1 を間違えたりしたが、 primary の bootxx はちゃんと書けた模様。
が、次の /boot が正しく読めず monitor に落ちる。メモリダンプすると全然違うものが load されてる。
dd で確かめてみるが installboot での /boot の block numbers はちゃんとあってる。

例によってじーっと見てみる。……あれ? /boot 読む時アクセスランプ点いてないじゃん。
どうも指定した sd1 じゃなくて sd0 を読んでるらしい。よく見ると bootdev の値が変。
newsmips/include/romcall.h によれば hd(1) は 0xa0100000 のはずだが 0xa1000000 になってる。
news68k だけ違うのか newsmips でもそうなのかは確かめてないがひとまず BOOTDEV_CTLR() を書き換え。
で、起動。……んー、完璧と言えよう。これで今週の目標は達成。ふう。

調子にのっていつものように md root kernel な bootable floppy を作ってみる。
が、やはりただでさえ m68k な上に SCSI 遅過ぎ。 make includes だけで 2時間かかったり。
今日はこのままほっとこう。朝までにはできあがってるといいな。

19990930

いえいえ、移植記を載せるなら NetBSD/bebox porting notes のほうが先でしょう ;-)
坂本さんの移植記がなければたぶんこのページも作られなかったと思います。
いずれにせよ、こういうのは人に読んでもらうというより自分のために書いてるものですし。

device driver とか kernel port とかの話をする場合、その前に曽田さんの連載がいりますね ;-p
第一回は Machine Independent および Bus Independent の話と実際の source tree 構造について。
第二回は bus_space(9) 関数群と bus_dma(9) 関数群の解説と使用例。
第三回は config(8) と files その他設定ファイルの書式について。

ここまでが前提知識で、あとは既存のコードを cut & paste するだけでもなんとかなります、とか。
詳しい話をするならば、 device driver ならこの後で probe/attach/ioctl とかの実際の記述の話。
kernel port なら cross compiler とか boot loader 問題とかデバイス情報の話、って感じかな?
でもいずれもそれだけで本が一冊できちゃいそうだし、季刊連載では苦しいか。
そもそも上の話は NetBSD でしか通用しないな。どちらかというと NetBSD の portability の話ですね。
私は design & implementation の話はさっぱりわかりませんので…… ;-p

戯言はこれくらいにして、今日もさらに boot loader 続き。
romcalls.S の trap #0 呼び出しの前後でレジスタ退避するようにする。
いくつかポカミスをしたが、無事くるくるまわる loadfile() 動作!
……と言いたいところだが、読み込むだけで kernel に制御が飛ばない。例によって reboot の繰り返し。

ふにふにと調査。全然関係ないけど「ふにふに」を最初に使った人ってちょっと尊敬しちゃうな。
どうも text は 0x0 から、 entry の _start は 0x1000 なのに text が 0x1000 から load されてる感じ。
libsa/loadfile.c を見ると、確かに entry のアドレスから読み込むように書いてあるような……
今までみんな _start が先頭にあったから気づいてないのか?
もしかして a.out で MI の loadfile() を使ってるのって昔の sparc だけ?

_start が先頭に来るように locore.s をいじって kernel を作り直してみる。
……が、今度はほとんど読み込まずに loadfile() の先頭で止まってしまう。
もう一度 loadfile.c をじっとながめる。……。
OMAGIC だと header を text より前に読み込んでるようだけど、 text が 0x0 からだと困るような……。
次に NMAGIC な kernel を作って試してみる。……が、今度は symbol table がまともに読み込まれない。
string table 長の値が変みたいだけど、 symbol table のアドレスが変なのか?
MI loadfile() って a.out じゃ全然ダメじゃん。いっそのこと kernel ELF にしたろか。

結局 OMAGIC に戻して loadfile() の flag から LOAD_HDR をはずしたら無事 kernel に jump したらしい。
が、らしいだけで実際は jump した時点でダンマリになってしまう。
キャッシュあるいは別の原因なのかどうかはわからないが、また地道に LED debug か……

19990929

BSD magazine 届く。雰囲気が堅いという意見もあるようだが、おおむね評判はいいみたい。
しかし改めてみると NetBSD の記事が多いな。
げげ、 Daemon News にも news68k のこと載ってたんか。知らんかった。
インストール記事ってやっぱり世間では需要大きいのかしら。
部屋の中でインストーラ使って入れたマシンってないんですけど。
というか、半数は入れた当時まだインストーラがなかったんだけど。
ところで、予告にある次号の記事って誰が書くのかしら……

今日も boot loader 続き。
bootxx() と boot() は d4〜d7 だけ渡して呼ぶことにする。
boot と installboot の同時作業でははまるのが目に見えてるので installboot は後まわし。
かわりに boot を手で floppy の 16セクタ目からベタで書きこむ。
bootxx.c の block_count, block_table もあらかじめ書いておく。
boot() のほうに渡す bootdev は実際に kernel がある hd(1) を見るように細工しておく。

いろいろはまる。 block_count は block_size 単位だが block_table はセクタ単位だったり。
BSS clear してなくて謎の動きしてくれたり。
news68k では SCSI disk は sd じゃなくて hd だったり。
romopen() の後 devname が破壊されてて printf() がふっとんだり。

そうこうしてるうちに loadfile() まではたどり着く。
が、 "Inappropriate file type or format" と文句を言って読み込んでくれない。
loadfile_machdep.h の記述をいろいろ変えてみるが変わらず。
そもそも存在しない filename を入れても同じこと言われる。変。
root directory がちゃんと読めてないのか? 一応ディスクのランプは点いてるけど。
newsmips だとちゃんと "No such file or directory" になるよなあ。なにが違うんだ。
……。どうも各 ROM call のあとの変数の中身が変なような。レジスタ退避とかしないといけないのか?

19990928

ASCII の BSD magazine 発売日。が、結局今日には届かなかったのでまだ読んでない。
いったい最後はどういう仕上がりになったんだろう。
表のページの URL だけ書いてここの URL は書かなかったけど、よく考えると清水さんのページからここにリンク張られてるんだった。うむむ。

今日は予定の道順どおりに boot loader をごそごそいじる。
まずは newsmips/stand 以下を news68k/stand 以下にまるごと copy する。
Makefile 中の CPPFLAGS とかいろいろ書き換え。
boot/locore.S と bootxx/start.S は適当(ぉぃ)に m68k assembler に書き換え。
romcalls.S は以前調べた結果から newsmips の syscall を trap #0 に置き換え。
function は d0 で渡して、 argv はスタックに積まれてる値を linkw fp,#0 して fp で渡す。
ただし _halt だけは moveq #8,d7 して trap #15 を呼ぶ。
load address はなんとなく 0x200000 っぽいのでそうする。

などとテキトーの極致としか思えない作業のあと make。
symbol 名などいくつか修正した後 bootxx 完成。うーむ。
news68k は a.out だから newsmips の installboot を直すのはちょっとめんどくさいな。
というわけで floppy の先頭に bootxx だけ書いてどうなるか試してみる。
a.out header らしき先頭 32バイトを削って i386 上で floppy に dd する。
で、 news68k のモニタで "bo fh()" して起動。
……。無言で reboot を繰り返してる。さすがにそんなに甘くないな。

いろいろいじって動作を確認してみる。
まず start.S でいきなり halt に飛ばす。
……。ちゃんとプロンプトに戻ってくる。これは OK。
start.S の中で手でスタックに引数積んで rom_write() 呼んでみる。
……。よくわからんがなんか 1文字出てきた。 _rom_write その他は動いてて address が変なのか?

もう一度 NEWS-OS の boot0 を調べてみる。
よく見ると 0x200000 に load されるのではなくて load されたあと自力で 0x200000 に転送しているようだ。
モニタで実際どこに load されてるか調べてみる……までもなく 0x0 の先頭に load されてた。
start.S にも転送させるコードを入れようかと思ったが面倒なので load address を 0x0 にして作り直す。
で、起動。……おわっ、いきなり画面が変な文字で埋まってしまう。
が、履歴を見るとちゃんと "NetBSD/news68k Primary Boot" が出てた。 printf() 動いてるじゃん。いいぞ。

bootxx() を呼ぶ前に各レジスタを引数とすべくスタックに積んでみる。
ううむ。スタックに積んだ順序と引数の順序がよくわからんが、最後に積んだのが最初の引数か?
d4 は 0xffc000 だから total memory かな。
d5 が printf で "boot" が表示されるから boot filename の pointer が入ってるっぽい。
d6 は 0xa0000001 だから 0xa0 が MAGIC とすると bootdev の fh(0,0,0) なのか?
d7 は "bo /x" の "x" の数字らしい。
d1〜d3 はいずれも 0 で d0 は 1。意味なしなのかこの数字に意味があるのか……
ま、ここまでわかればあとはなんとでもなりそう。いまさらですが、つばいさんに感謝。

19990927

どうも失礼しました。 source も見ずにあてずっぽ言ってちゃダメですね。
結局 M68030 用の TBIA_30() もあったんですね。
そもそもこんな VAX emulation な関数がダサいという話もありますが。
hp300 よりも mvme68k のほうがメンテされてるというか、見通しはいいですね。
hp300 は memory map が変だったり VAC や HP_MMU なマシンがあって面倒なんだ、という気もします。

で、 VENUS-X ですが、ページの説明を見る限り 030 用キャッシュのほうは動いてるように読めます。
060 のほうは実機が動いてるのかどうかよくわかりませんが。
68030 だと物理アドレスキャッシュになるので、対処すべきところはそんなに多くないです。
hp300 で #ifdef HAVE_CACHE_PAC してる sys_machdep.c の cachectl1() と DMA まわりだけ。
結局は hp300/locore.s で定義されてる PCIA() 内の 2次キャッシュクリアをどうするか、なんですが。

そうそう、 ppp の設定ですが、一応大昔に書いたページがあります。
最近 ppp は使ってないので、今ちょっと試してみました。
/etc/ppp/peers/ 以下の読み込みが root 権限で行われなくなったみたいですがそれ以外は問題なさそうです。
少なくとも DTI に対して PAP 認証では接続できました。

道はそっちだよ、と昨日書いたそばから脱線して news68k/dev/zs.c をいじる。
今の serial console はたまに文字が化けたりする。 csh の prompt が変だったり。なぜか tcsh だと OK。
これは sun3 でも同じ症状。同じ zs でも sparc や macppc は問題なし。
以前から気になってた ZS_DELAY() を無効にしてみる。
……なおった。うーむ。 m68k は delay() なんぞ入れなくても十分遅いということか?

19990926

昨日は車で走り回ったので今日は自転車でいろいろ走り回る。
暑さ寒さも彼岸まで、とはよく言ったもので、日が暮れるともう肌寒かったり。

ひと段落ついたし最近飛ばし過ぎでもあるので、今日は news68k 作業お休み。
今週の目標は昨日も書いたとおり native boot loader ということにする。
ベースとしては newsmips のがほとんど流用できるはず。
まずは romcall.S の中身の検討と load address の確認かな。
boot loader が動いたら、 L2 cache 問題の挙動が変わるか確認して、その後で DMA 調査、てな具合か。
そうそう順調に進むとも思えないけど、ひとまず道はそっちだよってことで。

19990925

先週から頼んでいた車の修理が完了したので引き取りに行く。
天気もいいことだし、久しぶりにそのままドライブにでも行くことにする。
ふと、そういえば彼岸なんだなあ、ということでおもむろに西に向かって 300km 走る。
で、到着。いきなり思い立って来たから手ぶらだけど、いいよね。
今 news68k のことをネタにしたらどんな話ができただろう、なんて柄にもなくしんみりしたり。
15分ほどで辞去してそのまままた 300km 引き返す。肝心の車の調子はいまいちだけど、まあいいや。

部屋に戻って片付けしてたら、なぜかもう 1台 SCSI ディスクが出てくる。
5" フルハイト 330M SCSI1 なんて代物なのですっかり存在を忘れてたが、今の news68k には十分。
早速つなげてテスト。……。 disklabel, newfs, mount とも問題なし。うんうん。
"root on sd1a" で立ち上げるべく tar でディスクにファイルを移す。
が、予想どおりというかなんというか遅過ぎ。「こんこんこんこん」みたいな seek 音で眠くなってくる。
まあ止まりはしないみたいだからしばらくほっとこう……

そうこうしてるうちになんとか終了。 /etc/fstab その他も修正。
よく考えたら newsmips 上で転送すれば 10倍速く済んだような気もするが、 load test したと思えばいいや。
boot loader はまだ NEWS-OS のが必要なので installboot だけ NEWS-OS 上で実行。

で、起動。おし、ちゃんと立ち上がった……かと思いきやいろいろ core 吐いてるぞ。おいおい。
fsck とか mount とか軒並動かん。 fsck_ffs や mount_ffs は OK。なんなんだ?
gdb で見てみると strcmp() で落ちてる。
ひょっとして……と思って /etc/fstab 確認すると root の mount point "/" を書くの忘れてる。
fstab 修正して起動。……ちゃんと起動した。うーむ。
間違えたのが悪いといえばそうなんだけど、 core 吐いて死ぬのはちょっとねぇ。

無事に起動したので表のページをまたちょっとだけ更新。 Boot message log はそちらにあります。
しかし泣くほど遅いな。 diskless の時の 10倍以上遅い感じ。実際そうなんだけど。
まあ、 kernel 作り直すたんびに NEWS-OS 起動して ftp する必要がなくなっただけでもよしとしよう。

さて、まがりなりにも動くようにはなったわけだけど、どうしたものか。
ここで区切りつけちゃうか、もう少し直してからにするか……
ncr5380sbc.c もよく見たら 2か所 #if 0 でコメントアウトしただけだな。うーむ。
とりあえず次は boot loader を始めてみるのが妥当な線かな?

ということで今日はもう作業やめてぐるぐる。
TBIA() その他は昔の記憶によれば m68k/cacheops.c もしくは locore.s とかにあります。
x68k がどう変わったのかは確かめてませんけど。以前は locore.s の中でした。
pmap.c で #include <m68k/cacheops.h> してない、ってやつかな?
ところで cacheops.c だと L2 cache の扱いがちゃんとしてないんですよねえ。どうすべきなんでしょ。
VENUS-X ってのは 2次キャッシュがつくようですが、これで NetBSD/x68k 試してる人はいない?
なんと bus snoop までしているそうだから大丈夫なのかな?

ASCII の BSD magazine 正式発表らしい。
しかし日刊 ASCII Linux 中の紹介記事のほうが詳しいのはそういうもの?
目次の「NetBSD (その他)」ってのもこれだけ見るとなんだかわけわかんないですね ;-p

19990924

メールで itojun さんのはっかーずぱらだいすにある Kernel hacker のための cvs 入門のページを教えて頂きました。
おお、まさに求めていたような説明です。ありがとうございます。ふむふむ。
tag のつけかたとか diff の作り方とか、どうすると一番よいかもうちょっと調べてみよう。

大学の研究室時代の先輩からも読んだよメールが届く。ありがとうございます。
「printf() が動いた感動」をわかってくれる人ってほとんどいないんですよねえ、というネタで笑って頂けるだけでも十分です ;-)

と、いろいろ励ましを頂いたところで今日も眠い頭で news68k SCSI の続き。
昨日から出ている "panic: pool_put" ってのは /sys/kern/subr_pool.c の中。
そもそもこんなところで落ちるのは根本的にどこかがおかしいような気がする。
PIO 転送の polling で動いてる arch ってほんとにあるのか?

昨日の結果から、割り込みかかりっぱなしになるのは BUSY monitor のせいというのは確か。
なので BUSY monitor を無効にした上で再度割り込みハンドラで si_intr() を呼ぶようにしてみる。
起動して disklabel sd0。……お、 panic しないぞ? ほんとか?

debug message だらけで何が起こってるんだかわけわからんので NCR_TRACE() 無効にして再度試す。
えい。……おぉ、なんかセクタ数とかいろいろちゃんと出てくるじゃん。
が、 "sd0: no disk label" とも言われてる。 newsmips だと NEWS-OS の disklabel も読めるのに……
dd して /dev/rsd0c 読んでみる。一応それっぽい中身が読めてるような……

ふと気づいて news68k/include/disklabel.h を確認してみる。
と、案の定 hp300 のやつを使ってた。というわけで newsmips から持ってきて作り直す。

で、またまた disklabel sd0 する。えい。

# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: hdsd00_639
[...中略...]
8 partitions:
#        size   offset     fstype   [fsize bsize   cpg]
  a:    31768        0     unused     1024  8192         # (Cyl.    0 - 32*)
  b:   181760    31768       swap                        # (Cyl.   32*- 221*)
  c:  1309896        0     unused      512  4096         # (Cyl.    0 - 1355)
  d:    21884   790527     4.2BSD     1024  8192    16   # (Cyl.  818*- 841*)
  e:   307200   812411     4.2BSD      512  4096    16   # (Cyl.  841*- 1159*)
  f:   190285  1119611     4.2BSD     1024  8192    16   # (Cyl. 1159*- 1355)
  h:   576999   213528     4.2BSD     1024  8192    16   # (Cyl.  221*- 818*)
disklabel: warning, partition b: offset % cylinder-size != 0
[...後略...]

おし、いい感じ。 mount -r や fsck -n も問題なさそう。まだ恐くて read only のみだけど。
書き込みも試してみたいけど、あいにくテストに使える空きディスクがない。
NEWS-OS のディスク壊しちゃうと NetBSD も boot できなくなるからなあ……
予備の SCSI ディスクのうち 1台は故障中。もう 1台は sun3 make build 用に使われちゃってる。敗北。
i386 の sd0 の中身を空いてる wd1 に移して 1台浮かせるか。めんどくさ。

とりあえず NEWS-OS のディスクをいろいろ読んでみる。
が、何をするにも遅過ぎ。 m68k CPU の PIO 転送だからそんなもんだというのはわかるが。

どれくらい遅いか計ってみる。

# dd if=/dev/rsd0c of=/dev/null bs=64k
^C179+0 records in
179+0 records out
11730944 bytes transferred in 286 secs (41017 bytes/sec)

うーむ。はるか昔(1.0A くらい?)の sun3 もこんな感じだったなあ。懐かしい。
で、 DMA が動くようになったら 700kbytes/sec くらいになって、それで速い速いと喜んでたような。
さて、 news68k でも DMA やるとしたらどこから手をつけたものか。
それより CXD1180 の信号モニタまわりの動作仕様を先に確認すべきかしら。うーん。

19990923

昨晩は結局朝までごちゃごちゃ。おかげで今日は眠くてなにもできん。
とりあえず昼にしかできない所用をいろいろ済ませて後は寝て過ごす。

起きてみると sun3 はまだ終わってない。今 groff の途中。
これだと full set のバイナリ作ろうと思ったら 1週間かかるな。

newsmips の boot floppy の件だけちょっと調べてみる。
mdsetimage で kernel file を mmap() したところに fs image を read() するところで落ちる。
深く考えず mdsetimage を static で作って 1.4R の boot floppy を起動してそこで image を書き込んでみる。
あとは手動で vnconfig だの installboot だのして newsmips 1.4K の boot floppy のできあがり。
だからどーした、と言われてもそれだけだけど……いわゆる「動いてしまったらどうするか問題」ですな。

眠い頭で news68k SCSI も少しだけ考えてみる。
log からすると arbitration, select, message out, command, status, message in, complete までは正常。
この直後で割り込みがかかって、そこで BSY が落ちてて unexpected disconnect になってる。
しかしここからあとはターゲットが disconnect の message を送るだけのはず。
なのにここで割り込みがかかるのは実際にここで BSY が落ちてるのか?
そもそも FORCE_POLLING の設定してても BUSY monitor の割り込み設定してるけどそんなものなのか?
Lost Arbitration フラグもそうだったけど、微妙に読みだしタイミングの違いとかあるのかしら。
arm32 はともかく vax の ncr.c は PIO でそれなりに動いてるみたいだし……

とりあえず ncr5380_select() で BUSY monitor 設定しないようにしてみる。
割り込みかかりっぱなしは直ったようだ……が、結局今朝と同じく "panic: pool_put" で死亡。
だめだこりゃ。寝よ。ぐぅ。

19990922

sun3 の make build は昨日の時点から 20時間後に sun3/stand/netboot 以下で undefined symbol で停止。
intoa() と int_addr() が libsa から libkern に移ったせいらしい。
あとで適当に send-pr しておこう。引き続き games, gnu 以下で make 続行。

並行して newsmips の boot floppy を再度作ってみる。
1.4R で使ってた distrib/newsmips 以下のファイルを持ってきて適当に修正。

……。途中まで順調だったけど、つばいさんの言っていたとおり mdsetimage で panic する。

trap: TLB miss (load or instr. fetch) in kernel mode
status=0xfc14, cause=0x10000008, epc=0x100000, vaddr=0x100000
pid=211 cmd=mdsetimage usp=0x7ffffa08 ksp=0xc419cc50
Stopped in mdsetimage at 0x100000:trap: TLB miss (load or instr. fetch) in kernel mode
status=0x8fc14, cause=0x30000308, epc=0x80109f50, vaddr=0x100000
pid=211 cmd=mdsetimage usp=0x7ffffa08 ksp=0xc419cb10
Stopped in mdsetimage at        0
80109f50:      lw      a0,0(v0)
db> trace
80109f40+10 (100000,0,0,0) ra 800088d4 sz 24	← db_disasm()
800088a4+30 (100000,0,0,0) ra 8000b4cc sz 24	← db_print_loc_and_inst()
8000b3f0+dc (0,0,0,0) ra 8010aaf4 sz 32		← db_trap()
8010a8d4+220 (0,0,0,0) ra 8010ddf8 sz 48	← kdb_trap()
trap+18c (fc14,10000008,100000,100000) ra 80002098 sz 72
mips1_KernGenException+c4 (81eb5348,c0062040,2022a000,80145040) ra 100000 sz 120
PC 0x100000: not in kernel space
0+100000 (81eb5348,c0062040,2022a000,80145040) ra 0 sz 0
User-level: pid 211
db>

うーん。locore_mips1.S まわりなのかな。 pmax とか arc とかだとどうなんだろ。(ぼそっ)

mips はよくわからんのであきらめて news68k SCSI を始める。
その前に NCR5380 のマニュアルを探してみる。
NCR 改め SYMBIOS 改め LSI LOGIC を探すが、マニュアルはなくて概略仕様説明しかないようだ。
AMD の SCSI chip のページに互換品のマニュアルがないかと探すが、こちらにもない。
最後に Alta Vista で検索をかけたら National Semiconductor の DP5380 のマニュアルがあったので入手。

マニュアル見ながら NetBSD のソース眺めたり NEWS-OS のバイナリ調べたり。
screg_1180.h には NCR5380 にはない "Extended Mode register" という記述がある。
なのでこれをいじる必要があるのかと思ったが NEWS-OS の scsi_1180.o では特に触ってないようだ。

もう一度 NCR_TRACE() の表示を出して動作を確認してみる。
……。 "unexpected disconnect." と言われるのは変なタイミングで割り込みが入っているからなのか?
そもそも PIO 転送時の割り込みはどういうタイミングで起こるのが正しいんだろうか。
再度 "NCR5380_FORCE_POLLING" セットして割り込みハンドラでも si_intr() 呼ばないようにしてみる。
……。割り込みかかりっぱなしのせいか止まってるように見えるが、気長に待っていると debug message が少しずつ進んでいく。

5分ほど待ってたら 1 sector read らしき 512byte の転送まで進んだけど、そのあとで panic した。

machine: discon, waited 0
sched: machine done, cur=0x0
sched: no work, cur=0x0
scsipi_cmd: sched done, cur=0x0
pool scxspl: putting with none out
panic: pool_put
syncing disks... done.

うーむ。結局よくわからん。
変に PIO で悩むよりいきなり DMA にチャレンジしてみたりしたほうがよいのだろうか。

19990921

cvs の option は ~/.cvsrc に "update -Pd" と書いておくとよいですよ、とメールを頂く。
どうもありがとうございます。人に頼ってばかりいないでちゃんとマニュアル読まないとなあ。
RCS 入門みたいな CVS 入門のページってないもんでしょうか。 UNIX MAGAZINE 引っ張り出すか……
それにしても最近いろんな方からメールをもらうようになりました。やっぱり *BSD Diary Links の影響大?

なんだか今日は頭痛気味で調子いまいち。
SCSI 調べる元気が出ないので current 化の状況報告だけ。

sparc, alpha は make build 問題なし。
newsmips は newsmips/stand 以下で make obj してると問題ありだったので send-pr 済。
sun3 は……現在 usr.bin/tn3270 あたり。あと 2日くらいか? (ただし MKMAN=no, MKLINT=no 設定)
sun3x で NKMEMCLUSTERS を増やしとかないと panic するのはほんとに足りないのか bug なのか。
それ以外のマシンはまだ 18日以前のバイナリのままで試してない。
news68k で make build するのは……たぶんできなくはないけど現状ではあんまり意味なさそう。
やるとしたら SCSI 動いた後の耐久試験としてかな。

そういえば IPv6 はまだ一度も試してないなあ。
一通り make build 終わったらやってみようかな。設定法全然知らないけど。

19990920

cvs update は "cvs update -d -P" が良いと思う、と曽田さんのお言葉。
file が足りないところで適当に cvs update 実行。
"back out...; too many people complained." なんていういやな commit log が流れてたりするけど……

ちまちまと news68k current 化作業開始。
diff 使ったり vi 使ったり mule 使ったり rcs 使ったり。
1.4R からの変更点はだいたい以前調べたとおり。ほかは INET6 まわりくらい。
約 1時間半で merge 作業完了。思ってたより手間じゃなかった。
make してみる。 2か所 typo があったがそれ以外は問題ない。ほんとか。

んでいつものように起動。……。 "nfs_boot: timeout..." とか出るけどこれは arm32 の de のせいかな。
それ以外は今のところ特に問題なさそう。
というわけで表のページも更新。といっても見た目あんまり(全然?)変わってるとこないけど。
kernel binary は置いてもしょうがないかな。 source だけにしよ。
で、次は SCSI か。こいつはまあ明日以降だな……

19990919

昨晩の NetBSD 本家の CVS update が遅かったせいか、 sup したソースが最新のになってない。敗北。
昨日のうちに thorpej 氏による autoconf.c まわりの変更が入ってるのでこいつは取り込んでおきたい。
というわけで、結局 sup から cvs import, update までやりなおし。
幸い朝の時点では sup.jp.netbsd.org も更新されてた。update script だけしかけて寝直す。

午前中で無事完了。とりあえず各種マシンでちゃんとコンパイルできるか試す。
……特に問題なさそう。ついでに sparc も ELF 移行作業をする。といっても手抜きして snapshot 使用。
あっさり移行完了。うーん、 i386 も変に細工せずに素直に snapshot 使った方がよかったかも。
sun3 と newsmips は型宣言まわりで一部エラーが出たのでとっとと send-pr する。
その他 alpha, macppc 等は kernel まわりについては特に問題なし。
powerpc が直ってない、って書いたのは間違いで 14日の時点で直ってました。

と、 newsmips の比較で hpcmips を参照しようとして sys/arch/hpcmips 等が作られてないのに気づく。
もう一方の新 arch の sh3, evbsh3, mmeye もない。
sup したツリーや CVS repository には入ってるので、 cvs update で作成されていないようだ。
man を調べてとりあえず "cvs update -d" とすればよいらしいのでそうしておく。

……などとやってると、別の用事もあって news68k にまで手を入れる時間がなくなってしまった。
まあ、 userland まわりも特に問題ないみたいだし、しばらくはこの source tree で作業すればよさそう。
なので news68k current 化もあせらずぼちぼちやることにしよう…… (こればっかりやな)

19990918

なんとなく流行に乗って街の本屋に SuperH プロセッサの本を買いにいく。が、いずれの店も在庫なし。
なぜか箕浦さんの名前にひかれて ;-) 今さらながら Oh!X 夏号を買う。
本当のところは m68k の MMU と MIPS 関連の記事が載ってたから。結構貴重かも。
しかし、なによりも「無改造 MZ-700 でビットマップ表示を」の記事に感動。
そういうことを考えるのもすごいが、そういうことを試せるマシンがいまだにあることのほうがすごいかも。
news68k なんて足元にも及びませんね ;-p

どうせ current の update には一晩かかるだろうから、その前にもう一度 news68k を clean up する。
まず内部ポートアクセスの volatile 有無チェック。ないところは追加。ついでにすべて u_char で統一。
次に NEWS-OS と交互に起動した時 RTC の年が狂う件を調べる。
現行のは mvme68k/clock.c ベース。 newsmips/clock.c とを見比べてみる。
mvme68k のは sun3 のがベースで、 RTC の年が 0の時 1968年としている。
それに対し newsmips (というか NEWS-OS)は年の下2桁をそのまま BCD で表しているようだ。
ということで clock.c 内の YEAR0 の記述を削る。再起動してテストも OK。
ふと 2000年問題が気になってテストしてみたが、特に問題ないようだ。

ほかにも直したいところはいろいろあるけど、対処法がわからんところばかり。
なので後は current update script だけ用意して明日頑張ることにしよう……

19990917

A社の B誌は 9月28日発売だそうです。
しかし、あれを買うのはいったいどういう人たちなのでしょうか ;-p

olseek() の修正は無事 commit された。すでに判明してたらしいけど、勉強になったからいいや。
hp300 と next68k の PMAP_NEW まわりも直ったようだ。 powerpc はまだみたいだけど。
でも、なんだか libc まわりに大量に修正が入ってるから sup するのためらってしまうな……

news68k の current への update 方法を考えてみる。
hp300 の 1.4R と current の diff を見ながら手修正、ってのは考えただけで大変。
rcsmerge が使えないか試す。 1.4R の hp300/pmap.c を適当な場所に copy して check in。
次に 1.4R ベースの news68k/pmap.c を上書きして check in。これで hp300 → news68k の変更点が出る。
最後に current の hp300/pmap.c を上書きして rcsmerge する。うん、結構うまくできてるかも。
って、こんな間抜けなことせずとももっと賢くやってくれる tool がありそうだけど……

current 化の準備として、結構な変更が必要そうな ncr5380*.[ch] を news68k/dev/ に持ってくる。
最終的には MI 側に quirk 処理追加でなんとかするようにしますから今は見逃して下さい >某偉い人
ほかに、 L2 cache 不具合対策で PG_CI マークしてるところを options で切替えられるようにしておく。
1.4R ベースの状態で確認しようと思ったが、 i386 は current にしてるから config(8) が通らない。
まあ、明日は出勤日だから日曜日が勝負だな。

19990916

祝! port-news68k.html 300kbyte 突破(ぉぃ)じゃなくて、 NetBSD/hpcmips import おめでとうございます。
ちなみに過去の記述を手繰ると 100kbyte 突破は 19990604 で 200kbyte 突破は 19990710 らしい。
書き始めたのは実質 5月の頭からだから、一応当初のペースからは半分に落ちてるようだ。
なお、依然として分割の予定はありません。だってめんどくさいんだもん ;-p

現実逃避中な方 ;-) から DESTDIR="/../." でちゃんと動きますよ、とメールをもらう。
"/" を指定すると "/emul/aout" を見るんだから、 "/../../" にすれば本物の "/" が見えるのだろうと思ってたのだが…
よく考えると "/emul" 以下に該当ディレクトリがなければ問題ないのか。
が、残ってた a.out の bash の挙動を ktrace(1) で調べてみると、それとも違う。

"ktrace bash /.././usr/local/lib/.profile" とすると、

   684 bash     CALL  open(0xa2ccc,0,0xa2ccc)
   684 bash     NAMI  "/./usr/local/lib/.profile"
   684 bash     RET   open -1 errno 13 Permission denied

と、"/emul/aout" は一切見ずに、最初の "/.." を取った path を見にいってる。
COMPAT_* の仕組みは真面目に調べたことなかったのだが、ちゃんとソースを読んでみる。

と、最終的に行き着いた /sys/compat/common/compat_util.c の emul_find() に

/*
 * We provide an escape method, so that the user can
 * always specify the real root. If the path is prefixed
 * by /../ we kill the alternate search
 */

と書いてありました。実は hack というよりも仕様だったのですね。 man には書いてないけど。

/sys/compat/ 以下を調べたついでに、 netscape の history.db が変な件も調べてみる。

該当箇所の ktrace(1) 結果は以下のとおり。

   911 netscape RET   read 260/0x104
   911 netscape CALL  compat_43_olseek(0x7,0,0,0x59d800,0xefbfbd24)
   911 netscape RET   compat_43_olseek -1 errno 22 Invalid argument
   911 netscape CALL  compat_43_olseek(0x7,0,0,0x59d800,0xefbfbd0c)
   911 netscape RET   compat_43_olseek -1 errno 22 Invalid argument

某所の 1.4R なマシンで同じ場所を確認すると、

  8298 netscape RET   read 260/0x104
  8298 netscape CALL  compat_43_olseek(0xa,0,0)
  8298 netscape RET   compat_43_olseek 0

なんか文字通り "Invalid argument" な感じ。なんなんだ。

じーっ、と /sys/kern/syscalls.master と /sys/compat/aout/syscalls.master とを見比べる。
……。 aout/syscalls.master の 19番 sys_lseek() は compat_43_sys_lseek() であるべきなような……
とりあえず試してみる。syscalls.master 直して aout_syscall*.[ch] 作り直して kernel make。
んで reboot して netscape 起動。……よっしゃ、完璧。
というわけで send-pr する。しかし今まで誰も困ってなかったのなあ。

19990915

さらに海外からお返事。「それは残念。でも応援してるから頑張ってくれ」とまたうれしいお言葉。
次は current ベースへの更新作業かな。 SCSI の検証はそのあとだな。

んで current source tree の update 開始。まずは今までどおりに sup をかける。
次に cvs import する。……さすがにディスクが忙しそうだ。
約 1時間20分で import 完了。当たり前だが conflict はない。で、次に cvs update する。
```
% cd /usr/src
% cvs -d /cvs/repository update -j current-19990910 -j current-19990914
```
こちらは約40分といったところ。 merge も特に問題ないようだ。

news68k から作業しようと思ったが、その前に i386 を更新することにする。
NetBSD ELF FAQ や神戸さんのメモを見ながら ELF binary 移行作業。
"DESTDIR=/../.." というのが肝ですな。どちらのメモも "../." になってるのは書き間違い?
うちでは COMPAT_AOUT ファイルを /usr/emul/aout に置いたので "DESTDIR=/../../.." とする。
linux emulation や cross compile 用 library は /emul/aout 以下に移動させないよう注意。
/usr/libexec/ld.so も /emul/aout 以下に移動した方が consistent かな?

いろいろ変更中のせいか make(1) の動きが変なような気がするがそのまま続ける。
BOOTSTRAP_ELF を設定して、 GNU toolchain は OBJECT_FMT=a.out で作成しインストール。
次に libc_pic.a を作成し lib/csu 以下を作ってから ld.elf_so 作成。
んで、あとはいつもどおりにひたすら make build。
……が、いくつかファイルが足りない。 cvs import で "-I \!" つけるの忘れてたようだ。ごーん。
間抜けなことに自分で書いたメモに書き忘れてたので修正。どーもすいません。
さらに DESTDIR 設定してたらいくつか make できないものがあったけど、これって make(1) のせい?

一応それなりには ELF 化できたようなので再度いろいろ確認。
ん? netscape の history.db が正常にアクセスできてないような。リンクが全部青色。 cache は OK。
ちなみに version は BSD 用 3.04 だったり。そんなもん使ってるのが悪いと言われそうだが…
ktrace(1) で調べてみると compat_43_olseek() で "Invalid argument" とか言われてるけど、このせい?

news68k の current 化のために PMAP_NEW の変更をちょっと見てみる。
が、 hp300 pmap ベースの m68k では全然ダメらしい。 sun3 と mac68k は確認済ってことなのに。
powerpc も問題ありらしい。まあこれはすぐ直るだろうけど。
arm32 は普通にコンパイルできたけど、恐くてまだ走らせてない。
ちょっと早まったかなあ。まあ i386 は問題なかったからいいや。

19990914

表のページを更新したのと関係あるのか、海外から 2件目の news68k 問い合わせメールをもらう。
なんと「マシン持ってるからぜひお手伝いしたい」という大変ありがたい申し出。
しかし、いかんせんマシンが NWS-1850 だとのこと。うーん。
残念だけど、 IOP マシンのサポートは現状ではまだ難しいです、とお詫びの返事を書いておく。

先走って arm32 も current 化を始める。
まず CATS で "opms at pckbc?" を使えるようにするパッチをあてる。
tlp ドライバも試そうかと思ったが、まだ 21143 等はサポートしてないようだ。
kernel については作成も起動も問題なし。
userland も特に問題なし。ただし make build 中 daily cron が走った時に一度固まってしまった。
うーん。まだどこかに問題ありなのか。

次にふたたび CVS の練習。 opms まわりを commit してみる。
マニュアル見ながら arch/arm32/conf に移ってテキトーに cvs commit してみる。
```
% cvs -d /cvs/repository commit files.arm32
```
commit log 書いてあっさり登録された。これでいいのかな。
次は arch/arm32/isa/ 以下で pms.c の追加。
新規の場合は cvs add してから cvs commit すればよいらしい。

current のほうは alpha の memcpy() の prototype の件もあっさり修正されたようだ。
PMAP_NEW や sh3 の件もあるし、今晩あたりまた sup して cvs import 2回目と cvs update も試してみるか。

19990913

安易に登山家なんていってると途中で遭難したりして……

NetBSD/hpcmips の mailing list のページが重たくなってきたので ;-p ちゃんと subscribe することにする。
せっかくなので NetBSD/sh3 のほうも subscribe する。と、その途端メール流量が爆発。うお。
それもそのはず、 NetBSD/sh3 正式 import どうもおめでとうございます。
さらに NetBSD/hpcmips の commit も間近のようだ。
というわけで(?)、 news68k の表のページもちょっとだけ更新。

macppc の ukbd.h の件はつばいさんの指令により send-pr して即 close された。うむ。
gethostbyname(3) がおかしい件もつばいさんからメール。
libc/net/gethnamaddr.c の _gethtbyname2() の中で、 static char hostbuf[] と malloc() された char *tmpbuf が同じ alignment であることを仮定しているのがおかしい、とのこと。
powerpc では machine/param.h の ALIGNBYTES が最大 alignment である (sizeof(double) - 1) にしてあるのでこの現象が発現する、と。

うーん。素人の私にはなんとなく意味がわかっても解決策など見当すらつきません。
そういうわけで、あとは曽田さんよろしくお願いします。ぺこり。 _o_
ちゃんと確認してないけど mips も ALIGNBYTES == 7 みたいですしー。

19990912

current 化の前にいろいろ準備。
懸案だった i386 と arm32 の 100BASE-TX NIC 入れ換え。 ex を i386 に、 de を arm32 に。
kernel には前から両方組み込んであるので rc.conf と ifconfig.* を直すだけ。

current のソースは /work/current に sup して /work/current/src 以下に用意してある。
CVS repository は適当に /cvs/repository に用意。いずれも arm32 の CATS 上。
で、 /work/current/src に移って cvs import 実行。 module 名は安直に src とする。
```
% cd /work/current/src
% cvs -d /cvs/repository import -I \! src netbsd current-19990910
```
src の次の netbsd はベンダー名で、 current-19990910 はタグ。
時間がかかりそうなのでしばらくほっておく。

次に CVS 作業領域の作成。の前に、 repository と作業領域は別のディスクにした方が merge 等が早いかも、ということでパーティション入れ換えたり。
……こんなもんかな。で、 cvs checkout で作業領域作成。作成場所は予定どおり /usr/src 直下。
```
% cd /usr/src
% cvs -d /cvs/repository checkout -d . src
```
最初の -d は repository の path で、 checkout の後ろの -d は checkout 先のディレクトリの指定。
最後の src は import の時に指定した module 名。
……。 180M くらいあるからさすがに時間がかかる。で、約40分で終了。
というわけで最初の導入作業は無事終了。今後の merge 作業等についてはまた改めて。

まず失敗しても影響の少ない(単に仕事してないだけともいう) alpha で試す。
いつものように TCWSCONS をベースに config して make。問題なく作成できて起動も OK。
userland はなげやりに "make obj && make build" してしばらくほっておく。

次にこれまた最近動かしてない macppc で試す。
"WARNING: clock gained 69 days" なんて言われてしまう。う〜む、そんなにさわってなかったか。
config して make しようとすると ukbd.h がないと怒られる。
調べてみると files.usb の ukbd から "needs-flag" がなくなっている。
とりあえず port-powerpc-ja に報告だけして、手で作ってごまかす。
こちらも作成、起動とも問題ないので userland を build する。

make build 中に m68k まわりの current での変更点チェック。
まず細かいところで COMPAT_14 や COMPAT_SVR4 の記述追加。
spl() の定義が arch/m68k/include/psl.h に移動。
machdep.c での allocsys() の MI 化。
pmap まわりの変更。 pmap_ptpage_addref(), pmap_ptpage_delref() 追加と pmap_extract() API 変更。
pmap_change_wiring() → pmap_unwire() の改名と pmap_pageable() 削除。
てな感じか。……とかやってたら chs 氏の PMAP_NEW 化のコードが commit されてしまった。ぐがが。
まあ、予告どおりといえばそうなんだけど、 m68k は大丈夫なのかしら。
いずれにせよ news68k の current 化は後日か?

……と、今度は alpha が sbin/badsect の ffs_bswap.c で memcpy() の declaration 云々と文句を言われてる。
確かに /sys/sys/systm.h から memcpy() の prototype がなくなってる。
macppc は無事に build できたが、 ifconfig(8) その他の動作が変。
ifconfig vr0 [host名] とすると全然違う IP address がついてしまう。 IP address 直接指定なら問題なし。
gethostbyname(3) が変なのかこちらも memcpy(3) が変なのか…
i386 と arm32 の current 化もちょっと様子見たほうがいいのかなあ。

19990911

『そこに山があるからだ』の用法は海外でもおんなじらしい。
登ってしまったら登山家はやっぱり次の山を探すのだろうか。

なんの脈絡もなくタイマ割り込みルーチンを見直す。
割り込みルーチンの先頭では CTRL_TIMER ポートに 0 と 1 とを順に書いて pulse edge を送る必要がある。
が、以前 IIOV() マクロを使わないようにしたときにはなぜか DELAY(1) をいれる必要があった。
```
*(char *)CTRL_TIMER = 0;
DELAY(1); /* ←これ */
*(char *)CTRL_TIMER = 1;
```
割り込みルーチン内で DELAY() なんてしてらんないし NEWS-OS は何もしてないので再確認する。
DELAY(1) を __asm("nop") に置き換えるがダメ。数増やしても変わらず。
と、逆アセンブルして確認すると最初の 0 の書き込みがない。 optimize で削られたらしい。やられた。
いろいろ調べて、結局 *(volatile char *) にすればよいことが判明。
そーかー、 volatile ってそういうことだったのかー。いやぁ素人なもんで。

直したところで egcs やら binutils やら news68k 上で作り直してみる。
ついでに tetris(6) を動かすべく /usr/games 以下も build する。
……。早くなったかどうかはよくわからん。ひとまず tetris(6) は console でも元気に動く。
というか、 news68k の作業もさることながら news68k 自身にこんなに仕事させるの何か月ぶりか……

次に、半日かけてようやく current source tree ができたので CVS による source update を試す。
……。うーん。よくわからん。どの引数が何を示しとるんだ。

数分間格闘してなんとなくわかってきた。
まず、 $CVSROOT ディレクトリ以下に "CVSROOT" というディレクトリを作る必要あり。
基本的に import/checkout ともカレントディレクトリと CVS repository との間でやりとりする。
import の時はカレントディレクトリ以下の内容が $CVSROOT の "repsoitory 名のディレクトリ" の中に入る。
checkout の時は repository の内容がカレントディレクトリの "repository 名のディレクトリ" の中にマージしながら入る。
www.netbsd.org の説明ページの例で言えば、 $IMPORTROOT 以下に sup して $SRCROOT/"repository name" 以下で build する、ということ。

ってことは /usr/src 直下に build source tree を作ろうとすると難しいのか?
repository 名が netbsd だとして、 /usr/src 以下に netbsd -> . の symbolic link を作るのは反則?
それとも repository 名を src にして /usr に checkout すればいいのか?

……などとテキトーなことを書いていたら、ねらいどおり曽田さんからメール。どーもどーも。
まず CVSROOT ディレクトリは "cvs init" すれば自動的にできるとのこと。
あと "repository 名" というのは適切ではなく "module 名" が正しい、と。
その他わからないところをここぞとばかりに質問したりして。
というわけで今日 2回目の更新。以下に CVS のまとめ。

repository (==$CVSROOT) が一つだけあって、ここに "*,v" のファイルをすべて置く。
import 元のディレクトリは CVS とは無関係。
import によって $CVSROOT 以下に "*,v" のファイルが作成される。
checkout は import された module の repository から「CVS 作業領域」を作るコマンド。
「CVS 作業領域」を作る場所はどこでもよい。ただし $CVSROOT 以下には作ってはいけない。
作業領域、つまり checkout 先のディレクトリは cvs checkout -d [directory] [module 名] で指定可能。
ディレクトリ指定しない場合は、カレントディレクトリの "module 名のディレクトリ" に作られる。
cvs commit, cvs update 等は「CVS 作業領域」内であれば常に使用可能。

よって、 current のおっかけの場合は
1. (CVS とは関係ない場所で) sup して最新の current を用意する
2. 次に、 sup した tree を cvs import して CVS の repository に取り込む
3. 初めての場合は cvs checkout して作業領域を作る
4. 2回目以降の更新では、新たに sup したものを cvs import したあと作業領域内で cvs update する
ってことですな。
たぶん cvs commit は逆に作業領域の変更を repository に入れるものですね。
さ、今から試してもう少し具体的手順まとめてみるか。

19990910

TNF Copyright にするのに紙がいるのは、 contribute されたコードが他の Copyright を侵害してたりしないか等の責任を明確にするため、とのこと。
たーしかに。権利には義務と責任が伴うわけですからね。

おとといの send-pr は一日半遅れでようやく返事が来た。 kern/8357 だそうだ。
と、 1時間少々で速攻 close されてた。よしよし。

NetBSD/prep も動きつつあるらしい。
NetBSD/ofppc とは違って OpenFirmware を使わずにやってるんですね。

今日はメイン端末の NetBSD/i386 不調。 mail 作成中に 2回も固まる。 2通が lost してしまう。
というわけで、ふたたび current 化の検討を始める。
どうせなので CVS でも使うようにするか、ということで Tracking NetBSD-current with CVS の説明見ながら設定を考える。

うーん。 source tree が 3セット必要、ってのはわかるけど、各コマンドのどれがどの directory なのかしら。
最終的に build する directory は今までどおり /usr/src 以下にしたい。
sup する source tree と CVS import のディレクトリはどこでもいいんだけど……
とりあえず current の tar_files を取ってくる。が、回線遅過ぎ。
ところで、今は current source tree の更新も sup ではなく cvsup 使うのが主流なのでしょうか?

ftp してる間に懲りずにまた news68k SCSI 確認。なんとなく make cleandir して kernel を作り直す。
……と、なぜか parity error の trap が出なくなってしまった。なんなんだ。
たしかにここしばらく make clean してなかったけど……。 NFS server の arm32 が変だったのか?

深く考えるのはやめて別のことを試すことにする。
machdep.c に si のハンドラ作って attach routine 内の NCR5380_FORCE_POLLING の flag をはずす。
が、変わらず。 printf() はさんでみると、 level 4 の割り込みかかりっぱなし。あれ?
よく見たら #if NSI > 0 してるのに #include "si.h" してなかった。ぐは。

直して再起動。今度はどーだ。えい。

[...前略...]
libero# disklabel sd0
ncr5380_machine: unexpected disconnect.
panic: ncr5380_done: state=idle
syncing disks... done
rebooting...
NEWS>

うぐぅ。まあ、 panic() するだけまだましか……

19990909

NetBSD/sh3 も merge 間近らしい。
ところで、ソースを The NetBSD Foundation Copyright にするのに紙ベースの手続きは必須なんでしょうか?
news68k でもごく一部の自分で書いたファイルは勝手に TNF Copyright にしてしまってるんですが……
Am53c974 の send-pr の時は勝手に TNF Copyright にして出してました。 pcscpreg.h とか。
結局 thorpej 氏により私の名前が contributor のとこに足されてそのまま commit されました。
send-pr の integrate と通常の commit とでは違うのかな。

問題の CTRL_PARITY, CTRL_PARITY_CLR を調べてみる。
news5000 の清水さんにも協力して頂く。どうもありがとうございます。
結局、そんなに難しいことはしてなくて一回ずつ叩いてるだけらしい。むむ。
ちなみに割り込みベクタと飛び先の設定もちゃんとされてた。
よく見たら adremap.h にも PARITY_VECTOR ってのがあるし。

確認のため config から SCSI だけはずした kernel を作ってみる。
起動。……やはりこちらは parity error は発生しない。うー。

とりあえずいろんなところで CTRL_PARITY_CLR を叩くようにしてみる。
が、とくに変化無し。次に割り込みハンドラでっちあげて CTRL_PARITY_CLR 叩いて return させてみる。
……。叩いても叩いても発生しているようだが、アクセスの度に起きているわけでもないらしい。
"parity error ignored" の printf() に埋もれつつも login: の prompt は出てきた。うーむ。
なんとか login もできた。が、 SCSI にさわった途端に freeze してしまう。
disklabel(8) も mt(1) もダメ。 console も ping も応答がないので完全に死んでる。

newsmips/dev/scsi_1185.c には次のような注釈がある。

*      DMAC_WAIT       --- DMAC_0266 wo tukau-baai, DMAC mata-wa SCSI-chip ni
*                              tuzukete access suru-baai,
*                              kanarazu wait wo ireru-beshi !

実際 NEWS-OS の scsi_1180.o では nop が 6つほどはさんである。

これに対し、ncr5380var.h ではレジスタアクセスが次のように定義されてる。

# define NCR5380_READ(sc, reg)          (*sc->reg)
# define NCR5380_WRITE(sc, reg, val)    do { *(sc->reg) = val; } while (0)

なので "ireru-beshi!" などと言われてもちょっと困ってしまう。
とりあえず ncr5380*.[ch] を MD に持ってきていろいろいじってしまうか……

19990908

今日は早く帰ったものの、なんだかやる気出ず。
ぼーっと意味もなくゲームに興じたり。なんかダメ。

とりあえず NWS-1750 内蔵 QIC の SCSI quirk エントリ追加 request の send-pr を書く。
……。 gnats-bugs からなかなか返事が来ない。調子悪いのかな。記述間違えてないよなあ。

Unified Buffer Cache 作業中の Chuck Silvers 氏から "enable PMAP_NEW for all platforms" の提案。
mac68k, sun3 でも動いてるってことは他の m68k もコードはできてるのか?
メールにある diff の URL にはアクセスできないみたいだけど……
next68k で動くようならば news68k もほとんど同じ変更でいけるだろう。
pmax は動いたそうだが、arm32, powerpc だとどうなんだろう。
あんまり関係ないけど、元のメールが mail-index.netbsd.org のアーカイブにないのはなぜかしら。

19990907

ふぬけてたのもつかの間、ふたたびハマリモード突入。うつうつ。
と言いつつ、一応今日も news68k 調べてみる。

ひとまず変なことになってないかチェックしてみる。
助言通りに vector.s いじって様子を見ようと思ったんですけど、いまいち make するガッツが出ない。
なのでもっとゲリラ的に NEWS-OS の vmunix から調べてみる。

まずは vmunix を binary search してベクタテーブルらしきところを調べる。
飛び先のわかっている autovectored のアドレスの位置から逆算して 192番のところを調べる。
が、飛び先は Xstray() で意味無し。まあ、 vectored ならそれが当然か。

次は NEWS-OS を起動してすぐ halt して monitor command でベクタテーブルの辺りを調べる。
えーと、と数えながら確認。おー、 0x800029f2 なんてそれっぽい飛び先が書いてあるじゃん。
で、その飛び先番地を見てみる。
……げげっ。 Xparity() ってなんだそりゃ。
それなら copypage() で発生するのもわかるが、なんで SCSI 触ったときだけ出るんだ?
そもそも parity error って NMI じゃなかったのか?
vmunix の Xauto7() を見ると確かに printf("auto7\n") しかしてないように見える。うむむ。

今まで NMI のハンドラ以外 parity check の設定はあんまりまじめにしてない。
ただ、 CTRL_PARITY と CTRL_PARITY_CLR のポートは locore.s の先頭で設定してるつもりなんだけど……
また NEWS-OS のバイナリ調べないといけないな。今週はそんな余裕ないけど。

19990906

締切に間に合ったので脱力状態。
と、ふぬけてたそばから動かんとの報告が。うそっ。
と思ったらプログラムは無実だった。やれやれ。

vector.s に行きつくのは昔の調査でだいたいわかってました。
で、ベクタをどうやって知るかというと、 NEWS-OS のヘッダファイルだったりひたすら "objdump --disassemble vmunix" だったりするのです。
0x300 ってことは 4 で割って 192番ですか。なんなんだろ。
SCSI を触ってないと出ないので SCSI か DMA なんでしょうけど。
SCSI は adrsmap.h からすると ipl 4 の autovectored らしいんだけど、ほかにもあるのかしら。
spl0() した瞬間じゃなくて遅れて出るのもよくわかんないな。

というわけで、今度は "objdump --disassemble scsi_1180.o" してみる。
scsi_hardreset() の中で 0xe0e80000 あたりになにか書いてる。
/sys/newshpdev/dmac_0226.h を見ると DMAC の soft reset らしい。
なのでこれを si.c に足してみる。
んで起動。……が、結果は変わらず。うーむ。

19990905

無事九州から帰還。最近新幹線に乗ってばかりいるような気がする……

行きの新幹線では毎日コミュニケーションズの Personal UNIX No.1 を買ってながめる。
Gimp とか Video/100BASE-TX Card の比較とか A/D コンバータの制御とか、わりと面白い記事もある。
でも、妙に初心者向けな記事があったり、いきなり「次号に続く」な記事があったり。
うーん。雑誌全体として目指してる方向がいまいちよくわかんないな。

帰りの新幹線ではまたまた OPEN DESIGN No.1 の SCSI 記事をながめる。
一度 SCSI の source を読んでから見直してるせいか、結構新たな発見が。
SCSI の規格上では Lost Arbitration のチェックを 2回する必要はないようだ。

というわけで、最終の新幹線だったのにも関わらず部屋に戻ってから早速試す。
といっても #if 0 で 2回目のチェック外して make するだけ。
……かと思ったら goto のラベルの使い方が変だぞ、おい。

とか文句を言いながら修正。んで ftp して起動。えい。

[...前略...]
si0 at hb0 addr 0xe0cc0000 ipl 4, polling
scsibus0 at si0: 8 targets, 8 luns per target
sd0 at scsibus0 targ 0 lun 0: <HITACHI, DK515C, CP16> SCSI1 0/direct fixed
sd0: 639MB, 1361 cyl, 14 head, 68 sec, 512 bytes/sect x 1309896 sectors
st0 at scsibus0 targ 5 lun 0: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st0: drive empty
st1 at scsibus0 targ 5 lun 1: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st1: drive empty
st2 at scsibus0 targ 5 lun 2: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st2: drive empty
st3 at scsibus0 targ 5 lun 3: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st3: drive empty
st4 at scsibus0 targ 5 lun 4: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st4: drive empty
st5 at scsibus0 targ 5 lun 5: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st5: drive empty
st6 at scsibus0 targ 5 lun 6: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st6: drive empty
st7 at scsibus0 targ 5 lun 7: <WANGTEK, SCSI-36, A> SCSI1 1/sequential removable
st7: drive empty
boot device: <unknown>
[...続く...]

おぉ、なんかちゃんと probe してるよ。なんて安直な ;-)
すばらしいというかあっけないというかさすが NetBSD というか……
st がたくさん出てるのは /sys/dev/scsipi/scsiconf.c で SDEV_NOLUNS 定義すればよいだけの話。

……が、この直後、

[...続き...]
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=0xc0a81409 (RARP from 0xc0a81408)
nfs_boot: server_addr=0xc0a81408
nfs_boot: hostname=libero
root on diamante:/export/NetBSD/news68k/root
root time: 0x37d28613
WARNING: clock lost 382 days -- CHECK AND RESET THE DATE!
init: copying out path `/sbin/init' 11
unexpected trap (vector offset 300) from 7e0fc
unexpected trap (vector offset 300) from 7e0fc
unexpected trap (vector offset 300) from 7e0fc
unexpected trap (vector offset 300) from 7e0fc
unexpected trap (vector offset 300) from 7e0fc
unexpected trap (vector offset 300) from 7e0fc
[...以下繰り返し...]

というわけで、さすがに最後まで安直というわけにはいかないようだ。
0x7e0fc ってのは copypage() の中。
vector offset の 0x300 ってなんだ?
DMA コントローラあたりがなにか悪さしてるのかしら。
ま、今日のところはここまで。おやすみなさーい。

19990903

なんとか行き詰まることなく例のアセンブラは一応動作。やれやれ。
news68k での経験が役に立ったような関係ないような…

で、 *BSD Diary links も無事に普通のところに戻ったようだ。
が、今週末はまた法事で九州行きなのでたぶん更新はないです。御了承下さい。

19990902

今日もお仕事は昔の news68k のようにそれなりに順調。
で、そのうち行き詰まったりするのだろうか。

自分自身の信号で Lost Arbitration になるのはもしかして SCSI ID の設定が変なのだろうか。
NEWS-OS の起動メッセージからすると sd0 が 0番、 st0 は 5番。
なのでホストが 7番以外ってのもあんまり考えられないけど。
ncr5380sbc.c は ID が magic number で埋め込んであるような気がするが、そんなものか?
あるいは CXD1180 のそこのレジスタのビット定義が違うのか。
それとも、問題となってる箇所には "Keep this code for reference anyway..." とか書いてあるから取っちゃっても構わないのだろーか。
あとは他のデバイス全部はずして floppy からブートしてみるか。
いずれにせよしばらく試してる暇なし。

19990901

*BSD がはずれて「そのほかの日記」になってしまった。うむむ。

メドがついたとたんに罠にはまったり。
news68k 初期のように闇雲にデバッグ。
アセンブルして、転送して、起動して、 LED 点けて、とか。やってること変わらんな。

やっと thorpej 氏による tlp の driver が commit されたようだ。
これでようやく CardBus の件も話が進むかな。
ってことは current 化はもう少し様子を見た方がいいのかしら。

19990831

なにも細工はしてないけど、更新時刻は不明らしい。
まあ、その日部屋にいれば寝る前には書いてるつもり。
何時に寝ることになってるかは知らないけど。

問題のアセンブラのメドが一応立ったので、帰ってから SCSI を見てみる。
ほんとはメドが立とうが引っ込もうがこんなことしてる場合ではないけど。

問題の "select found SCSI bus busy, resetting..." のメッセージは計 42回出てくる。
SCSI ID 0〜6 のそれぞれで 6回ずつか?
inquiry とあとなにやってるんだろ。
NCR5380_DEBUG つけたり ncr5380_debug = 3; したりして様子を見る。
が、何も出てこない。どうやら DDB つけてないと出てこないようだ。
symbol table が用意できてないので DDB はまだ試してないのだが……
めんどくさいので #define NCR_TRACE printf などとひどいことをする。
やたらと warning は出たが一応通った。起動するとこれまた一応いろいろ出てくる。

ちゃんとソース読んでないのでよくわからんが、最初の scsibus_reset は動いてるっぽい。
ncr5380_select() でアービトレーションに入った後、バスも獲得できているようだ。
が、その後 BSY と SEL をアクティブにするとなぜかその時点で Lost arbitration のフラグが立ってしまって busy になってしまう。
message は ncr5380sbc.c の 1411行目あたりの "lost two" というやつ。

うーん。なるべくしてなっているのか、NCR5380 とは違うからそうなっているのか。
レジスタのビット定義もそれなりに同じに見えるけど、 Extend Mode register とやらを設定しないといけないのか?

19990830

本業は相変わらずアセンブラと格闘。
で、帰ってからは原稿と格闘。
なんとか 3時前には仕上げる。ぐったり。明日からまたつらそうだ。

*BSD Diary Links にまで捕捉されてしまったらしい。
タイトルは *BSD に違いないけど、 Diary にはやっぱり抵抗が……(まだ言ってる)
そういえばどこにも書いてなかったけど、名前の漢字は筒井です。
トップのページのタイトルがひらがななのは特に意味はありません。

……と、ついにファイルサイズが大き過ぎる弊害が出てきてしまったらしい。
うーん。最初は news68k が中断しないよう自分にプレッシャーかけるためだけに書き始めたのに。
まさかこんなに続けることになろうとは。 (が、 news68k は止まってるので意味なし)

今さらツール使うようにするのもめんどくさいしなあ。
私はプログラミングが嫌いな人なので CGI とか perl とか書けないし。
変にファイル名かえちゃうとリンクが困るし。
……というわけで問題は先送り。(こればっかし)
まあ、サイズが破綻するより news68k が終わる方が早いでしょ ;-p

19990829

今日も仕事いくつもりだったけど結局やる気出ず。あぁ明日からが憂鬱。

某原稿の校正始まる。
えっ? はみ出してるからもう 1ページ? 削るんじゃなくて? しかも今月中に? どひゃー!
というわけではまりモード 2乗確定。 SCSI もここの作文も当分先送りだな…

19990828

今日はお仕事で某アセンブラと一日中格闘。
普段 NetBSD の reasonable な source ばかり見てるせいか、 XXX なコードであーやんなっちゃう。
というわけで、部屋に帰ってきてまでコードいじる元気出ず。

動いてしまったら次を探す、なんてことやってるとそれこそ番号が 2桁に突入しちゃいます ;-)
しかも、高いマシンは買えないからますます遅マシンばかりになっちゃうしー。
普段は一週間(or月)単位で SETI@home 動かすしか仕事がないマシンばかりになっちゃうしー。
変な CPU だとそれすら動かないしー。

news68k 以外に SGI とか CobultQube とか他にも候補はあったんですけどね。
どっちも個人が遊びで出すには苦しい値段ですよねー。
hppa は割と安いし OpenBSD/hppa もあるけど、 pmap とかの問題は手に負えそうにないのでパス。
luna68k はすでに始めてる人がいたし、モノをよく知らなかったのでパス。
arc を入手して曽田さんのお尻を叩くという案もあったけど発見できず。

news68k で始めることにしたのは、

「m68k 系は割と簡単」
「せっかく newsmips に名前変えたのだから」

というつばいさんの言葉が決め手。

ちなみに前にも書いてますが、移植をしたのは news68k が初めてです。
つばいさんの NetBSD/sun3x をテストしてた頃は移植なんて夢のまた夢だと思ってました。
が、 pcscp(4) が動いた時にも思ったけど、何事もやってみればなんとかなるもんですねえ。
で、一時期は「あわよくば port-master」とか思ってたけど、今や完全に息切れ状態。
動いてからどうするか、は永遠に課題のままのようです。
まあ、それ以前の課題というか動いてないところはたくさんあるんですけどね。
『NetBSD/x68k で出来ることは NetBSD/i386 でもできる(しかも圧倒的に高速に)』の言葉の重さはどの MACHINE にもあてはまります。愛着がない分もっとつらいかも。
それでもあえて次を考えるならばこんなマシンで hpcarm か hpcsh3 か? CE 環境がないと無理?

気晴らしにもっと書こうと思ってたのに mail-index.netbsd.org の調子が悪いみたい。リンクが張れん。
core-digest なんてのができてたのと関係あるのか?

19990827

うーん。 NWS-1750 ってのと 9番ってのとどっちがダメなんでしょう? 両方?
半分以上はもらったマシンだし、 10万以上出したのは 1台だけ(i386 除く)だし、いいじゃないですか ;-)
それより、 TC の 100BASE-TX がなくて困ってる、ってのも結構なもんじゃないですか?
TC-VME bridge の後ろに VME-PCI bridge をつなぐって手があるぜ、なんて言ってた人はいますが……。
現実路線でいくなら current-users に流れてた FYI とかどうでしょう。日本からは無理そうだけど。

……と、おもむろに news68k SCSI コードを書き始める。
files.news68k を修正。うーん、と深く考えず device 名は si にする。
arm32/podulebus/csa.c と news68k/dev/if_le.c とを切り貼りして si.c 作成。所要時間 3分。

とりあえずは polling version。 make して修正して make して reboot。ほっ。

[...前略...]
si0 at hb0 addr 0xe0cc0000 ipl 4, polling
scsibus0 at si0: 8 targets, 8 luns per target
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
si0: select found SCSI bus busy, resetting
[...後略...]

というわけで、さすがにそう簡単にはいかないのであった。
でも、なんとなく QIC のアクセスランプはついてるから bus reset くらいは動いてるのか?
port access に wait 入れてみるが変わらず。
うーん。レジスタの内容もう少し真面目に見てみるか。
先は長そうなので今日はここまで。あとはゲームしよ。

19990826

昨日は思いっきり酔って書いてたせいか 19990824 の記述の一部消しちゃったようだ。すいません。
思い出せる範囲で修正。が、記憶が……。日記ツールかせめて RCS 使えって?
結局今日は午前中仕事にならず今週末も出勤確定。ダメダメ。

CXD1185 関連資料はしかるべきところには送付済みです。
PowerBook G3 がひと段落して、さらに余裕があればいつか反映されるかも。
あ、 news68k も news1200 は CXD1185 なんだっけか。

「部屋に PC を 5台も」、ですか。
PC-9801NS/L とか MacOS 互換機とか StrongARM CATS とかは PC って言うんでしょうか?
ちなみに最新入荷の NWS-1750 の IP address は 192.168.20.9 だったり。
でも 100BASE-TX なのは 3台だけですね。
元 WorkStation と呼ばれるマシンがすべて 10BASE-5/T なのはやっぱり貧乏な証拠?
ところで、某偉い人は部屋に全部で 11台とか言ってたような…

日記モードはこれくらいにして source tree の NCR5380 チェック。

% grep ncr5380sbc /sys/arch/*/conf/files.* /sys/dev/*/files.*
/sys/arch/arm32/conf/files.arm32:device oak: scsi, ncr5380sbc
/sys/arch/arm32/conf/files.arm32:device csa: scsi, ncr5380sbc
/sys/arch/mac68k/conf/files.mac68k:device       sbc: scsi, ncr5380sbc
/sys/arch/pc532/conf/files.pc532:device ncr: scsi, ncr5380sbc
/sys/arch/sparc/conf/files.sparc:device si: scsi, ncr5380sbc
/sys/arch/sparc/conf/files.sparc:device sw: scsi, ncr5380sbc
/sys/arch/sun3/conf/files.sun3:device si: scsi, ncr5380sbc
/sys/arch/vax/conf/files.vax:device     ncr: scsi, ncr5380sbc
/sys/dev/isa/files.isa:device   nca: scsi, ncr5380sbc

てな感じで結構色々ある。順に眺めてみる。
arm32 の 2つが PIO のみでかつ polling と interrupt driven 両方ともあるようだ。
ほんとに NCR5380 互換だとしたら attach と割り込みだけ書けば一瞬で動きそう。
polling なら割り込みすらいらないはずだけど、そんなにあまくないか?

DMA 転送のコードが用意されているのは mac68k, pc532, sparc, sun3。
DMA 関連の MD function は機種毎に結構使い方が違う。
sun3 のが一番参考になりそうかな。 news68k の DMA の概要は調査要。
Scatter/Gather は自動か手動か……。 DMAC0226 で調べれば資料あったりするかな?

19990825

忙しい中出張飲み会その他でヘロヘロ。
今日も日記モード。というかそれ以前に文字がぼやけてたりして。

/sys/arch/sparc/dev/si.c を開くがそのまま沈没。
今日は強制的に飲まされて文字が霞んでる状態。ダメ。ぐったり。

19990824

ハマリモード進行形につき今日も日記 & ぐるぐるモード。
助言どうもありがとうございました。まあ DMA 他調査はまだ必要なんですけどね。
/sys/arch/sparc/dev/si.c あたりが参考になるかな。
ちなみに CXD1185 は怪しいロシア語のページが検索で引っかかってたりして。

ぐるぐる。う。凄い人でも遅マシンへの移植マニヤでもないっす〜。
移植してるのは news68k が初めてですし、遅マシンばかりなのは貧乏なだけですぅ。
なので 030 な x68k も買えませんです ;-p

まあ、無意味に multi architecture で NetBSD 動かしてうれしがってるのは確か。
正確に言うと、 "Make it working with reasonable way" って感じですかね?
news68k port も pcscp(4) frontend も macppc の wdc(4) 対応も adv(4),vr(4),ex(4) の big endian 対応も動機はみな同じ。
copyright を主張できるようなコードが全然ない(ほとんど cut & paste しかしてない)のも同じだったりして。

それぞれの対象に対して特に愛着や必要性があるわけじゃなかったりします。動かすために買ってたり。
なので動いてしまった後どうするか、ってのは実は永遠の課題。
"reasonable goal" の向こうにははたしてなにがあるのでしょーか。

19990823

なんとなく /sys/dev/ic 以下の SCSI 調査。
screg_1180.h と ncr53c9xreg.h とが違うのは確認済。
今日は ncr5380reg.h を見てみる。
レジスタ数は 8つで同じ。なのでちゃんと眺めてみる。

NetBSD の /sys/dev/ic/ncr5380reg.h のレジスタ定義:

/*
 * Machine-independent code uses these names:
 */
#define	sci_data	sci_r0	/* r:  Current data */
#define	sci_odata	sci_r0	/* w:  Out data */

#define	sci_icmd	sci_r1	/* rw: Initiator command */
#define	sci_mode	sci_r2	/* rw: Mode */
#define	sci_tcmd	sci_r3	/* rw: Target command */

#define	sci_bus_csr	sci_r4	/* r:  Bus Status */
#define sci_sel_enb sci_r4	/* w:  Select enable */

#define	sci_csr 	 sci_r5	/* r:  Status */
#define sci_dma_send sci_r5	/* w:  Start dma send data */

#define	sci_idata	sci_r6	/* r:  Input data */
#define	sci_trecv	sci_r6	/* w:  Start dma receive, target */

#define	sci_iack	sci_r7	/* r:  Interrupt Acknowledge  */
#define sci_irecv	sci_r7	/* w:  Start dma receive, initiator */

NEWS-OS の /sys/newshbdev/screg_1180.h のレジスタ定義:

/*
 *		SCSI I/F Chip CXD1180 Register address assignment
 */
#define	SCSI_BASE	0xe0cc0000
#define	sc_csdr		*( (u_char *)(SCSI_BASE + 0) )
#define	sc_odatr	*( (u_char *)(SCSI_BASE + 0) )
#define	sc_icomr	*( (u_char *)(SCSI_BASE + 1) )
#define	sc_moder	*( (u_char *)(SCSI_BASE + 2) )
#define	sc_tcomr	*( (u_char *)(SCSI_BASE + 3) )
#define	sc_curbr	*( (u_char *)(SCSI_BASE + 4) )
#define	sc_selenr	*( (u_char *)(SCSI_BASE + 4) )
#define	sc_bstr		*( (u_char *)(SCSI_BASE + 5) )
#define	sc_sdmas	*( (u_char *)(SCSI_BASE + 5) )
#define	sc_indatr	*( (u_char *)(SCSI_BASE + 6) )
#define	sc_sdmatr	*( (u_char *)(SCSI_BASE + 6) )
#define	sc_resipr	*( (u_char *)(SCSI_BASE + 7) )
#define	sc_sdmair	*( (u_char *)(SCSI_BASE + 7) )

#define	sc_ex_moder	*( (unsigned char *)(SCSI_BASE + 4) )
#define	sc_ex_tclow	*( (unsigned char *)(SCSI_BASE + 5) )
#define	sc_ex_tcmid	*( (unsigned char *)(SCSI_BASE + 6) )
#define	sc_ex_tchi	*( (unsigned char *)(SCSI_BASE + 7) )

……。これって、もしかしておんなじ? まじ?
型番が CXD1180 なのはそういうことなの?

しかし、今週は予定通りしょっぱなから本業大ハマリ状態。
本業のコードが動くまで NetBSD のコードなんぞいじってる暇はないのであった。うつうつ。

19990822

結局会社には行かず家でぐったりしたり別の某ゲームしたり。
月曜からの憂鬱を思うと source を開く元気は出ず。
…と、ぼーっとしてると時代は 1.4.2 にも向けて動き出しているらしい。

19990821

JNUG meeting and NetBSD BOF 当日。
普段より早起き(笑)して朝 8時の新幹線に飛び乗る。
途中寝たり起きたり。天気は晴れたり降ったり。
12時前にお茶の水到着。東京は快晴。マクドナルドで昼食。
日大理工学部 8号館をさがしてぐるぐるぐる。 15分程度うろうろ。迷い人多数だったらしい。

総会および BOF の内容は別途報告が出されると思うので詳細は省略。
news68k の話題も振られるが、プレッシャーかかるところまでには至らず。 ;-p
sh3 や hpcmips の話に感心したり共感したり。 tetris(6) は news68k では動かしてなかった ;-)
このほか、椿井さん、箕浦さん、坂本さん、伊藤さん、中田さんほかいろんな方とお話できました。 ;-)

終了後も曽田さん、古田さんほかとちょっとお話。
source code も data sheet も無しで SCSI ドライバ書きは厳しいわねぇ、そーですよねぇ、とか。
とりあえずレジスタ配置だけでも似たような石があったりしないか見てみたら? との助言。
やっぱりそれしかないか。あとは根性勝負の disassemble のみか…

あまりの楽しさに泊まりも考えたけど、結局あきらめて予定通り日帰り。
19時過ぎお茶の水駅前で宴会組の皆さんとお別れ。
東京駅では岡山行最終に駆け込み乗車ぎりぎりセーフ。ふぅ。
帰路は Open Design SCSI 特集を再読したりしながら 23時帰宅。

いやぁ、往復 7時間約 3万円かけて出かけただけの価値はありました。
もっとも、そうそう何度も行けるとは思ってませんけどね。

19990820

東京行に備えて床屋行ったり回数券買ったり。
その結果、片道の旅費だけで原稿料が消えてしまう。
これで日帰りはもったいないんだけどなぁ…
とにかく、明日は 8時の新幹線だから今日は早く寝よう。

…の前に、ばらしたままだった news68k を組み立てて起動。
特に変わることなく NEWS-OS も NetBSD も立ち上がる。
うーん。最近本業でもプログラミングさせられてるから元気足りないんだよなあ。

19990819

東京行新幹線回数券など探索。8月21日ならぎりぎり OK か。
うーん。残念、なんて言われると迷っちゃうな。
本業はトラブルばかりで、逆に自分一人だけ頑張ってもしかたないみたいだし。

ふと久しぶりに NWS-1750 の電源を入れてみる。
…が、ウンともスンとも言わない。おい。
モニタのプロンプトどころか電源ランプすら点かん。
電源ケーブルチェック。…問題ない。
コンセントつけかえ。…変わらず。
抵抗値確認。…うーん、こんなもんか?
とりあえず上ぶただけあける。ヒューズは OK。

うーん、これはちょっと根が深そうだなあ。
……と、ヤケになってばらしたらマザーの電源ケーブルはずれてる。あぅ。
単に前に本体ばらしてその後組み付ける時にケーブルつなぎ忘れてただけでした。とほほ。
しかし、夏休みがあったとはいえ 3週間ほったらかしだったのか。いかんな。

19990818

JNUG meeting and NetBSD BOF 参加の算段。東京は遠い。うー。
本業もさらにバタバタしてるので土曜は日帰りで日曜出勤かも。秋葉寄る暇なんてないな。

NetBSD/hpcmips は merge に向けて動き出したらしい。
news68k は SCSI 書いてから…と思いつつ全然作業してない。
hpcmips は 1.3I ベースから 1.4J にしたそうですが、そんなに大変じゃないのかな?
とか言ってると今度は 1.4K だ。

19990817

休み明け早々本業がばたばた。
…にもかかわらず、某所では色々口出してしまったり。
大学にいた頃も「曽田さんに仕事をさせよう計画」とかやったのを思い出す。

19990816

徹夜で現実逃避してしまったり。
いつのまにか増えていたゲームが今日は妙に進んでしまう。わはは。

さすがにまずいだろう、という時点でようやく書き始める。
予定通り、書き始めればわりと順調。ぱぱっと書いて出してしまう。
一応 news68k にも触れておく。

しかしこりゃ夏休みの宿題というよりも修論締切当日ってやつですな。
まだこれでおしまいじゃないだろうけど。

19990815

実家でも作文&更新するつもりが設定ミスのため敗北。
迫り来る締切、進まない原稿、残りわずかの夏休み。うぅ news68k どころではないですぅ。

某偉い人と「まるで小学生の夏休みの宿題ですね」などと鬱を共有してみたり。
あぁ、ツクツクホーシや甲子園をやらなくなった NHK に焦燥感を覚えたあの頃の気持ちが今再び。
って全然うれしくない〜

19990811

書き上がってからのつもりだったがあきらめて実家に戻ることにする。
はたして夏休み最終日の締切当日はどうなっていることやら…

というわけで、ここの更新はするかも知れませんがしばらくは news68k ネタは多分出ません。御了承下さい。

19990810

休み中なのにいろいろ逃避中。
単一 GENERIC kernel でどこまで対応できるかを考えてみる。
が、そもそも news700 の MMU 仕様とか IOP の仕組みとか全然分かってないのどうしようもない。
sparc の sun4m merge のときってどれくらい苦労したんだろ。

19990809

先の長い news68k は置いといて、ようやく締切のある作文の準備を始める。
参考までにライバル(?)の "Linux×BSD HYPER PRESS" を買ってきて読んでみたり。
うーん。やっぱり如何に短くまとめるかが問題だなあ。

…とやってたはずが、なぜか NetBSD Mailing List の NetBSD/pc98 merge の話に口をはさんでしまう。
個人的には、 MACHINE_ARCH 問題より device の判定に flags での暗黙指定や起動時の customize をばりばりに使ってることの方が気になってたりして。

news68k ではどうかというと、 MACHINE の定義は単一の GENERIC kernel で共用できる範囲というのが news700 や IOP で困るかも…
まあ、やってできないことはないとは思うんだけど。
ただ、 sparc/include/param.h の CPU_ISSUN4* の定義みたいなことするのかと思うとやってられない…

19990808

『最近ちょっと変だよ?』
『いや俺が変なのは昔からだ』

というわけで、進捗せず。

『ぜんっぜん、どういうわけか分からないよっ』

19990807

とりあえず今日明日は泊りでお出かけ。
来週はそれどころじゃないかも。

一部ではすでに原稿書いてしまった人がいるらしい。
お出かけ先でちょっと世間一般の意見聞いてみるか。

19990806

明日から夏休み。…なんだけど、のんびりとはしてられないかも。

とどまることを知らず今度は 1.4J。
current 化について考える。どうせやるなら全部のマシンでしたいけど…
i386 に関しては神戸さんのメモとかあるのでそんなに問題ないかな。
sparc も elf 移行しないといけないけど、 SS1+ じゃめんどいなあ…
おとなしく sparc は snapshot 使ってするか。
alpha, arm32, macppc, newsmips, sun3 は今までどおり make build かけてひたすらほっとけばいい?

news68k はどれくらいなおさなきゃいけないんだろ?
MD に影響する MI の変更って bufcache まわりとか今回の 1.4J の splsoftclock() とか結構あるのか?
ほかの各 m68k arch の 1.4R からの diff 確認していくしかないのか…
先は長い。というか、立ち止まってるとどんどん goal が遠くなる…

19990805

いまさらながら macppc の xcoff boot loader の問い合わせが来たので返事を書く。
うーん。やっぱり英語の返事はめんどい。

皆勤続けてるわけじゃないから、 news68k ネタがないのに無理して毎日書く必要はないんだけど……
気分転換に current 化でも考えるかな。

19990804

今日も news68k ネタ出ず。 A の B 方面にも力入れないといけないし…

『……もしかして、ごまかしてる?』
『全然そんなことはないぞ』

19990803

仕事に疲れて小説読んだりゲームしたり。
うーん。どっちもいまいち。
A の B のネタも考えないといけないけど進まず。

あいかわらず news68k ネタないな。すいません。

19990802

今週はずっと連休前修羅場モードな感じ。
ってことはここもずっと日記モードか?

ふと見ると実はすでに 1.4I。 2日で次に行かないでくれ〜。
1.3 は 1.3K までだったっけ?
1.4R まで行って RELEASE と区別つかなくなる、ってのも洒落じゃなくなくなってきたな。

19990801

出先から帰宅。と言ってもすでに 23時なので日記モードすらめんどい。
とりあえずメール確認。私はさいわい偉い人ではないので未読 4桁、とかにはならない。

しかしこのままでは休みボケのまままた休みに入ってしまうな。
仕事一杯かかえてるのに。大丈夫かいな。
とか言いつつ JNUG に Registration する。
A の B の締切が夏休み最終日で、それが終わった後で今度は東京行きかー。うーん。

19990728

問い合わせやらなんやらの返事メールを書いてたらすでに 23時。
なお、明日から 3日間また別の法事のため休ませて頂きます。御了承下さい。

screg_1180.h と scsi_1180.o を眺める。
レジスタは 8つ。うち 4つには拡張モードとやらがあり別の働きもするらしい。
が、レジスタの略称からしてよくわからない。

sc_csdr: Command Status and Data Register?
sc_odatr: Output DATa Register?
sc_icomr: Initiator COMmand Register?
sc_moder: Mode Register?
sc_tcomr: Target COMmand Register?
sc_curbr: CURrent Busphase Register?
sc_selenr: SELect ... わからん。
sc_bstr: Bus STatus Register?
sc_sdmas: ??? DMA Status?
……

なんて勝手な推測しててもしかたないな。
別のところのコメントには "scsi control register" とかあるんだけど、該当しそうなのがないし。
逆アセンブルソースを読むには元気が足りないよ〜。

19990727

久しぶりに NWS-1750 の中身を見てみる。
CXD1180 の副番があるかと思って chip を見るが "CXD1180" の表示とシリアルコードがあるだけ。
製造年は '87年のようだ。 CXD1185 は '94年生産中止らしいからそれよりだいぶ古いのね。
しかし CXD1180 って足が 48pin しかないんだけど、どうなってるのかしら。
ちなみに CXD1185 は 64pin。

ついでに zs の clock を確認してみる。
基板上には 25MHz と 20MHz の発振器しかついていない模様。
25MHz のほうは CPU clock だろうから周辺は 20MHz のほうか。
だとすると clock は 4MHz かな?
zs.c の PCLK って 9600 で割り切れなくてもいいのか?
以前試した時は怒られたような……。でも x68k/dev/zs.c では 5MHz になってるな。ううむ。

19990726

巷で噂の A の B な方面からお誘いが。思わず OK してしまう。
うーん。 news68k すらロクに進んでないのにそんなことしとる場合かという気もしないでもない。
ま、なんとかなるでしょ。

SCSI 続報。やはり CXD1180 の資料入手は難しそう。まあ仕方ない。
あればそれで書けるってわけじゃないけど、とっかかりとしては欲しかったな。
が、ないものはしょうがない。現状でなんとかしよう。

世間で使うツールでは自分自身にアンカー張ってあるほうが便利なんでしょうか。
mule-1.1 + html-helper-mode で手書きという超時代遅れ環境なのでよくわかりません ;-p
リンクされてないと被リンク可能なのがわからない、ってことかな。 URL の cut & paste はしやすいか。
まあ複雑なアンカーは使わないのでこれで御勘弁を。
あ、変換 script 書いてくれてもいいですー。

うーん。今日も日記モードだな。ダメ。

19990725

今日はぼーっとしたりかたづけしたりゲームしたりで news68k 進展せず。
まあ、あせらず進めよう。勝負は夏休み入ってからかな。
しかしもう 1.4H なのか。

19990724

SCSI の資料片手に勉強。が、まだまだ先は長そう。
ついついまた別のゲームやってしまったり。

UNIX USER の某記事を立ち読み。
『NetBSD ではいろいろなことを自分たちのためにやっているが、 FreeBSD では user のためにやっている』
うーん。正しいような気もするが、なにか違うような気も…
どっちかってーと、「NetBSD user == source をいじる人」という気がしないでもない。
いずれにせよ、私は "Our goals for portability are limited due to quality reasons" よりも、 "A reasonable goal ... but, likely quite time consuming" っていうほうが好き。

19990723

2日間、会社もこのページも忌引休暇を取らせて頂きました。悪しからず御了承下さい。
で、帰ってきた早々 mail 整理したりぐるぐるしたり。

SCSI に関して明るい知らせが届いてたり。
なぜかはるばるイタリアから news68k の問い合わせが来てたり。
なんだかいい感じ。

古田さんにはかなり前から観測されてた模様。
で、現在は日付のアンカーはつけてるつもりなんですが……。こういうのですよねぇ。
HTML には詳しくないもんで、なにか勘違いしてるでしょうか?
ちなみにここが全部手書きなのは日記ではないからです。 ;-p
って今日も思いっきり日記モードだけど。

うちと違って NetBSD/news5000 のほうは順調に進んでいるようですね。
newsmips の 1.4R バイナリはありますけど、 1.4R ベースの boot floppy から抜き出すのがお手軽かも。
って、読まれてるかどーかわからないのにここに書いてもしょーがないですが…

クロスコンパイル環境の話は伊藤さんの別のページにまだあるみたいです。
ふあぁ。明日は出勤日だからいいかげんもう寝よ。おやすみなさい。

19990720

ぐるぐるしてたら別の某氏の日記のページを発見。
思わず読み耽けると 0xdeadbeef のコメントが書いてあったり。今まで気づかなかったとは不覚。
しかしなんとも懐かしいタイトルですねぇ。
『1 と 9 と 8 と 4 の年』なんてくだりがあったような。うわ〜、 15年以上も前なのか。
ちなみに某 game の最後の 1% はこちらでもかなりてこずりました。でもその割には大した絵じゃないです。

週末に寮内の安全点検とかで電気配線チェックが入るらしいので色々整理する。
コンセントは壁に 5つしかないのに必要数は 30以上なのでタコ足するなと言われても困るのだが……
とりあえず見てくれの悪い 3つ口をやめて 6口テーブルタップ特価 600円とか買ってきてゴマカす。
ちなみに NWS-1750 は相変わらず畳の上に転がしたまま。
そろそろ常置場所を決めてやらないといけないけど、筐体でかすぎ。

news68k ネタがないもんだから日記モードに入ってしまっている。いかん。
というわけで(?)、昔買った「改訂版 UNIX デバイスドライバ」を読んでみる。
こいつは pcscp(4) を書く前に買ったんだけど、まだ DMA まわりしか読んでない。

「SCSI ドライバ」というそのものの章があるので改めて読む。
ただし、この説明も SVR4 の SDI とやらをベースにしてるのでそのまま適用はできない。
一応 struct scb, struct sfb の説明とかは参考になるかな。
が、いまいち訳がわけわからん。というか訳者がちゃんと内容を理解して書いてるか怪しいなあ。

あと調べるべきは具体的な SCSI の石の説明だけど……
Am53c974 の英語マニュアルはちょっとすぐには読む元気が出なそう。
どこかに日本語で書かれた SCSI chip のマニュアルないかしら。

19990719

ゲームやりながらトラ技 SPECIAL と OPEN DESIGN の SCSI の解説記事を眺める。
おし、ようやく 100% 達成。とかやりながら読んでるとすでに日付変わってたり。

各ドライバは上位の MI SCSI ドライバからコマンド列のみを受け取る。
んで、ドライバはコマンドをキューに入れたり出したり、
command/status/data/message 等の phase を切替えたり、
同期転送や select, reselect 等の設定をしたりする。
論理的フェーズと物理層の信号操作の関係とか target ID の設定とかは各 chip の機能による。
また、上記以外に probe/attach はもちろん、 DMA の scatter/gather の設定や割り込み処理も行なう。

あんまり真面目に考えてないけど、こんな感じか?
うーん、結局 pcscp(4) では結局一番下の probe/attach/DMA/interrupt しか書いてないんだよな。
それも PCI の bus_dma(9) と chip の S/G 機能を使ったから自分ではなにも知恵使ってない。
Am53c974 のマニュアルの SCSI core 部分の説明を ncr53c9x.c 見ながら読まないといけないなあ。

が、いずれにせよ chip のマニュアルも参考になる source もない状態で書くのは苦しいか?
データ転送もよくわからんし。そもそも DMA 使えるのか?
と思ったら NEWS-OS の sys/newshbdev/dmac_0266.h にはちゃんと #ifdef news1700 な項目があった。
newshbdev/fdreg.h の FD_PSEUDO_DMA ってのはまた別の話なのか?

…と、fdreg.h の中に "#define phys(x) ((caddr_t)(x)+0xc0000000" とかある。
見え方は同じでも、物理アドレス 0x0 からと 0xc0000000 からってやはりなにか違うのか?
てな具合に ??? ばっかり。

19990718

今日もほぼ一日出歩いてたのであまり進展なし。
途中立ち寄った本屋で OPEN DESIGN No.1 "SCSI 完璧リファレンス" というのを見つけて買う。
SunOS のドライバの話とかも載ってるが、 SCSA って FreeBSD の CAM みたいなものか?
だとすると Julian's SCSI driver の参考にはあまりならないないかな。

aha.c やら wds.c やら ncr53c9x.c やら眺めてみる。
似てるところ違うところいろいろあるんだけど、何をベースにするのがいいか。
それよりまず SCSI pointer の概念とその実装を勉強するのが先か。

screg_1180.h と screg_1185.h を比べてみる。
はっきり言って全然違う感じ。ダメかも。
しかも screg_1185.h は結構 comment が親切なのに screg_1180.h はかなりいい加減。
そもそも news68k の DMA ってどうなっているのだろうか。
scsi_1185.c でも DMA 関連のコードは #if defined(mips) の中にしかないような…。

19990717

今日は 1000m 泳いだり 250km 運転したりでへろへろ。
というわけで例によって考えるだけ。

boot loader のほうがやりやすそうなんだけど、やっぱり次は SCSI を動かすことを目標にしよう。
boot loader だけ先にできても、 vnd 上で installboot して別のマシンで floppy に書く、しか試せないし。

SCSI を書くにあたって何が必要か考えてみる。
まず MI SCSI driver と各 chip の driver との関連。 sc_adapter と sc_link とかか?
実は scsipi_cmd と scsipi_minphys だけか?
次に driver に必要な関数群。 probe, attach は当然として、他に init, poll, sched, done, intr 等々。
各ドライバで微妙に名前や構成が違ったりするのでよーわからんが…
まあ、各 chip で機能が違うとすれば当たり前か。

んで、一番肝心な CXD1180 の情報。現状なんにも資料がないのだが……
まず newsmips の CXD1185 と似たようなもんだろうと仮定して newsmips/dev/scsi_1185.c をベースに考えよう。
大元の Lite2 の news3400/hbdev/scsi_1185.c も見た方がいいかな。
それと NEWS-OS の scsi_1180.o を逆アセンブルして推測。使っている関数は scsi_1185.c と結構似てるみたいだし。
m68k の NEWS-OS でも news1200 では scsi_1185.o があるのでこっちも参考になるかな。
あとは screg_1180.h と screg_1185.h の比較。
newsmips/dev/sc_wrap.c はあんまり見ないで、と言われてるけど、 MI SCSI を使う場合の相違点ということで眺めてみよう。

と、やることリスト書くとこんな感じなんだけど、実際できるのかしら。
scsi_1180.c 下さいとか CXD1180 のデータシート下さいとか頼んだ方が早いのだろうか。
実は MI に driver のあるなんかの石の互換だったりしないかなあ。甘いか。

19990716

再び NEWS-OS の /boot を見てみる。が、やはりよくわからん。
一応 MAGIC を見て動作を変えているところはあるようだが…
そもそも NMAGIC と OMAGIC で何が違うんだ。

いろいろやってみるが MAGIC と L2 cache には関連なさそうな感じ。
だから NMAGIC で動かすことにこだわることはないかな。
というわけで結局進展せず。

19990715

fj.os.bsd.netbsd を読んでいてふと news68k の kernel の MAGIC のことを思い出す。
以前にも少し書いているが、現状 NEWS-OS の vmunix は (magic 410) と出るが NetBSD だと (magic 407) である。

で、各 arch の Makefile.${MACHINE} の LINKFLAGS を見てみる。
現状 news68k では "-N" にしてたのだが……。
各 arch で結構バラバラ。"-n", "-N", "-z" なんでもあり。
m68k まわりだと、 sun3 は "-N" だがそれ以外はみな "-n" になってる。

というわけで news68k でも "-n" の NMAGIC にしてみる。
……。できた kernel を file(1) でみると "old SGI 68020 pure executable" と NEWS-OS の vmunix と同じ表示が出てくる。そういうことだったのね。
んで起動。……ぐは、最初の copyright すら出てこない。
とりあえず、しょっぱなで monitor に落として memory の中身を確認する。
お、 NEWS-OS の vmunix 読んだ時と同じく 0x0 番地からメモリサイズやらいろいろ入ってるじゃん。
うーむ、やっぱり NEWS-OS の /boot は magic で動作区別してたのね。

んで、どこで止まってるか調べてみる。
まず同じソースから "-N" の OMAGIC で作って立ち上がるか確認。……うん、問題なく動く。
もう一度 "-n" の NMAGIC で作って起動。……間違いなく動かん。

そして久しぶりに LED デバッグ。 pmap_bootstrap() は通過。
MMU on 後も動いてる。 uvm_setpagesize() も問題ない。
で、 news68k_init() の中で死んでるのを確認。
さらに調べる。最初の uvm_page_physload() で死んでる。
printf() 使おうと思ってその前に consinit() 入れてやるがそれも死んでしまう。
uvm_page_physload() を飛ばしてやるとその次の pmap_enter() は通過したが、こんな状態では意味無しかな。

しかし OMAGIC だと動いて NMAGIC だと途中で止まるってどういうことだ?
boot loader がさらにいろいろ余計なことしてるんだろうか。
それにしても、わけもわからずたまたま OMAGIC にしてたから今まで動いてたのか。
運がよかったというかなんというか……
結局、要するに native boot loader を先に書け、ということか?
それとも NEWS-OS の /boot で変なことしてないか確かめるのが先?

19990714

今日もお休みにしようかと思ったが、なんとなく next68k の下を眺めてみる。
……。結構ごちゃごちゃしてる。実は news68k と同じレベルかも。

hp300 で #ifdef HAVE_CACHE_PAC になってるところが next68k だと #if defined(HP370) になってる。
hp300 の 68030 マシンの PAC は動いてるのかがどうも気になる。
hp300/locore.s を見ると 68030 でも妙な MMU 関係らしき I/O ポート叩いてるんだよなあ。なんなんだろ。

19990713

重い作業はガッツが出ないので細かいネタを 2つ 3つ試してみる。
が、例によって変化なし。

うにゅ。今日はもう充電のためお休み。くー。

19990712

今日もいまいち元気出ず。
と、某所からもリンク張られてしまってたりして。
ふと、道はどっちに向かってのびているのだろう、とか考えてみたり。

とりあえず NEWS-OS の boot sector を確認してみる。
特に version number とかはなさそう。
あとは書くだけ。書くだけなんだけど、なんだけど、うぐぅ。

19990711

昨日の newsmips boot floppy は kernel が 1.4_BETA だったり /usr/mdec/ 以下を入れ忘れたりしてたので作り直す。
installboot は partition c を指定しないとダメなのね。
make だけで image 作れるようにはなったが、 sysinst は先が長そう。

newsmips/stand/ 以下の source をざっと眺める。
*.S な source だけ news68k 用に直せばいいのかしら。
ちょっとだけ作業を始めるが、途中気分転換にドライブに出かけて戻るとなぜか 23時。
まあ、たまにはこんな日もあります。

19990710

ふと見るとこの port-news68k.html のサイズが 200kbyte 突破している。
ここまででかくなると分割した方がいいのかもしれないけど、めんどうなのでしばらくほっとく。

arch/newsmips/stand 以下を取ってきて試してみる。
commit されたのは current 用だが、うちはまだ current にしてないので無理矢理 1.4R 上で試す。
いつものように make obj && make するといきなり error。お?
よくある obj directory をちゃんと扱えてない問題らしい。
ざっと見て、 boot/Makefile の .PATH: と CPPFLAGS, bootxx/Makefile の CPPFLAGS に ${.CURDIR} 追加。
あと bootxx/Makefile の L に ${.OBJDIR} 追加。こっちはなくてもいいかも。

……。今度は libsa に loadfile() がないと怒られる。
これは current で MI に変更になった箇所なので強引に変更。
できた。んで早速 install boot floppy 作ってみる。
install 用 ramdisk kernel は以前作ったことがあるのでそれを書き込むだけ。
i386 上で floppy に dd して起動。
……。かなり時間がかかるがちゃんと立ち上がる。うーん、すばらしい。
terminal type? に vt100 と入れると画面が乱れるのがアレだけど、どうすべきかな。

というわけで boot floppy image も distrib/newsmips 以下のファイルと同じく物置ディレクトリに入れておきます。
あ、この変更以外に /etc/disktab にも floppy エントリ足さないといけないです。
以上、私信終わり。 ;-p

news68k もはやいとこ boot loader に取り掛からないと。
その前に表のページにも kernel binary と source へのリンクを張っておく。
しかしやはり PG_CI 追加 hack はひど過ぎ。なんとかしたいなあ。

19990709

kernel 移植に役に立つかもしれないメモ 2つ。
bus_space(9) 関数群の解説。うーん、勉強になる。 ←今までロクに理解してなかったりして
news68k は……幸い zs も le も bus_space(9) は使ってないからほっとこう(←手抜き)。
files.* の中の needs-flag と needs-count の説明。うーん、知らんかった。直しとこう。

telnetd が core を吐くのは /etc/gettytab がないせいとか書いてあったような…
これって今でもそうなんだろうか。と思って news68k で試すが別に問題なさそう。
gettytab がないとデフォルトでは "4.4BSD UNIX (libero) (ttyp0)" なんて出るのか。うーむ。

と、ここで突然思い立ってまたまた勝手に方針を変える。
意を決して arch/news68k 以下の source を公開に向けて直していくことにする。

まずは adrsmap.h を使うのをやめて必要なところで #define するようにする。
adrsmap.h 程度の中身なら copyright の問題はないと思うが、いちいち許可をもらうのもめんどくさいし。

次に各 source の clean up。
といっても真面目にやってたらいつまで経っても終わらないので、 comment の追加だけにとどめる。
dirty hack なところとか、ベースにした source とかを memo。

げっ!!! ここでまたしても大ボケなミス発覚。うひゃあ。
I/O を tt0 で map するようにしたら pmap.c で PG_CI つけなくてもよくなった、って書いてたけど、 実は大ウソ。
修正したつもりが #endif を挿入する位置間違えてる。これじゃ結局常時 |= PG_CI されてるじゃねーか。
ちゃんと直して確認してみる。
……動かん。こりゃやっぱり 2次キャッシュ全然ダメじゃねーか。
まあ、どっちにしてもダメなままなだけだからいいんだけど。
やっぱり公開してみんなにチェックしてもらわないとダメね。

……とかやってるとなんだか途中でだんだんめんどくさくなってきてしまう。
まあ、もともとそんなにいじってないから、注釈といってもこんなもんかな。
というわけで、表のページ(?) で公開する前に物置ディレクトリに source と kernel をこそっと置いとくのでお暇な方はチェックしてみて下さい。
あ、以前に書いたように、 boot できる kernel を make するには objcopy が a.out-newsos3 の BFD target が作れるよう用意して下さい。

19990708

英語の NetBSD/news68k 説明ページを書いたそばからいきなり大げさにリンク張られてしまう。
うぅ。出るとこ出されてしまったのでもう引くに引けないかも。
……といっても、そうそう user がいるとも思えないから止まってしまわないようにするだけ。

と、今度は NetBSD/newsmips の native boot loader が commit されてしまう。
あぅーっ、来週月曜まで本業が半修羅場モードなのでもう少し待って下さい〜。
ひとまず NetBSD/newsmips News のとこでも update してて下さい。 ;-)

某漫画に出てきた次のセリフを見てうっ、とか思ったり。
『もう俺にゃついて行けねェ。でも…』
『なァ、あんたはどうして前へ進めるんだ』
うーむ。全然関係ないんだけど、趣味で思い悩んだりしてはいけない、ってことですな。

19990707

news700 はやはり独自 MMU だとのこと。
うーん。ここはあっさりあきらめて sun3 のように kernel 2種類にしてしまえばいいかなあ。
そうすると directory 構成とかまた悩ましいけど。

abs 氏に送っていた new style NetBSD/newsmips のページが commit された。
SONY な logo を貼った方がインパクトあるかも。色数多いけど。

しぼみゆく気合いを消滅させないために NetBSD/news68k の英語ページも書くことにする。あぁ自虐的。
というわけで、曽田さん NetBSD/arc のページもよろしく〜。 ;-p

19990706

今日もいまいちやる気なしなのでやることリストでも書いておこう…

SCSI と FD。これは頑張るしかない。
boot loader。順序からしたら SCSI が先のような気がするが、こっちのほうが楽かな…
2次キャッシュ問題。これはどうした対処したもんか。
news700 対応。実際動かすかどうかはともかく、単一 kernel で両方対応させるのかどうか。
I/O アドレス指定の方法。 news700 対応するなら固定ではダメ。 tt0 も 68020 じゃ使えないのか?
機種判別方法。同じく news700 対応するなら CPU 判別でやるしかないか?
source の copyright 確認。 adrsmap.h とかまずいかも。 machid.h は newsmips と同じだから OK。
timer まわりの確認。動いてるようだが妙に時計が遅れるような…
RTC まわりの設定。NEWS-OS と年の設定が違うような…
zs まわり確認。妙に文字落ちするような気がするが sun3 も一緒か?
soft interrupt と AST の見直し。今は他の m68k と同じく emulate してるが、ハードで用意されてるんだからそっち使うべき。
keyboard と flamebuffer。 kb はいいけど fb はディスプレーどころかケーブルすらないからなあ…
COMPAT_NEWSOS。が、これは Lite2 見て newsmips から始めるべき?
memory parity 設定。今のところ無視してる。CTRL_RAM ってのもあったな。
その他のデバイス。 isdn, lpt, vme 等々…

……。うーん。重いのと細かいのばっかりだな。進まないわけだ。
あれ? news700 って locore.o からするともしかして 68851 PMMU じゃなくて独自 MMU なのか?
とりあえず address 指定方法は newsmips の news5000 merge の動向を見守ろう…

19990705

ほっとくことにする、と書いたそばから kernel を 0xc0000000 とか 0x40000000 とかの物理アドレスにマップしたらどうなるか試してみる。
……。どっちも固まってしまう。やっぱダメか。

うにゅ、などと投げやりなことを書いてたら再び tsubai さんから助言を頂く。毎度すいません。
助言に従いもう一度 NEWS-OS の boot0 を見直す。確かに trap #0 で ROM を呼び出してる感じ。
書けるかどうかはともかく、引数とその渡し方くらいはがんばって調べよう、そうしよう……

19990704

とりあえずごまかせば動いてるので 2次キャッシュの問題はしばらくほっとくことにする。
んで、次の課題の boot loader をちょっと見てみる。

NEWS-OS の secondary boot の /boot を objdump で逆アセンブルしてみる。
……。うーん。よくわからん。いまいち気合いが入ってないせいもあるけど。

もっと短い primary boot の boot0 を確認してみる。
が、こいつは a.out でなくベタ binary なのでそのままでは逆アセンブルできない。
いろいろ試行錯誤して "objdump --disassemble-all --architecture=m68k -b binary boot0" で出てきた。
……。が、特に ROM を call してるようなところは見当たらないような…
うーん。 ROM がどこかのメモリでポインタ渡ししてるんだろうか。

……。なんか気分が乗らなくてダメ。現状 boot はとりあえずできてるわけだし……。うにゅ。
そもそも "serial console の diskless nfs root で multi user まで動かす" という当初の目標はいつの間にか達成してしまってるわけで。
自分じゃ何にもコード書いてないけど。 cut and paste だけでここまで来ちゃうとは、さすが NetBSD というかなんというか…
pcscp の時はまだ自分で考えたコードがあったというのに。このままではいけない。

というわけで、やはり次は要求度の高い SCSI を志すことにしよう。
とは言っても、自分で全然理解できない上にデバイスの情報もないから、思いっきり先長そうだけど。
まずは SCSI driver に必要な関数群の把握かな。
sys/dev/ncr53c9x.c とか newsmips/dev/scsi_1185.c, newsmips/dev/sc_wrap.c あたりから見ていくか。
NEWS-OS で参考になるのは sys/newshbdev/screg_1180.h くらいか。
外出先の本屋でたまたま見かけたトラ技 SPECIAL に SCSI が載ってたのでそれも買う。

が、勉強から入ってるとここに書けるようなネタはなくなっちゃうなぁ。
news68k やり始めた 5月前半は暇だったけど今はまわりがバタバタしてるし。
まあ、趣味なんだからなんとでもなるか。ぼちぼち進めよう。

19990703

tsubai さんの助言に従い kernel text の cache flush をいろいろ試す。
昨日も書いたように pmove a2@,tc の MMU on 前後にいろいろコードを書いてみる。

CTRL_CACHE_CLR をたたくのはすでにやっているがダメ。
MMU on 前後で kernel text をがばっと読んでみるがやはりダメ。
MMU on 前に kernel text を読んで書き戻してもダメ。
MMU on 後に書き戻そうとしたら PG_RO なので無理ということに気づかず悩んでしまったり。

うーん。やはりうまくいかない。
もっとも自分の書いたコードが意図したとおりに動いてるのかも怪しいけど。

……と、書いたそばから間違い発見。あぅ〜、ごめんなさい。_o_
kernel text だけは PG_CI つけてないとダメ、って書いてたけど実はそうではなかった。
pmap_bootstrap() での data/bss 他の pte 設定は
```
protopte = (protopte & ~PG_PROT) | PG_RW;
```
なので kernel text で PG_CI つけてたらそのままこちらも PG_CI ついてしまう。
というわけで、修正した kernel で確認すると、 data/bss/pte も PG_CI つけてないとダメなようだ。
kernel text の場合は illegal instruction で、data/bss/pte の場合は MMU fault。うむ。
要は 2次キャッシュは全然ダメってこと。ところで 0xdeadbeef ってなにか意味あるのか?

しかしよく考えると、最初 pmap_enter() でも PG_CI つけてないとまともに動かなかったのだが……
I/O 空間を tt0 でマップするようにしたら PG_CI つけなくてもよくなった、ってのも変。
もちろん、 I/O 空間の pte には PG_CI を指定していた。

一度マニュアルの MMU あたりをじっくり確認した方がいいのだろうか……
NEWS-OS は特に何もしてないように見えるんだけど、何が違うんだ。
CTRL_PARITY とか CTRL_RAM とか関係あるのか?

19990702

tsubai さんから PWS-1560 でも single user まで到達、との報告が入る。
自分以外のところでも動いていると言われると、思ってたよりうれしかったりして。

ちなみに PWS-1560 では PG_CI なしでも変わりなく動いてるとのこと。
というわけで NWS-1750 でおかしいのは 2次キャッシュのせい、というのは間違いない模様。
よく考えると、以前は pmap_bootstrap() の中で全メモリリードとかしていたが、ホントは MMU on 直前にすべきか?
うーん。あとでちょっと試してみよう。

port-mips-ja で "mips系ワークステーションへの porting 備忘録" なるものがあるとの記載が。
ぐるぐるして発見。うおっ。これはやられた。
うーむ。どこかで見たような叫びが……。なぜかうちでも見覚えのある某うなり声まで……。
負けずに頑張らねば。って張り合ってもしょうがないけど。
ROM 内 routine とかってやっぱり参考にはならないのかなあ。
と、ここにもこんな記述が。偉い人。そーかー、そうだったのかぁ ;-p

19990701

気がつけば 7月。本体入手後 2か月経ったことになる。
ここまで動くようにはなったが、まだまだやることはたくさんある。
次はやっぱり SCSI かなあ。全然情報ないけど。
そもそも SCSI のドライバにどれだけのものが必要かすらよくわかってなかったりする。
pcscp は結局書いたの frontend だけだったしなあ。
NEWS-OS を調べても NetBSD とは全然違う作りしてるだろうし。

tsubai さんから PWS-1560 で mountroot() の rarp request が出てきたとの報告。
そこまでいけば supported model が一つ増えたと思っていいかな?
でも出すとこに出すにはまだ早いかな。

そういえば SCSI, fd 以外の課題として native boot-loader というのがあったな。
SCSI よりはこっちを調べる方がまだ楽そう。今週末の課題はこれかな。

19990630

プロバイダから smtp server 設定の変更の予告メールが来る。
昨日変だったのはそのせいなのか? でもそういう報告は何にも書いてないぞ?
まあいいや。ちゃんと設定直して MX 引くようにでもしようかな。

今日も 2次キャッシュをちょろちょろいじる。
初回電源投入直後の様子を探るが、multi user まで起動はしたものの、すぐに le0 がおかしくなる。
うーん。初期化だけじゃなくて実行時にも変になるのか?
NEWS-OS の 0x800xxxxx と 0xc00xxxxx のアドレスの使い分けが関係あるのか?

PWS-1560 の "level 3 interrupt" の件は fdc からの割り込みが原因らしい。
NEWS-OS の boot-loader は news1500 と news1700 を区別してるようだが…
ハードが違うからソフトも違うことしてるのか?
ひとまず NEWS-OS から初期化してるっぽいコードを真似して入れてみる。

うーん。次は勉強がてら fd.c を書いてみようか。
何が必要かいまいち把握できてないけど。
i386/isa/fd.c とか sun3/dev/fd.c とかいろいろあるけど、どれがわかりやすいかな。
そういや fd の fdc/fd 分離および MI/MD 分離とかいう話はどうなってるのかな。

19990629

なんか今日はプロバイダの smtp が変なのかメールが出ていかない。
全然関係ないけど、いろいろ調べてると知らないうちに APOP に対応してたのでまずそっちを設定。
sendmail.cf で指定したのと違う smtp server に投げに行くけどこれってこっちの設定か? 向こうのせいなのか?
とりあえず pop server に smtp 投げるとうまくいくようなのでそうする。

news68k は今日も 2次キャッシュまわりを探る。
CACHE_CLR をいろんなところでたたいたり MMU on 後 longjump させてみたり。
……。うーん。ハズレばっかり。
よくよく考えると昔は電源投入直後は動いてたんだから、やっぱり invalidate がうまくいってないのか?
しかしじゃあ NEWS-OS はなんで動くんだ? kernel text の pte をあとからいじってるわけじゃないよな?
hp300 はもともと PA!=VA でいろいろ細工してるから 2次キャッシュつきでも動いてるとか…

いろいろやってもダメなのでやる気なくなってくる。
とりあえず PG_CI つけてごまかしてると動くしなあ。
かといって scsi を書き始めるにはかなり先が長い。
とりあえず source の clean up でもするか?
それには単一の kernel でどこまでのモデルをサポートするかを決めた方がいいんだけど…
IOP 付きは今は除外して、安直に news700/1200/1700 の 3種類に分けた方が無難か?
I/O address とか全然違うし。まあ 1200 は置いとくにしても、 68020/68030 の機種間はかなり違うしなあ。

19990628

locore.s の最初の方の 2次キャッシュ制御ポートのいじり方を変えてみる。
……。いろいろやってみるが、 kernel text の PG_CI をはずしてると何やってもダメそう。
うーん。正解はあるのか?

PG_CI つけててもたまに le0 が変なのか yp まわりがおかしくなる。
が、動く時はちゃんと動く。 MI な問題なのか news68k な問題なのか……

などとやってる間に今日も i386 死にまくり。 1時間で 3回。
うーん。 current 化を真剣に考えた方がいいのかしら。
最近の current 事情ってどんな具合なんだろ。

19990627

tt0 使用バージョン kernel を PWS-1560 でテストしてもらうが、変化無しとのこと。
うーん。やはりどこかでなにかを初期化しないといけないのか。
NWS-1750 だとたまたま何もしなくて済んでるだけとして、 interrupt まわりのハードってなにかあるのか?
各デバイス自身はハードウェアリセットで初期化されてるはずだよな?
まずは INT_STATUS を確認するのが先かな。

割り込み問題はひとまず置いといて、PG_CI 問題をもう少し調べてみる。
pmap_bootstrap() 中の kernel text の PG_CI を外してみる。
起動。……。これはやはりダメな感じ。
今度は kernel data/bss および ste, pte 等のページの PG_CI を外してみる。
……。こっちは外したままでそれなりに動いているような……。
うーん。まだちゃんとテストしてないからわからないが、問題は instruction cache ということ?
見たところ 2次キャッシュに D/I の区別はなさそうなんだけど……。

なんかいい load test ネタはないかなということで crashme を作って動かしてみる。
man を見ながら開始。……なんかごちゃごちゃ出てくるけど、要は OS が落ちなきゃいいんだよな?
一応 userland が動いていることを確認するために裏で top も走らせておく。

お? 動きが止まったかと思ったらまた server の arm32 が固まってる。
しかしこれじゃテストにならんというか、一体何のテストをしてるんだか……。
めげずに走らせ続ける。…… arm32 は都合 3回固まったが、 news68k は動き続けてる。
と、 4回目の arm32 再起動後に news68k が panic() したけど、これって単に nfs 先の swap がおかしくなっただけのような気も…

swap を酷使すると arm32 がもたないので、今度は i386 上の nfs で egcs-1.1.2 をコンパイルさせてみる。
config.guess に news68k 追加して ./configure && make bootstrap 仕掛けてちょっと外出。

……。 3時間ほどして帰宅すると、今度は i386 が固まってる……。おーい。
かたや news68k は健気に "nfs_timer: ignoring error 64" と叫び続けている。
しかし一体なんなんだ。やっぱり SETI@home が悪いのか?
それとも気温のせいなのか? でも今日はそんなに暑くないぞ?

やっぱり NetBSD 1.4 の RELEASE 版はダメなのか。
floppy に書き込んだ瞬間とかパケット受け取った瞬間とかに固まることが多いから DMA まわりが変なのか?
spl まわりの追加修正パッチはあてているが変化なし。
i386 と arm32 だけでも current にしたほうがいいのかしら。うーん。

19990626

今日は次にやりやすそうなところとして Transparent Translation Register の設定に手をつけてみる。
これは何かというと、指定したアドレス範囲を PA == VA としてアクセスするようにするもの。
と思っているがちゃんと確かめてない。 powerpc の BAT もこれと似たようなものらしい。

しかし、手を付け始めたはいいがついつい久しぶりに macppc で遊んでしまったり。
……。 macppc の 1.4 の install kernel 付き xcoff boot loader なんてものを作ってひと段落。
んで news68k の作業に戻る。

まず Users Manual の中身を改めて確認する。
最初の説明は 9-13 ページの 9.3項 TRANSPARENT TRANSLATION にある。
具体的な設定については 9-47 ページ 9.7.3項 Transparent Translation Registers のところに説明がある。
が、以前にも書いたように、肝心の bit field の説明の図が "UNABLE TO LOCATE ART" と言って出てこない。
これは Figure 9-37 だが、他にも出てこない図がたくさん。
Win95 で見ても xpdf とかでも出てこないから、元から入ってないらしい。

他のページを眺めていると、 9-5 ページの Figure 9-3 の bit field の説明図がほぼ同じような感じ。
というわけでこれを参考に設定をすることにする。
マップする空間は 0xe0000000〜0xe1ffffff まで、アクセスは read/write とも、 cache は inhibit。
Function Code ってのがよくわかってなかったりするが…
ひとまず 9-14 ページの例に習って FC_BASE=5, FC_MASK=0 とする。

ということで locore.s にコード追加。
tc レジスタの設定の直前に tt0 の設定を入れる。コードはこんな感じ。
```
RELOC(protott0, a0)
movl #0xe0018550,a0@
pmove a0@,tt0
```
で、とりあえず make。……が、 as に tt0 なんぞ知らん、と怒られてしまう。おい。
tt0 は 68030 のみなんだっけ? binutils-2.9.1 の gas がいるのか?
……と、いろいろ探すと sun3/sun3x/locore.s で tt0 使ってるところがある。
上記命令は ".long 0xf0100800" でいいらしいのでそうしておく。
うーん、でもそうすると tt1 はどうなんだろ。まあこれは後回し。

もう一度 make。今度は無事通った。
起動。追加しただけで他は変えてないから当然だが問題なし。副作用はない。
次に news68k/machdep.c の中の IIOV() マクロを削除して make して起動。
……。無事 trap() も起こることなく立ち上がる。よさそうね。

というわけで "nuke IIOV() macros" 行動開始。
source-changes だとこの表現よく出てくるけど、どれくらい普通に使っていいんだろ。
などと考えながら news68k/dev 以下の clock_hb.c, zs.c, if_le.c の各ファイルを修正して起動。
……げ。 zstty1 の attach が終わったところで沈黙してしまう。何度やっても一緒。
これって tsubai さんとこと同じ症状か? でも ipl 3 の表示は出てきてないしなぁ。

しょうがないので一つずつ元に戻していく。
……。 clock_hb.c で IIOV() 復活させたらちゃんと起動する。

問題の箇所は clock_intr() 中の次の部分。

	/* Pulse the clock intr. enable low. */
	*(char *)IIOV(CTRL_TIMER) = 0;
	*(char *)IIOV(CTRL_TIMER) = 1;

これは sun3/sun3x/clock.c ほぼそのまま。 NEWS-OS では "sf CTRL_TIMER; st CTRL_TIMER" って感じ。
うーん、と考えて、 IIOV() 削除した上で上記 2行の間に DELAY(1); を入れてみる。
……。ちゃんと起動した。そーゆーことなのか?

tt0 が使えるようになったので、これで PG_CI 問題が変化するか確かめてみる。
まず pmap_enter() で無条件に "npte |= PG_CI" してたのを元に戻す。
起動。……。まともに動いてるような……。
何度も再起動したり kernel make とかしてみるが、落ちないようだ。
うーん。 cache flush ポートの VA が変だったのかなあ。計算上はあってたはずだけど。
それとも pte の参照回数が変わってくるから TLB まわりの影響なのか。
しかし PG_CI 外す前と dhrystone の結果が変わらないような気がするがそんなものか?

次は pmap_bootstrap() 中の kernel と pte その他のページにつけている PG_CI をはずしてみる。
……。こっちはダメ。以前と同じく configure() 以前でぼとぼと落ちる。
うーん。もう少し flush するポイントを見極めれば大丈夫なのか?

19990625

console が使えないとなにかと不便なので zs を確認してみる。
と言いつつ、手のつけやすいところをやってるだけだったり。

まず、ざっとみて zs_attach() 中で cs->cs_defspeed にどんな値が設定されているか printf() で確認する。
……。その結果、 zstty0 は 11815 なんて数字が出てくる。
zstty1 は zs_defspeed そのまま 9600 と出てくる。

現状 zs.c では PCLK は newsmips と同じ 4.9152MHz に設定している。
が、実際は 4.9152×(9600/11815) の 4MHz くらいという推定が成り立つ。
baud rate ならば 4MHz ちょうどというよりは 9600×416 の 3.9936MHz だろう。
PC98 でいう 8M 系と 5M 系というやつですな。
ということで、それを PCLK として設定。
make して起動。……。おし、 getty 正常に起動。よしよし。

今日は職場の飲み会でいい加減酔っているのでこれ以上は頭が回らない。
というわけで今日はここまで。おやすみ。ばた。ぐぅ。

19990624

朝起きてちょっと様子を見てみる。
と、なんと今度はメイン端末の i386 マシンが固まってしまっている。
うーむ。 arm32 はともかく、この調子の悪さは何なんだ。
SETI@home を妨害する電波が出てるのか?
なんてことあるわけないから単に仕事させ過ぎか夏が近付いているせいか。
それとも NetBSD-1.4 のどこかに問題ありなのか。

i386 再起動して news68k に login してみる。うん、まだ動いてるようだ。
親の telnet が死んで終わってしまっているが、 setiathome も 0.3% までは進んでたようだ。
それだけ確認して setiathome 再起動して出社。

帰宅。……見ると今度はまた arm32 が止まってる。だめだなあ。
再起動して様子を見てみる。
……。 news68k が全然メモリが足りてなくて、 NFS 先の swap のディスクがガリガリ言い続けている。
よくよく見ると 16M とってた swap file をほぼ使い果たしてる。あわてて追加。
こりゃ arm32 耐えられなくても仕方ないかも。それでも news68k は動いてるんだから問題なしか?

主な status はこんな感じ。

libero-% uptime
 9:42PM  up 19:12, 1 user, load averages: 2.26, 2.06, 1.79
libero-% ps -u
USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
tsutsui    248 25.0 36.5 14556 5960 p0- DN    7:58AM  333:45.17 ./setiathome
tsutsui    324  3.5  3.3   512  524 p0  Ss    9:40PM    0:01.26 -csh (tcsh)
tsutsui    394  0.0  1.1   252  156 p0  R+    9:42PM    0:00.20 ps -u
libero-% pstat -s
Device      1K-blocks     Used    Avail Capacity  Priority
/swap1          32768     7308    25460    22%    0
/swap           16384     9344     7040    57%    0
Total           49152    16652    32500    34%
libero-%

結局うちでの問題は 2次キャッシュまわりだけと考えていいのかな。
PG_CI 付きでは動くけど、なしだと動かない理由はわからないまま。
HP370 とかの 68030 で 2次キャッシュつきのマシンって実際に動いてるのか?
あと、問題といえば zs が腐るのと PWS-1560 での割り込みか。

げっ!! arm32 reboot したら arm32 自身の setiathome の途中結果が消えちゃってる。
あぁ 9日分の計算結果が… ようやく 50% 超えたとこだったのに、大ショック。

19990623

pmap.c の pmap_enter() で常に npte |= PG_CI するようにしてみる。
make して起動。…うむ、kernel #310 か。
全然関係ないが、 OpenBSD/hppa のページを久しぶりに見てみたら、 kernel #1078 になってた。
まだまだ先は長いな。

と、結構まともに動いているように見える。
あいかわらず console はぐちゃらけているが、 telnet は問題なし。
結構いろいろまともに動いているような気がする。
load test するならということでいきなりここで SETI@home の client を起動してみる。

起動したかに見えたがやはり固まってしまう。
が、 ping には反応し続けている。どうなってるのか?
と思ったら、死んだのは news68k ではなく nfs server の arm32 のほうらしい。
FPU 無しの SA-110 でここ一週間ほど SETI@home をやらせててやっと 50% 行ったとこだったんだけど、久しぶりに落ちたなあ。
というわけで arm32 を Reset。
が、また news68k 固まる。…かと思いきややはりまた arm32 が固まってる。
なんか突然調子悪いな。なんなんだ。

もう一回起動。今度はそれなりに動くが、やたらと server 側のディスクが忙しい。
news68k に telnet して top で調べると……結構調べられちゃうところだけでも大した進歩かも。
というのは置いといて、 daily cron が動いて server 側にがしがし access にいって arm32 が落ちたのか?
うーん。なぜか cron の負荷がいつまでも減らないが、 setiathome も動き続けている感じ。
とにかく PG_CI で状況は変化するということか。
また部屋が暑くなるけど、しばらくほっといて様子見てみよう。

19990622

userland でも cache flush は ld.*so とかで必要だよーん、とメールをもらう。
確かに libexec/ld.aout_so/arch/m68k/mdprologue.s とか見ると trap12 で cachectl1() を呼んでいる。
が、いずれにせよ今は userland 以前でおかしいので、 sysnews.o の cache まわりは気にしなくてもいい、ってことですね。

再び tsubai さんから動作レポートをもらう。お世話になります。 _o_
zs の attach の後で "level 3 interrupt." が表示され続ける、とのこと。
うーん。確かに昨日割り込みまわりかと思って printf() と status read を追加したような気もするが…
すでに鳥頭状態でいつ入れたのかはよく憶えてないです。すいません。
とにかくなにか割り込みがかかりっぱなしになっている感じ。
ipl 3 は fdc か scsi でどっちも attach してない(まだ書いてない)が、 news1500/1700 で微妙に違うのか…
それとも PROM の boot 時の操作の違いか…

PG_CI 有無では動作に違いはなさそうに見える、とのこと。
てことはやっぱり 2次キャッシュがついてるとなんか変、ということなのか…
pmap.c でもすべて PG_CI つけてみるか?
ま、それ以外の変なところを直すのが先かな。

割り込みがなにか変なのかなと思って intr.h で spl*() をすべて spl7() すなわち splhigh() にしてみる。
が、とくに変化無し。そもそも _spl() と _splraise() の違いもよくわかってないんだけど…
根気よく NEWS-OS を調べてデバイス初期化な感じの箇所を探すか…。うーんめんどくさい。

19990621

今日も打合せでしゃべりすぎでガス欠状態。
言ってはならないことをたくさん言ってしまったような気がする。はは。
というわけで帰ってきたら 23時。が、とりあえず新しい kernel だけ作ってみる。

PG_CI ありとなしの kernel を改めて作る。
やはりつけてないと configure() までたどり着けない。
ようなんだけど、実際どうなんだろ。

で、ひとまず tsubai さん宛てに送っておく。
無責任ですいませんが時間があればよろしくです。_o_

NEWS-OS の sysnews.o は NEWS-OS で man sysnews すれば載ってるよ、と曽田さんに言われたのを思い出して確認してみる。
cache 関連は二つ。 NEWS_CACHECTRL と NEWS_CACHFLUSH。

説明はこんな感じ。

NEWS_CACHECTRL
       Declare whether to use cache in the specified area
       (in the unit of a page) or not.  This is effective
       only on those machines utilizing an MC68030 as the
       main CPU, but ignored on those utilizing an
       MC68020.
       The format is as follows:

       sysnews(NEWS_CACHECTRL, addr, count, cacheable)
       
NEWS_CACHEFLUSH
       Flush the instruction cache or data cache in the
       specified area.  For those machines utilizing an
       MC68020 as the main CPU, this is effective only if
       FLUSH_ICACHE is specified; if FLUSH_DCACHE is
       specified, this is ignored.
       The format is as follows:

       sysnews(NEWS_CACHEFLUSH, addr, count, whichcache)

うーん。特に外部キャッシュを意識したものじゃなさそう。
しかしこれが用意されているということは、これらを使う必要がある場面があるということか?
が、そういえば NetBSD にも m68k_sync_icache(2) ってのはできてたな。

19990620

さびしー、などと軟弱なことを書いたせいか、 tsubai さんから PWS-1560 が近くにあるけどなにかしましょうか、と声をかけて頂く。どうもありがとうございます。
NEWS-OS の記述からすると news1500 シリーズも中身は news1700 とそう変わらない感じ。
なので 2次キャッシュがないとどうなるか、ということで試してもらう。

まず、今の kernel は news1700 の Model ID しかチェックしてないので news1500 の ID も追加する。
今まで Model 名は単純な const char 配列に入れてたけど、 newsmips/machid.h にあるように ID には隙間が多い。
なので hp300/hp300/machdep.c の struct hp300_model を真似して struct news68k_model を定義して ID から Model 名を引くようにする。それでも数多いけど。
ちなみに newsmips では PROM に ID ではなく Model 名が直接入ってるのでこんなことはしてない。
一応まず自分のところでテスト。うん、ちゃんと Model 名表示されてる。
ほんとは locore.s 中で ID 調べて news700/800/1200/1700/1800 のいずれのクラスのマシンか判定する必要があるんだけど…
まあそんな細かい話は後回し。

ということで、テスト用の kernel を作ってこちらから送って試してもらう。
……。その結果、 zs の attach まで終わった後で沈黙、とのレポート。
また、複数回やっても変化なさそう、とのこと。
うーん、 confiugre() は終わってるようだけど mountroot() までたどり着けない、って感じかな?
少なくとも cpu_initclocks() 中の printf() は実行されてない。
tcpdump で見ても le0 からは何も出てないとのことなので zs が死んだだけというわけでもなさそう。
これはこれでまた別の問題なのか? spl0() したところでダメになっているのか?
とりあえず 2次キャッシュの有無とは関係なさそうだけど…

そういえば 2次キャッシュがないマシンで 2次キャッシュ制御ポートたたいてもいいのかな。
ま、 NEWS-OS でも区別してなさそうな感じだからいいのか。

起動しないのはこの際ちょっと置いておこう。
2次キャッシュの影響の確認ということなら、明日は kernel page に PG_CI つけたのとつけない場合で変化あるか見てもらえばいいかな。
こちらで事前に試すと、 PG_CI なしだとやはり configure() にたどり着けないことが多い。
というわけでまた明日以降もよろしくです。

19990619

ここんとこ本業にまったく気合いが入ってなかったため今週も土曜出勤。
が、やはり気合いが乗らずテキトーに終わらせてしまう。

なんとなく NetBSD/hpcmips や NetBSD/sh3 の mailing list archive を眺めてみる。
うーむ。なんかみんな大人数で楽しそうですねえ。
一人きりの作業だとさびしーけど、やはり news68k の名前ではインパクトがいまいち。
どっちにせよ人に見せられるようなソースじゃないけど。

後輩に「なぜそんなマシンでやろうとか思うんですか?」と訊かれて、「『そこに山があるからだ』ってやつだよ」とか返事したのを思い出す。
山にもいろいろありますわ、ってことですな。
しかし、曽田さん仕事抱え過ぎという気がしないでもない。がんばれー。(無責任モード)

意味もなく昨日に引き続いて multi user での起動を目論む。
NWS-1750 の電源を入れてすばやく boot command を打ち込む。
……。例によって結構調子よく進んでいる。
"starting local daemons:." のあと、遂に getty 起動! ……かと思いきや console がぐちゃらけてしまった。
うーむ。 zs のボーレート設定かどこかがおかしいのか?
変なボーレートになっているのか parity まわりが変なのか…

console の表示はぐちゃらけているが、 telnet では外から普通に login できてしまう。
が、確率的事象だと思うと、やはりいまいち感動が足りない。
さも当然、という感じで su して /etc の下のファイルを vi で設定してまわったりして。
あまりにも普通に動くので思わず kernel make とか仕掛けてみたが、さすがに途中で panic した。

ゴールはすぐ目の前に見えているのに、その前に横たわる川を渡る術が見つからない、てな心境。
さあ、どこから手をつけたもんか。
今日はとりあえずあきらめてゲームだな。

19990618

あらためて昨日の kernel をブートしてみる。
……。やはりしばらくほっといた後の電源投入直後は調子いいようだ。
statclock() まわりがまともになったせいか、結構いろいろまともに動く。
ls とかだけでなく dynamic link なバイナリもちゃんと動く。
termcap を用意してやると vi も使えて rc.conf の編集もできちゃったりして。

また調子にのって multi user までいけるか試してみる。
結構調子よく進んだが、 "building databases..." のところで le0 が死んでしまったようで nfs server not responding で止まってしまう。
うーむ。前よりまともに進んでただけにちょっと残念。

しかしやはり動くのは最初のうちだけ。
まず "copying out path `/sbin/init' 11" のあと "uvm_fault(0x8b9c4, 0x27e000, 0, 0x1) -> 0x1" で落ちる。
0x8b9c4 は kern_malloc.c の free() の中の btokup() マクロのあたり。
これは malloc.h で定義されている。要は kmemusage[] の中身を読もうとして失敗している。
うーむ。アドレスがおかしいのか書き込む時に変だったのか。

他に昨日と同じく "le0: dropping chained buffer" が出ることも多い。
あとは ping には反応するがコンソールがダンマリになったり。
と思ったらおもむろに nfs_lookup() の中で落ちる。
マクロが複雑過ぎてよくわからんが、 nfsm_fhtom() のマクロの中か?

んで、次は 0x7cd94 で trap 1。
これは syscall() の最後の rts。
なにが悪いかというとスタックの中身が 0xabababab になっているようだ。
panic() 時の Kernel stack trace では 0xabababab に交じってまともそうな数値も入っているが…。
キャッシュからメモリへの書き戻しが変なのか? そもそもスタックポインタが変なのか?

また別のとこで落ちる。今度は 0x7a004 で pmap_enter() の中。
引数の pmap が 0x46fc2700 なのが悪いらしい。
が、値が悪いのか pmap が悪いのか…

というわけでよくわからないまま。ふぅ。

19990617

複数の kernel を黙々と何十回と起動して状況の把握を試みる。
確率的なところもあるので断言はできないが、なんとなく傾向がわかってきた。

まず、よくよく観察すると PG_CI をつけた時とつけない時とではやはり落ち方が違う。
PG_CI なしの場合は configure() が始まる前に落ちる場合がある(いつもではない)。
kernel text/data/bss 他にPG_CI をつけている場合は、少なくとも mountroot() までは進む。
ような気がする。やっぱりキャッシュもなにか変なのか?

次に statclock() で落ちる原因。
よーく調べると、 clock.c の中で stathz を初期化せず 0 のままにしてる場合に statclock() で落ちているようだ。
hp300 や mvme68k は複数のタイマがあるので stathz は hz と同じ 100 に設定されている。
news68k はタイマは一つだけなので sun3 と同じく stathz は 0 にしないといけない。
が、少し前のコードでは mvme68k のコードが残ってて stathz が 100 になってたようだ。
その場合 statclock() はどこからも呼ばれないので落ちなかっただけらしい。
で、その後いろんな落ち方をするのはキャッシュのせいか?
しかし、よくそんな状態で single user で動いたりしたもんだ。

statclock() で落ちる直接の原因は前に書いたとおり。
落ちているのは /sbin/init が起動する前だから curproc == 0 なのは問題ない。
つまり、 /sbin/init も動いてないのに CLKF_USERMODE(frame) が真なのが変、とのこと。

ということで statclock() ひいては hardclock() の引数の frame の出どころを調べる。
hardclock() は news68k/dev/clock_hb.c に書いた clock_intr() から呼ばれる。
これはほぼ sun3/sun3x/clock.c から持ってきたそのまま。
で、 clock_intr() は locore.s の _isr_clock() のハンドラから呼ばれる。
この _isr_clock() も sun3 から持ってきている。

が、よく見ると sun3 の locore.s の _isr_clock() では引数としてスタックになにも積んでいない。
他の m68k arch では、割り込み時の sp トップに積まれている値を改めてスタックに積んでいる。
さらによく見ると sun3 以外では引数は (struct clockframe *) だが sun3 では構造体そのものが引数。
そもそも sun3 は cpu.h の struct clockframe の定義からして違う。ハードで細工してるのか?
……ではなくて、 INTERRUPT_SAVEREG でスタックに積んだ分も struct clockframe に含めてるのか。
というわけで直す。まず locore.s で引数をスタックに積むようにする。
で、 news68k/dev/clock_hb.c 中の clock_intr() の引数もポインタ渡しに変更。

そしていつものごとく make して起動。
……落ちない。無事 stathz == 0 の状態で statclock() は動いてるようだ。
が、 RARP で "le0: dropping chained buffer" と怒られて IP が取得できない。
うーむ。これって今回の修正と関係あるのか? 単にキャッシュが原因の別の問題か?
まあ、これは明日考えよう。今日は一つ解決したから OK だな。

19990616

またまたアドバイスにしたがって news68k/include 以下のファイルを見直してみる。
思えば hp300, mvme68k, x68k と適当にいろんなところからかき集めているので、よく見ると変。
が、 intr.h の定義とかはともかくあんまり本質的なのはないような…
そもそもベースは同じなわけだし。

proc.h で MDP_STACKADJ が hp300 と mvme68k で違うのはなにか意味があるのだろうか。
param.h の UPAGES も 2 だったり 3 だったりするが…
non-contig 関係か? なんとなくそうなのか?
と考えながら作り直すが、目立った変化はない…のかなあ。よくわからん。
どっちにしろ、依然としてまともには動いてない。

うーん。昨日は PG_CI をつけてもダメ、って書いたけど、 PG_CI 付きと無しの kernel を同時に置いて 2つ交互に立ち上げてみると PG_CI 付きの方がなんとなく長持ちしているような…
気のせいなのか? それとも関係あるのか? 全部変なのか? locore.s いじりすぎか?

19990615

アドバイスにしたがって、 pmap_bootstrap.c ですべての pte に PG_CI をつけてみる。
make して起動。…ダメ。
やはりキャッシュではないのか。

最近よく起こるのは kern_clock.c の 925行目あたり、 statclock() で curproc == 0 なのに CLKF_USERMODE(frame) が真になってて p->p_uticks++; で落ちるというもの。
これが本質なのか、他が悪くてここもおかしくなってるのか、わけがわからん。
まあ、何回か同じ現象が起きているのだから手がかりには違いないが…

19990614

最初に mountroot() までたどり着いてから早10日。
いろいろやっているものの結局あれから何も進展していない。
このままではそろそろここに書くネタがなくなってしまう。なんとかせねば。

NetBSD admin-ja mailing list でさりげなく news68k の名前を出されてしまう。
う、とか思いながら某氏こと曽田さんに arc が載ってないぞお、とツッコミを入れるが、さらりとかわされてしまう。
そのかわり(?)に NEWS-OS のキャッシュ操作についてちょっと教えてもらう。
うーむ。 pmap_bootstrap() 中で全メモリリードとかしてもダメみたいだから、キャッシュは関係ないのだろうか。
tsubai さんも DRAM っぽいなあと言われてたそうだし。

もう一度 locore.s の始めから一通り見直した方がいいのだろうけど、この中途半端な状態ではいまいちやる気が出てこない。
せめて症状が一定してればいいのだが、 MMU fault だの illegal instruction だの bad kernel access だのいろいろ言われるとなんだかもう。
現実から目を背けて transparent translation register の使い方でも調べてみようかしら。

あと、 NEWS-OS を起動した時には 0x0 番地から memory 量その他の値が格納されてるみたいなのだが…
NEWS-OS の locore.o の _start 中にはそんなとこに書き込むコードはない。
boot loader が書くのかと思いきや NetBSD を起動した時は 0 のまま。

うーむ。 NetBSD と NEWS-OS で kernel の magic が違うせいだろうか。
NEWS-OS の vmunix は magic 410 だが "objcopy -O a.out-newsos3" の吐くコードの magic は 407。
NEWS-OS の file(1) で調べると "pure" がつくかつかないかの違い。
まあ、読み込めるんだったらそんなとこで区別してるとも思えないが…

そのほかに、 NEWS-OS では locore.s 中で vbr と sp に 0xc00xxxxx のアドレスを入れている。
が、 pte や crp, tt0, tt1, tc 辺りには 0x000xxxxx のアドレスを入れている。
ちなみに KERNBASE は 0x80000000。この辺なにか意味はあるのだろうか。

19990613

今日もゲームから始めてしまうが、意外とあっさりケリがついてしまう。
なので、仕方なく「UNIX カーネル内部解析」を本腰を入れて読み始める。

しかし、大学時代は仮にもプロセッサ関連の研究室にいたはずなので、いまさらこんなものを読んでいてはなにをしとったんだと言われそうだが…
ま、大学でする勉強は、理論と実装／教科書と製品とのギャップが大き過ぎる、ってことですね。
ヘネシー／パターソンの本じゃ OS 側の実装にはあまり触れてないし。

実際今の仕事でも、講義や研究室で学んだことより、自分が趣味でやってたことの方がよっぽど役に立っている。
電子回路学の教科書だけじゃ、実物の回路作れないもんね。やっぱラ製(まだあるのか?)とトラ技だよ。
大学の研究室で唯一学んだことと言えば、
「進んでいない仕事、芳しくない成果を、如何に素晴らしい結果に見せるか」
という発表技術の重要さ、ですな。

などと下らないことを考えながら、キャッシュについて一通り読み終える。
大雑把な概念はつかめたが、やはりキャッシュの実装がどうなっているかを知るのが先。
MC68030 自体は命令／データ分離の仮想キャッシュだが、サイズが 256byte ずつなので alias 等の問題は起こらない。
単純に context switch 時に flush してやるだけ。これは他の m68k arch と同じ。

問題は 2次キャッシュの仕様。現時点ではほとんど不明。
まあ NWS-1750 が出た時代からして、命令／データ統合・direct map・write through・バス監視なし物理キャッシュといったところだろうが…
フラッシュ操作も一つしかないみたいだし。
ところで hp300 の物理キャッシュのマシンはどういう仕様なのだろうか?
簡潔さが売りの物理キャッシュだから、どちらもそんなに複雑なことしてるとは思えないが…

物理キャッシュであれば、 OS が関与する必要があるのは I/O 操作時くらい。
が、 DMA は使ってない(使い方がわからん)ので現時点では問題ないはず。
どの範囲の物理アドレスがキャッシュされるのかはよくわからん。

怪しいと言えば、 PROM monitor がハードディスクから kernel をメモリ上に読み込む時。
monitor 上でキャッシュがどう扱われているかはわからないが…
monitor で CACHE_CTRL の 0xe1300000 に何か書き込んでから boot すると "Boot error 4" が発生する。
NEWS-OS も一発目の起動の時は kernel 読み込み後 copyright 表示まで 3秒ほど間があるので、そこで何かしてるのか。
locore.s の先頭で "st 0xe1900000" はしてるけど、それだけでは足りないのか。
試しに FDD から boot させてみるが変わらず。 network boot なら変わるのか?
でも NEWS の場合設定がめんどくさいぞ。

19990612

じっくり読んでみよう、とか書いたものの、相変わらず未練がましく locore.s をいじってしまう。
cache flush のやりかたをいろいろ変えてみたりするが、変えたのに対応するような変化はなし。

動かないマシンに向かってばかりだと滅入ってくるので、気分転換にドライブにでも出かけてみる。
あてもなく走って気がつくと日本海。といっても感慨に耽けるでもなく、ただぼーっと海を眺めて戻る。

気分転換したところで、ようやく NEWS-OS のバイナリを調べ始める。
CTRL_CACHE_CLR の 0xe1900000 は locore.o の dcia() 等何か所かで使われている。
が、 CTRL_CACHE の 0xe1300000 は locore.o の _start の最初で一回 "st 0xe1300000" されてるだけ。
うーむ。 2次キャッシュって NEWS-OS では常に ON されてるのだろうか。
というより、そもそも 2次キャッシュを disable することってできるのか?
NEWS-OS も起動時には "Enable Internal Inst/Data Cache" と言うだけ。

次はそれっぽい symbol を key に検索してみる。
今までにわかっている分として、 locore.o 中に icia(), dcia(), cache_ctrl() がある。
cache_ctrl() は引数を cacr レジスタに入れるだけ。
icia(), dcia() はそれぞれ I-cache/D-cache を flush している。
といっても、 2次キャッシュについては I/D の区別はなく、どちらも "st 0xe1900000" してるだけ。

他に cache 関連ぽいのがあるのは locore.o 以外では machdep.o くらい。
ぱっと見てわかるのは cacheflush() と cachectrl() の二つ。
cacheflush() は引数に応じて icia() と dcia() を呼んでるだけ。
cachectrl() は長くていまいちよくわからん。頑張れば discompile できなくもなさそうだが…
vtopte() を呼んで、いろいろ bit test をしては dcia(), icia() を呼んでたりする。
この cachectrl() がどこから呼ばれているのかも問題だが、やはりめんどい処理が必要なのだろうか。
うーむ。この辺の元のソースをおねだりしたほうが早いのだろうか。

他に machdep.o の startup() も眺める。
PROM 内部 routine は使ってない(使えない)から PROM に reserve されてるページは map しなくてもいいはずだよなあ。
"Enable Internal Inst/Data Cache" を表示するのは startup() から呼ばれる initcpu() の中。
といっても、単に cache_ctrl() を呼んで cacr を設定してるだけな感じ。

cacheflush(), cachectrl() の symbol があるのは sysnews.o の中。
実際には cacheflush() しか参照されてないみたいだが…
sysnews() は machine dependent な処理をまとめてテーブルで処理してるのか?
sysnews() で検索しても引数がわかんないとつらそう。
やっぱりソースが見てみたい…。

19990611

依然として壁にぶち当たったまま。
まあ今までが都合良くとんとん拍子に進んでいただけだけど。

cross な egcs をもう一度作ってみる。
pkgsrc/cross の下に m68k-netbsd をでっち上げる。
BINUTILS_GNUTARGET と TARGET_ARCH に m68k-netbsd を set。
BINUTILS_LDEMULATION に m68knbsd を set。
んで、 make。前と同じように egcs の途中の cross ar でこける。
どうも pkgsrc cross な binutils がちゃんとできてないようなので、現状の cross 用 binary を使うようにする。

……。よし、 cross egcs はできた。
make install して、 cross make script で cc は pkg の egcs, binutils は手持ちの cross binary を参照するようにする。
早速 kernel を make。んで、起動。でや。
……。相変わらずのようだ。

問題は news68k quirk なところにあるのだろうか。
だとすると NEWS-OS の解析でもしないと、いきあたりばったりではどうしようもない。
怪しいといえば 0〜0xfff までの firstpage の部分だが…
その前に、明日は「UNIX カーネル内部解析」をじっくり読んでみることにしよう。
さ、今日はもう NetBSD やめてゲームしよ。

19990610

今日も本業でエネルギー使い果たした感じ。
なので思いつくままにいろいろ試すだけにする。

pmap_bootstrap.c で pte の 0 clear をしないようにする。……変化なし。
pmap_bootstrap.c で全メモリを 0 clear する。……改善の兆しなし。
locore.s の中で movew #PSL_LOWIPL,sr してたのを configure() の最後で spl0() する。……効果なし。
locore.s 中の BSS clear を削除。……ダメ。

うがーーーー!! なにが悪いんだ!!

気分転換に powerpc の COMPAT_LINUX でもやり始めようか。
それとも pkgsrc の m68k-cross の egcs をちゃんと作れるようにするか。
ちなみに今の cross 環境は 1998/05 あたりに sun3 用に作った NetBSD-1.3 の gcc-2.7.2.2+myc1 ベース。

19990609

今日は本業を気合いを入れて片付けた上で早く帰ってくる。
とりあえず locore.s や pmap_bootstrap.c をちょこちょこいじって試す。
…が、敗北。くぅ。

pmap.c の pmapdebug をすべて有効にして様子を見てみる。
うーん。 pmap_enter() していく途中でおかしくなっているようにも見えるが、 printf() でおかしくなっているような気も…
そのうち pmap_init() 前でもおかしくなる。
挙げ句に最初の printf(version) が動き出す前にいきなり monitor に落ちてしまう。

うーむ。やはり pmap 以前の問題なのか?
locore.s も pmap_bootstrap.c も他の m68k とくらべ変なところはないと思うのだが…
わからん。やっぱり全部一から理解していくしかないのか?
というわけで、あとはゲームに走ってしまい気がつくとえらい時間。
こりゃ明日もダメだな。

19990608

昨日遊んだツケを本業で払っていたら帰宅時間が 23時半。
ゲームと NetBSD と本業、どれかは犠牲にしないといけないが、優先順位は?

時間がないが、 PAC についてちょっと調べる。
適当に "grep CACHE_HAVE_PAC /sys/arch/hp300/*/*" してみる。
実は少ない。 DMA を除くと本質的には hp300/sys_machdep.c の cachectl1() だけ。
これは pmap.c の pmap_procwr() から呼ばれる。

なのでとっとと試してみる。
news68k/include/cpu.h の定義を #define CACHE_HAVE_PAC に変更。
locore.s の ectype を EC_PHYS に変更して PCIA() に 2次キャッシュクリアのコードを追加。
んで、起動。でい。
……。見た目なんら変わるところなし。動く時だけ動こうとする。
zs の echo back が返ってくることが多くなったような気はするが…。よくわからん。
うーむ。意図したとおりに動いてないのか意図が間違っているのか…
やはり問題は pmap のほうなのか?

うお? 一回だけ "starting system logger" まで進んだぞ? なんだ? これも確率の問題なだけか?
…と、ほっといたら引っかかりながらも ypbind まで起動した。
が、 /usr/lib の下を展開し忘れている。しまった。
うーむ。状況は改善されているのか? ただの偶然なのか?
止まってる隙をついて server に/usr/lib 以下を用意してやると、さらに徐々に進んでいく。
結局 "clearing /tmp" のあとあたりで panic()。
うーん。ここまで動いても偶然だとするとあまりうれしくないぞ。

19990607

危惧していたとおり(?)、今日は昨日の新たな障壁によりほとんど作業できず(わはは)。

とりあえず、たまたま動いた時に取れた single user 記念の screen shot でも張っておこう。

NEWS> bo /3
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd()/netbsd
548696+26004+110408 start at 0x00001000 (magic 0407)
Copyright (c) 1996, 1997, 1998, 1999
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.4 (LIBERO) #173: Sun Jun  6 19:37:49 JST 1999
    tsutsui@mirage:/usr/src/news68k/sys/arch/news68k/compile/LIBERO
SONY NET WORK STATION, Model NWS-1750, Machine ID #10557
real mem  = 16756736
avail mem = 13197312
usbbing 409 buffers containing 1675264 bytes of memory
mainbus0 (root)
hb0 at mainbus0
le0 at hb0 addr 0xe0f00000 ipl 4: address 08:00:46:00:35:36
le0: 8 receive buffers, 2 transmit buffers
clock0 at hb0 addr 0xe0d807f8 ipl 6: Mostek MK48T02, 2048 bytes of NVRAM
clock0: delay_divisor 82
zsc0 at hb0 addr 0xe0d40000 ipl 5 vect 64
zstty0 at zsc0 channel 0 (console)
zstty1 at zsc0 channel 1
hz=100, stahz=100, profhz=100
boot device: <unknown>
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=0xc0a81409 (RARP from 0xc0a81408)
nfs_boot: server_addr=0xc0a81408
nfs_boot: hostname=libero
root on diamante:/export/NetBSD/news68k/root
WARNING: bad date in battery clock -- CHECK AND RESET THE DATE!
/etc/rc: Can't open /etc/rc
Enter pathname of shell or RETURN for sh:
#
#
# ls
altroot dev     home    mnt     proc    sbin    swap    tmp     var
bin     etc     kern    netbsd  root    stand   sys     usr
# ps
  PID TT  STAT      TIME COMMAND
ps: warning: /var/run/dev.db: No such file or directory
    5 ??  Ss     0:00.39 -sh
    7 ??  R+     0:00.22 ps
# df
Filesystem                           512-blocks     Used    Avail Capacity  mounted on
diamante:/export/NetBSD/news68k/root    2062354  1381700   577536    70%    /
# halt

halt したあとでそのまま固まっててそこでおしまい。
うーん、 #173 か。ま、そんなもんでしょ。
ちなみに最初の起動から wdc, adv に pcscp と遊びまくった macppc は現在 #485。
そういえば、 adv と言えば、先日の修正が commit された。

ついでにおかしくなった時はこんな感じ。

[...]
trap type 1, code = 0xa64d, v = 0xabababab
kernel program counter = 0x7db0a
pid = 1, pc = 0007DB0A, ps = 2000, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: 00000000 00000004 ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB 00000000
areg: 0065F000 0065D2A4 ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB FFEFFD74

Kernel stack (0065FEC4):
65FEC4: 0007D4C6 0065FF10 00000080 ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB
65FEE4: 00000000 ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB 00001320
65FF04: 00000001 0000A64D ABABABAB 00000000 00000004 ABABABAB ABABABAB ABABABAB
65FF24: ABABABAB ABABABAB 00000000 0065F000 0065D2A4 ABABABAB ABABABAB ABABABAB
65FF44: ABABABAB ABABABAB FFEFFD74 00000000 20000007 DB0AB00C CEEEA64D 286E0000
65FF64: 0065FFAC 0065FFAC FFFFFF0D 4E754E75 ABABABAD ABABABAD ABABABAD ABABABAB
65FF84: 4E56FF0D 000FF07C FFFFFF0D ABABABAB 00003C7C 00000000 80200000 ABABABAB
65FFA4: 00002000 00000004 0065FFAC ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB
65FFC4: ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB
65FFE4: ABABABAB ABABABAB ABABABAB ABABABAB ABABABAB ABAAABAB ABABABAB 
panic: Address error
trap type 1, code = 0xf64d, v = 0xabababab
kernel program counter = 0x7e48e
trap during panic!
[...]

0xabababab ってのは monitor が起動時の memory test で書き込む値。
でも起動時の書き込みでおかしくなるのなら、電源を入れてからの時間は関係ないと思うのだが…。
問題は 2次キャッシュなのか? pmap なのか? それ以外の別のものなのか?

19990606

ふと気がつくと電気をつけたまま寝てしまったようで、時計を見ると午前 3時を指している。
前回(いつから連載になったんだ)あんな引きで終わったので、なんだか考え出すと気になって仕方がない。
というわけで、こんな時間からいきなり作業を始めてしまう。

まず m68k/m68k/cacheops.c まわりの削除。
files.news68k 直して、 #include <m68k/cacheops.h> を足したものを削る。

次に hp300/locore.s から TLB/cache flush まわりのコードを持ってきて、 cpu.h に prototype 追加。
#ifdef M68040 の部分は鬱陶しいので削る。
#if defined(M68K_MMU_HP) の部分のうち、 2次キャッシュに関する部分は残し、 HP MMU 自身の操作については削る。
"do not ask me, this is how hpux does it" なんて書いてあったりしてよくわからんところもあるが…
TLB invalidate の時に 2次キャッシュって flush しないといけないのか?
hp300 だと #ifdef DEBUG の中で jne _C_LABEL(_TBIA) してたりするが…

一応書けた。思ったよりは簡単だったけど…本当にこれでいいのか?
pmap.c はまだだけど、ひとまず make してみる。
その前に pmap_bootstrap.c でキャッシュ制御ポートの VA を locore.s 内の変数に代入しておく。
素直にリンクできた。で、起動。
……。あんまり確認してないが、 panic() の仕方とかはあんまり変化してないような…
強いて言えば、 panic() 中にたまに hang して monitor までたどり着けないことがあるような気がする、って程度か?

もう一度書き直したコードを見直してみる。
ん? hp300 のだと ICIA() で 2次キャッシュクリアしてないみたいだけど、いいんかいな。
それに、 Invalidate data cache の場合 on-chip cache については aliasing problems はないから flush しなくていい、って書いてあるけど…
NEWS-OS の locore.o では dcia(), icia() とも on-chip キャッシュをクリアしているように見える。どっちが正しいんだ?
Invalidate TLB のほうでクリアしてれば問題なしってこと?
ICIA(), DCIA() それぞれ直して試してみるが、特に変化ないようだ。問題の本質ではないのか?

ここまでやったからには pmap.c 周辺も直してみる。
まず pmap_bootstrap.c で pmap_aliasmask を設定。機種判定はひとまずおいておく。
で、news68k/include/cpu.h で #ifdef news1700 の時 #define HAVE_VAC する。
そうしておいて pmap.c の #ifdef M68K_HP_MMU を #ifdef HAVE_VAC に置き換える。…のでいいのか?
だいたいはこれでいいはずだけど、 firstpage ってのの扱いがよくわからん。
要は hp300 の先頭ページは特殊用途で例外、ってことだよな?

こちらもわりと簡単にできた。なにも考えてないから、という説もあるが…
再び make。……。今回も何事もなくリンクできてしまう。
で、起動。さぁ、どーだ。
……。最初の Copyright の "C" を表示したところでいきなり panic()。がっくし。
今回も電源切ってほっとけばもう少し先までは進むのか? でもどっちにしても変化なしということか…
うーん、もう外が明るい。鳥のさえずりも聞こえる。ダメだ。Zzz…。

再び目覚める。時計の針は午前 11時半。で、再びマシンに向かう。
こんなことしてたら今週仕事続かんぞ、とか思いつつやっぱり遊びが優先。

……。いろいろ試してみるが、芳しい成果は得られないまま。
以前と変わらず、一発目はそれなりに動こうとする。
何回か起動しているとだんだん panic() するタイミングが早くなる。
panic() の時の stack trace を見ると、表示される pc と code の中身が実際の kernel の中身と違う。
やっぱり参照が変なのは確かのようだ。しかしなぜ時間とともに変わるのか?
キャッシュの disable も flush も実はうまくいってなくて、 valid/invalid の初期状態で動いたり変だったりするのか?
キャッシュの制御にはもっと難しい操作が必要なのか? NEWS-OS をもっと調べないといけない。

ひとまず飯を食うことにする。ふう。で、その間電源を切ってた NWS-1750 の電源を入れ直す。
いつものように起動すると "/etc/rc: Can't open /etc/rc" の表示が。そういえば /etc/rc 消しといたんだっけ。
"Enter pathname of shell or RETURN for sh" が引き続いて表示される。これを見るのは初めてだな…
今回は panic() しないのか、と RETURN を叩くと、なんと! echo back が返ってくるではないか! おおおっ!?
実は zs は無実なのか? そうなのか? …などと動揺していると、なんと今度は "#" の /bin/sh prompt が!!
うおおお〜〜〜っ!! これって 祝! single user 到達 というやつか?
興奮を抑えつつ ls と打ってみる。…が、反応がない…
と思いきや、約 1分後にちゃんとディレクトリが表示された。よっしゃ!!

う〜む。遅いとか ping の反応が変とかいろいろ問題はあるが、動く時は動くということか。
つまり、今現在直面している壁は厚そうだけれども、それを越えればその向こう側のゴールはもうすぐだということ。
おし、なんだかまた元気出てきたぞ。今週もゴール目指して頑張ろう。

……。とは書いたものの、今日は早くから作業したので一日が長い。
ひと段落したので、某氏に勧められた「UNIX カーネル内部解析」の本を買いに出かける。
街の本屋をいくつかまわって 3軒目で発見。税込み 4,587円なり。くぅ。
が、ついでに(?)新たな Win Game も買ってしまう。あぁまた新たな障壁が…

買ってきた本を眺めてみる。
「キャッシュとマルチプロセッサの管理」と副題があるが、まあ MP にはまだまだ縁がないだろうな。
ぱらぱらと眺めていて、ふと 68030 の NWS-1750 のキャッシュは物理アドレスキャッシュではないかという気がしてくる。
68020 なら MMU 外づけだが、 68030 では外部に仮想アドレスは引けるのか?
hp300 でも 68020 の HP320 等は VAC だが 68030 の HP370 とかは PAC。
とりあえず明日からは PAC 前提でコードを直してみよう。

19990605

printf() 動作 & mountroot() 到達おめでとう mail をもらう。
どーもどーも、とか言いつつ、「printf() が動いた感動」をわかってくれる人って世の中ほとんどいないんですよねぇ、とかやりとりしたり。
その他に 2次キャッシュと pmap の兼ね合いの解説もしてもらう。
コード切り貼りしてるだけじゃなくて中身ももう少し理解しないと…。

今日はまず現状どうなっているのかを確認してみる。
昨日と同じく、電源投入直後は /sbin/init が立ち上がって sh が動きそうなところまでは行く。
たま〜に "Automatic boot in progress: starting file system checks." が表示されたりする。
ping を打ってみると、普通に反応する時と 5秒くらい沈黙してまとめて返事してくる時とがある。
何回かやっていると MMU fault だの uvm_fault だの illegal instruction だのが出始める。
そのうち configure() が始まる前にすでにおかしくなってしまう。

うーむ。おかしいのは確かだが、どうも原因は一つではなさそうだ。
あんまり根拠ないけど。まあここまで動いてるのが不思議なくらいだから…

まずメモリがおかしくないか確認してみる。
NEWS-OS は (parity error とか起きたことあるけど) 今のところ普通に動くので、ハードが原因ってことはないと思うが…
久々にふたを開けて、軽く掃除して SIMM を疑惑の韓国製のものから SS1+ から外したものに交換する。
起動。とりあえず monitor はふつーに立ち上がる。
NEWS-OS を動かしてみる。いろいろ試すがこれも普通に動く。
で、 NetBSD を起動。…何回か試すが、時間が経つにつれおかしくなっていく、という症状は変わらず。
うーむ。やはりハードの問題ではないようだ。

しかし、panic() する度に RESET するのがなんだかめんどくさくなってきた。
たかが RESET といっても、電源スイッチを押しながら RESET を押す必要がある。
その上本体前面のカバーが邪魔で、片手で押すにはかなり無理があるのだ。

というわけで、再び monitor に落とす方法を探ってみる。
飛び先の見当はついているので、あとは引数だけ。
locore.s の doboot() に monitor に飛ぶコードを追加。
NEWS-OS のバイナリをざっと眺めて、引数は d7 に 0x08 を入れてみる。
起動。…うまい具合に(?)すぐ panic() してくれる。
で、キーを押して "rebooting..." の表示の後、見事 "NEWS>" のプロンプト登場。完璧と言えよう。ほほ。

次にソフト的な要因を考えてみる。
ちゃんと考えてないが、以前 sun3 で pmap の初期化がされてなくておかしくなった時の症状に似てなくもない。
というわけで、ふたたび pmap_bootstrap.c から見直す。
怪しいところと言えば、 hp300 quirk である pagezero や last kernel PT page の処理。
中途半端に残っている部分があったが、バッサリ削除してみる。で、 make してひたすら起動。
あいかわらず動きかけたり panic() したりと変だが、ひとまず mountroot() より前で変になることはなくなったような…

前回削除した identifycpu() 中の Model ID → Model 名変換のコードを復活させてみる。
何も変えてないはずだけど、今度はちゃんと動いているような…
やっぱりどこか参照がおかしくなっていたのか?

次は machdep.c やら vm_machdep.c やら pmap.c やらの上記 hp300 quirk 処理を探す。
全部削除する必要はないかも知れないが、元にした source が hp300 と mvme68k がごちゃまぜなのでおかしい可能性は大。

……。わからん。
いろいろ試してみるが、これといって変化なし。
やっぱり 2次キャッシュまわりをちゃんと考えないとダメなのか?
disable してても勝手に ON してるのか? それとも OFF にしててもなにか副作用があるのか?
電源切って 10秒じゃ消えないけど 2分で消えるといったらやっぱり SRAM くらいか?

仕方がない。どーせいずれは必要になるんだから hp300 から 2次キャッシュのコード持ってきてみるか。
そうなると cacheops.c は使えなくて hp300 のように locore.s に TBIA() やらを書いて…
pmap.c と pmap_bootstrap.c も直して…。 HP_MMU のキャッシュ操作を news68k 用に置き換えて…
…なんか多いな。まあいいや。さあ、結果は如何に? 待て、次号!

19990604

今週はようやく土曜日休めそう。
「100ある仕事のうちの 50をこなして 80やったように見せる」ってな感じか?

ふと気づくと、この port-news68k.html のサイズがいつの間にか 100kbyte を超えている。
しかし我ながらよく書いたもんだ。ま、自分で読み返しても役に立つからいいでしょ。
printf() 動いた記念というわけでもないが、ページのスタイルをいろいろ手直しする。
jweblint かけてみたり lynx でも見やすいように変えてみたり。
ついでに以前作った NEWS logo も張り付けてみる。
うん、こんな感じかな。

んで、昨日の続き。
uvm_fault の中に表示されている 0xe1c00000 ってのは IDROM のアドレス。
要はそれを使ってる identifycpu() の中で IIOV() 足すの忘れてるだけ。
直して起動。…あれ? identifycpu() の中で panic() もせず沈黙してしまう。
うーん。怪しいといえば model ID から model 名の変換をしているところ。
何故ならば私の書き直したところだからだ by坂本さん。
って全然書いてるもののレベルが違うけど。
model 名の配列は /sys/dev/ic/ncr53c9x.c を真似して書いているのだがいけないのか?

深く考えるのはやめて model ID だけ表示するように直す。
起動。…次は hb0 at mainbus0 の後で panic()。
アドレスを見ると今度は badaddr() の中。
news68k/dev/ 以下で badaddr() 使ってるところ調べると if_le.c で IIOV() が余計についてた。
直してまた起動。…今度は clock0 の attach 最中に set_vector_entry() で panic()。
これは単に sun3 から持ってきた時に、チェックに使う値の define を間違えただけ。
また直してまた起動。…今度は mountroot() まで進んだみたいだぞ。
ちゃんと root device とかも入力できる。入力できるだけでそれ以上動かないけど。
少なくとも cngetc() についても動いてるってこと。

config に "options NFS_BOOT_BOOTPARAM" をつけてなかったのでつけて作り直す。
起動。tcpdump で確認するとちゃんと RARP request 出してるようだ。えらい。

割り込みハンドラ書いてないから受信ができないのは当然だが、 time out すらしてくれないということは、書いたはずの timer 割り込みも動いてないのか?

NEWS> bo /3
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd()/netbsd
559068+26168+110524 start at 0x00001000 (magic 0407)
Copyright (c) 1996, 1997, 1998, 1999
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.4 (LIBERO) #96: Thu Jun  4 19:02:18 JST 1999
    tsutsui@mirage:/usr/src/news68k/sys/arch/news68k/compile/LIBERO
SONY NET WORK STATION, Model Id 13, Machine ID #10557
real mem  = 16760832
avail mem = 13193216
using 409 buffers containing 1675264 bytes of memory
mainbus0 (root)
hb0 at mainbus0
le0 at hb0 addr 0xe0f00000 ipl 4: address 08:00:46:00:35:36
le0: 8 receive buffers, 2 transmit buffers
clock0 at hb0 addr 0xe0d807f8 ipl 6: Mostek MK48T02, 2048 bytes of NVRAM
clock0: delay_divisor 82
zsc0 at hb0 addr 0xe0d40000 ipl 5 vect 64
zstty0 at zsc0 channel 0 (console)
zstty1 at zsc0 channel 1
boot device: <unknown>
nfs_boot: trying RARP (and RPC/bootparam)

さて、今度はどう debug しようかな。
今は printf() 使えるので結構余裕かましてたりして。

まず debug より前に le の割り込みハンドラを用意する。
machdep.c を開いて newsmips/newsmips_trap.c の真似して status register を見て leintr() を呼び出すようにする。
make して起動。…おっ。stray intr とか文句をいいながら RARP での IP address 取得には成功。受信してるぞ。
よくわからないが time out もしてる。これって timer 動いてるのか?

ここまであっさり進むとは思ってなかったので nfs server 側の準備をちゃんとしてなかったが、改めて diskless boot の設定をする。
適当にファイル展開して、 /etc/bootparams 直して、んでもう一回起動。
stray intr がやたらと出るので見にくいが…
"init: copying out path /sbin/init 11" は出た。
そのあとで trap2 で落っこちた。場所は mi_switch() の中か?
うーん、よくわからん。もうちょっと printf() の出し方をなんとかしよう。

と、いじってたらまたまた identifycpu() あたりで落っこちるようになってしまった。
何が起こってるんだ? 毎回違うところで落ちてるような…
割り込みが変になったのか? ちゃんと初期化してないから動く時だけ動くとか?

うーん、元に戻らなくなってしまったぞ。どうなってるんだ。
挙げ句に panic: pmap_enter_ptpage: can't get KPT page とか出るし。
もしかしてまたメモリがおかしくなったのか?
そのわりには NEWS-OS は動くよなあ… やっぱり uninitialized ほにゃららか?

どーがんばっても元に戻らん。どーなっとるんだ。
panic: pmap_init: bogons in the VM system! とか言われることが多いような…
うーむ、 single user までもう少しかと思った途端こうなるとは… ま、世の中そんなに甘くないってことか。
それ以前に RCS とか使ってれば元に戻れたのか。ちゃんと考えようかな。

…と、 make clean して make し直してる間 NWS-1750 の電源切っておいて次に起動したら立ち上がったぞ。
実は本体の問題なのか? それだけはかんべんしてくれ。
何度か試す。…やっぱり電源切って 2分ぐらいほっとくとちゃんと立ち上がるようだ。
まあ今はあまり深く気にしないことにする。

で、あらためてどこまで進んでいるか確認する。

[...前略...]
zsc0 at hb0 addr 0xe0d40000 ipl 5 vect 64
zstty0 at zsc0 channel 0 (console)
zstty1 at zsc0 channel 1
boot device: <unknown>
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=0xc0a81409 (RARP from 0xc0a81408)
nfs_boot: server_addr=0xc0a81408
nfs_boot: hostname=libero
root on diamante:/export/NetBSD/news68k/root
root time: 0x3757d9f1
WARNING: bad date in battery clock -- CHECK AND RESET THE DATE!
init: copying out path `/sbin/init' 11
/etc/rc: Can't open /etc/rc

ここまでで沈黙。しかし ping には反応する。
これって root は mount できてて /bin/sh も動いてるけど、 zs がおかしくて出力されないってことなのか?
うーん、ほんとにもう少しなのか? だまされてないよな?

ヤケになって multi user mode になるかどうか試してみる。
動くわけないと思いつつ動いたらどうしようなんて考えながら /etc の下やら /usr の下やら用意する。
…準備 OK。電源切って、しばらく待って、起動。
i386 マシン上で tcpdump の出力を見ながら news68k の console の 98note の画面をじっと見る。
と、"Process (pid 1) got signal 11" というのがどどどーっと流れ続ける。
動きかけてはいるが動いてはいない、ってことか。
まあいいや。明日になったら zs をちょっと真面目に調べてみよう。

19990603

仕事はあいかわらずたまりまくっているが先送りしてとっとと帰ってしまう。
かわりに今日はちょっと真面目に news68k しようかな。

昨日の推定を確認する方法を考える。
まず kernel 自身について。
うーん、と考えて MMU を on したあとに off してみて LED をつけてみる。
make して起動。…お、ちゃんとつくじゃん。

なので、kernel 自身については PA == VA でよくて、 I/O 空間の map が変ということらしい。
もう一度 pmap_bootstrap.c を眺めてみる。

以前にも調べているが、今度は物理メモリマップを書いてみる。

00000000 !--------------! firstpa
         ! kernel text  !
         !--------------! etext
         !   "    data  !
         !--------------! edata
         !   "    bss   !
         !--------------! kstpa
         !  kernel      !
         !  seg. table  !
         !--------------! kptpa
         !  kernel      !
         ! page table   !
         ! (sysptpage)  !
         !  ----------  ! iiopa
         ! (IO space)   !
         !--------------! kptmpa
         !    ptmap     !
         !--------------! lkptpa
         !   last kpt   !
         !--------------! p0upa
         ! proc0 u-area !
         !              !
         !--------------! avail_start
         !              !
         !              !
                :
         !              !
         !              !
         !--------------! avail_end
         !    msgbuf    !
0xxfc000 !--------------! maxmem
         !  PROM work   !
0xxfffff !--------------!

こんな感じか。

I/O がどこに map されているか引き続き読んで調べる。
ste には上記のように用意された pte を前から順に登録しているだけ。
ってことは VA 空間は最初の方しか map されてないってこと。
なので 0xe0000000 以降から始まる I/O 空間は PA != VA ですな。これじゃ LED 点かなくて当然。
I/O 空間は VA の intiobase から map されることになるようだ。

今は適当に 0xe0c00000〜0xe1d00000 までを I/O 空間としてマップしている。
LED 制御は 0xe0dc0000 なので (intiobase + 0x001c0000) を叩けば LED が点灯する。はず。
試してみる。 m68k の assembler にてこずるがなんとか書く。
make して起動。おりゃ。
…ついた。動いてるじゃん。いいぞ。
何回か試す。ちゃんと main() に飛ぶとこまで進んでるようだぞ。

ここで I/O 空間の map について改めて考える。
news68k/dev 以下のドライバは VA == PA 前提のアドレス指定がしてある。config の記述もそう。
理由は単に NEWS-OS や newsmips の真似をしただけ。
まあ、これは news68k/include/cpu.h の IIOV() マクロでごまかせば何とかなる。
しかし、よく考えると I/O 空間を 256Mbyte も map してることになる。
これだと pte だけで 256kbyte 食っていることになる。
それくらい屁でもないのかもしれないが、すき間だらけなのにもったいない。
NEWS-OS のように tt0, tt1 レジスタを使うべきなのだろうか。
使い方よく知らないけど。

最終的にどうするかは置いといて、調子に乗って IIOV() 使うように書き換えて main() に飛んだ後どうなるか試す。
起動。ほいっと。
…やはりなにも出ないか。まあそんなに甘くないわな。
ん? なぜかオレンジの LED が点灯してるぞ?
調べてみると locore.s の doboot() に書いておいた LED のコードが実行されてるようだ。
doboot() を呼ぶのは machdep.c の cpu_reboot() だけ。
もしかして生意気にもどこかで panic() してるのか? ほんとか?

半信半疑ながら panic() しそうなところと consinit() まわりをチェックする。
と、 consinit() での DIP_SWITCH のアドレス指定に IIOV() 足すの忘れている。

直して起動。そりゃ。

NEWS> bo /3
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd()/netbsd
557264+26004+110524 start at 0x00001000 (magic 0407)
Copyright (c) 1996, 1997, 1998, 1999
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.4 (LIBERO) #81: Thu Jun  3 20:15:47 JST 1999
    tsutsui@mirage:/usr/src/news68k/sys/arch/news68k/compile/LIBERO
uvm_fault(0x8e93c, 0xe1c00000, 0, 0x1) -> 0x1
  type 8, code [mmu,,ssw]: 4010755
trap type 8, code = 0x4010755, v = 0xe1c00000
kernel program counter = 0x7b6ec
pid = 0, pc = 0007B6EC, ps = 2004, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: 00002704 00000052 00000000 00000000 00000000 00000000 00002000 00000000
areg: E1C00000 0009CCD0 FFEFFFFC 000A5A98 000AA000 00000000 000B7F34 FFEFFFFC

Kernel stack (000B7E40):
0B7E40: 0007F47E 000B7E8C 00000080 00000000 00000000 00000000 00000000 00002000
0B7E60: 00000000 FFEFFFFC 000A5A98 000AA000 00000000 00000000 000B7F34 000012F2
0B7E80: 00000008 04010755 E1C00000 00002704 00000052 00000000 00000000 00000000
0B7EA0: 00000000 00002000 00000000 E1C00000 0009CCD0 FFEFFFFC 000A5A98 000AA000
0B7EC0: 00000000 000B7F34 FFEFFFFC 00000000 20040007 B6ECB008 1EEE0755 0200000F
0B7EE0: E1C00000 E1C00000 000AA000 10101010 0007B6F2 0007B6F0 0007B6EE 0009CCFF
0B7F00: 0200FF0D 000FF487 00000000 00000400 E1C00000 FFFFE1C0 20200000 000B7F3C
0B7F20: 00000000 0000007C 000B7F48 000AA000 00000000 000B7F44 0007AEF6 0009CCD0
0B7F40: 000AA000 000B7F78 0007AA18 0008E5D2 000AA000 00000000 00000000 00000000
0B7F60: 00000000 00000000 FFEFFFFC 000A5A98 FFFFF000 000ED000 000B7FAC 00003BBE
0B7F80: 00003B08 00089850 000AA000 00000000 00000000 FFEFFFFC 00000000 000AA000
0B7FA0: 00000000 00000000 00000000 00000000 00000000 000AA000 00000000 00000001
0B7FC0: 00000001 00012214 000BB000 00000000 00001000 FFEFFFFC 00000000 000B7FF4
0B7FE0: 0007A8C6 000BB000 00001000 000AA000 00000000 00000000 00000000 00000000
0B8000: 
panic: MMU fault
System halted.  Hit any key to reboot.

rebooting...

おおおおおおおお〜〜〜〜〜〜〜〜っ! printf() 動いた! 信じられん。
printf() 動くまで 3か月というのが当初の目標だったけど… 1か月かからずに動いてしまった。
感動。しかもまだ kernel #81 だし。

うーん、なんだか今日はもう十分満足してしまったぞ。
仕事さぼった甲斐があったってもんだ。うんうん。

19990602

19990602 って書いてるけど部屋に帰ってきたのは日付の変わった午前 2時半。なんとかしてくれぃ。
さすがにいじってる元気はないので某氏からの mail のフォローだけ。

MMU on 後に反応ないというのは、

kernel 自身の map がうまくいってない
LED 制御ポートの map ができてないから点灯させられない
そもそも monitor 領域は map してなかったので monitor に落ちるはずがない
そのほか

ということですな。現状がどうなのかちゃんと確認する手段を考えないといけない。

なのでひとまず MMU を on する直前のメモリ内容の確認を先にしようと思うんですけど…
NEWS-OS の machdep.o からすると reboot() も halt() も最終的には同じ trap15 を呼んでるので、 d7 かどっかのレジスタの引数で halt になるはず…
あと NEWS-OS で kernel 自身は locore.s で map されてるけど、それ以外を map しているところを探すと。
ふあぁ。この分だと明日も無理そうだから今週末こそまとめて作業だな。

19990601

最近本業が雪ダルマ式にあわただしくなっていっている。
ほんとはこんなもの書いてる場合ではないのかもしれないが、 nice 値を下げないためにも何か書いておく。

MMU を on した瞬間に死んでしまう原因を考えてみる。

pmap_bootstrap() で使う値を設定し間違えている。
hp300 と mvme68k の不整合に気がついていない。
実は VA != PA である。
news68k の内部構造が変。
その他もろもろ。

mvme68k では physmem を pmap_bootstrap() 中で用意しているという違いがあったが、locore.s で用意しても変わらず。
ほかにはそんなにまずいところはないように見えるが…

VA == PA の場合は mvme68k/locore.s のコメントにあるように単に MMU on するだけ。(なのか?)
VA != PA の場合は hp300/locore.s のようにいろいろ細工しなきゃいけない。具体的には VA == PA になるページを用意してそこに MMU on のコードを書いて実行し元に戻っている。
x68k も VA == PA のようだ。 amiga や atari はよくわからん…

NEWS-OS のコードを見ると PA は 0 から始まっているように書いてあるように見えるが…
そもそも NetBSD では MMU の srp, crp 両方使ってるが NEWS-OS では crp のみでほかに tt0, tt1 も使っていてちょっと違う。

LED デバッグだけではなんともなりそうにないので、せめて monitor に落とせないか試してみる。
NEWS-OS からそれっぽいコードを見つけて書いてみる。
起動。えい。おっ…っとそれっぽい動きをしたかと思ったが monitor に落ちずに NEWS-OS の vmunix が再起動してしまった。
こりゃ 0番地に飛んでるだけみたいだな。敗北。
思いつきで対処してもダメか。時間作ってちゃんとソース眺めてみないと…

19990531

午前中の打合せの熱弁で体力を使い果たしてしまい、とっとと定時に帰る。
まあ、土曜日の苦労はおおむね報われたので OK。

問題の Win Game は会社の先輩に貸し出してしまったので今日はさっさと news68k にとりかかる。
まずは binutils を作り直す。
複数の objcopy を使い分けるようなことをしなくても、 configure で "--enable-targets='m68k-netbsd m68k-sony-newsos4'" のように複数指定すればいいはず。
make してテスト。動作 OK。よしよし。
Makefile.news68k も objcopy 呼び出すように書き換える。

んで次は locore.s で 0番地付近を使わないようにしてみる。
hp300 のように text の先頭に ".fill NPBG/4,4,0" を追加。
make して ftp して boot。お、ちゃんと(?)ハングアップする。いいぞ。

適当な場所で LED を光らせてみる。
素直に点灯してくれる ;-) とりあえず BSS clear は通過してるようだ。
いろいろ試す。 pmap_bootstrap() も通過している。
どうも MMU を enable したところでさよならしてる感じ。ま、そんなもんだろ。
さて、これから先はどうやって debug したもんか。

しかしコンパイルしてると nfs server の arm32 死にまくり。今日はひどいな。
死ぬのはいいけど reboot のたんびに fsck でやたら待たされるのがかなわん。
ex on arm32 を直すのが先か? de と ex 入れ換え計画か? それとも fxp 新規導入か?

19990530

起きたら昼過ぎてた。すでに今週ももう休みが終わってしまう〜って感じ。
やっぱ土曜日仕事しちゃダメね。

作業用 i386 マシンの電源を入れるが、なぜか Win Game 始めてしまったり。
…クリア。うーん、しょうがない、 news68k やるか。今度は NetBSD 起動。
昨晩の続きで machdep.c をひらく。が、やはりいまいちガッツが出ない。ぷぅ。

このままでは先に進まないので方針変更。とにかく kernel をリンクしてみることにする。
news68k/compile 以下に移って i386 上で cross make を走らせる。
……。例によってぼこぼこ error が出る。が、だいたいはしょーもない typo とか定義忘れの類なので、ちょいちょい直しながらひたすら make。
頭を使わずひたすら修正。 -Wall はつけてるけど -Werror はつけてないので結構危ない warning 見落としてるかも。

で、わりと本質的な修正なしにリンクまで進んだ。本当にいいのか?
と心配するまでもなく Undefined symbol がこれでもか、と言わんばかりに出る。
ま、書いてない関数もあるんだからこれはこれで当たり前。逆に思ったよりは少ないかな?

まず locore.s まわりから修正。 locore.s で使うマクロは assym.h に入れないといけないのね。
ということで genassym.cf を修正。ちょこちょこ。
そのほかに入れ忘れてた変数追加とか余計な値削除とか。

次に怒られてるのは TBIS() とか DCIS() とかの TLB/cache 周りの命令。どこに入ってるんだ?
いろいろ調べて hp300 では locore.s に入ってるけど mvme68k では m68k/m68k/cacheops.c のを使ってるのが判明。
いろいろかき集めてくっつけてたのが悪いのね。
というわけで files.news68k 直したり #include <m68k/cacheops.h> 追加してまわったり。

次は uvm_map.o で pmap_prefer() がないだと。
えーと、確かに mvme68k にはないけど hp300 にはあるなあ。…ん? #ifdef M68K_MMU_HP の中じゃん。
ざっとしらべて include/pmap.h の PMAP_PREFER() の定義を削除して解決。

次。 cninit.o で constab がないとか言ってる。
うーん、と hp300 やら newsmips やら見て、 news68k では constab[] 使わないことにしたので cninit.c はいらないという結論。 files.news68k から削る。

だいたいこんなもんか? あとは実際にまだ書いてない関数だけかな。 ipl 3,4,5 のハンドラとか。
というわけで machdep.c やらにダミーのエントリ追加。

んで再び make。…うーんできてしまった。
NWS-1750 起動して、 ftp で /netbsd として置いて、 monitor に落としていよいよ起動。どきどき。えい。
```
NEWS> bo /3
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd()/netbsd
Bad exec file format.
```
なに〜! これでは動く動かない以前の問題ではないか。なにが不満だ、おい。

file(1) を使って file 形式をもう一度確認してみる。
今回 make した kernel は当然 "NetBSD/m68k object file not stripped" と出る。
NEWS-OS の vmunix は "old SGI 68020 pure executable" と出てくる。
でも NetBSD/m68k の objdump で解釈できるんだから a.out には間違いないよなあ。 magic の問題だけか?

とりあえず m68k クロスの objcopy に入っている "a.out-sunos-big" とかに変換してみる。
ftp して halt して…。やっぱりダメ。
そもそも NEWS-OS の file(1) が "data" と表示するようでは無理だわな。

うーん、どうしたもんか。 NEWS-OS 上で make しないといけないのか?
この遅いマシンでそんな気の長いことやってらんねーぞ。だいたい egcs もうまく作れんのに。
リンクだけ NEWS-OS 上でするとかか? それも無理だよな。

と、 binutils が NEWS-OS の形式をサポートしてれば問題ないんじゃないか、ということで試す。
binutils-2.9.1 を展開してたディレクトリで "configure --target=m68k-sony-newsos4" してみる。
……。 gas はダメと怒られたがそれ以外はいけそう。んで make。
できた。 objdump 走らせてみると a.out-newsos3 というのがある。これでいけるか。

"objcopy -O a.out-newsos3 netbsd /tmp/netbsd" として変換。
再び NEWS-OS 起動して ftp して halt して起動。今度はどーだ。えい。

お、ちゃんと読み込んでるじゃん。よっしゃ。

NEWS> bo /3
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd()/netbsd
595248+27552+116228 start at 0x00000000 (magic 0407)
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd(0,0,0)/vmunix
943812+242952+307752 start at 0x000019e8 (magic 0410)
[以下略]

およ? 起動しないのは当然(?)として、なぜかその後でデフォルトの NEWS-OS の vmunix が勝手に起動してしまった。何が起こってるんだ?
RAM に前回の残骸が残ってるのかと思って電源を切ってやり直すが変わらず。
うーむ。 0番地からスタートってのがダメなのか?
NEWS-OS の vmunix は最初の 0x0 から 0xf00 までは 00 で埋められている。
最初のほうは boot loader 用作業領域なのか?
それとも NEWS-OS と同じく KERNBASE を 80000000 にしとかないといけないのか?

ま、なんにせよ、道は果てしなく遠いということか。今日はここまで。

19990529

今日の出勤は自分で決めたことなので朝から出たりはしない。
というわけで今日も中途半端に時間がある。

うーん、今度はなにしよう、ということでおもむろに adv の初期化が arm32 でうまくいかない件をまた調べ始める。
試行錯誤するのは今までさんざんやったので今日は FreeBSD のソースを調べることにする。
ftp かけて advansys.c とか advlib.c とか取ってくる。
しかしあいかわらず FreeBSD のソースディレクトリ構成はよくわからん。

FreeBSD の adv は CAM 化されたものしかないのでどうかなと思ったが、元は同じ Linux のがベースのようだ。
しかし FreeBSD 版は Justin Gibbs 氏が直々に書いてるだけあって NetBSD のよりよっぽどきれいだったりして…
NetBSD の adv って wrapper かましただけというか、関数名とか構成とかは実はかなり Linux なまま。
初期のコードは構造体の中身をデバイスに出力するのに構造体のアドレスを (u_int16_t *) でアクセスして、 padding の部分は if 文でカウンタの値見て飛ばすというヒドイことをしていた。
さすがにこれは big endian 対応でなんともならんので直してもらったが。

というわけで読みやすい FreeBSD のコードを黙々と調べる。
見た目は違うようでも元が同じなだけに初期化手順はそんなに違わない。
でも構造というか機能の階層化はちゃんと書き直されている感じ。
関数名とかはやっぱり _ で区切るのが正当だよなあ。
大文字小文字入り交じった関数名はやっぱりイヤ。

ずっと見ていくと FreeBSD 版では adv_init() の先頭で reset_chip_and_scsi_bus() を呼んでいる。
NetBSD 版だと AscInitFromEEP() の中で呼んでるけど、なんか呼んでる順番が違う。
というわけで AscInitFromEEP() の先頭でも AscResetChipAndScsiBus() を呼ぶようにしてみる。
コンパイルして再起動。お、ちゃんと起動するじゃん。
再度 reboot。うん、問題なさそうだな。というわけでひとまず会社行くか。

…ちょっと気合い入れ過ぎてしまい帰宅したら 23時。いかんな。
というわけでもう一度 adv の動作を確認。うん、よさそうだな。
サクッと patch つくって adv の作者の Dante さんにメール。
Dante さんとは adv の big endian 対応でさんざんやりとりしたので send-pr より早いはず。
さてどんな返事が来るかな。

これでは今日も news68k への道にならん、ということで machdep.c をひらく。
が、もはや身体が電池切れで consinit() いじったところでもう頭が動かなくなる。ぷー。
今日は nfs server が hang しても reset を 2回しなきゃいけない憂鬱から解放されたということで… おやすみなさい。

19990528

週末は気合い入れよう、と言ってたそばから明日も土曜出勤決定。うほ。
日曜に頑張ればなんとかなる…のか? まあぼちぼち進めよう。

とりあえず簡単な vector.s を直す。
ちょいちょいと飛び先書いておしまい。

次は locore.s。 hp300 とか sun3 とか見ながら handler 追加。こんな感じでいいのかしら。
そして EIO スペース記述用の変数を追加して代入。
以前機種判別を machdep.c に入れたけど、 I/O address は機種毎に違うから、本来なら判別は mvme68k みたいに locore.s ですべきなんだよなあ。めんどくさ。
というわけでとりあえず今は news1700 に決めうち。

同じく pmap_bootstrap.c にも EIO 処理追加。 hp300 のを見ながら直す。
ん? 最後のページがどうこうってのと page 0 がどうこうってのは mvme68k では削除されてるのか?
x68k と比べるとまた微妙に違うな。まあいいや。 news68k でも削っとこ。(超テキトー)

isr.c にも isr_add_custom() 追加。 sun3/sun3/isr.c から copy して変数名だけちょっと調整。
"XXX - could just kill these..." とか書いてあるけど、実はこれあまりよろしくないのか?
machdep.c はちょっと大変だから明日帰ってきてからだな。

ひと段落したところで、久しぶりに NWS-1750 の電源を入れてみる。
と、コンソールに何も表示されない。おいおいまたかよ。
うー、もっかいふた開けないといかんのか、と悩んでたら、単に RS232C のクロスコネクタが抜けてただけでした。ダメだなこりゃ。

19990527

binutils-2.9.1 をちゃんと作ってみる。
pkgsrc の patch をちゃんと眺める。LIBTOOL のとこだけ直す。
結局 patch-a[degh] をあてなければよいようだ。
./configure --target=m68k--netbsd ; make で今度は完成。
実行。ちゃんと動く。これで sun3 はまたまた失業。 :-p

sun3/sun3x/clock.c を見ながら news68k/dev/clock_hb.c と news68k/news68k/clock.c を修正する。
ベースにした mvme68k の pcc のタイマ設定周りはざっくり削除。
sun3 も実はタイマ割り込みは ON/OFF だけで周期の設定等はないような感じ。
clock の割り込みハンドラで割り込み制御レジスタを OFF/ON してるのも同じ。
ありがちな実装なのか? 単なる真似っこ? とにかく同じように書いておく。
statintr 関係についてもざっくり削除。
sun3 でも leds_intr() とかがある。将来は LED の制御ってしたほうがいいのかな。

これで一応 news68k/dev 以下は終わったつもり。
あくまでもつもりであって全然確認してないけど。あとは compile してから。
これで次は news68k/news68k 以下をもう一度確認したらあとは make するばっか、のはず…

直さないといけないところを思い出してみる。

locore.s の割り込みハンドラ
vector.s のテーブル
locore.s, pmap_bootstrap.c での EIO のマップ
isr.c に isr_add_custom() 追加
machdep.c の consinit() まわり
machdep.c に ipl 3,4 の割り込み dispatcher 記述
machdep.c の nmintr() まわり(前回わけわかんなくなってるので)
各種 prototype 宣言

くらいか? まだまだあったような気がするけど…

そういえば、 thorpej氏が tech-kern で次のようなことを書いていた。
On the hp300, physical RAM is always located at the end of the physical address space. In the hp300 pmap_bootstrap(), the PTEs are frobbed manually to map the last page of RAM VA == PA. This is used to provide a trampoline page that code can execute from when both the MMU is enabled and disabled :-)
hp300 の RAM ってケツから下へ伸びていくのか?
やっぱり locore.s とか pmap_bootstrap.c の pa == va の処理は余計なのかしら。
x68k とか mvme68k でも該当コードは残ってるけど。

なんにせよ、今週末は気合い入れて頑張ってみよう。どう頑張っても敗北の予感はするが…

19990526

m68k の objdump を使うために sun3 を起動。 clock.o を改めてチェック。
startrtclock() はほとんど 1行だけ。 "*(char *)CTRL_TIMER = 1;" みたいな感じ。
他は RTC まわりの関数だけ。そういうものなのか。

しかし sun3 をいちいち起動するのもめんどくさいので i386 で m68k cross の objdump を作り直してみる。
binutils-2.9.1 を展開して configure して make。
あえなく Error。直すのもめんどくさいので次は手で pkgsrc のパッチを当てて作ってみる。
今度は $(LIBTOOLS) がちゃんと定義されなくてダメ。うぐ。
素直に pkgsrc の下で m68k--netbsd をデッチ上げて make。
問題の ld と as はいらないからいけるはず…と思ったら NFS server の arm32 が hang してしまう。うがー。

CATS に 3C905B 使ってると、大量にパケットを受信すると固まるんだよなあ。
送信側の MTU が大きいとダメなのか? せめて panic() してくれんとなにもわからん。
i386 では問題になってないのか? arm32 の ex と i386 の de 入れ換えようかな…

上記の ex on arm32 以外にもやることリストはたくさんあるが news68k 優先でやってるので止まったまま。
リストの中身見直すとほかにこんなこと書いてある。

thorpej からもらった RTL8139 ドライバの test & debug (結構大変そう)
adv driver を arm32 で使うと reboot 後の初期化に失敗する対策 (sync まわりっぽい)
macppc で vr driver 使うと MTU 小さくしないと "transmit aborted" と怒られる原因調査 (i386 でも変?)
macppc の on-board "valkyrie" video サポート (ofb.c 分割が必要?)
macppc floppy driver (linuxppc 参照)
ncr driver bi-endian 化 (OpenBSD 参照)
COMPAT_NEWSOS の可能性検討 (Lite2 参照)
newsmips native boot loader (news68k もだけど)
newsmips wscons 検討 (よくわかってないので調査要)

うーん。優先度高くないのもあるけど、なんか多いな。誰かやりません?

19990525

今日も全然 news68k やってる暇なかったけど、ここに書くためだけに source をちょっとだけ眺める。
MK48T02 について見てみる。で、 sun3/sun3x/mk48t02.h とか見てて重要なことに気づく。
同じファイルの中にあるけど実は clock と timer って全然別のデバイスじゃねーか。だー。
よく考えたら当たり前。i386 でもそうだし mvme68k のコードもこれなら納得。なんてお馬鹿な私。
でもなんで別の source になってないんだよ〜。うーんだまされた。

しかし MK48T02 が NVRAM と RTC しか持ってないとなると news68k の timer 割り込みってどうなってるんだ?
adrsmap.h には CTRL_TIMER ってアドレスしかないけど、 ON/OFF 制御だけなのか?
newsmips だと一応割り込み周期の設定ができるみたいだけど、それすらないのか? 謎。
NEWS-OS のバイナリを見てみる。 clock.o に startrtclock() ってのがあるけど、 CTRL_TIMER の 0xe1000000 しかそれっぽいのはない。
NEWS-OS の clock.h も見てみるが timer については何もない。うーむ。

全然関係ないけど、 LEAPYEAR(year) のマクロが (((year) % 4) == 0) になってるのは 2100年問題だよなと思ってたのだが…
NEWS-OS の clock.h には "good till time becomes negative" なんて書いてある。そうかも。

19990524

今日は月曜日。でも休みなしだったので逆にあんまりいつもより憂鬱にならなかったりして…
しかしやっぱりやる気は出てこない。あぁしんど。

というわけで今日はとっとと切り上げて帰る。
が、あいかわらず書き始める元気は出なくて Win ゲームやってしまったり。

区切りがついたところでようやく if_le.c を開く。しかしすでに時は 23時をまわってたりして…
といっても、 if_le.c はほとんど newsmips そのままで OK。 confargs 直すだけ。のはず…
ほんとはアドレスその他を config からの値を使わず unit 番号で決めうちしてたりするのを直したいけど。
今はそーゆー細かい話は置いといて実際に動き始めてから気にすることにする。

お次は clock_hb.c。これがまたいろいろわかんないんだけど…。
とりあえずベースは mvme68k の clock_pcc.c。
どうも news68k では nvram の部分は使ってないらしい。
それはいいんだけど、 newsmips と全然違うのはそういうものなのか…。
clock_pcc.c では 2種類のタイマを設定して clock_pcc_profintr() と clock_pcc_statintr() の 2つのハンドラを設定している。
割り込みは vectored なのでそれぞれ個別に pccintr_establish() している。
この 2つの使い分けがよくわかってなかったりするのだが…。
それ以前に mvme68k/dev/clock_pcc.c ではアドレス指定に struct pcc を使ってるので、これを news68k 用に別の表記に直さないと…。

もう一度 sun3/sun3x/clock.c と比べてみる。
と、 "This doesn't need to do anything, as we have only one timer and profhz==stathz==hz." とのコメント。そうか、 arm32 の起動時にもそんな表示があったなあ。
というわけで、別にタイマを 2種類用意する必要はないのかな。
さらに isr_add_custom() なんて関数発見。 news68k でもこれを用意してやった方がスマートか?
sun3 のはいまいち quirk な書き方が多くてよくわからないが…
いろいろ探して sun3/sun3/isr.c を見てみる。うーむ、 mvme68k/mvme68k/isr.c と似て非なる記述。どうしたもんか。
こういう細かい話は眠い時には考えらんないので今日はやめ。やっぱり休日に一気に作業したかったなあ。

19990523

今日は朝からコーディング、と思ったけど起きたら 10時過ぎ。昼から出社と思うと始めるガッツなし。
中途半端に時間があるので、以前から出そうと思いつつさぼってた send-pr を出すことにする。
内容は、 src/distrib の特定の場所で make obj してから make すると怒られるというもの。
修正は単に list 中のカレントディレクトリのファイルの path に ${CURDIR} を追加するだけ。
1.4R の src.tgz から distrib 以下を展開して、ざっと眺めてちょいちょいと patch 作成。
んで、いつものようにテキトーな作文して送信。 misc/7628 だそうだ。

そろそろ出かけよう、と思ったら財布の中身が 300円を切っている。う。
銀行まで足を伸ばして昼飯食って出社。 30分で済ませてとっとと帰ろう。
… と目論んでいたがあえなく敗北。そのかわり(?)、なぜか SPARCstation1+ を入手。

そんなこんなで結局部屋に戻ったのは 16時近く。
と、 mail をチェックするとさっき出した PR が速攻で close されてた。
うーむ、こんなことなら 1.4R 出る前に出しとくべきだったか。

もう休みが終わってしまう〜、とか思うとますます元気なし。
というわけで(?)、もらってきた SS1+ で遊ぶことにする。
まず中身をチェック。メモリは 1M×16, HDD は例の Quantum 105S, video は full size CG6 がついてた。
シリアルコンソールをつないで動かしてみる。やはり例の 105S のヘッド固着で起動しなくなって捨てられたようだ。

一応動作確認はできたので、現在使用中の SS1 と入れ換えることにする。
といっても、 25%高速化(当社比)するだけだけど。 ;-p
ついでに FDD も奪って Sun3/80 につけかえちゃえ。
Pizza Box 3台を畳の上にふたを開けて並べて移植手術開始。
HDD と SIMM を SS1 から SS1+ に、 FDD を SS1 から 3/80 に。
ついでに HDD マウンタも交換。さらに余ってた 4M SIMM×4 も取り付ける。
これで sparc もメモリ 40Mbyte。ほんとは 3/80 で 4M SIMM を使うのがベストだけど、うちの 3/80 の revision では使えないんだよねえ。

すべて終わって起動。 SS1+ も 3/80 の FDD も問題なし。
というわけで SS1 はお蔵入り。 memory 16M, CG6 video, keyboard/mouse/HDD/FDD 無、というのでよければ欲しい方に差し上げます。

このままではいつまで経っても news68k への道にならないので、仕方なく zs.c を書き始める。
以前 x68k 版をベースにしようと決めたけど、細かいところが結構違う。
各種定義を x68k/include/z8530var.h でしてたり、シリアルコンソール時の初期化を自前でやってたりする。
ちょっと考えた末、やっぱり newsmips 版ベースで割り込みまわりだけ x68k から持ってくることにする。
ところで、 zsc が 2つ以上ある時も割り込みハンドラはすべて zshard() で同じなのだろうか?
同じでもいいけど、それだとなんか vectored interrupt 使ってる意味があんまりない感じ。
まあいいや。どうせ 2つ目をつなぐことなんてまずないし。

黙々と書く。すでに半分忘れてるので hb.c とか見直しながら進める。うー、 confargs が…。
zsaddr[] を zs_match() の中で代入してるけど zs_attach() で設定すべきなような…。
attach 中に splhigh() とか splzs() とかしてるけど、これって必要なのかしら。
adrsmap.h にある SCC_STATUS0 のアドレスってなんなのかしら。
newsmips は使ってない。 Lite2 の news3400/dev/scc.c とか見ればわかるのか?
setsoftserial() の仕様ってどんななんだ? mvme68k だけ引数が違ってたりするし、また調べないと…。

一応できた(つもり)。でも zscn{get,put}c() で SCCPORT0A とか使ってるのはイマイチだなあ。
NEWS は port A しかシリアルコンソールに使えないようだから、決めうちなのはそんなに問題ないんだけど…。
でも、少なくとも本来なら adrsmap.h をちゃんと分割してしかるべきところで必要な分だけ定義すべき。
x68k みたいに最初から配列に入れとくのがいいのか?
まあいいや。あとは困ってから考えよう。

明日は if_le.c かな。時間があればだけど。

19990522

定時に出社したのに帰宅したらなぜか 22時。さらに明日も顔を出さないといけないようだ。
うーむ。別に仕事自体はわりと楽しいからいいけど、なんなんだこれは。
というわけで今日も Jolitz 本(日本語版)読んだだけ。英語版もあるんだけど、ほとんど開いたことなかったりして。

しかし本文よりも脚注のほうが面白かったりしてそっちばかり見てしまう。
たとえばこんな感じ。順不同。

「ISA スロットにマイナスドライバを挿入して NMI を一時的にグラウンドにショートさせるという非常に野蛮な手段があるが、これは大変デリケートな操作であり、コネクタのピンを慎重に数えてから行なうべきである」
「現在では両者(注:IBM と Apple)ともに、 PCMCIA や PCI のような、より現代的で優秀かつ構成可能な公開アーキテクチャを採用しているという事実を考えると、まだ彼らにも学ぶことがあるのかもしれない」
「Windows95では…(中略)…その内部のアプローチは不正確で、しばしば失敗したりイライラさせられたするが、あそこの連中のほかには、この問題を誰も深刻に受け止めていないという点は、指摘しておかなければならない。」

PDP-11/VAX 依存についてはこんな感じ。

「Solaris のような現代的システムを除いて、 BSD をはじめ他のすべての UNIX システムは、いまだに上述したような PDP-11 式の古いアプローチに頼っている」
「… 古い PDP-11 を(あまり上手にではないが)模倣しているのである」
「… これだけテクノロジーが変わっても、 PDP-11 の亡霊がいまだに残っていることを指摘しておく」
「このフォールトの名前は VAX/PDP-11 の ast (asynchronous trap)に由来する」
「これは PDP-11 には整数除算命令がなく、例外には浮動小数点のシグナルが使われていたからである」
「昔からの慣習が、しぶとく生き残っているのだ」

うーん、 AST ってそういうことだったのね。ちなみに AST の説明は 120ページで、最初に出てくる 97ページと前後してます。
NetBSD でも m68k 系の locore.s にある rei には "Emulation of VAX REI instruction" って書いてあったりするんだよなあ。

なんてこと読んでると結局 news68k 進展せず。うーん意味なし。道は遠い。
明日は Lions' book でも読んで PDP-11 勉強するか。

19990521

今日も本業の方がドタバタ。なんとかして。
週末になったらあきらめてガシガシ書こうと思っていたのに、結局明日も出勤が決定。まあいいけど。

気がつくと current はすでに 1.4C になってたりする。
うかうかしてると、もし仮に動くようになったとしても某 arc のようにいつまでたっても merge できん、ということになってしまう。
と、自分は棚に上がってさりげなく別方面にプレッシャーかけてみたりして。

今まであれだけ書いときながらなんにもしない日があるのもアレなので softclock について調べてみる。
まず軟弱に黒悪魔本(日本語版)の 52ページ「ソフトウェア割り込み」を読む。
「作業要求の列を作った後、高優先度の割り込みは、低優先度で実行される関数の要求を発する」だって。
さすが評判通り、やっぱりわけわからん。いや、わからんこともないんだけど。

しかたがないので赤悪魔本(英語版)を読む。 Software Interrupt は 56ページ。
やっぱりこっちのほうが読みやすかったりして。
On some architectures, the interrupts are true hardware traps caused by software instructions.
Other architectures implement the same functionality by monitoring flags set by the interrupt handler at appropriate times and calling the request-processing functions directly.
ってあたりの説明はあるけど、具体的な実装はやっぱりソース追うしかないのか。

Jolitz 本(日本語版)も見てみる。 99ページあたり。
えーと、 AST についても書いてあるけどよくわからんな。結局 signal 処理のことなのか?
うーん。ちゃんと腰を据えて読まないといけないけど、今日は眠いのでやめ。にしても m68k 版が欲しい。

しかし Jolitz 本を見ていると、「BSD (の Low level 部分) は PDP-11 や VAX に依存している」と言わんばかりの記述があったりする。
レベルは違うにしても「Linux は i386 の構造に依存している」と手放しでは笑えないかも。

19990520

今日も特に進展なし。というより今までが気合い入れ過ぎ。
hp300 の IIOMAPSIZE, EIOMAPSIZE だけ確認しておく。
cpu.h, vmparam.h に書いてある。
EIOMAPSIZE は 14Mbyte とかになってる。がばっと取っても問題なさそう。
でも EIO のコードは pmap_bootstrap.c から取っちゃったんだよなぁ。気が向いたら直すか。

sun3x のコードもちらっと眺める。
sun3x も autovectored, vectored 混在らしい。
softclock がどうなってるかよくわからんが… jolitz 本やら悪魔本とかちゃんと調べるか。

19990519

ひさびさに本業が忙しく、今日はまったく進展なし。
でもせっかくなのでなにか書いておく。別に日記にするつもりはないけれど…

某氏からは「割り込みハンドラが呼ばれるのは spl0() が実行されたあとで、 spl0() が実行されるのは configure() のあとだから、割り込み書いてなくても mountroot() までは進むよ」と言われている。
でも、ここはちゃんと全部を用意してからチャレンジすることにする。
別に完璧を目指してるわけでもなんでもなくて、どうせ最初はまともに動かないことがわかりきっているから。
実際動かないのをまのあたりにするときっとやる気をなくしてしまうだろうし。
デバッグとコーディングを同時進行できるほどの元気は多分出ない。
そもそも中途半端に書いたところで、 kernel をまともに link させるのはかなりめんどくさいだろう。
…となんだかんだ言ってただ書くのをめんどくさがってるだけかもしれないが…

少しは kernel のことも書いておく。
あとちゃんとわかっていないのは softclock の処理と I/O 空間の範囲。
clock の割り込みには soft, hard の 2種類があるようだが、実装をちゃんと確認してない。
mvme68k ではそれぞれ別の vector を設定してるようだが、 autovectored のときどうなるのかちゃんと見ないと。
MK48T0x を使ってる arch のソースを調べないといけない。 sun3 とか見ればわかるか?

I/O 空間については、要はどこからどこまでを map するか、という話。
PROM は 0xe0000000 あたりから。この次に出てくるのは FDC_DMA の 0xe0c80100。
これから le の 0xe0f00000 まで続く。
0xe1000000 から 0xe1f0000000 までは制御用レジスタやら IDPROM やらが続く。
最後に 0xf0000000 以降に fb や 2チャンネル目以降の zs, le つまり外部スロットの I/O が配置されている。

やっぱり hp300 みたいに IIO と EIO と両方定義して 2か所 map すべきなのか?
fb は今のところ書く気ないから 0xf0000000 以降はほっといてもいいか?
そうするにしてもやたらとすき間が多いけど、そのままがばっと map していいものなのか。
ちょっと考えただけではわからん。 hp300 のマップ見て似たような大きさだったら真似しよう。

19990518

今日もコード書く気が起こらないので考えるだけにする。
ということで、次は zs について。

zs については mvme68k のものをベースにしようと決めていたが、中身をちゃんと確認してみる。
要は MD な部分の見極めだが、実際はアドレスと vector 値の設定くらいだろう。
というわけで mvme68k/dev/zs.c を見てみる。

が、 zs_init_reg[2] の値が vector 値らしいのだが、なぜか "0x18 + ZSHARD_PRI" などというものが書かれている。
ZSHARD_PRI は 4、つまり ipl の値。 0x18 ってのは level0 autovectored の vector なので、これは ipl 4 の autovector である。なんでこんな値が?
ほかで上書きされているのかと思って調べてみるがそうでもないようだ。
mvme68k/dev/zs_pcc.c の pccintr_establish() ではちゃんとした vector 値を渡しているのに…

なにか勘違いしているのかと思い、今度は x68k/dev/zs.c を調べる。
zs_init_reg[2] の初期値は 0x70。これは config に書かれている 112 と一致する。
さらに x68k では "zs_init_reg[2] = ia->ia_intr;" と config からの値も代入している。
やっぱりこれでいいんだよなぁ。 mvme68k のって本当に動いてるのか?
と思ってさらに見ていくと、実は "Vector is programmed into the SCC by the PCC." なんてコメントが書いてあった。がく。
結局 pcc 上の zs では zs_init_reg[2] の初期値は無意味ってことか。だったら変な値書くなよ。
どうも zs の元のコードの sun3 の記述がそのまま残ってただけらしい。

と、ここでまた重要なことに気づく。
mvme68k の zs のコードは zs.c と zs_pcc.c に分かれているというのは以前書いたとおり。
probe, attach のコードは zs_pcc.c にあり、レジスタの設定等は zs.c 側の zs_config() で行なっている。これは問題ない。
が、現状の mvme68k の zs のコードでは zs_config() を zs_pcc_attach() から呼んでいるのだが、これだと config で指定された vector 値を zs_config() に渡す術がない。
そもそも zs_config() の引数の struct zsc は MD で定義されているので、 zs が分割されている意味はあんまりないような気がしてきた。
うーん。なんかめんどくさくなってきたから news68k は x68k/dev/zs.c ベースでいくか。

19990517

しんどくなってきたので、今日はコーディングをやめて考えを整理する。
まず問題の割り込み処理の方策について。どんな割り込みがどこにどう存在しているかをまとめる。

今までわかっているのは次のとおり。

ipl 1 は NEWS-OS のバイナリからすると AST (async TRAP?) の処理となっているが、よくわからないので無視。
ipl 2 はどうも softclock らしい。ハンドラは autovectored のみ。これには割り込み禁止／許可を制御するポートがある。
ipl 3 は前にも書いたとおり fd, lpt のほか外部スロット割り込み。ハンドラは autovectored のみ。
ipl 4 も以前書いたとおり le, scsi と外部スロット割り込み。ハンドラは autovectored のみ。
ipl 5 は autovectored で kb, ms があり、 vectored で zs がある。
ipl 6 は hard clock。ハンドラは autovectored のみ。
ipl 7 は parity error。ハンドラは当然 autovectored。

で、これらをどう扱うべきかなのだが…

まず vectored の zs については isrlink_vectored() を使えばよい。途中に hb_intr_establish() をかますかはひとまずおいておく。
問題はこれ以外の autovectored な割り込みだが…
いろいろ眺めて考えたが mvme68k でも isrdispatch_autovec() は結局使ってなかったりするので、

isr.c は元の mvme68k の形のまま変更しない。
isrlink_autovec() も isrdispatch_autovec() も使わずに、 machdep.c に ipl 1〜6 のそれぞれに対応する dispatcher を書く。

ということにする。これなら isr.c が MI になっても問題ないし machdep.c という名前もあっている。
VME で使える割り込みも決まっているようだし、 hb_intr_establish() を定義する必要はないかな…。

次に console の処理について。
zs と screen のように console になり得るデバイスが複数ある場合の処理がよくわかっていない。
というわけで某氏に mail で質問してみる。すると

昔は hp300/conf.c のように constab[] にずらずら書いて hp300/autoconf.c の hp300_cninit() で選ばせる、ってのが主流だった。
が、これだと細かい選択ができないので、今は MD のどこかで console の種類を決めたあと sys/dev/cons.c に定義されてる cn_tab に代入する、ってのが流行りだと思う。

との回答。なるほど。つまり newsmips/cpu_cons.c のようにやればよい、と。
ところで、現在の newsmips/cpu_cons.c では console が zs であっても fb の初期化にいってしまう。
しかしこれだとサポートしてない fb だった場合変なことになってしまうし、そもそも cn_getc() が用意されてなかったりする。
本来なら screen/kbd の類が console の場合は ROM内 routine を使うのが妥当だろう。
まあ newsmips の場合は ROM の仕様がわかってない上に Lite2 にもそのコードしかないので仕方がない。
news68k の場合は当分 zs しか使えないのでそもそも関係ないけど。
が、 cpu_cons.c ってのをわざわざ別にする必要はないかな。 machdep.c に入れてしまっていいか。

19990516

今日は news68k/dev 以下に取り掛かる。
まずは news68k/dev/hb.c から。
しかし device attach (というか autoconfiguration) の仕組みをちゃんと理解してないのでなかなか進まない。

newsmips の hb.c は autoconf.h を include している。が、これは struct confargs の定義だけ。
しかも hb.c では ca_name と ca_addr しか使ってないようだが…

各種 source を眺めて考える。 x68k/dev/intio.c や mvme68k/dev/pcc.c を見て比べてみる。
これらは intiovar.h, pccvar.h で intio_attach_args, pcc_attach_args を定義してそれを使っている。
ということで、 hbvar.h を作ってそこで hb_attach_args を定義してそっちを使うことにする。
"#define cf_addr cf_loc[HBCF_ADDR]" などの定義も書いておく。
自動生成の ioconf.c や locators.h を見て仕組みを納得。
autoconf.h は今のところ空にしておく。

ところで、 autoconf.c は newsmips から持ってきてるのだが、これは mainbus.c が別にいるようだ。
mainbus.c がない arch の場合は autoconf.c で mainbus の attach をしてる。
分けてたほうがすっきりしてる感じがするので持ってくる。 files.news68k も修正。

んで、 mvme68k/autoconf.c を見ながら news68k/mainbus.c を直す。
ここでも confargs を使ってるが、 ca_name しか使ってないようなので単に char * にする。
cpu の表示は machdep.c の identifycpu() でするのでここでは attach しない。
ん? mvme68k では attach するデバイスのリストを機種毎に切替えている。 news68k もそうすべきなのか?
たとえ可能性は 0に等しくても、万一 NWS-1800 をやることがあれば iop0 at mainbus0 は必要だろう。
となると autoconfiguration 以前に機種判別用変数を用意する必要があるのか?

てなわけで machdep.c の identifycpu() を直して global 変数を作る。
ついでに model ID と model名を対応させる配列を作る。
素人プログラマなのでこういうのがさくっと書けないんだよなあ。
で、ヤになってくるとこんな作文に走ってしまうわけですな。
NWS-1200 だと struct idrom の構成が違うらしいのだが…。とりあえず無視。

mainbus.c に戻る。ひとまず news1700 の記述だけ用意する。
そういえば NEWS-OS の news1700 の config には vme0 という記述があるのだが…
VME-bus なんて実際に付くことあるのか? 一応 #if 0 でくくって書いておく。
vme の intr_establish とかってどうなっているのだろう…。上位で mvme68k のまねしとけば大丈夫?

ようやく news68k/dev/hb.c に戻ってくる。 x68k/dev/intio.c, mvme68k/dev/pcc.c を参考に修正する。
が、それぞれなんか微妙にやりかたが違う。どれを採用すべきなのか。

newsmips/dev/hb.c や mvme68k/dev/pcc.c は mainbus と同じく attach すべきデバイスリストを持っている。
しかし x68k/dev/intio.c にはそういう定義はない。
mvme68k/dev/pcc.c はリストを順番に見てそれぞれ config_found() をかけている。
x68k/dev/intio.c はそのまま config_search() をかけている。ここまではいい。
しかし newsmips/dev/hb.c はリストのそれぞれに対して config_search() をかけてる。変じゃないか?

config_search() を調べようかと思ったが、それより newsmips で実際に修正して動かしてみることにする。
まず hbdevs[] を削って x68k/dev/intio.c のように config_search() を一回だけ呼ぶようにする。
make して reboot。… "hb0 at mainbus0" を表示したあと沈黙してしまう。
やっぱりダメなのか? と思いながら調べると hb_search() の中で ca_name を設定してなかった。
hb_search() の中に "ca->ca_name = cf->cf_driver->cd_name;" を足して再度挑戦。
無事起動。各デバイスの probe routine さえしっかりしてれば config からの情報で十分、と。
news68k/dev/hb.c も上記のようになおして一応これで attach 部分は終わり。
本来ならせっかく bus 定義してるのだから bus_space(9) とか使うようにすべきなのだろうが…。

次は問題の hb_intr_establish() を考える。
ここ 2日間で考えたとおり、 vectored/autovectored の両方に対応している mvme68k にならい news68k/news68k/isr.c を作るつもりでいるのだが…
mvme68k/dev/pcc.c は vectored しか使わないので autovectored で割り込みを assign するコードはない。
深く考えず hb_intr_establish() の vector 値の引数が -1 だったら autovectored ということにするか。

と、ここで news68k 特有の事情があることに気づく。
mvme68k/mvme68k/isr.c の isrlink_autovec() では、渡された割り込みハンドラを isr_autovec_list_t というリストに登録している。
割り込み時に呼ばれる isrdispatch_autovec() ではすべての該当割り込みハンドラをリストの順に呼び出すようになっている。
この時、より優先度の高い割り込みのハンドラを先に呼び出すために、 isrlink_autovec() における登録時に priority という software 上の優先度を示す数値を渡し、それによりリストの順序を変えているのだ。

これに対し、 news68k では interrupt status register が存在し、それにより割り込み源を特定することが可能。
つまり autovectored であるものの newsmips/newsmips_trap.c と同じように status のみを見て優先度の高い順にハンドラを呼べばよい。
というよりは、 NEWS-OS が newsmips と news68k とでソースを共有できるように実装したと見るべきか。

というわけで、どちらの方針で実装するか決めなければならないのだが…
将来 mvme68k/mvme68k/isr.[ch] が m68k/m68k 以下に移動することが前提なのならばそちらを使えるようにしないといけない。
この場合割り込みハンドラ内で status を見ることになるが、当然無駄に遅くなる。
isr.c が MD であるという考え方ならば newsmips と同じような dispatcher にすればよい。
だがしかし、そうすると autovectored の場合に hb_intr_establish() を呼ぶ意味はなくなってしまう。
vectored を使っているのは zs だけらしい…

…とわけわかんなくなったところで今日の作業はここまで。ふう。

19990515

NEWS-OS の if_lance.o を調べてみる。
それっぽい数字は 0xe0e00000, 0xe0f00000, 0xe1c00000 と 3つ。
ROM monitor で見てみる。 0xe1c00010 からが MAC address っぽい。
newsmips/dev/if_le.c と同じように各バイトの下位 4ビットずつに計 12バイト入っている感じ。
なので残りのどちらかがアドレスかな。

次は scc.o。
0xe0d40002, 0xe0d40000, 0xe0f40000 ってとこか。
newsmips の adrsmap.h からすると port A/B と status てな感じか。

しかしこんなんでいいのだろうか。
…と思ったら sys/news1700/adrsmap.h ってのは NEWS-OS の中に入ってた。がーん。
しかも cache enable とか必要なものはすべて書いてある。ショック。
しかしこれであとは書くだけか?

とにかく書き始めてみる。
まず files.news68k と config の書式。
x68k は "device* at intio? addr ? intr ?" という形式だがどうすべきか。
結局 sun3 のように "device* at hb? addr ? ipl ? vect ?" という書式にする。

そういえばデバイスのアドレスはわかったものの割り込みがわかっていない。
NEWS-OS の起動時に出る数値は結局真の値ではなかったのだ。
adrsmap.h によると、 le, scsi は ipl 4 の autovectored らしい。
locore.o から察するに clock は ipl 6 で kb, ms は ipl 5 。
肝心の zs がわからん。でも vectored ならばいくつにしたって構わないのか?
とりあえず適当に決める。いちおう config(8) は通った。よしよし。

コード修正は news68k/news68k 以下から始める。
基本的に hp300 と mvme68k のどちらかをベースに、他方を参照しながら修正という形を採る。
割り込みまわりは mvme68k で、 memory まわりは contiguous な hp300。
おたがいに quirk な部分は generic そうな方を採用。なんていい加減。
I/O スペースはどこからどこまで map すればいいのだろう。えい、とりあえずテキトー。
2次キャッシュの制御を考えた場合、HP_MMU とか M68040 のコードは残しといた方がいいのかしら。
struct idrom の構造が newsmips と違うじゃねーか。めんどくさー。
model/cpu の表示って configure() の中でやるの? cpu_startup() でやるの? arch によって違うぞ。
といった具合にいきあたりばったり方式で進めていく。

……が、プログラミングに関してはどシロートなので、コーディングはしんどくてかなわん。ひー。
だんだん自信を失いつつも news68k/news68k 以下を一通り修正。 i386 上でえいやと cross-make。
……やはり予想どおり山のように error が出る。うー、ぐったり。ボト。
うー、やー、だー、とかつぶやきながら地道にひとつ一つ潰していく。
しかし修正してるうちになんだかわけわかんなくなってきた。
考えると頭がウニになるので、まず kernel を link することだけを目標にして深く考えないことにする。

怪しい warning は出るものの、一応 news68k/news68k 以下のコンパイルは通った。
次は news68k/dev の下。しかし今度は hb_intr_establish() とか書かないといけない。
mvme68k の pcc.c は vectored だけだけど、 autovectored が混在する時ってどうなるんだろ。
…ふと newshbdev/scc.h を見ると spl5 と書いてある。
locore.o の ipl 5 のハンドラは kb, ms しか見てなさそうだから vectored でいいのかな。
vect についても "#define SCCVEC0 64" を信用していいのか?
とわかったところで今日のところは力尽きて挫折。

19990514

locore.s の _start から main に飛ぶまでは 2次キャッシュを除いてひとまず分析終わり。
でいいのかどうかは知らないが、どっちにしても考えてるだけじゃしょうがないので次に進む。

というわけでデバイスまわりに目を向ける。
まず printf() のために zs は必要。
あと最低限 clock と interrupt handling は必須。
single user まで行くには le もいるだろう。

とっかかりとして newsmips の zs.c と if_le.c を眺める。
基本的には chip の address と MAC address を格納している場所がわかればなんとかなりそうな感じ。
address はなんとか調べるとして、後は割り込みがどうなっているかなのだが…

予備知識があんまりないので引続き newsmips のコードを調べてみる。
leintr() とか zs_intr() とかは、最終的には newsmips_trap.c から interrupt status に応じて呼ばれる。

比較として、 m68k で zs を載せている x68k のコードを見てみる。
と、 x68k の GENERIC を見ると NEWS-OS と同じような intr の数字が書いてある。
NEWS-OS のあれはあれで「そんなもの」だったということか。
で、 x68k/dev/zs.c を見る。割り込みの設定は intio_intr_establish() で行われている。
intio.c を見る。 intio_intr_establish() ではベクタに応じて構造体 iiv[] に呼び出す関数と引数を登録。
iiv[] に登録された関数は intio_intr() の中で呼ばれる。
intio_intr() は locore.s の _intiotrap から呼ばれる。
_intiotrap は vector.s に登録してある。なるほど。

次に hp300 を見てみる。が、こちらの GENERIC には intr の数字がない。
ヘッダやらを探してみるがそういう数字はないようだ。
locore.s の中の割り込み関連の記述も結構違う。
x68k の locore.s では unexpected 扱いの lev[123456]intr が hp300 では重要な扱い。
x68k では vector 別に intrcnt を数えているが hp300 では interrupt level 別。

どうも m68k には autovectored interrupt と vectored interrupt という 2種類の割り込みがあるらしい。
hp300 は前者のみ、 x68k は後者のみを使っているようだ。

さすがに推測だけではなんともならんのでここにきて manual を持ち出す。それによると…
m68k には 3bit 分の割り込み要求ラインがあり、 3bit の数値が 1 以上となった時に割り込みがかかる。
数値が大きい程優先度が高く、 7 はいわゆる NMI になる。
で、次に autovectord/vectored の説明があった。
割り込み要求元デバイスが vector 値を CPU に通知する機能があればその vector の指すアドレスに飛ぶ。これが vectored。
デバイスが vector 値を送れない場合は割り込みレベル 1〜7 に対応する vector の指すアドレスに飛び、そこで割り込み元を判断する。これが autovectored。
でいいのか? まあ大きくは違わないはず。
config の記述からしても news68k は vectored interrupt だろう。

さらにいろいろ調べると mvme68k は vectored/autovectored の両方に対応しているようだ。
どちらもそれぞれ x68k と hp300 のコードとほぼ対応しているが、より整理されている感じ。
たとえば、 pcc.c の pcc_intr_establish() はさらに上位の isrlink_vectored() を呼ぶようになっている。
vector.s も default は badtrap を書いておいて isrlink_vectored() で書き換えている。
zs も zs.c と zs_pcc.c に分けられているし、努力のあとが感じられる。
さらに locore.s を見ると最初に bss をクリアしてたりして news68k との親近感が湧く。
clock も例の MK48T02 を使っている。
というわけで、このあたりは mvme68k をベースにすることに決定。 files.news68k も直す。
ところで clock.c は dev, ${MACHINE} どちらのディレクトリに置くべきなんだ? 現状は結構バラバラ。
と思ったら mvme68k/clock.c と dev/clock_pcc.c に分けられてた。なるほど〜

mvme68k の GENERIC 等には intr は記述されていないが、 dev/pccreg.h あたりに定義されている。
config で "?" になってたらデフォルト値を使う、ってのが正しい?
そのデフォルト値を探すのが先だけど。まず ROM search か?
fdc と SCSI は NEWS-OS のヘッダに書いてあるが zs, le はない。むぅ。
adrsmap.h 下さい、って頼んだ方が早いかな。どう考えても licence の問題はなさそうだし。

19990513

ふと ROM monitor からなにか情報が得られるのではないかと気づく。
というわけで monitor に落として調べてみる。

まずは例の LED 制御から。 help でコマンドを確認して
```
NEWS> ms e0dc0000 1
```
としてみる。
あっけなく基板上の緑の LED が点灯。 0 を書くと消える。
ほかにもいろいろ書き込んでみる。 bit0 で緑、 bit1 でオレンジの LED が点灯するようだ。
AT互換機 BIOS の beep みたいに診断コードを出すルーチンでも用意するか。

help の中に "mu :Memory Usage" というのがあるので見てみる。

NEWS> mu
c0ffc000 !--------------! c0000000 !--------------!
         ! Lower margin !          ! Operating    !
c0ffc000 !--------------!          ! system use   !
         ! calloc() use ! c0ffc000 !--------------!
c0fff400 !--------------!          ! Reserved     !
         ! Boot stack   ! c1000000 !--------------!
c0fff800 !--------------!
         ! ROM stack    !
c1000000 !--------------!
         ! Upper margin !
c1000000 !--------------!

 Size of main memory: 01000000
Reserved for monitor: 00004000
 Dynamic alloc. base: c0ffe900
         Current MSP: c0fff800
         Current ISP: c0ffffa8
           Active SP: ISP
NEWS>

と、メモリマップが出てくる。 0xc0000000 から 16M なのか。
アドレスが表示されるということはメモリを減らすと表示も変わるのか?

ということで SIMM を 4枚抜いて試してみる。

NEWS> mu
c0bfc000 !--------------! c0000000 !--------------!
         ! Lower margin !          ! Operating    !
c0bfc000 !--------------!          ! system use   !
         ! calloc() use ! c0bfc000 !--------------!
c0bff400 !--------------!          ! Reserved     !
         ! Boot stack   ! c0c00000 !--------------!
c0bff800 !--------------!
         ! ROM stack    !
c0c00000 !--------------!
         ! Upper margin !
c0c00000 !--------------!

 Size of main memory: 00c00000
Reserved for monitor: 00004000
 Dynamic alloc. base: c0bfe900
         Current MSP: c0bff800
         Current ISP: c0bfffa8
           Active SP: ISP
NEWS>

というわけで 0xc0000000 から後ろの方へと配置されるようだ。
表示のフォーマットからしてどんな場合でも contiguous memory だろう。

ここまでわかったところで、 SIMM を元に戻して再起動。
…が、"panic:" とか言って monitor すら立ち上がらない。おいこら。
もう一回めんどくさい分解をして SIMM を差し直しもう一度起動。
…が、今度はウンともスンとも言わなくなってしまった。おいちょっと待て。
かなりあせりながらまたまた分解。 SIMM をはずして、軽く掃除して、おそるおそる再度電源ON + RESET。
…と、やっとちゃんと起動してくれた。ふぅ。
parity error のことといい SIMM 交換した方がいいのかしら。

気を取り直して0xc0000000 以外にも RAM がマップされているか調べてみる。
0x0, 0x40000000, 0x80000000 にも見えているようだ。これなら KERNBASE はどれでも OK?
0xfffff000 にアクセスすると
```
fffff000:  Bus error     pc = e0006b02
```
と怒られた。 monitor は 0xe0000000 からってことか。

19990512

なんか昨日の page table の計算はおかしいような気がする。
というわけで hp300 の pmap_bootstrap.c を眺めてみる。 manual は後回し ;-p。
どうも page table entry と segment table entry と二種類あるようだ。
説明がないかと探すと /sys/arch/hp300/DOC/HPMMU.notes というのがある。
HP MMU の説明だが "mimic the Motorola 68851 PMMU" とあるから同じようなもんだろう。

というわけで読んでみる。
segment table から page table を引いて、その entry のアドレスから pa を参照する、ということらしい。
1つの table entry は 4byte なので 1ページの pte で 1024ページ分の物理メモリ。
ste も 1024個の pte を参照できるので 1024×1024×4k = 4G と va 空間を全部参照できるわけだな。
page size が 8k の amiga とかのことは今は忘れる。

ここまでわかったところで pmap_bootstrap.c の続き。
引数は 2つ。 firstpa は RAM の開始物理アドレス。
nextpa は kernel end 直後のページの物理アドレス。ここからいろいろ配置していく。

まず kernel の ste を 1ページ。
次に pte を Sysptsize と I/O スペース分をあわせただけ用意。
ややこしいが Sysptsize はページ数、 [IE]IOMAPSIZE は I/O スペースに必要な entry 数。
NPTEPG は 1ページに含まれるエントリ数で machine/param.h に定義されている。
次に pmap で使う kernel PT map を用意。
んで last kernel PT とやらを用意。たぶん va の最後のページはなにかで使うんだろう。
というか、 pa の最後にはなにか見えてるはずで va=pa にしてるのか。
あとはそれぞれをつらつらと初期化。

ここまでわかったところで NEWS-OS の locore.o を見直す。
実は 0x800xxxxx のアドレスは symbol のアドレスか?
直接 vmunix を "objdump --disassemble" してみる。が、 sun3 では遅過ぎ。
i386 の cross でやろうとしたら objdump を入れてなかった。敗北。

めげずに調べる。 pte は compile 時にすでに kernel 内の data 先頭に配置されてて場所が決まってるのか。
道理でどこにもアドレスを代入してるところががないわけだ。
メモリクリアしてたのは bss 以降らしい。
pte は text を read only, data 以降を write 可で初期化か。
kseg_table ってのがあるけど 2kbyte しかないぞ?
NEWS-OS の KERNBASE が 0x80000000 だからか? うーむ。

maxmem, freemem, physmem なんて symbol 発見。
やはりアドレス 0 から読んだ値を書いてる。 PROM が書き込むのか?

19990511

今度は NEWS-OS の locore.o の中身を見てみる。
が、やはり magic number や absolute address が多くてよくわからん。
アドレス 0xe1280000 が _ctrl_ast という symbol になっている。なんかの制御用ハードか。
ほかにも 0xe1xx0000 あたりにいろいろあるようだ。
movel %al@(188), 1286a <monitor> なんてのもある。ふむふむ。

スタック設定して、メモリクリアして、 page table 作って、 MMU セットして… って感じか。
さすがに MMU の中身まではよくわからんので Users Manual の MMU のところを開く。
が、一部の図が "UNABLE TO LOCATE ART" と抜かして出てこないではないか。
それも一番肝心な bit field の説明図が出てこない。意味なし。

仕方ないので適当に推測。 start, end address と flag を渡してサブルーチンコールしてるのか?
ふと /sys/arch/hp300/include/pte.h とかを見ればよいことに気づく。うむ、ちゃんと説明がある。
page table の address らしきものから適当に逆算を試みる。

まず 0 から 0x80000fff までそのまま read only で map (なのか?)。
続いて 0x80000fff を write 可で。RAM か?
で、 0x0f800000 とか 0x0f000000 とかのアドレスをどこぞに map してるようだ。 ROM なのか…
ん? 同じアドレスを書いてるから物理アドレス 0x01ff0000 を 0x0f800000 に map してる、ってのが正解?
disassemble する前に勉強しとけよ、という声が聞こえてきそうだ。

さらに先を見る。 main() は呼んでなくて _u とか _Umap とか作ってどこかに飛んでいる。
_u ってどこかで見たんだけどどこでだっけ…
Jolitz 本を見るがない。とはいっても i386 の説明でも十分役に立っているが。
boot loader からの flag は d6 と d7 に入っているっぽい。
hp300, x68k その他もそうしてるみたいだから m68k の伝統か?
ん? 先頭で moveml 8, %d0-%fp ってのがあるからこっちが本物?

しかし物理メモリの情報はどっから取ってきてるのか。
アドレス 0 を怪しげに読み書きしているコードがある。
12bit 右シフトとかしてるしこれか? 謎だ。
そもそも kernel はどこに load されてるのか?

さらに眺めていると live_led などという symbol がある。
調べてみると 0xe0dc0000 の bit0 をいじると基板上の LED が制御できるようだ。試してないけど。
これを使えば bebox の locore.s の debug_led のように「どこまで進んでるか」 debug も可能か。
まだなにも書いてないのに気が早いけど。作文するよりコード書け、ってか。

ふと NWS-1750 のコンソールを見ると fsck エラーで止まっている。
電源入れっぱなしにしてたはずだがどうなってるんだ?
見ると parity error で落ちた模様。おいおい。

19990510

hp300 のをもとに locore.s をいじり始める。
とりあえず HP_MMU と M68040/M68060 のコードはじゃまくさいので削除。
MMUbase って何に使ってるんだ?
HP MMU と M68040 だけ使ってるかと思ったが、外部キャッシュの制御にも使われているようだ。

やはり予備知識なしにやってもわけわからんので MC68030 の Users Manual を見てみる。
とりあえず Introduction と Instruction Set Summary から目を通す。うーん、こういうレジスタ構成か。
おいおいそんなレベルから始めるのかよ、という声が聞こえてきそうだが、千里の道も一歩から ;-p

今度は x68k の locore.s を見てみる。
機種数が少ないせいかちょっとはすっきりしているような…
MMUbase は使われてない。外部のコントローラーか?
やはり 2次キャッシュ制御の資料は必要か。
あと必要になるのは物理メモリアドレス／量と boot device/flags の受渡しとかか。
もちろんまだまだたくさん必要なのだろうけど。
ほかに m68k で 2次キャッシュを積んでる機種ってあるのか?

19990509

ハードディスクに入っている NEWS-OS 用のバイナリを確認してみる。
gcc-2.2.1 とか入っていて思わず涙が出そうになる。;-)
いきなり egcs-1.1.2 とか作ってみるが、どうも egcs は NEWS-OS の as が解釈できない命令を出すらしくこける。
NEWS-OS の環境を整えても仕方ないので tcsh だけ作ってやめる。

街の本屋に出かけて m68k 関連の書籍がないか探してみる。
が、やはり今時そんなものはどこにもないようだ。x68k の本はあったけど。
やはり source から完全 bottom up で理解していくしかないか。
あとは Web の英語か。
「PowerPC 概論」という似て非なる本の中身を見て思わず買いそうになるが、ここはぐっとこらえる。

間に合うか心配していた src/distrib/notes/i386/hardware の修正が入って NetBSD-1-4 branch の pullup は終わりということなので sup かけて一通りのマシンで make build してみる。
今のところ特に問題なし。というかあったら困るけど。
ということで、そろそろ news68k 開発用の source tree を用意するか…。先は長いぞ。

19990508

ちょっと片付いたので NWS-1750 を分解して中を見てみる。
しかしお世辞にもメンテしやすいとは言えないつくり。

まず問題の NVRAM を探してみる。
が、なんとマザーボードに直付けされているではないか。なにを考えているんだ SONY よ。
どうもソケットを使うとすぐ上にある拡張スロットに干渉するからのようだ。
とりあえず sparc の NVRAM とは違って時計が狂うだけなので放っておくことにする。
電源投入時に毎回リセットを押さないといけないけど。時計は timed で OK。

気を取り直して今度はメモリを確認する。
30pin の SIMM が 16個ついている。うち 4個は直付け。
ん? ってことはどうやったら最大 32Mbyte になるんだ?
とりあえず最後のバンクに 4M SIMM をつけてみる。… 12M しか認識しない。
SIMM を全部はずして最初のバンクに 4M SIMM をつけてみる。 … 直付けの 4M しか認識しない。
うーん、32M 使うには拡張スロットを使うのか?
今日のところはあきらめてふたを閉める。

というわけで 4M SIMM は NWS-3470 につけることにする。
こっちは上側のカバーをはずすだけで OK。
ざくざくっと 8枚差して電源 ON。
PROM, kernel とも難なく認識して無事起動。
これで i386, macppc に続いて newsmips も 64Mbyte クラブの仲間入り。
試しに make -j20 とかで kernel を作ってみる。当たり前かもしれないけどちゃんと動く。うむ。

19990507

NEWS-OS の /usr/src/sys の下をのぞいてみる。
もちろんすべてのソースがあるわけはない。
ヘッダをいくつか見てまわる。役に立つような立たないような…

SCSI は newsmips とはちょっと違い cxd1180 というらしい。
zs と le は newsmips とほぼ同じ感じ。
hb は hyper-bus の略らしい。

sun3 を立ち上げて objdump で locore.o を逆アセンブルしてみる。
もとがアセンブラだから結構役に立つかも。
NEWS-OS 4.2 のコンパイラはあまり賢くないから discompile わりと楽だよ、という話を思い出す。

…と、どうも変だと思ったら NVRAM の電池が切れているようだ。
NVRAM は sparc と同じものだから直しようはあるけど…うーんめんどくさい。
しかし置き場所を何とかしないと…

19990506

部屋に帰ってきたので箱を開けてみる。
やはりでかい。5インチ full hight HDD と QIC 内蔵なんだから無理もないが。
しかしこれが定価 255万円で売ってたんですねえ。
NWS-1450 のほうが小さくてよかったかも。 NWS-3470 と重ねて置けるし。キャッシュついてないけど。

とりあえずシリアルコンソールをつなげて起動。

「もう何年も動かしてない」とのことだったが難なく NEWS-OS が起動。

NEWS> bo
Boot0 (NEWS-OS 4.2) loading hd(0,0,0)boot
Boot (NEWS-OS 4.2, news1700)
: hd(0,0,0)/vmunix
943812+242952+307752 start at 0x000019e8 (magic 0410)
SONY NET WORK STATION, Model NWS-1750, Machine ID #10557
NEWS-OS Release 4.2C #0: Tue Jul 21 14:22:38 JST 1992
    root@wsrel11:/MAKE4.XR/src/sys/NEWS1700
Copyright (c) 1990, 1991, 1992 Sony Corporation
All Rights Reserved
real mem  = 16777216
avail mem = 14581760
using max. 2798 buffers, 11460608 bytes [dynamic allocate buffer]
Enable Internal Inst/Data Cache
Floating-Point Coprocessor is mc68882
Initializing SCSI.......... done
sdc0 at hb addr 2000 intr 0
sd0 at sdc0 slave 0 (bus=0, chan=0, lun=0)
sd0: hd639
stc0 at hb addr 2000 intr 5
st0 at stc0 slave 0 (bus=0, chan=5, lun=0)
st0: 5125 (512 BYTES REC)
fc0 at hb addr 0 intr 20
fd0 at fc0 slave 0
fd1 at fc0 slave 1
fd2 at fc0 slave 2
fd3 at fc0 slave 3
en0 at hb addr 0 intr 16
en0: hardware address 08:00:46:00:35:36
bpf: en0 attached
kb0 at hb addr 0 intr 36
ms0 at hb addr 0 intr 40
fb0 at hb addr 0 intr 44
fb0: NWB-225 (1280 x 1024 8 plane)
fb1 at hb addr 0 intr 44
fb1: NWB-514 (1280 x 1280 4 plane)
rs0 at hb addr 0 intr 48
lp0 at hb addr 0 intr 104
isdn0 at hb addr 0 intr 120
isdn0: NWB-236 	ISDN/X.25 Interface Board
bpf: is0 attached
bpf: dx0 attached
bpf: dl0 attached
bpf: sl0 attached
bpf: sl1 attached
bpf: lo0 attached
root fstype 4.3 (sd0a)
swap fstype spec (sd0b, 90880KB)
erase ^?, kill ^U, intr ^C
#