このあと文字化けした表示が続き、まるで動きません。このあと、パッチの当て忘れに気づいたり、あれこれ試行錯誤したのですが、結局のところシェルプロンプトを拝むことはできませんでした。昔の環境なら動くはず以前動作させていた環境なら動くはずです。動いているところから色々変化させて挙動の変化を見るほうが良いに決まっています。初めからそうすればよかったのです。いうことで以前のVMイメージを起動して、当時作ったカーネルを起動します。はい、当然のことながら起動します。それでは、ステータスレジスタを変化させてみましょう。いうことで、ステータスレジスタを変化させて試してみますが、なんだか様子が変です。以前は止まっていたはずなのに、なにをやっても正しく起動してきます。頭から見てみようカーネルの作成ミスや修正のセーブし忘れなど、ケアレスミスを見つけやすくするためにカーネルの作成回数や「ここを実行したよ」というデバッグ文字を出しています。ここをよく見るとおかしなことが。通るべきルートを通っているはずなのに、デバッグ文字が出力されていません。シリアル部分が詰まっているのかなぁ、と思っていたのですが、いよいよ疑わねばならない感じです。リブートではなく電源OFFからやり直してみたり、ここまででずいぶん時間を食っています。デバッグ文字が出力されていない理由、それはその部分を実行していないだけなのです。違うルートを通っていると。絶対通らないはずと思い込んでいたルートにデバッグ文字を入れると、きっちりそこの文字が出ました。実行されないところを一生懸命直したりしてバカだなぁ、ということにつきるのですが、問題はそのルートです。#endifそうです、ステータスレジスタにゼロを入れて完全にクリアしています。前回、NetBSDではステータスレジスタのBEVフィールドを保持して書き戻していると書きましたが、あれは大ウソだったということです。ONEを移植する際に、最初につまづいたのは「ステータスレジスタにゼロを入れて書き戻すとハングする」という事象だったはずです。西村さんのエスパーメールにも、ステータスレジスタの全ビットを書き換えるコードの是非について言及があったので、当時もこのルートを通り、うまくうごかずu-bootをまねて0x10000004を設定して動かしたはずです。時間がたつとバグが消えるなんて話は、本当ならばうれしいですが、おかしな話です。私はマジックナンバーを設定したいのです。以前そうしていたように0x10000004を設定してカーネルを起動します。s0,0(s2)db>あれ、死んだ。以前と真逆の結果です。ERLを追加してみたりしました。起動しない(3)起動しないパターンの共通項はERL=ONのようです。死んだときのメッセージについては次のとおりです。causeのが微妙に違っています。まとめさて、いろいろと試してみましたけれど、実際に動かしてみてわかったことは、「元のコードが正しかった」ということのようです。西村さんからもらったエスパーメールはマジックナンバーのメールだけでなく、実はそのあとにも数通いただいていたのです。そのメールの内容は、当時はさっぱり理解できなかったのですが、いま改めて読み返してみると、テクニカルかつ示唆に富む内容だなぁと噛みしめている次第です。個人あてメールを勝手に引用するのはマナー違反だと知りつつ、一文だけ引用させていただいて、今回のエントリーを締めたいと思います。2015の8日目です。結論から言うと、本件はまだ解決していません。時間切れではなく実力不足ですいません。ONEでNetBSDを動かす話をしました。ONEという小さなMIPSマシンにNetBSDを移植した話なのですが、このなかで一番最初に実行されるlocore.Sの冒頭でダンマリになってしまう現象に悩まされていました。Developerの西村さんからヒントをいただいて、無事に先に進んだという部分があります。エスパーによるリモートデバッグといえましょう。先に進んだのは良かったのですが、見よう見まねでステータスレジスタに設定した0x10000004は謎のままです。mips/locore.Sという一番最初のファイルにマジックナンバーを入れておくのはどうにも気持ちが悪いですし、本家にフィードバックする際に説明できないのでは困るので、まじめに調べてみようと思ったのがきっかけです。Calendar駆動で調べ始めたのですが。問題の個所はsys/arch/mips/mips/locore.sの以下の部分です。#endifif-else-endifを整理すると次の三行になります。interruptsmfc0でステータスレジスタをv0にロードして、andでBEVフィールド以外はゼロクリアして、mtc0でステータスレジスタをストアしています。if-else-endifを考慮すると、ステータスレジスタに対して様々なパターンで処理を行っています。ステータスレジスタに何をやっているのか処理を切り替えているということは、何らかの理由があるはずです。プロセッサごとの初期化処理に違いがあるということでしょうか。そのためにフィールドのそれぞれの意味を確認します。24kのドキュメントをあたってみます。先に出てきたのはBEV,TS,REです。エクセプションベクタの場所を制御します。0だとノーマル、1だとbootstrapです。TLBWRによってマシンチェック例外が引き起こされたことを示す。プロセッサがユーザモードで実行中にリバースエンディアンメモリ参照を有効にします。サポートされていません。