NetBSD/bebox porting notes

NetBSD/bebox 移植記、その0。 [Current]

BeOS R3

BeBox用のBeOS R3が到着。
インストールしてみたが、見た目上なんら変わるところなし(?)
UVM対応とかしたいなぁ。

wscons

NetBSD/beboxをほとんど触ってなかったので、久しぶりにcompile。
speakerがMIベースになっている。
serial consoleで起動したら、gettyが死にまくり...
wscons consoleで起動したら、全然平気。
うーむ。何故?
BeOSでばかり遊んでいないで、NetBSD/beboxの作業も楽しまねば!
world21 with wscons 楽しみ(^^)

BeOS R3

BeOS R3 for Intelが来た。
マニュアルからBeBoxの記述が消えた。
うーん。無きものとして扱われるか、BeBox。

wscons

というわけで、wsconsを使うように変更してcommit。
vga0をwsdisplay0にしてconsoleにはっつけるのはすぐ出来た。
が、何故かpckbcのpckbdのwskbdがconsoleにくっつかない。
うーん、と悩んでソースを追っ掛けてたら、 __HAVE_NWSCONSがdefineされてないと、consoleになれないことに気づいた。まだまだ修行が足らんなぁ...

interrupt

8259使わないとダメそう、という結論にたっした。
edge triggerな割り込みラインは、 BeIntrControllerでハンドルすることは無理、ちゅーことですね。いや、前からわかってたことだけど(^^;)
ということで、もとのコードに戻す。
しかし現在のコードも汚いので、いずれ書き直す。
MIなVGA/keyboard/mouseドライバのwsconsがcurrentにmergeされた。
pcvt使うより、楽に使えそうなので、 port-beboxではそっちを使うようにしよう。

interrupt

割り込み回りを改造してみる。
Be interrupt controllerだけを使うようにしてみようと思ったが、ダメかも。
ISAの割り込みがほとんど全部上がってしまっているように見える。ずーと割り込み上がりっ放し。一応動けるみたいだけど、洒落にならないくらい遅いので、どーにもならん。
ISAに関しては、8259を使わざるをえないのか!?
ffs bi endian patchがcurrentにmergeされた。
これで、i386のようなリトルエンディアンマシンでも、 powerpcのffsイメージを作成するのが楽になった。
vnconfigしてmountするだけですからね。

bus_space_map

bus_space_mapでpageマップするようにしてみようと試してみたが、これをやるにはbebox/isa下の、 bus_space某を使ってないドライバと、その他、 I/Oを叩いているところを全部書き換えないといけないですねぇ...
割り込み先にやろっかな。
[linux-ppc] BeBox slownessとか発見。これは66MHzのBeBoxの話かな?
とにかく、どこがボトルネックになっているのか調べないといけないな。

IDE HDD DMA

linuxppcは、CD-ROMに入っているinstallerでは動かないことがわかった。ftpサイトに置いてあるFD_SETUPとかなら起動できる。結局インストールしなかったけど :-)
kernel profilingはまだできない...
mcountで止まっているのかどうかもまだ調べてないし(^^;)
BeBoxのハードウェアspecを見直してみると、wdcはISA DMA 5chにつながっている模様。で、drq 5を使うようにconfigしてみる。
panic。調べてみるとwdc_isa.cのdmasetupに渡す引数の中身が入ってない :-< sc->sc_ad.dma_arg = sc; を追加。
起動成功。
だが、DMAが使えないHDDのようで、PIOモードのまま(T_T) うむぅ
割り込み回り書き直し、bus_space_mapをpageマップするように変更をしはじめようかな...

linuxppc

egcs/binutilsのsnapを使ってみる。
ちゃんと使える模様。profilingもどきもuserlandでは出来る。
kernel profileはまだできない。hack hack
早くsys/cpu/powerpcができてほしー
powermacもcurrentにmergeされるといろいろと作業しやすくなるんだけど。
試しにlinuxppcの98/2のCDを買った。2週間くらいで届く。
BeBoxにインストールしてみようとしたが、intstaller.prepで止まる。むぅ。

D0000000

53C810がmapされているあたりを触るために、 BATで0xD0000000をmapしているが、これはまずいことが発覚。
userlandのmemoryは、0xD0000000から256Mをページマップで使用している。BATでここをmapしてしまうと、どちらが優先されるかちゃんと調べてないが、おそらくBATなので、 userland codeが動かなくなるのだ。
やはり、PCI/ISA I/O MEMをBATでmapするのは無理があるようだ。 pageでmapするようにしようかな。powermacではpageでmapしているので同じようにするだけだし。
gcc-2.8.0を使ってみる。
PowerPC Hackers Mailing List

INSTALL floppy

distribでi386を真似してramdiskを作ってみる。
memory file systemを使うために、i386/i386/md_root.cをそのまま持ってくる。files.beboxを書き直してcompile。 compileは通った。
crunchgenでコマンドをくっつけるわけだが、cross環境で使えるようになっていない(調べてない :-)ようなので、beboxでくっつける。
mdsetimageでkernelにfile system imageをくっつける。
kernelをgzipで圧縮すると... 1000Kぐらい。
BeOSのfile systemに焼いてみようとすると... floppyに入らない。BeOSのfile systemはloggingのための領域を最低512Kも取っているとっても馬鹿で使えないOSなので、どうにもならない。
仕方ないので、DR8.1という古き良き時代のBeOSを持ってきた。楽勝でfloppyに入る。おまけにこれだと、古いBootROMでも読み込めるという素晴らしいおまけ付き!
floppyを入れて起動...
動いた! sysinstまで動いてしまった(^^) serial consoleにしておいたのだが、これまたok!
fdiskはcompile時の不手際でくっついてなかったので、 partitionを切れなかったが、BeOSで切っていたので disklabelを書くことができた。IDE HDDを newfsしてmountすることにも成功!
distrib/setsの下でbase.tgzなどを試しに作ってみる。一応できたので、インストールしてみる。
distributionのpathがよくわからなかったが、なんとかインストールすることができた。wd0をroot file systemにして再起動してみると... 起動成功!
インストール環境はi386と同等なものにできそうだなぁ。 distribの下とかdocumentの整備をしないといけないけど。
DMAの件がまだけりついてないのと、ncrもやらないと。

DMA & floppy その2

disklabelが書けない理由、それは... disklabel -r -w fd0 floppy としていたこと。disklabel -r -w /dev/rfd0a floppy ってやらないと書けないのね ;-) 知らなかった。
disklabelなんてHDDとかMOにしか書かないしなぁ...
で、DMAの実装方法だが、とりあえず使ってなさそうな isa_chipset_tag_t iba_ic(=> ia_ic => sc_ic) に、I/O空間の0x480をmapしたhandleを入れて、 isadma.cでそれを使うようにしてみた。
もうちょっと綺麗に書けそうな気がする。 chipset_tagには別の意味がありそうだし。このtagに DMAのregisterをmapしたhandleを入れられる構造体でも入れるようにした方が良いかも。
とりあえず、floppyにdisklabelが書けてnewfs(ffs)できて、 root filesystemとしてmountすることも可能だ。

DMA & floppy

DMAについて調べてみた。
BeBox(というかMPC105のAddress Map Aモード)では、 PCI/ISAからは、メインメモリが0x80000000から始まっている様に見える(0x00000000はPCI/ISAのメモリ空間)。つまり 0x80000000 = 物理メモリ0x00000000に対応しているということ。
BeBoxにのっているPCI-ISAブリッジに入っているDMAは、 32bitアドレス空間にDMAすることが可能である。 ATの普通のDMAは24bitまでしかDMAすることができない。
つまりDMAするときは、必ずbit31(PowerPC風に言うとbit0か) を1にしないといけない。
isadma.cでは、0-7,8-15,16-23bitの設定をしている。 82378ZBでは、これらを設定すると自動的に0になるので (8237互換のため)、それらの設定のあとに、24-31bitの設定をしてやらないといけない。
adhocにやってしまおうかと思ったが、どうやらAlphaにも 82378ZBが載っているのがあるらしい。共通に使えた方が美しい。
ちなみにadhocにやってみたところ、fdを使うことに成功!
mkisofsで焼いたfloppyはmount_cd9660できたが、 disklabelができていなかった。要調査。

external serial

そういえば、シリアルのcom0,com1は無事に使えているようだが、 com2,com3が使おうとするとササるようだ。
com2,com3は割り込みがBeINTRコントローラに繋がっているので、 8259に繋がっているのと違って、うまくさばけていないのか!?
そろそろkernelだけでも新しいbinary snapを作るかな。 floppy使えるようになってからと思ってたけど。

stream busification functions

commit。大丈夫かな。
これで、machine independentなneドライバとwdcドライバを使用できるようになった。
locore.Sとsetjmp.Sをlocore.s、setjmp.sにrename。
問題なければpowerpcの方もやっておこうかな。
tsubaiさんのpowermacコードを見る。
うまくpowermac dependentなコードだけを抜き出していて、 powerpc dirのファイルを使うようになっている。
mipsやm68kのようにpowerpcもCPU dependとarch dependを分けてもらった方が良いかも...
BeBoxに似た構成のPowerPCマシンもあるらしいし。
そういえば、PIOSのマシンはどんなもんなんだろう...

bus_space_{read,write,set}_{,multi,region}_stream_{2,4,8}()

というわけで、byte(octet) stream i/oを実装しようと思い立つ。
bus_space_{read,write,set}_{,multi,region}_{2,4,8}() は、reverse byte load/store instructionを使用し、 bus_space_{read,write,set}_{,multi,region}_stream_{2,4,8}() は、load/store instructionを使用する、と。
あ、libcのbswap{16,32}をアセンブラで書くようにしようかな。折角 1 instructionでできるんだし。
と思ったが、1 instructionでは、 memoryのload/storeの時にしかできない模様。
PowerMacで、NetBSD/powerpcが動き出しつつある模様。
DDBをcommitしないと。

悩ましい問題

bebox/isa/以下のドライバ。endianが違うだけで i386/isa/以下のドライバが使えるはず。で、wsconsはじめ、これらのドライバの代わりになるものが出来つつあるので、それに移行すべきだろう。 isa/以下には、DMA、isa_machdepくらいしか必要ないはず。BROKEN_INDIRECTなdefineも外したい。
NE2000ドライバ。if_ed.cを持ってきて使っているが、既にobsoluteなもの。neドライバに代っているのだ。しかしif_neを使うとendianでひっかかりそうなのがやっかい。 dp8390.cをbig endianでも使えるように改造するべきか。 big endianなportでdp8390.cを使っているのはないのかな?
ncr。いろいろ調査してみると、デフォルトでは、0xd*00*000(忘れた) とかにmapされているので、603eから見るとmapされていない phys addressにある。BATレジスタを使ってmapしないといけない。また、big endianなportではそのまま動かないことも判明。 ncrに渡すscriptをlittleにしないと(scriptのアドレスだけかな?)。 OpenBSDでは、すでになっているので持ってくれば良いだろう。
wd。MIなコードになっているので、それに移行しないと。これまたendianではまるか!?
DMA。いいかげんcoding開始しないと...
MACHINE_NEW_CONTIGも。

clock

BUSくろっくってBeBoxならどれでも33MHzだったのね...
意味ないコードを入れてしまったなぁ。ま、いいか。

stand/boot その2

bootinfoの置場所を 0x3030～0x3100に変更。
BeOSの起動のための情報が0x3020あたりにあるらしく、ここを壊してしまうと、電源OFF-ONしないとBeOSが立ち上がらなくなる。
delayのために、BUS clockを測定するコードを入れてみる。
空ループにかかった時間をTIMEBASEからと、 i8253のclock0から推測する。clock0に0xffffを仕掛けて、いくつ減ったか調べる。1秒間に何countするかはわかっているので、どのくらいの時間loopしていたかわかる。これにより、TIMEBASEが何countすると、何秒か、というのがわかる。
が、あんまり精度がよくなかったので、ある程度以上のcountなら BUS clock 33MHz、以下なら 25MHzと決めうちしてしまった。
kernelにも、この値を渡すべくbootinfo.hを改良。
bugも取る。commit。
MACHINE_NEW_NONCONTIG どうしよっかなぁ。

stand/boot

stand/boot commit終了。
くっつけるkernelのアドレスを固定しようとheaderにアドレスを仕込んだがBeBoxのBOOTROMがheaderを読んでくれない。
仕方ないので、kernelがどこにくっついているか調べるルーチン追加。
使ってないアドレスにkernelをコピーしておく。
bootするときは、コピーした所からopen/readで読み込む。 gzipしたkernelをくっつけてても、gzip対応のopen/readなので、しっかり読み込む。
boot loaderをserial console versionとvga console vergionの二通りmakeで作成できるように書き直す。
さらにport-i386を真似て、bootinfo.hを付け足す。
メモリサイズ、コンソール名(serial port番号/ボーレート)を kernelに渡す仕組み。kernelをcompileしなおさなくても、 boot loaderを変えるだけで、動的にvga/serial consoleを使用できる。
bootinfoの置場所は 0x3020～0x3100。多分問題なく使用できるはず。試してない。
kernelの方もbootinfoを使うように改造しないと。
IDEドライバ(wd*)がマシン依存/非依存に別れた。
さっそく見てみたが...
BeBoxではBeOSとの互換性を保つために、データのみbig endianで書かなければならないのだが、その部分のコードがdev/ic/wdc.cにある... どうしようかしら...
データをlittleで書いて、partition tableなどだけendianをひっくりかえそうかな...

BOOT

PowerMacの方で、boot loaderにkernelをくっつけようとしているので真似してみる。
PowerMacでは、boot loader(XCOFF)にnetbsdという名前のsectionに kernelをくっつけている。
最初kernelをhexdumpとかでCのソースコード(配列)に変換してくっつけようと思っていたのだが、compileに時間がかかりすぎるので却下。
そこで、linuxppcのmkboot.cとmk_pef.cをhackして、 ELFからPEFを作成するものを作成した。で、それでPEFのDATAセクション (MAGIC numberが入っている程度)にkernelを潜り込ませることにする。
boot loaderの方で、自分にくっついているkernelを、 entryにcopyしてbootするわけです。
でlibsaが最近賢くなっていて、gzipされたfileを直接open/readできるようになっている(openやread内部でgzファイルの処理を行う)。自分にくっついているkernelをopen/readできると、非常に簡単に gzipされたkernelでbootすることができるので、メモリを読み込むpseudo driverを作成してみる。
devparseでfileがNULLだと、F_RAWフラグがたつので、その様にする。で、device固有のopenは何もしない。 device固有のreadは、kernelが入ったaddressに、 blk * DEV_BSIZE分offsetをかまして、size分 bufにbcopyするようにすれば良い。
ちゃんと動いた!
あとは、もっときれいに書き直したり、devparseのbugを直さないと。最大の難関はlinuxppc/BeBoxの人に、GPLのcodeだけど BSD licenceで配布して良いかい? と聞いて許可を求めなければならないこと。
メールして30分くらいで返事。快諾していただきました(^^) 感謝!
ということでdebugしたらimportしよう。

zzz...

CPU1がCPUバスのバンド幅を食い潰している可能性があるならば、眠らせれば良い。
PowerPCのsleep機能を使ってみるが、dhryの結果に差はみられない。
そもそも眠ってないのかも?
PentiumIIマシンに開発環境を移す作業が結構手間取って、あんまりhackできなかった。
FreeBSD-2.2.2でcross環境を作ったら、ldとstripで、 Memory exhausted で落ちるものができてしまった。
そうこうしている内にNetBSD-1.3がreleaseされたので、 FreeBSDからNetBSD-1.3に乗り換え。cross環境を作成する。
ちゃんと動く。
サポートしてないVIDEOボードを使っている人に、 serial consoleがあると良いと言われたので com を生かす。
com0:0x3f8,com1:0x2f8まではわかるが、com2,com3の I/Oポートアドレスがわからないので、linuxppc/BeBox boot floppyのソースをながめる。
com2:0x3f8,com3:0x388とあった。com2は間違いだろう。 com3はこのアドレスで認識された。
com2のアドレスを調べるために、BeOSのserial driverのソースを探す。どっかにあったと思ったが見つからない。仕方なく、 BeOSのserial driverをpefdump。3f8とかで検索すると、それらしいデータ列が見つかった。3f8,2f8,380,388... com2は0x380の模様。試してみると認識された(^^)
実際に使えるのか確かめたいが、現在(98/1/11 1.3A)kernelが動かない(^^;) IDEのドライバ(wdc0)がwd0を見つけるまでは動くが、そこで無限ループしているらしい。多分lockmgrというので待っている。IDEドライバを外すとroot mountまで行くが、 nfsサーバの準備をしていないのでrootをmountできない(^^;)
とかやってたら、config周りが書き代わりはじめた...

cross環境で作る native compiler その2

:binutils
ppc-makeでの環境変数を設定した状態で、
./configure --prefix=/usr/local/PPC --host=powerpc-elf-netbsd \
--target=powerpc-elf-netbsd --build=i386-unknown-netbsd1.3A
gmake
gmake install

:gcc
setenv PATH /usr/local/Be/powerpc-elf-netbsd/bin:`printenv PATH`
patch -p < gcc-2723-assert.diff
./configure \
--prefix=/usr/local/PPC \
--host=powerpc-elf-netbsd \
--target=powerpc-elf-netbsd --build=i386-unknown-netbsd1.3A
gmake LANGUAGES="c c++" \
HOST_CC=/usr/local/bin/gcc \
GCC_FOR_TARGET=/usr/local/Be/powerpc-elf-netbsd/bin/gcc

HBench-OS

安定したは良いが結構遅い。体感speedはDhrystoneの値そのままという感じだ。DX4-75MHzの1/3か...
Operating System Benchmarksってので計ってみる。
時間がかかるので全部testしてないが、memory copy (bcopyね) のバンド幅が7MBytes/sec(だったかな?)ぐらい。あきらかにDX4-75より遅い。
CPU1の方がMPU105間のbusのバンド幅を食い潰しているのか? LEDを頻繁に書き換えているのがいけないのか。

pmap

crashmeで止まる原因は、考えるにどうもpmapのところにありそうな気がする。何故ならば私が書き直したところだからだ。
何回かpmapのところでtrapが発生しているのを確認している。
というわけで、powerpc portのものに戻してみることにする。
必要なものはmem_region。物理メモリと使用できるメモリのスタートアドレスとサイズが入った構造体だ。 NetBSD/powerpcではOpenFirmwareからmem_regions()でこれらを貰う。
そこで、物理メモリにstart 0,size 物理メモリサイズ、使用できるメモリにstart kernelの最後のアドレス (page alignにあわせずみ), size 物理メモリサイズ - startを代入してみる。
BeBoxの割り込みステータスレジスタがあるところを mapするのと、msgbufのmapをどうするか試行錯誤したが、 cpu_startupのversion表示の直前でkmem_allocするようにしてみた。
pmap.cをpowerpcのやつに戻したら、何と! crashmeで10分持つようになった(^^) 今までは5分耐えなかったのである。どのくらい耐えられるか耐久してみるのも一興かも...
compileをしていても途中でささったりしていたのだが、これもちゃんと動くようになった。格段に安定するようになった。いや、私が単に不安定にしていただけだった... まだまだ修行が足らない。精進精進。

NetBSD/powerpc with PSIM

PSIMでNetBSD/powerpcを動かすときの胆は、 ofwboot.elfの.note sectionを削ることにある。
chirpでは、.note sectionにいろいろ書くらしい。が、ofwboot.elfには書かれてないので、 ppc-strip --remove-section=.note ofwboot.elfですぱっと切り取ろう。
あとは、mkisofsでkernelその他入りのiso9660 filesystem imageを作って、tree-970207のfileimageのpathを書き換え、 psim -f tree-970207 ofwboot.elfで起動だ。
binutils-2.8.1.0.18/gcc-2.7.2.3を使いましょう。
binutils-2.8.1 - binutils-2.8.1.0.15ではbootできないkernelになります。

loading kernel...

BeBoxでのNetBSD起動をどうするか考えてみた。
BootROMから直接kernelを読むのも考えたが、 ELFじゃなくなるし(PEF)、symbolとかがどうなるのかわからんので、いまいちだろう。
でも、現状のboot floppyだと IDEとかSCSIのドライバを書かないといけない。時間がかかる。
BeBoxがbootできるデバイスにNetBSDのkernelを入れるためにはどうするか...
BeBoxのboot image(PEF)にNetBSDのkernel(ELF)を埋め込むというのはどうだろう。デバイスからkernelを読む代わりに、 boot imageに埋め込まれたkernelを読むわけだ。これなら、どのデバイスでも、BootROMが読める限り、 NetBSDが起動できるわけだ。埋め込むkernelをlinuxにすれば linuxも起動できるだろう(書き換えが必要かもしれんが)
kernelを作る度にboot imageを作り直すわけだが、 Be,Inc.がBootROMのエントリを公開しない限り、こういう方法でないとだめだろう。このくらい公開してくれてもいいじゃねーか、まったく...
この方法で面倒なのは、BeOSファイルシステム(bfs)に boot imageを書き込むことである。今はISO9660にkernelを書いてるが、これは簡単だから良い(floppyが増えるのがちょっと嫌)。 (kernelを頻繁に作り直すときは、今の方法だな。) いちいちBeOSを起動するのも面倒だしなぁ... mkbfsとか作るか? 情報が公開されていれば、だけど :-P
kernelを小さくするためにzlibを使ってみる。起動の時にuncompressするわけだ。

IDE HDD

余った(余らせたといふべきか...)270M IDE HDDが手に入ったので、 IDE HDDを使えるようにすべく行動開始。
IDEのドライバ wdc.cは以前に動かしたことがあるので使えるようにするまでさほど苦労はない。
設定したport(0x1f0)にそのままアクセスしようとするので、 bus_space_mapで返ってくるアドレス(0x800001f0だな)を読み書きするように変更。
16bit,32bitで読み書きするところをreverse byte load/store するように変更。PowerPCにはendianをひっくり返して load/storeする命令があるのでそれを使う。(in[s][wl]/out[s][wl]マクロ)
但し、ディスクへのデータ読み書きだけは、 endianをひっくり返さない。
BeOSでIntelパーティションを設定して中身を見てみたのだが、 BOOTブロック(1セクタ目)のMAGIC numberがbig endian(だよな?) で書き込まれる。NetBSD上でfdiskやdisklabelがこれのせいで動かないのだ(当初、データもendianをひっくりかえしていた)。パーティション情報などもbig endianなので、MAGIC numberだけの話ではないのは当然。
fdiskとdisklabelだけ、endianを引っくり返して(というか、データのread/writeは16bitで行うので、16bitごとにendianをひっくり返すことになる)やろうかと思ったが、なんかアレなので、 wdc.cで、データのread/writeだけはそのままload/storeするように変更(ATAPIの方も変更しないとCD-ROMとかが読めないか? 持ってないからわからん)。
BeOSで作ったパーティションにdisklabelを書いたり、 NetBSDのfdiskで作ったパーティションを、BeOSで見たり(パーティションがあるのがわかるだけね。mountできたりするわけない...)
disklabelを書いてみる。interactiveに操作もできるぞ。
newfsもokay! 最初sector/cylinderなどが1になってて(謎)、 newfsが動かなかったが、disklabelのgeometry情報を変更したらちゃんと書けた。newfs完了までが思ったより速かった。意外。
nfs上のファイルをlocalのIDE DISKに移してみる。相変わらずCPUがささったりするが :) なんとか root:wd0a(20M) usr:wd0e(170M) swap:wd0b(80M)の状態で multiuser mode 起動! (/etc/rcでmount -aしてなかったりしたこともあったが :-)
ときどき止まるのを除けば :) なかなか快適。
次はSCSI(ncr)か!? floppyの方が先か... DMAがなぁ...
いや、その前にpmap.cをNetBSD/powerpcのやつに戻す方が先だな。
あ、そうそうdisksubr.c/disklabel.hはi386のやつ、そのまま。

interrupt

ひさびさにport-powerpc@netbsd.orgが盛り上がった。 PowerMacへの移植が始まると、powerpcもbeboxも大分楽になるに違いない(バグ出しとか)。
で、割り込み関連のバグというか、私の移植ミス発見...

extintr.cの401行

        hwpend = ipending & ~pcpl;      /* Do now unmasked pendings */

ここに、

        hwpend &= 0x0fffffff;

が必要。OpenBSD/powerpcでは、 hwpend &= ((1L << ICU_LEN) - 1);ってなっている。

これがないと、SINT_CLOCK,SINT_NETのbitまで落としてしまう。
これで、ちょっとはマシになったかな。
次のコーディング対象は何にしようかな。DMAか。

stack

ほぼ毎日cvs updateしているが、日によって動いたり動かなかったり...
OpenBSD/powerpcから持ってきた割り込み機構をちゃんと持ってこれていないのかも。ed0がTimeoutしてしまうのです。key入力が効かなくなったり。
ある特定の条件のもとに発生すると思われるので、DDBで追っ掛けることにする。そのためstack traceコマンドをimplementする。

stackがどうなっているのかgccのソース(config/rs6000/rs6000.c) で調べた。

   V.4 stack frames look like:
        SP----> +---------------------------------------+
                | back chain to caller                  | 0
                +---------------------------------------+
                | caller's saved LR                     | 4
                +---------------------------------------+
                | Parameter save area (P)               | 8
                +---------------------------------------+
                | Alloca space (A)                      | 8+P
                +---------------------------------------+
                | Varargs save area (V)                 | 8+P+A
                +---------------------------------------+
                | Local variable space (L)              | 8+P+A+V
                +---------------------------------------+
                | saved CR (C)                          | 8+P+A+V+L
                +---------------------------------------+
                | Save area for GP registers (G)        | 8+P+A+V+L+C
                +---------------------------------------+
                | Save area for FP registers (F)        | 8+P+A+V+L+C+G
                +---------------------------------------+
        old SP->| back chain to caller's caller         |
                +---------------------------------------+

これを元に簡単にコーディングしてみたところ、なんとなくうまくtraceできている模様。
SOFTWARE SPECIFICATIONSの System V Application Binary Interface: Power PC Processor Supplement, IBM. を参照して、よりtrace情報をわかりやすくしたい。

@ha !? @h !?

OpenBSD/powerpcよりsplXXX、割り込み等を持ってきた。
BeBoxの割り込み構造に基づいて書き直したが、イマイチ。
もっと書き直すつもり。
で、OpenBSDから持ってきたソースでは当初まったく動かなかった。
正確には割り込みハンドラのとこまで来てささる。
printfも使えなくなっているので、LEDを点灯させながら、追っ掛けていった。

結構bug(?)が見つかった。

/* Disable translation, machine check and recoverability: */            \
        mfmsr   2;                                                      \
        lis     3,(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@ha;                     \
        addi    3,3,(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@l;                    \
        andc    2,2,3;                                                  \
        mtmsr   2;                                                      \

disableにしたいのならば、

        lis     3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@ha;                     \
        addi    3,3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@l;                    \

だろう。あと、これらのbitは(確か)全部下位16bitに収まっているので

	andi.   2,2,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@l;

で良いはず。NetBSD/powerpcは、こうなっている。

あとは、@hの代わりに@haが使用されていること。例えば、

/* First have to enable KERNEL mapping */
        lis     31,KERNEL_SEGMENT@ha
        addi    31,31,KERNEL_SEGMENT@l

これ、NetBSD/powerpcだと、

/* First have to enable KERNEL mapping */
        lis     31,KERNEL_SEGMENT@h
        ori     31,31,KERNEL_SEGMENT@l

となってます。

「@h」と「@ha」の違いは果たして!?
binutilsのgasのソースで違いがわかります。

@hでは、

                ex.X_add_number = (ex.X_add_number >> 16) & 0xffff;

@haでは、

                ex.X_add_number = (((ex.X_add_number >> 16) & 0xffff)
                                   + ((ex.X_add_number >> 15) & 1));

NetBSD/powerpcを参照するに、 @haが使用されるのはアドレスに対してのみの模様。
32bitの定数をレジスタにいれる(lis+ori等)場合、@hを使用しないと上記のように値が変わってしまいます。
OpenBSD/powerpcでは、ほとんど@haが使用されており、 @hでの値と異なる場合があるため、例えば address transrationがうまくいかない (はず。beboxではできなかった)。
ひょっとするとPowerPC604eでは動くのかも...
もしくはgasのversionが違うとか? うーむ、謎だ。
Wolfgangさんに教えてもらったが、上記解釈は間違っていた。
@ha の a の意味するところは add らしい。

たとえば、

	lis     3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@ha;
	addi    3,3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@l;

のように、addiを使う場合 @ha を使用しなければならない。

	lis     3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@h;
	ori     3,3,~(PSL_DR|PSL_IR|PSL_ME|PSL_RI)@l;

のように、addiを使わないのならば、@h を使うべきである。

次のようなこともあるので、アドレスを使う場合は、 @haを使っておくのが無難らしい。

        lis     3,xxx@ha
        lwz     3,xxx@l(3)
is correct, while

	lis     3,xxx@h
	lwz     3,xxx@l(3)
could access a different word (64k lower address than &xxx).

addi,ori どちらを使うかは好みの問題ということですね。
定数はlis @h+ori、アドレスは@ha+addiを使う、などと心掛けておけば、要らぬ間違いが減るでしょう。きっと。

spl

ソース保守/コンパイル用のNetBSD/i386がなんとか復活したので、 cvs updateしながら、compileしてみたりしているが...
動く時と動かない時がある(^^;)
rarpのパケットの送信終了を検知してないらしい?
OpenBSD/powerpcを参考に大幅に書き換えを実行するしか!
割り込みに関する考察が必要。

OpenBSD/powerpc

久しぶりの更新...
NetBSD/beboxは無事にcommitされ、今ではsupで取り寄せることも可能になってます。でも、まだExperimental portsですから、 1.3RELEASEには含まれません。
OpenBSD/powerpcはOpenfirmwareから脱却したよん、という様なメールをV.I computer/RMTXの人から貰う。今のところOpenBSD/powerpcは PowerPC604e VME ボードで動くようだ。 kernelのbootはOpenfirmwareを使っているようだが、これは仕方ないだろう。
デバイスとしては、ISAにシリアル、PCIに21140(DECの100/10ether)、 NCR 53C860(SCSI)、Universe(TundraのPCI-VMEブリッジ)が載っている。このうちUniverse以外はOpenBSD/powerpcでサポートしているようだ。
PCIのVGAボードも使えるのかな? ドライバが入っているが作りかけに見えた。まだシリアルコンソールだけのようだ。
ISAの割込、SCSIのサポートのところは大いに参考になりそう。 anonymous CVSで引っ張らねば。

current-1013

ed0 timeout, RPC timeoutの件は調査してない...
このままうだうだしていると、いつまでたってもまともに動かないので、commitすることを志す。
10/13のcurrentでcompile完了。一応(?)動作...
commit完了。よりhackしやすくなったわけだ(^^)

current-0925

なんとか動いた。
rarpするときにed0 timeoutと出るのと、 nfs root mountするときにRPC timeoutが3回でるのが気にかかる。
前者は、splimpしたまま送信しているらしい?
後者は、nfsサーバの1007番portに対して送信しているので、答えてもらえないだけ? sunrpcポートに出すとちゃんと返事が帰ってくる。nfs root mountのソースに虫がいるのか?
どちらも調査が必要。hack hack hack

splXX

ときどきprocess tableがおかしくなったり、 softnetが入りにくく(?)なったりするが、まぁ、そこそこ動いている。
commitしようかなぁ、とcurrent持ってきてコンパイルしたら、結構変わっている(^^;)
consoleまわりや、msgbuf、bootinfoなど。
msgbufはサイズ変更ができるようになった程度なので、あんまり問題がなさそう。
consoleはboot時の情報 bootinfo を読むようになって、動的(?)にコンソールデバイスを変更できるらしい。
bootinfoをサポートしなければ。
bootinfoを使わない方法で、取りあえずcompileは通した。
動作確認をしなければ...
CVSの修行中。習うより慣れろ :-) ですね、これは。

Optimizing PowerPC Code

届いた。一週間ちょい。
PowerPC Microprocessor Family: The programming Env.とかぶっている内容が多いが、検索がしやすいので持っておくとうれしいこともあるかも。
肝心のoptimizeの内容が少ないような気がするが... こんなものかな?

NetBSD/bebox

NetBSD/beboxをcommitするための作業を開始しなければ。
まだsplXXで遊んでいる。もうちょっと安定させないと心情的にcommitするわけにはいかない。ソースも綺麗にするする。
NetBSD/beboxに関する質問は、sakamoto@netbsd.orgまで。誰も使ってないから質問なんてないか...

BootROM

Be,Inc.としては、「あなたの言うことは理解できるが、もう情報を出すつもりはない。すでに出してある情報を参考にしろ」だそうだ。
となると、SCSIとIDEのstandaloneなドライバを作成しないとフロッピーなしでの起動はできない。
BootROMを逆アセンブルして、その中身を使うのも良いけど、あんまり建設的ではないなぁ...
ドライバを作る方が、他のアーキテクチャやOSのブートアップ時に使い回しがきくので建設的。

NetBSD/bebox port master !?

Core Groupの方から、NetBSD/beboxのport masterに誘われてしまった(^^)
なってみようかな。

boot

splXXをいろいろ変えて試しているが、良い方法がみつからない。
で、Be,Inc.からBeBoxのBootROMについての質問の回答が返ってきた。
Unfortunately, we are not planning on doing anything to the BootROM of the BeBox to allow it to read various kernels, as we have long stopped production of the BeBox.
だと。だったらソースコード公開するか、エントリの公開をしてくれ。
「Seriously though, we would like the BeBox to be open to all comers, even other operating systems -- a Linux port is already up and running! For the lunatic fringe, getting control of the entire machine is the ideal environment. Happy OS hacking! 」ってNews letterで書いてるのに。
Be,Inc.のうそつき。もう一回交渉してみるか。
BootROMを逆アセンブルか...
bootROM imageを pefdumpで逆アセンブルすることができるが、 PowerPCのアセンブラは読みにくい。省略形のニーモニックで出力してくれれば良いのに。
「Optimizing Powerpc Code : Programming the Powerpc Chip in Assembly Language」という本を買ってみる。なんか良い本らしい。オンラインで買うのは、中身を確認できなくてつまらん。
着くのは7～14日後。business hourなのでもっとかかるかな?

swap?

CPUがstallする件で、swap spaceがないからではないか、というアドバイスを貰った。

さっそく、試してみる

	    dd if=/dev/zero of=/be/home/be/swap bs=32k count=3072

	    /etc/fstab add:
	    ariel:/be/home/be/swap none swap sw,nfsmntpt=/swap

	    # swapctl -A

うーむ、状況変わらず。上記の設定で、swapを使えているのか、いまいち不安だ。NetBSD/i386でも試してみるが、よーわからん。
複雑なことをやらなければ止まらないわけだから、 splXXやDMAのあたりを綺麗にする方が先だな。これは。

trap

crashmeで落ちる原因をよくよく見たら、単に、trap.cで illegal instructionや、align exception、trace trapなどを defaultでpanic()させているだけだった...
trapsignalで、processに通知してやることで、そのへんはちゃんとhandleできるようになった。
しかし、crashmeをちょっと長く動かせるようになったに過ぎない...
プロセス数が増えると、ささる。
プロセス数がささる原因なのか?
kernelをrecompileするときは、さほどプロセスを使わないので、直接原因ではないと思われるが...
ささらないで、panicしてくれればちょっと簡単になるんだろうけど。
地道にprintfデバッグか!? 前兆があれば良いのだが。

native compiler

splXXは、とりあえず、ハードウェアインタラプトに関するものはすべて external interruptをmaskするように変更。
安定度が少しだけ向上した。
maskすべきものだけ、maskするように変更しないと。
intrnames、intrcntなどがNetBSD/powerpcになかったので、追加。割り込み回数をcountしておくためのもの。これらがないと vmstatが動かない。
で、nativeなgcc/binutilsを作ってみる。

作り方は、以下の通り。powerpc-elf-netbsdなcrossコンパイラが前提。

:binutils
setenv PATH /usr/local/Be/powerpc-elf-netbsd/bin:`printenv PATH`
./configure --prefix=/usr/local/PPC --host=powerpc-elf-netbsd
gmake
gmake install
# libiberty/Makefile
#  $(RANLIB) -> ppc-ranlib

:gcc
setenv PATH /usr/local/Be/powerpc-elf-netbsd/bin:`printenv PATH`
./configure \
--prefix=/usr/local/PPC \
--host=powerpc-elf-netbsd \
--target=powerpc-elf-netbsd --build=i386-unknown-netbsd1.2G
gmake LANGUAGES=c HOST_CC=/usr/local/bin/gcc

これで、kernelをrecompileすることも可能かもしれない。
が、そこまで安定していないのであった :) 途中で死んでしまう。
crashmeしたら一瞬も持たなかった :)
安定度向上とDMAが次の目標かな。

Dhrystone(1.1)

486DX4-75MHzで6万くらい。
UltraSparc-167MHzで34万。
BeBoxでは2万程度... こんなに少ないわけがないと思うので、何かが悪いはず。clockかな。

multi user mode

いぢめるためにmulti user modeで立ち上げてみる。
syslogdを動かすとささる。
原因はmsgbufpにきちんとmapしたaddressが入っていなかったため。
i386とかarm32などなどを真似して実装する。
syslogdが動くようになった(^^)

dmesgでlogも表示できるぞ。

NetBSD 1.2G (GENERIC) #34: Thu Aug 28 23:23:01 GMT 1997
    sakamoto@ariel.cec.co.jp:/be/src/NetBSD/sys970801/arch/bebox/compile/GENERIC
CPU: PowerPC 603e (Revision 400)
real memory  = 83886080 (81920K bytes)
avail memory = 74727424 (72976K bytes)
using 1024 buffers containing 4194304 bytes of memory
mainbus0 (root)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0
pchb0: Motorola product 0x0001 (rev. 0x24)
pcib0 at pci0 dev 11 function 0
pcib0: Intel 82378IB PCI-ISA Bridge (System I/O) (rev. 0x43)
Symbios Logic 53c810 (SCSI mass storage, revision 0x02) at pci0 dev 12 function 0 not configured
S3 Trio32/64 (VGA display) at pci0 dev 14 function 0 not configured
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
lpt0 at isa0 port 0x378-0x37b irq 7
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0: 
wd0: 335MB, 682 cyl, 16 head, 63 sec, 512 bytes/sec
wd0: using 1-sector 16-bit pio transfers, chs addressing
ed0 at isa0 port 0x300-0x31f irq 5
ed0: address 00:40:33:91:5b:37, type NE2000 (16-bit)
pc0 at isa0 port 0x60-0x6f irq 1: color
spkr0 at pc0 port 0x61
biomask 4000 netmask 4020 ttymask 40a2
ticks_per_sec = 8250000
hz = 100
ticks_per_intr = 82500
boot device: 
root device: ed0
dump device: 
file system (default generic): nfs
nfs_boot: using network interface 'ed0'
nfs_boot: client_addr=0xc0a80102
nfs_boot: server_addr=0xc0a80101
nfs_boot: hostname=bebox
root on ariel:/be/home/be/root
root time: 0x3405f4f1
init: copying out path `/sbin/init' 11

あと、telnetdがcoreを吐く原因がわかった。
/etc/gettytabがないとcoreを吐いて死んでしまう。
DMAの前に splxx をちゃんと実装しないと。
割り込みを止めないので、割り込み入り放題 :) なのだ。

locore.S

SIGSEGVが発生する原因をよくよく調査してみると、 dsi trapが発生するのはロード系命令のはずなのに、 dsisrでストア系命令をあらわすbitが立っている。
603eでは、TLBミスのexceptionはロードとストアで別れている。 tlbdsmissとtlbdlmiss。そのexceptionハンドラはlocore.Sの中にある。これらのハンドラで、dsisrを書き込んでいるのだが、その書き込む値が、両方ともストアのための値だったのだ...
locore.Sの690行目、tlbdlmissのところ。
```
	lis     1,0x42000000@h          /* set dsisr<1> to flag pte not found */
	    
```
これ本当は、
```
	lis     1,0x40000000@h          /* set dsisr<1> to flag pte not found */
	    
```
となるべき。コメントにもbit 1(PowerPCでは上からbit 0,1,2...と呼ぶ) の説明しかしてないのに、書き間違えたのね...
Bug Report上げておこう。
初めてsend-prしてみた。 NetBSD Problem Report #4052です。この修正で正しいのだよなぁ...
しかしNetBSD/powerpcって本当に動いているのかな?(^^;)
っと思ったりする。
昨日ちょろっと試した限りでは落ちなかったが、結構robustになったのか!? もっといぢめてやらないと。
次はDMAかな。

SIGSEGV

間が空いてしまった...
相変わらず/sbin/initでSIGSEGVが発生する原因を修正できない。
initにktraceをかけることができたりすると良いのだけど。
BeにBootROM内のエントリー公開を求めた(返事がなかったので2回ほど)
公開してくれないかな...

vm_fault

8/1のcurrentで、コンパイル成功。起動できるようになった。
のは良いが、DMA使うところが全滅。とりあえず DMAを使うドライバを外しておく。DMAは後回しだ。
相変わらず、/sbin/initでSIGSEGVが発生する。
これの修正が第一目標。
/sbin/initが悪い可能性も否定できない。
NetBSD/powerpcの方で起きているか、portメーリングリストでだいぶ前に聞いたのだが、反応なし...
例の属性チェックをコメントアウトすると、 /bin/shまで動くが、1.2Eの頃より落ちやすくなっている :-(
ソフトウェア割り込みのところを直して速くなったから?

1.2G

8/1のcurrentで、コンパイルし直してみる。
結構いろんなところが変わっていて、configも新しくしないといけなかったり、machineとかmachine_archなどに、アーキテクチャ名などを入れておかないといけなかったりする。
なかでもDMAの大幅な変更がきつい。
alphaのdma周りのソースが別れていたので、それを持ってくるが、結構違う(当たり前か)。i386のisa_machdep.cから抜き出す方が楽そう。
dev/isaなどに置いていたif_ed.cとかwd.cをarch/bebox/isaとかに引っ越ししてみる。dev/isa/files.isaをarch/bebox/confに置いて、引っ越ししたソースのところだけ取り替える。
ヘッダはどうするかな...
ソフトウェア割り込みは、setsoft*で、splxを呼ぶからおかしいだけ、と判明。呼ばないように変更。

rewrite

currentに近づけるべく、書き直しはじめる。
NetBSD/beより NetBSD/bebox かな。
ちゅーことで、タイトルも変えてみる。
どーも、NetBSD/powerpcのソフトウェア割り込み回りがうまくないので、arm32やalphaなどを参考に書き直すつもり。
mipsはソフトウェア割り込みの機構がちゃんとしてるから良いなぁ...
それに比べて、powerpcやSH3は...
splxと割り込みから帰るところでソフトウェア割り込みハンドラを起動すれば良いはず。

hack

少しづつコンパイルしたプログラムを、NFSサーバに揃えて、multiユーザ環境に近づけている。
viとかsystatのようなcursesなプログラムもちゃんと動く。
カーソルがどっかにいったままになったりするけど :-)
nethackも動くぞ(笑)
inetdを動かして、外からrloginすることにも成功。
telnetだと、telnetdが(生意気にも)coreを吐いて死んでしまう。
時々kernelが突然死ぬので面白い :-)
ソフトウェアインタラプトはどうしよっかな。

application

ちゃんと動いているのか調べるために、/binや/sbinの下をコンパイルしているのだが、どーもちゃんとコンパイルできないものがある。
最適化オプション "-O" が付いているとうまくコンパイルできないのだ。
gccのせいなのか、ソースが悪いのか、コンパイル方法が悪いのか。
disklabelとかnewfsとかmountあたりが早く使いたい...
disksubr.cと格闘しなければ。

scheduling

ネットワークが遅い理由が半分判明。
ether_input(NICの受信インタラプト時に呼ばれる)で、 schednetisr(NETISR_IP)が、直接(splxで呼んでいる)softnet()を呼んでしまうのが原因。schednetisr()を実行している時点では、 IF_ENQUEUEされていないので、ipintrは何もしない(できない)。
本来は、schednetisr()した時点でsoftnet()を呼ぶのではなくて、 NICからの割り込みのハンドラから抜けた時点で、 schedulingが起きて、softnet()が呼ばれるのが正しいのではないか、と思う。
splx()で、softnet()が呼ばれないようにしたら、とりあえず速くはなった。
10msごとのclock割り込みから、ipintrが呼ばれるので、 ethernetで受信してから最大10msの遅延が生じるけど :-(
この辺は、外部割り込みの割り込みレベルとかともからむので、全面的に見直しが必要。
bnlsrがbnslrに直っていた。

TODO

書ききれないほどあるけど、とりあえず解決すべき問題点を。
遅い。FreeBSDマシンからかけたpingのroundtripが、1000ms強かかる :) /bin/shが立ち上がるまでに、めちゃめちゃ時間がかかる。 PSIM(PowerPCのシミュレータ)上でNetBSD/powerpcを起動するくらい、時間がかかる。clock.cの私が書き換えた部分にbugがいるのだろう...
ディスクの読み書き。フロッピー、IDE HDDなどへのアクセスがうまくいかない。disklabelなどがきちんと読めないからだろう。 disksubr.cはi386から持ってきたまんまなので、エンディアンの問題があるかもしれない。
DMA。7/1以降のNetBSD currentでは、DMAのフレームワークが変更になってしまったので、その辺を書き直さなければならない。
swap/dump。これまた最近変更になった部分だが、その辺りも見直しが必要。
外部割り込み。8259-BeIntController-PowerPCあたりのハンドラの最適化。割り込みレベルについては、まったく考慮されていないので、その辺のコーディング。

/sbin/init

signal 11, SIGSEGVが発生する原因は、vm/vm_map.cの
```
        /*      
         *      Check whether this task is allowed to have
         *      this page.
         */      
  
        prot = entry->protection;
        if ((fault_type & (prot)) != fault_type)
                RETURN(KERN_PROTECTION_FAILURE);
	    
```
ここのところ。ここで、prot = VM_PROT_READ|VM_PROT_EXECUTEだが、 fault_type = VM_PROT_READ|VM_PROT_WRITE なので、returnしてしまい、結局 vm_faultでページをmapできなくなってしまう。
initのソースのどこでこれが起きるかというと、main()に入る前 :)

lib/libc/localeのlocaleconv.cで、これが起きる。

    static struct lconv ret;

    if (__mlocale_changed) {
        /* LC_MONETARY */
        ret.int_curr_symbol     = _CurrentMonetaryLocale->int_curr_symbol;

この代入するところで、

    exc_dsi|exc_user=0x6737c dsisr=0x42000000 at 0x5e7b8

が発生する。

quick & dirty hackな感じで、vm/vm_map.cの上記のif文をコメントアウト :)
initがforkして/sbin/shが起動!!!
single user modeで立ち上がることができた!!!!! (祝)
ちゃんと/bin/shでシェルのコマンドが使用できる。
/bin/shと/sbin/initしか持ってきてないので、なにもできないけどね。
まだいっぱい問題があるのだけど...

src/lib/libc/arch/powerpc

libcをクロスコンパイルしようとしたときに、
```
	+ exec make -f /usr/local/Be/usr/share/mk/sys.mk -f Makefile
	creating accept.o
	: Assembler messages:
	:2: Error: Unrecognized opcode: `bnlsr'
	*** Error code 1
	    
```
というエラーが起きる。オペランド`bnlsr'なんてものはないので、 `bnslr'に修正する。書き間違いらしい。

/sbin/init

/sbin/initが動き出している様な気がする。
ユーザプロセスでの仮想メモリの使い方がNetBSD/powerpcとは違うのかもしれない。

serial console

serial consoleを試してみる。
前に試したときに動かなかった理由がわかった。
com.cを見るとわかるが、
```
#if 0
        XXX NEEDS TO BE FIXED XXX
        comconstag = ???;
#endif
	
```
という様なところが二カ所 :) ここをfixしたらserial consoleが動いた。

DDB

if_ed.c with IPKDB は、付焼刃では動かないことがわかったので、とりあえず置いておく。
OpenBSD/powerpcはDDBに対応していそうなことを知っていたので、そのファイル(db_*)を持ってきてみる。
簡単に動いた。
レジスタの退避などを行っていないようだったので、 ipkdb_glue.c kgdb_glue.cなどを参考に、DDBでも似たようなことをするように改造した。さらに、7月に入ってDDBがELFのsymbolなどに対応したようなので、BeBox bootをELF symbolを読み込むように改造。DDBでsymbolを解釈できるようにできた。
本当に正しく動いているのかまではわからないが...

init

/sbin/init起動まで一歩前進。まだ動いてないけどね :)
vm_machdep.cのソースがちょこっと古かった... pmapのポインタがきちんと渡っていなかったので、新しいソースと合わせる。
でも、まだ動かない...
Process 1 got signal 11。SIGSEGVです。
原因は、dsi isi trap時にpageをmapできていないこと。
vm, pmapまわりがきちんと動いていないようだ。
pmapは一番書き直したところが多いから、間違いも多そうだし(^^;)
NetBSD/powerpcのportmasterからIPKDB対応版if_ed.cをもらう。が、古い(^^;) 今のversionに対応させるのもなかなか大変。

boot

カーネルがbootできない原因がちょっとわかった。
BeBox boot imageのサイズがある程度大きくなると NetBSDのkernelが起動できなくなるらしい。
ちゃんと調べてないけど、ちょっと小さくしたら動いたのでそのままほったらかし。
IDEとかSCSIのドライバを組み込むことになったら、もっとサイズが大きくなるので、そのうちちゃんと調べないと。

current

ipkdbはif_ed.cなどに細工が必要らしいのでパス。
NetBSD/powerpcのportmasterがif_ed.cを改造していれば組み込めるんだけど、openfirmware用のしかないとなると、自力改造しかない。
やはり地道なデバッグの方が、今のところ良いのかも。
6月の終り頃にNetBSDのDMA関連がガラッと変わってしまい、今作業中のソースをcurrentに載っけるとコンパイルができない。
i386ほどDMAに制限はないので(32bitリニアにDMAできる)、 NetBSD/i386のソースを持ってくることもないのだが、持ってこないで自力で書くのも結構なボリュームになりそうなので、とりあえず、currentを追っ掛けるのはstop。
1.3になったときに考えよう。そうしよう...
実は、ipkdbかserial console作業中にカーネルがbootできなくなってしまったので(^^;) それを復活させないといけないのです...
SCCSかなんかで管理するのが正しいのだろうなぁ。
ディスクが欲しい... あと、速いCPU。

/sbin/init

NetBSD/beのクロス開発環境をNetBSD/i386に構築できた。
クロス用makeスクリプトをちょこっと書き換えるだけで、コンパイルできるようになった。kernelもコンパイルできると思うが、やってない。
lorderが古いとNM環境変数を見てくれないので、取り替えるとかする。
NetBSDのincludeファイルは、src/sysでクロス用make includes, usr/include/*をコピーすることで簡単に集められる。
usr/src/lib/csu辺りから、ちゃんとmakeできるか確認しながらコンパイルしていってみる。
これなら他のプラットフォームでも簡単にmakeできると思う。
未だ /sbin/init は起動せず...
/sbin/initを動かすためにユーザ空間にファイル名などをカーネル空間からコピーするのだが、この時に失敗している。
マップされていないアドレスにコピーするので、そこでDSIトラップが起きる。そこでそのアドレスのところをマップするはずなのだが...
この辺のことで、NetBSD/powerpcのportmasterに聞いてたら、 ipkdbのことを教えてくれた。UDP/IPでのremote kernel debug です。remote側にgdb,kernel source, kernel symbolがあれば良いらしい。試してみよう。

IDE HardDisk

toshibaの2.5インチHDDを2.5=>3.5マウンターで、 BeBoxに載っけてみる。
isaのwd.cを生かすと、最初はwdc resetが効かなかったが、次の日はendianが逆ながらも :)動き出した。
BeBoxの電源が入らなくなってあせってたら、電源ケーブルが抜けかけていただけ :)だったということがあったので、そのときにdiskの抜き差しをやったのが良かったのだろう。
とりあえず、クロス開発環境での/sbin/initの作り方を調べなければ。

swap mount

nfs越しのswapだが、directoryを作るということではなかった(^^;
dd if=/dev/zero of=swap bs=32k count=2048 てな感じで、 swap用のfileを作っておくのが正解だった。
NetBSD/i386 を NetBSD/sun3 の diskless サーバとして設定する、が参考になる。

root mount

floppyが読めるようになった(?)し、etherもしゃべれるようになった。
しかし、まだ/sbin/initを読み込むまでには至っていない。
floppyでは、cd9660ファイルシステムをmountできていないし、 nfsでは、swapファイルシステムをmountしようとして(?)こけている。
今は、NetBSD/powerpcのファイルシステムfloppy(cd9660)を使っているが、これがいけないのか? /sbin/initなどの実行ファイル形式はa.outだが、NetBSD/beでもa.outは実行できるはずなのだが...

Interrupt

Linuxppcのソースを見直していたら、8259の初期化をまったくしていないことに気が付いた。BeBox用のboot floppy でも、8259の初期化をまったく行っていない。
対して私のソースは、boot floppyでも、NetBSD kernelでも両方で8259の初期化をしてしまっている。
前に8259の初期化しないkernelを作ったことがあったが、 boot floppyのコードまで手を付けたことはなかった。
っちゅーことで、8259の初期化をしないことにしてみる。
動いた...
どの割り込みが来ても、EndOfInterruptで落とすことができる。
初期化方法が間違っていたのか、そもそも初期化を行ってはいけないのか。謎に包まれているが、動いたので良い :)

network boot

割り込み、シリアルコンソールは、時間がなかったのでパス。
Linux/ppcのソースを読み直さないと。
とりあえず、FreeBSDでのrarpd,bootparamd,mountd,nfsdの設定を見直す。
nfs bootしなおしてみると、お、bcopyでexceptionだ。 '/sbin/init'のパスネームをコピーするときに落ちているのか?
画面がぐちゃらけるのは直っている。mountdがいなかったからかな... ま、なおったから良いか :) まだ/sbin/initを読み込めてないけど...

ethernet

とりあえず動かない割り込みは放っておいて、割り込みの動く Ethernet(NE2000)を使ってみる。
受信できない原因は、やはりエンディアンの所為であった。
dp8390reg.hの中で、ed_ringという構造体を定義しているが、その中のcountを引っくり返さなければいけなかった。
rsr,next_packetは、LITTLE_ENDIANと同じ順番で良い。
エンディアンのことは考え出すとわけがわからなくなるので、動いた時点で思考stop。
とりあえず、rarpdからIPアドレスをもらい、bootparamdから、自分のホストネームとnfsサーバのIPアドレスをもらえたらしい。
そのあと、画面がぐちゃらけてしまい、何が起っているのか追えなかった。ログを取れるようにシリアルをコンソールにするように改造しなければ。
あ、シリアルの割り込みもひょっとして動かないのだろうか(T_T)

not End of Interrupt 2

割り込みが落ちない件でBe,Inc.にメールを送ったら、「Please refer to the Linux sources available online.」ときた。ま、動いてるソースがあるんだから、それを見ろってのはあたりまえか。しかし、Linuxのソースはもう既に読んでるんだけどなぁ(^^;)
Linuxから、割り込みルーチンのところのソースをそのまま持ってきてみるか...
まったく同じってわけではないが、ほとんど同じようなソースなんだけど。うーむ。

not End of Interrupt

キーボード(irq1)の割り込みが上がりっぱなしになる。
とりあえずirq1をmaskしておくと、起動時のroot file systemの選択でキー入力が使用できる。が、maskしておかないと、上記の様に割り込みが上がりっ放しになるので、どうにもならない...
floppy(irq6)も割り込みが上がりっ放しになっているようだ。おかげでフロッピーを読むことができなくなっている。
またNE2000 ethernet(irq5)は割り込みをちゃんと落とせているようだが、エンディアンの関係か、受信がきちんとできない。 rarpパケットを投げて、rarpd(FreeBSD上で走らせている)が、返答しているところまでは、logとtcpdumpにより確認している。

BeBoxでの割り込み

頭がこんがらがってきたので、BeBoxでの割り込みについてまとめてみる。
PowerPCは外部割り込みラインをひとつ持っている。
そこに、BeBoxの割り込みコントローラがつながっている。
BeBoxの割り込みコントローラには、すべてのデバイスの割り込みラインが繋がっていて、さらに82c59も繋がっている。
GeekPort,SCSI,Serial3,4などのデバイスは、 BeBox割り込みコントローラにしか繋がっていないが、それ以外の(PC/ATで一般的な)デバイスは、 BeBox割り込みコントローラと、82c59の両方に繋がっている。
つまり

ってわけだ。(BeBookよりリンク)
82c59はedge triggerな割り込みをハンドルし、 BeBox割り込みコントローラはlevel triggerな割り込みをハンドルする。
どちらのコントローラで受けるかは、それぞれの mask register で設定する。両方で受けるようにすると、まずいかもしれない。

Interruptの落とし方

82c59を触らずに、Interruptラインを落とすことはできるのか。
82c59にはauto end of interruptなる機能があるようだが、それを使えば良いのだろうか。
謎なのが0xbffffff0のPCI/ISA INTACKレジスタ。 MPC105の機能らしいが...

Timer

irq0 は、使ってはいけないものなのかもしれない。 0x7ffff2f0 にもirq0を示すbitは存在しない。
普通(?) PowerPCでは、Timer割り込みに DECレジスタを使う模様。つまり82c54(82379に入っている)は必要ない。
というわけで、irq0、82c54を使用しないように、割り込みハンドラ回りを改造。0x7ffff000 からはじまる 1ページをpmap_enterなどで仮想アドレス空間にマップする。
ISAの方からまともに割り込みが上がってないようだが(?) どうやらtimerの方は動いているらしく、rootをmountしようとするデバイスのtimeoutだけ :)はうまくいく。
DECレジスタに書き込む値は、NetBSD/powerpcでは、 openfirmwareから貰っている。とりあえず、バスクロック33MHz、 DECレジスタは4クロックで '-1'される、ことを考慮して、 10msごとに割り込みを上げるように決め打ちで設定。
PowerPCでソフト的にバスクロックを調べる方法はあるのかな。 82c54で一定時間はかって、その間にいくつDECが減るか調べる、という方法かな。

Interrupt 82c59

とりあえず、0x7ffff2f0を使わずに、82c59だけを使うような PCI/ISA interrupt generic handlerを書いてみる。
確かに割り込みが上がってきているようだ。
timer (irq0)の割り込みが上がりっ放し...
IO_ICU1に0x60を書けば、irq0を落とせるのではないのか?
うーむ、どうしたもんだろ...

Interrupt Handler

82c59(82378の中にある)を叩くように変更してみる。
どうやら割り込みが上がって来ているようだ。
OS Writer's Cookbookによれば、「 When possible, interrupts should be handled with the Be controller where they can be directly identified and dispatched. Interrupts in the ISA controller require many (slow) ISA I/O accesses to identify and acknowledge the interrupt, and a second level of dispatching to get to an interrupt handler.」とのことなので、 external interruptがきたら、0x7ffff2f0(Interrupt sources)を読んで割り込み要因を特定し各handlerに飛ぶ、というのが正しいのだろう。
0x7FFFF000から始まるページをマップしなければ。

Interrupt

そろそろ割り込みまわりも考えはじめないと。
ISA/PCIからの割り込みを起こさない状態では、 root/swap filesystemをmountする直前まで動いている。当然割り込みが動かないので、floppy diskもnetworkも動かないけど :)

malloc

うー、mallocでこける。
mallocで割り当てられたvirtual addressに対して、アクセスしたところで、DSI trapで落ちている。
pmap_enterでは、physical addressがちゃんとマップされているように思えるのだが、実際にはマップされていなくて、何もないところをアクセスしてDSI trapを起こしているようだ。
trap.cに手を加えて、簡易モニタを突っ込んだ。 DDBを使うのが筋ってものだろうが、machine dependentなところを作るのが面倒だったので...
603eのメモリ制御のところを真面目に追っ掛けないといけないらしい。
動いた(^^)
ハッシュドページサイズが小さいのが原因だったらしい。
8Mで64K、64Mで512Kといった感じで、実メモリ容量によってページテーブル(?)を増やさないといけないのだが、 NetBSD/powerpcでは、optionsで設定しないと64Kになってしまう。
BeBoxに80M載っけている私のマシンではページテーブルが足らなくなってしまって、こけてしまっていたらしい。

FrontPanel LED

BeのdevsupportとかmklinuxとかにLEDの付け方を、何度かメールで問い合わせてみたが、音沙汰なし。
BeDevTalkの検索で探したら、 BeOS Led Driverが見つかった。
まだ試してないけど、ソースを見る限り、 isaのaddressの0xc00に8bitでwriteすれば良いらしい。 0x80000c00か、0xc0000c00のどちらかだな。
試した。0x80000c00に8bit writeすればLEDがつく(^^)
上位4bitが左のLED bar、下位4bitが右のLED bar。
0x0～0xf で大きくなるにつれ、LEDも下から長くなる。
Beから返事がきた。「The LEDs are illuminated on their own via hardware. There is nothing for you to do.」だと。まったく :)

エンディアン三度

if_ed.cでNE2000のROMからMACアドレスを読み込むところ。 NE2000は16ビットモードなので、 MACアドレスも16ビットずつ読み込みます。ここは問題なし。
ところが、読み込んだデータをsc_enaddrに格納しているところでエンディアンが関係します。0,2,4,6,8,10バイト目を拾っているが、 BeBoxでは、1,3,5,7,9,11バイト目を拾うようにしないと。

device driver

isaとかpciとかのドライバを使うためには __BROKEN_INDIRECT_CONFIG をdefineしないとだめみたい。__BROKEN_INDIRECT_CONFIG を i386のようにinclude/types.hあたりでdefineしないと、呼び出し側と呼び出され側で引数の意味が変わってしまいます。

bus_space_read write_multi_N

bus_space_*_multi_*は、bus spaceの方のアドレスは固定、書き込むor読み込むデータのアドレスはincrementする。
bus_space_*_multi_*を呼び出す側では、きちんとcastしてない場合が多いので、macroでcastするようにする。関数として実装しとけば良いのだろうけど。 caddrとかで渡されても、正しくincrementできないぞぅ。

AAPR

BeOSがバージョンアップされた。prerelease版のprerelease版て感じでバグバグしているが、HDDのパーティションを切ることができるようになっている。しかもIntelパーティション(ATで使われている方式) 対応(^^)。これで一台のHDDでBeOSと共存できる。

エンディアン再び

MPC105のマニュアルをよくよく読んでみると、 PCIのコンフィグレジスタを32bit長で読み書きするときはエンディアンをひっくり返せ、と書いてある。
たしかにひっくり返っていたので、そのようにbus_space_read,writeを書き直す。16bitのときも一緒だろう...
PCIのコンフィグレジスタはこれで読めた。
ISAのデバイスもこれでアクセスすれば良いのだよなぁ...

ふと、INETを生かしてコンパイルしてみたら、 nfsのところでコンパイルが通らない。
見てみると、be という変数を使っていた(^^;)
アーキテクチャ名をbeにしてあるので、とりあえず、 nfsの方の変数名を変えておく。

Memory Mapping

PowerPCのアドレス変換方法は4種類ある。(603eUM 5.1.3)
1. Page address translation translates the page frame address for a 4-Kbyte page size
2. Block address translation translates the block number for blocks that range in size from 128 Kbyte to 256 Mbyte
3. Direct-store interface address translation used to generate direct-store interface accesses on the external bus; not implemented in the 603e.
4. Real addressing mode translation when address translation is disabled, the physical address is identical to the effective address.
4. は、そのまま何も変換しないでアドレスをメモリコントローラに送る。起動直後やboot floppyは、このモードでアクセスしている。
3. は、PowerPC603eにはそもそも実装されていない。
2. は、128Kbyte～256Mbyteの大きさのブロックをまとめてアドレス変換するための機構。すでに書いたように、 0x0～,0x80000000～、0xC0000000～それぞれから始まる256Mbyte の仮想アドレス空間は、そのアドレスのまま物理メモリにマップしたので、BAT変換に関しては、ほとんど何も考えなくて良い。
1. は、仮想アドレスでの4Kbyteのページを任意の物理メモリにマップする機構。NetBSD/powerpcでは、 Technical Details on NetBSD/powerpcや、include/powerpc.hを見るとわかるが、

0xD0000000 ～ 0xDFFFFFFF ユーザー空間セグメント
0xE0000000 ～ 0xEFFFFFFF カーネル空間セグメント
というようなアドレスを仮想アドレスとして使用している。

0xD0000000 ～ 0xDFFFFFFF	ユーザー空間セグメント
0xE0000000 ～ 0xEFFFFFFF	カーネル空間セグメント

pmap.c

MACHINE_NONCONTIGをdefineしないようにして、porting BSD paperや、他のcontiguous memoryなアーキテクチャのソースを参考にして、余計なものを外す。
cpu_start()まで動いたが、どうもディスクキャッシュを取るときにささる。
nbuf * 64Kbytesを取る。nbufは80Mの物理メモリの時1024。
nbuf = 944のときにささるのを確認。
よーく調べると、pmap.cで、vm_page_alloc(NULL, NULL)とよんでいるところがおかしい。
vm_page_alloc()では、MACHINE_NONCONTIG がdefineされていると、引数(object)がNULLのとき、vm_page_insert()をよばないようになっているが、MACHINE_NONCONTIG がdefineされていないと、引数のcheckをおこなわないので、 vm_page_insert()に NULL な引数が渡されてしまい、 exception(?)が発生してしまう。
contiguous memoryな picaやpmax アーキテクチャでは、 vm_page_alloc1()という関数をpmap.cの中に抱え込んでいた... vm_page_free1()というのも一緒にもらってくる。
configure()まで動いた(^^)
本腰を入れてデバイスドライバの移植(てほどでもないけどね)をせねば。

pmap.c

Openfirmwareが提供するメモリは、どうやら分断されている模様。 (psim + NetBSD/powerpc のシミュレーション環境で確認)
powerpc/include/vmparam.hに、MACHINE_NONCONTIGがdefineされている。
0～4Kぐらいは、exception vectorに喰われるのは良しとしても、他に使えない領域があるのは、納得がいかない。
Openfirmwareが使用している空間が使えない、ということなのだろうか。
折角flatなメモリ空間が使えるのだから、使おう。
pmap.cは結構書き直さなければならなそうだ。

Device Driver

NetBSD/powerpcでは、デバイスドライバーはOpenfirmwareを利用してつくられている。
BeBoxには、そんなもの付いていないので、自前で用意しなければならない…
が、前述のように、ISA/PCIはAT互換機と同様にアクセスできるわけですから、i386のデバイスドライバーをさくっと、持ってきてしまいましょう。
inb、outbなどは、さくっとdefine。デバイスのメモリ空間へのアクセスはうまいことずらす。
i386/isa/pccons.cはほとんど書き直しなしで、使用できました。
printfが使えるのは非常にうれしい(^^)

Memory Management

NetBSD/powerpcでは、しょっぱなのBAT registerの設定で、 main memoryの 0～256M しかマップしていない。
これでは、アドレス変換をするように設定した時点で、 BeBoxのISA、PCIなどが、触れなくなってしまう。
ので、Initial Memory Management and head.S で、やっているように、

BAT0 0x00000000 0x00000000 メインメモリ
BAT1 0x80000000 0x80000000 PCI/ISA I/O
BAT2 0xC0000000 0xC0000000 PCI/ISA Memory
というように、アドレス変換時でもアクセスできるように設定する。

BAT0	0x00000000	0x00000000	メインメモリ
BAT1	0x80000000	0x80000000	PCI/ISA I/O
BAT2	0xC0000000	0xC0000000	PCI/ISA Memory

NetBSD kernel port start...

Be Newsletter

今の今、気付いたけど、BeのNewsletterに、OS Writer's Cookbookとかあるぞ(^^;)
よくまぁ、これを見ずにbootまで漕ぎ着けたものだなぁ…
Linux/ppcとNetBSD/powerpcのソースさまさまですね(^^)
How the Be OS Starts Upも参考になる。

ISO9660ファイルシステム

当初のブートに使うファイルシステムをcd9660(ISO9660)にする。
これでファイルに関しては、エンディアンを考えなくても良くなる。
FreeBSDでcd9660なフロッピーを作るには
mkisofs directry > /dev/fd0
とかする。directry以下にcd9660ファイルシステム上に置きたいファイルを入れておく。
これでカーネルの移植に取り掛かれる。

フロッピー

フロッピーからちゃんと読めるようになった… かな?
アドレスの演算をミスっていた… (なさけない)
さて、ffsはエンディアンを気にしなければならない。どうしよう。
FreeBSDでビッグエンディアンなffsを読み書きできるようにするのが正しいのだろうなぁ。
rawでもいいけど、美しくないし。

ELF

Executable and Linkable Format(ELF)の資料は、サーチエンジンで探せばいろいろ出てくると思いますが、ftp://ftp.intel.com/pub/IAL/TIS/pfmt11.pdf のpdfに含まれるELFの章を見るのが良いかと。
他に、psファイルに変換したものもありますが、どうも図がずれたりする。フォントの関係かな?

FDC

フロッピードライブコントローラーであるが、 DMA使わないと、まともに読み書きできないものなのだろうか。
DMA使わないと、データ読み書き出しのterminateが発生しない(?)ので FDCが動き続けてしまう、のか…
謎だ。とりあえずDMAを使っておこう。
BeBoxに限った話ではない。

ISAのデバイス

irqとかdmaなど、ATで触るように、BeBoxでも同様にアクセスできる。
intelの82378ZBのおかげか。

エンディアン

BeBoxのPowerPCはbig endianで動作。
MPC105の先のPCIでは、little endian。
MPC105にはバイトスワップ機能があり、 AT互換機でデバイスを触っているようにアクセスできる。
あまり考えなくても良いようになっているようだが、考えると頭が溶けるので、やっぱり考えないようにしよう…

スタック

でかいバッファをstackに取ってはならない。
のか?
とりあえず、少なめに取る方が無難のようだ。
exception起こしても、見つけられないし(ハンドリングしてないから…)
libsa/cd9660.cのcd9660_readでは、buf[2048]とか取っている。 static付けるか、関数外へポイだ。

フロッピードライブのユニット番号

Linux/ppcのBeBox用のブートプログラムのソースを見てて気付いたが、BeBoxでは、FDDがユニット"1"として繋がっている様だ。
実際、自分で組んだfloppy drive device driverでも、ユニット1として、アクセスしないとダメだった。
確か、FDDに繋ぐケーブルでユニット0とユニット1を選べるはず。
3つコネクタが付いたケーブルの2つめの先がよじれているのは、二台繋ぐときに片方をユニット0、もう片方をユニット1するためだとか。
BeBoxの製造工程のアセンブルミスというのでなければ、なんらかのポリシーがあるのかも? 謎だ。

時間計測

時間計測と言っても、単にwaitするときにだいたいの時間がわかれば良いってだけの話です。

PowerPCには、勝手にカウントアップしていくレジスタがあるので、それを使うことにより、適度に正確な時間を調べられる。

loop:
	mftbu r30       #load from TBU
	mftb r31        #load from TBL
	mftbu r29       #load from TBU
	cmpw r30,r29    #see if 'old' = 'new'
	bne loop        #loop if carry occurred

TBはPPC603/603e/604/604eは、単位が1/4 Bus Clockなので、 33 × 4 MHz 周期にカウントされていることになる。
Thanks to BeTalk-J mailing list [bebox 2056] 川辺さんの記事

BeBoxのメモリマップ

MPC105は、二種類のメモリマップを用意することができる。

BeBoxでは、PCI + ISAのメモリマップ(Address Map A)を使用している。

Processor Address Range Definition
0x00000000 ～ 0x7FFFFFFF System memory space
0x80000000 ～ 0x807FFFFF ISA/PCI I/O space
0x80800000 ～ 0x80FFFFFF PCI config space
0x81000000 ～ 0xBF7FFFFF PCI I/O space
0xBF800000 ～ 0xBFFFFFFF Reserved
0xC0000000 ～ 0xFEFFFFFF PCI memory space
0xFF000000 ～ 0xFFFFFFFF ROM space

Processor Address Range	Definition
0x00000000 ～ 0x7FFFFFFF	System memory space
0x80000000 ～ 0x807FFFFF	ISA/PCI I/O space
0x80800000 ～ 0x80FFFFFF	PCI config space
0x81000000 ～ 0xBF7FFFFF	PCI I/O space
0xBF800000 ～ 0xBFFFFFFF	Reserved
0xC0000000 ～ 0xFEFFFFFF	PCI memory space
0xFF000000 ～ 0xFFFFFFFF	ROM space

もどる