Athlon64X2 の編集

* 「はりぼてOS」が実機ではうまく起動しない、という話題のページ
-(by [[K]], 2006.07.20)
-このページ名は、実機でうまく起動しないという最初の情報が、Athlon64X2機だったことに由来。

*** 基礎情報
-以下に「はりぼてOS」が動かなかったという報告を載せますが、このページでいいたいことは、「だから以下の機種は悪い」ということではなくて、「だから「はりぼてOS」は悪い」ということです。
-「はりぼてOS」のどこに問題があって、どうすれば克服できるかが分かったら、是非修正方法をまとめたいと思います。このページはそのための情報収集ページです。
-2006.07.20の段階では、Athlon64X2ではうまくいかないらしいということが分かっていますが、これがAthlon64X2だけの問題なのか、他のDualコアCPUでも同じなのかは分かっていません。またAlthon64X2機のどこに問題があるかも分かっていません。CPUの設定が悪いから動かないのか、チップセットの設定が悪いからなのか、その辺も解明する必要がありそうです。
-2006.09.23の段階では、下記のバージョン6のパッチさえあてれば既知のすべての問題は解決する、というのが[[K]]の見解です（註：下記に明記されているように、バージョン6の修正内容は、バージョン4の内容も含む）。
----
-ちなみに考え方としては、この方法で以前は問題なく起動できたのだから、起動できなくなったのは最新機種などの互換性が不十分なためだということもできます。しかし[[K]]としては、ハードウェアの些細な差異を吸収することもソフトウェアに課された役目だと考えているので、ハードウェアよりも「はりぼてOS」のほうを責めたいと思います。

*** 集計データ
-(当然ですがこの表を勝手に書き換えてはいけません。こめんと欄の内容を[[K]]がたまに集計してここに反映させます。)
-動かなかったよ情報：
|CPU|チップセット|異常動作報告|正常動作報告|備考|
|Athlon64X2|nForce4|1|0|ver6が有効|
|Athlon64X2|nForce410|1|0|ver6が有効|
|Pentium3|i810|1|0|ver4が有効|
|Pentium4|i845|1|0|ver4が有効|

*** 対策パッチ
-そもそもこれで状況が改善するかどうかすらわからないので、興味がある人だけが実験してください。
----
-バージョン6（バージョン4の変更に加えて以下の変更をしたものがバージョン6です）
--naskfunc.nasへの変更：
 
 （中略：以下をソースの末尾に書き足す）
 
         GLOBAL  _asm_inthandler27
         EXTERN  _inthandler27
 
 _asm_inthandler27:   ; （これは_asm_inthandler20等とほとんど同じ）
         PUSH    ES
         PUSH    DS
         PUSHAD
         MOV     EAX,ESP
         PUSH    EAX
         MOV     AX,SS
         MOV     DS,AX
         MOV     ES,AX
         CALL    _inthandler27
         POP     EAX
         POPAD
         POP     DS
         POP     ES
         IRETD
 
--bootpack.hへの変更：
 
 （中略）
 
 /* naskfunc.nas */
 （中略）
 void asm_inthandler21(void);
 void asm_inthandler27(void); /* ココ！ */
 void asm_inthandler2c(void);
 （中略）
 
--int.cへの変更：
 
 （中略：以下をソースの末尾に書き足す）
 
 void inthandler27(int *esp)
 {
     /* PIC0からの不完全割り込み対策 */
     io_out8(PIC0_OCW2, 0x67); /* IRQ-07受付完了をPICに通知 */
     return;
 }
 
--dsctbl.cへの変更：
 
 void init_gdtidt(void)
 {
     （中略）
 
     /* IDTの設定 */
     （中略）
	set_gatedesc(idt + 0x21, (int) asm_inthandler21, 2 * 8, AR_INTGATE32);
	set_gatedesc(idt + 0x27, (int) asm_inthandler27, 2 * 8, AR_INTGATE32); /* ココ！ */
	set_gatedesc(idt + 0x2c, (int) asm_inthandler2c, 2 * 8, AR_INTGATE32);
      （中略）
 }
--「説明しよう！」
---変更箇所がやたらと多いですが、結局やっていることは、IRQ-07を受け付けられるようにしただけです。しかもそのIRQ-07が起きたときにする処理といえば、PICに割り込みを受け付けたよと連絡するだけで、他には何もしてしません。こんな意味がなさそうな処理を書き足すだけで直ります。
---明白に効果アリ。決定版っぽい。
~
~
---そもそもIRQ-07は受け付けないように設定しているわけですが、なぜこんな割り込みが起きるのでしょうか？これは実はマスタPICの「不完全割り込み」というもので、要するにPICが「お、なんか割り込み来たな？」と回路が動き出したところで割り込み信号が途絶えてしまい、何番の割り込みだったのか記憶するのが間に合わず、分からなかったという状態です。PICの反応速度を越えた割り込み信号の急激な変化、と言うと分かりやすいでしょうか。
---こんなときでもPICはとりあえず割り込みがあったことをCPUに伝えようとします。そのときには、とりあえずそのPICが管理している最大の番号の割り込み番号を使うという仕様になっています。今回問題を起こしているのはマスタPICなので、それでIRQ-07が発生するんです。
---さてでは、そんなへんてこな割り込み信号をマスタPICに送った犯人は誰でしょうか。実はスレーブPICです。この問題を引き起こすチップセット内のスレーブPICは、初期設定すると割り込み通知信号線に一瞬ノイズが載るようです。この線はまさにマスタPICのIRQ-02につながっているため、マスタは割り込みが来たと思ってしまい、しかしこれは一瞬のノイズでしかないのですぐ消えてしまいます。それでマスタPICは不完全割り込みを起こしてしまうのでしょう。
---（上級者向け追加コメント）ちなみにPICが不完全割り込みを起こすのはエッジトリガモードのときだけです。IBMの設計者がもうちょっとまともでTOWNSのようにレベルトリガモード前提でハードウェアを設計してくれていたら、こんなややこしいことに悩まされずに済んでいたものを・・・。
---ちなみにOSASKでは、以前に別の機種でまさにこのIRQ-07問題に悩まされたため、かなり以前に対処済みでした（[OSASK 2674]～[OSASK 2784]）。
----
-バージョン5（バージョン4の変更に加えて以下の変更をしたものがバージョン5です）
--asmhead.nasへの変更：

（中略）
 
 ; PICが一切の割り込みを受け付けないようにする
 ;   AT互換機の仕様では、PICの初期化をするなら、
 ;   こいつをCLI前にやっておかないと、たまにハングアップする
 ;   PICの初期化はあとでやる
 
     CLI                 ;                                                   ココ！
     MOV     AL,0xff
     OUT     0x21,AL
     NOP                 ; OUT命令を連続させるとうまくいかない機種があるらしいので
     OUT     0xa1,AL
     STI                 ;                                                   ココ！
     NOP                 ; STIとCLIが連続するとちょっと気持ち悪いのでNOP     ココ！
 
     CLI                 ; さらにCPUレベルでも割り込み禁止
 
 ; CPUから1MB以上のメモリにアクセスできるように、A20GATEを設定
 
         （中略）
--bootpack.cへの変更：

void HariMain(void)
 {
     （中略）
 
     init_gdtidt();
     init_pic();
     io_sti(); /* IDT/PICの初期化が終わったのでCPUの割り込み禁止を解除 */
     fifo32_init(&fifo, 128, fifobuf, 0);
     *((int *) 0x0fec) = (int) &fifo;
     init_pit();
     init_keyboard(&fifo, 256);
     enable_mouse(&fifo, 512, &mdec);
     io_cli();                                                      /* ココ！ */
     io_out8(PIC0_IMR, 0xf8); /* PITとPIC1とキーボードを許可(11111000) */
     io_out8(PIC1_IMR, 0xef); /* マウスを許可(11101111) */
     io_sti();                                                      /* ココ！ */
     fifo32_init(&keycmd, 32, keycmd_buf, 0);
 
     （中略）
 }
--「説明しよう！」
---ひよひよさんの報告から考えてみると、どうやらAlthon64X2では、PICへの設定中はCLIにしておかないとまずいのではないかと推測される。ということで、PICへの設定中はCLIにするようにしてみた。効果はあるだろうか。
---（asmhead.nasで、直後にCLIすることが分かっているのにあえて一度STIするのは、PIC設定中に受け付けた割り込みがもしあったら（まあ多分ないだろうけど）、それを32bitモードに入る前に処理させてあげるため。）
---結局これもイマイチ効果なし。
----
-バージョン4（バージョン1～3の変更は破棄してください）
--asmhead.nasへの変更：

（中略）
 
 waitkbdout:
         IN      AL,0x64
         AND     AL,0x02
 ;       IN      AL,0x60         ; ココ！（削除）
         JNZ     waitkbdout      ; ANDの結果が0でなければwaitkbdoutへ
         RET
 
         （中略）
--「説明しよう！」
---どうやら一部のチップセットでは、キーボードデータが来る前に入力ポートを空読みするとチップセットが暴走するようだ。本来の8042では、空読みした場合、直前のデータが何度でも読み取れることになっていた。この仕様を一部のチップセット開発者が勝手に変更してしまったのだろう。・・・と予想した。結果は如何に？！
---効果ありのようだ。i810やi845などのインテル系チップセットでは、この対策をしないと無事に起動しないらしい。
----
-バージョン3（バージョン1やバージョン2の変更は破棄してください）
--asmhead.nasへの変更：

（中略）
 
 ; CPUから1MB以上のメモリにアクセスできるように、A20GATEを設定
 
         CALL    waitkbdout
         MOV     AL,0xd1
         OUT     0x64,AL
         CALL    waitkbdout
         MOV     AL,0xdf         ; enable A20
         OUT     0x60,AL
         CALL    waitkbdout
         MOV     AL,0xff         ; ココから
         OUT     0x64,AL
         CALL    waitkbdout      ; ココまで
 
 ; プロテクトモード移行
 
 	    （中略）

--「説明しよう！」
---MonaOSでキーボードコントローラに謎の0xffを送信しているらしいので、真似してみた。しかし効果はなかった。
----
-バージョン2（バージョン1の変更に加えて以下の変更をしたものがバージョン2です）
--asmhead.nasへの変更：

（中略）
 
 waitkbdout:
         MOV     AH,255          ; 255回、ポート0x64を空読みして時間稼ぎをする   ココから
 waitkbdout1:
         IN      AL,0x64
         SUB     AH,1
         JNZ     waitkbdout1
 waitkbdout2:
         IN      AL,0x64
         AND     AL,0x02
         IN      AL,0x60         ; から読み(受信バッファが悪さをしないように)
         JNZ     waitkbdout2     ; ANDの結果が0でなければwaitkbdout2へ
         RET                     ;                                              ココまで
 
         （中略）
--「説明しよう！」
---どうもこれは効果がなかった。チップセットの反応が遅すぎたわけではなかった。
----
-バージョン1
--asmhead.nasへの変更：

（中略）
 
 ; CPUから1MB以上のメモリにアクセスできるように、A20GATEを設定
 
         CALL    waitkbdout
         MOV     AL,0xd1
         OUT     0x64,AL
         CALL    waitkbdout
         MOV     AL,0xdf         ; enable A20
         OUT     0x60,AL
         CALL    waitkbdout
 
         MOV     AX,0xffff       ;                                   ココから
         MOV     ES,AX
         MOV     CX,0x1234       ; CH = 0x12; CL = 0x34;
 test_a20:
         MOV     AL,[0]          ; 0x00000000番地の値を読み取っておく
         MOV     [0],CL          ; 0x00000000番地にCLを書き込む
         MOV     [ES:0x0010],CH  ; 0x00100000番地にCHを書き込む
         CMP     [0],CL          ; 0x00000000番地の値とCLを比較
         MOV     [0],AL          ; 0x00000000番地の値をもとにもどす
         JNE     test_a20        ;                                   ココまで
 
 ; プロテクトモード移行
 
 	    （中略）
--「説明しよう！」
---どうやらキーボードコントローラはCPUに比べて動作が遅いらしく、A20GATE信号を設定してもすぐには反映されていなかったようだ。そのため、一部のCPUが高速な機種では（もしくはチップセットが遅い機種では）たとえばメモリの0x00123456番地を読み書きしても、0x00023456番地を読み書きしてしまうという問題が起きていたようだ。
---この番地の間違いが起きると、asmhead.nasでのmemcpyがうまくいかないことになる。0x00100000番地にあるはずのディスクデータがなかったり、もしくは0x0010c200番地に書いたつもりが実は0x0000c200番地に書いていた、なんてことになる。特に後者は深刻で、asmhead.binが0x0000c200番地以降にあるので、これを上書きしてしまうとまさに自殺になってしまい、謎のデータを実行することになってしまう。
---tanakaさんの報告でDSKCACの値を変えたら動いたというのは、まさにこれなんじゃないかと思う。それでこの修正を思いついたわけだ。・・・（少なくとも一部の機種においては）この予想が的中したみたいなのでよかった。
---しかし他の機種ではハングアップ問題が発生。このパッチはどうも使えないようだ。

*** こめんと欄
-ひよひよさんによる報告。 http://hiyos.info/HiyOS/20060430.htm さしたる根拠はないが、[[K]]はダブルフォールト（やトリプルフォールト）が直接の原因ではないと思っている（間接的な原因である可能性はありうる）。 -- [[K]] SIZE(10){2006-07-20 (木) 17:37:11}
-私の持っているパソコンのうちの１台で動作しなかったので報告させていただきます。動作しなかったパソコンは、CPU:Pentium3 500MHz、チップセット:Intel 82810と結構古いパソコンです。私の場合は、asmhead.nasのmemcpyを３回目に実行する時点でパソコンが再起動してしまいます。 -- ''qwert'' SIZE(10){2006-07-21 (金) 02:48:54}
-qwertさんへ。情報ありがとうございます。 -- [[K]] SIZE(10){2006-07-21 (金) 17:59:35}
-うちのGateway GT4012j(Athlon64x2、nForce410)でもCDブートさせるとすぐにリセットがかかります。簡単ですが報告まで。 -- 名無しさん SIZE(10){2006-07-23 (日) 13:56:02}
-ご報告ありがとうございます。 -- [[K]] SIZE(10){2006-07-23 (日) 17:10:37}
-ほんをかったんですけど、動かなかったので本捨てちゃいました。 たしか家の殆どのPCで動かなかったと思います。 hrbのFDイメージか何か無いですかね？ i810のマシンもあるんで動作の報告はできると思います -- 名無しさん SIZE(10){2006-07-24 (月) 03:49:06}
-それはもったいない。捨てる前にここで聞いたらよかったですね。ディスクイメージは http://hrb.osask.jp/ にいろいろありますよ？ -- 名無しさん SIZE(10){2006-07-24 (月) 07:43:26}
-asmhead.nas 5行目 : DSKCAC EQU 0x00100000 -> DSKCAC EQU 0x00180000で動きました！！(Pentium4 1.8G/asusP4B266/radeon8500)報告まで。寝ます！ -- ''tanaka'' SIZE(10){2006-07-30 (日) 13:00:22}
-tanakaさんの情報が正しいと仮定すると、CPUの動作が速すぎてA20GATE信号線の切り替わりが間に合っていない可能性が考えられますね。今日中にテスト用の対策コードを準備しますので少しお待ちください。 -- [[K]] SIZE(10){2006-07-30 (日) 14:23:24}
-とりあえず適当に作ってみました（バージョン1）。興味のある方は実機テストをどうぞ。 -- ''K'' SIZE(10){2006-07-30 (日) 16:28:55}
-ひよひよさんのブログ（ http://hiyos.info/HiyOS/20060730.htm ）によると、この対策コードは効果があったそうです。これで他の機種でも問題が解決するかどうかは分かりませんが、とにかく一歩前進です！tanakaさん、ひよひよさん、ありがとうございました。 -- ''K'' SIZE(10){2006-07-30 (日) 23:57:41}
-↑えぇ～と、今まさに検証中なのですが、HiyOSに組み込んだ分にはうまく動いたのですが、はりぼてOSについて harib27f と harib03e に適用して試したところ真っ暗画面のままでした。asmhead.nas については HiyOS も harib27f も全く同じなので、どこで問題が発生しているかを見極める必要がありそうです。でも、今日のところはおやすみなさい。。。すいません。 -- ひよひよ SIZE(10){2006-07-31 (月) 00:11:26}
-qwertさんのi810機でもこの修正で改善する可能性がありそうです。 -- [[K]] SIZE(10){2006-07-31 (月) 00:26:59}
-実験してみたので報告します。このコードをasmhead.nasに追加してみたところ、再起動はしなくなりましたが　jne test_a20　のループを抜けられないようです。A20GATEに問題があるのかどうか私にはわかりませんが、メモリのアドレス指定に問題があるのは間違いないようです。 -- ''qwert'' SIZE(10){2006-07-31 (月) 23:16:14}
-GT4012jで報告した者です。ひよひよさんと同じようにharib27fにパッチを当ててみましたが、リセットする現象は直りませんでした。() -- 名無しさん SIZE(10){2006-07-31 (月) 23:35:06}
-私もパッチを当ててみましたが動かなくなりましたorz。メモリアドレス0x00100000付近に原因があるのではないかと推測。調べを入れてみたいと思います！（手動バイナリサーチ） -- ''tanaka'' SIZE(10){2006-08-01 (火) 09:18:34}
-手動バイナリサーチ結果報告です。0x00108000以上正常動作。0x00107ffff以下異常動作。以上の結果から、メモリマップ以外の所にも何か入ってるみたいです。 -- ''tanaka'' SIZE(10){2006-08-01 (火) 10:16:18}
-みなさん実験と報告をありがとうございます。パッチを入れたら黒い画面のまま動かなくなる症状が多数報告されていますが、これはA20GATEの設定そのものに失敗しているせいではないかと思います。さてどうしましょうか。しばらく新対策を考えます。 -- [[K]] SIZE(10){2006-08-01 (火) 12:50:46}
-とりあえず思いつきで一つ作りました。waitkbdoutの処理を書き足してみることにしました（バージョン2）。さて効果はあるでしょうか。興味のある方は実機テストをどうぞ。 -- ''K'' SIZE(10){2006-08-01 (火) 13:09:38}
-バージョン１とバージョン２を両方適用して試してみましたが、真っ暗のままでした。。。環境によって現象が異なるみたいですねぇ。 -- ''ひよひよ'' SIZE(10){2006-08-01 (火) 23:07:40}
-またまた4012jで実験してみました。◇バージョン1+2でもリセットしてしまいました。◇DSKCAC EQU 0x00180000もやってみましたが効果ありませんでした。◇マシン環境に自信が無くなったので「HiyOS 0.0.5.20060730」を試させて頂いたのですが、こちらは正常に起動しました。(マシン環境は無罪かな・・?) -- ''4012j'' SIZE(10){2006-08-01 (火) 23:41:28}
-バージョン2は的外れだったのかなあ。 -- [[K]] SIZE(10){2006-08-01 (火) 23:52:10}
-a20gateは的はずれではないようです。mona2のコード入れたら動きましたｗ。参考http://tkralia.hp.infoseek.co.jp/mona/mona1017/secondboot.html -- ''tanaka'' SIZE(10){2006-08-02 (水) 18:50:07}
-GT4012jでリセットすると言っている者ですが、原因に思い当たりました！BIOSでUSBキーボードやマウスをPS/2にエミュレーションする機能が有効になっていると問題が起きるようです。 -- ''4012j'' SIZE(10){2006-08-02 (水) 20:43:53}
-昨日HiyOSを実行したとき、USBマウスでカーソルが動かせたので気づいたのですが、GT4012jは(多分)デフォルトでエミュレーション機能が有効なようです。※残念ながらBIOSメニューに設定項目が無く検証はできていません。 -- ''4012j'' SIZE(10){2006-08-02 (水) 20:44:32}
-ですが、もともとはりぼてOSが動いていた別のマシンで裏づけを取りました。BIOSにUSB Keybord Support／USB Mouse Supportという項目がありデフォルトは両方Disabledだったのを、Keybordの方だけEnabledにしたところ　・無印はりぼてOSはリセット死　・バージョン1は黒画面で固まる　という風になりました。(Mouseの方はどっちでも起動しました) -- ''4012j'' SIZE(10){2006-08-02 (水) 20:45:01}
-連投失礼しました。なんだか微妙な原因で申し訳ないです。。参考(関係ありそう?)：http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/i386/usb-legacy-support.txt.html -- ''4012j'' SIZE(10){2006-08-02 (水) 20:46:36}
-tanakaさんの報告によると、どうやらMonaではA20GATEの設定直後に謎の設定をしているようです。ということで、それを真似してみようと思います。しばらくお待ちください。 -- [[K]] SIZE(10){2006-08-02 (水) 22:08:53}
-今週中には解決しそうですね。しばらく待ってます。（他力本願中） -- ''ひよひよ'' SIZE(10){2006-08-02 (水) 22:17:10}
-準備しました。バージョン3です。さて無事に改善するでしょうか。興味のある方は実機テストをどうぞ。 -- [[K]] SIZE(10){2006-08-02 (水) 22:18:30}
-4012jさんの指摘は今回の問題に関係があるかどうかまだ判断が付かないので、バージョン3の効果を確かめてから考えます。 -- ''K'' SIZE(10){2006-08-02 (水) 22:20:44}
-harib27fにバージョン３を適用しましたが、真っ黒画面のまま止まってしまいました。（前回同様） -- ''ひよひよ'' SIZE(10){2006-08-02 (水) 22:46:25}
-harib27f＋バージョン3でも、リセットしてしまいました。 -- ''4012j'' SIZE(10){2006-08-03 (木) 08:24:45}
-やっと原因が判明か！？waitkbdoutのIN AL,0x60が悪かったみたいです。コメントアウトしたところ、パッチなしでも起動に成功しました。 -- ''tanaka'' SIZE(10){2006-08-03 (木) 09:21:33}
-なんとすばらしい着眼点！・・・さっそくこれを公式パッチ候補としてまとめることにします。 -- [[K]] SIZE(10){2006-08-03 (木) 10:50:14}
-まとめました。バージョン4です。こんなわずかな修正で動くようになったらいいなあ。 -- ''K'' SIZE(10){2006-08-03 (木) 11:07:34}
-バージョン4試しました。Athlon64x2マシンではまたリセットしてしまいました。。でもサブマシンではBIOSでUSB Keybord SupportをEnableにしても起動するようになりました！ -- ''4012j'' SIZE(10){2006-08-03 (木) 21:44:02}
-バージョン４で正常に動作しました。 -- ''qwert'' SIZE(10){2006-08-03 (木) 22:18:16}
-みなさんありがとうございます。バージョン4とバージョン1とを組み合わせたらいいのかなあ。もうちょっと考えてみます。 -- [[K]] SIZE(10){2006-08-03 (木) 23:14:21}
-bootpack.cでひよひよさんの真似してio_sti()の位置を変えたらAthlon64x2マシンで動きました！もっと早く試してればよかったですね。ホントスミマセン。ちなみにバージョン4の変更はあっても無くても起動しました。実機で動かせるようになって嬉しいです！！ -- ''4012j'' SIZE(10){2006-08-03 (木) 23:24:17}
-HiyOS と harib27f で何処が違うんだろうと思っていたのですが、io_sti() の位置が違いましたか・・・（自分でやったはずなのに忘れてました。） -- ''ひよひよ'' SIZE(10){2006-08-03 (木) 23:26:48}
-http://hiyos.info/HariboteOS/20060804.htm にバージョン１＆４の適用＋bootpack.c 内の io_sti() 呼び出し位置を変更した harib27f 改造版をアップしておきました。あともう少しで解決ですかね？？？ -- ''ひよひよ'' SIZE(10){2006-08-04 (金) 02:05:36}
-ご報告ありがとうございます。そしてバージョン5を作りました。バージョン1は多分なくてもOKな気がしてきたので、バージョン5には含まれていません。io_sti();の位置を変えればいいというのはたいへん有効そうですが、なぜ変えたら直るのかの合理的な説明が必要だと僕は感じたので、バージョン5はひよひよさんの変更とは少し違っています。興味のある方は実機テストをどうぞ。 -- [[K]] SIZE(10){2006-08-04 (金) 12:24:30}
-うちのAthlon64x2環境ではバージョン5でもリブートしてしまいました。なんともデリケートですね。 -- ''4012j'' SIZE(10){2006-08-04 (金) 22:06:44}
-ご報告ありがとうございます。そうなると init_pit(); か init_keyboard(&fifo, 256); か enable_mouse(&fifo, 512, &mdec); のどれか（もしくはすべて？）においても、CLI中にやらなければいけないということなんでしょうねえ。デリケートですねえ。 -- [[K]] SIZE(10){2006-08-05 (土) 00:53:31}
-http://hiyos.info/HariboteOS/20060806.htm にバージョン５を適用＋ bootpack.c 内の io_sti() 呼び出し位置を変更した harib27f 改造版をアップしておきました。色々試してみたのですが、io_cli(); を init_pit(); の前に持ってきても真っ暗画面で止まってしまったので、結局 io_cli(); は諦めました。 -- ''ひよひよ'' SIZE(10){2006-08-06 (日) 22:53:21}
-ご報告ありがとうございます。でもその結論はどうも受け入れられないので、とことんやるしかないかなと観念中です。・・・僕としては不本意なのですが、もうこうなったら1台買ってしまおうかなと（新品でも5万円台で買えるみたいなので・・・OSはいりませんしね）。 -- [[K]] SIZE(10){2006-08-07 (月) 00:35:15}
-私も CrystalCPUID の開発のために何台か買っていますし、ハードウェア依存プログラム開発者の宿命かと。実機がないとデバッグしようがありませんからね。。。 -- ''ひよひよ'' SIZE(10){2006-08-07 (月) 07:56:38}
-役に立つか分かりませんが、私もAthlon64x2マシンで更に調べてみました。[A]元々あるIDT/PIC後のio_sti()／[B]init_pit()の前の行にio_cti()挿入／[C]io_out8(PIC1_IMR, 0xef)の次行にio_sti()挿入／[D]for (;;)の前行にio_sti()挿入………としたとき、＜有効化:[D] コメントアウト:[A][B][C]では起動＞＜有効:[A][B][C] コメ:[D] はリセット＞＜有効:[C] コメ:[A][B][D] はリセット＞＜有効:[A][B][D] コメ:[C] はリセット＞という結果になりました。やはりIDT/PICの初期化をした後、[D]あたりでSTIするまで、一度も割り込み許可状態にしてはいけないみたいです。(↑で紹介されている、fifo32_init()の後でSTIするパターンはまだ試しておりませんでした) -- ''4012j'' SIZE(10){2006-08-07 (月) 23:54:28}
-わざわざ細かいテストをしてくださった上にご報告までしていただきありがとうございました。自力解析の際の足ががりとさせていただきます。 -- [[K]] SIZE(10){2006-08-08 (火) 00:13:13}
-追加しました。[E]fifo32_init(&keycmd, 32, keycmd_buf, 0);の後ろにio_sti()追加／＜有効:[E] コメ:[A][B][C][D] はリセット＞／以上、追加試験してみましたが、なんとうちの環境ではリセットしました。また、ひよひよさん作の harib27f_plus2 でもリセットしてしまいました。マシンごとに微妙に割り込み禁止必須範囲が違うんでしょうか。。 -- ''4012j'' SIZE(10){2006-08-08 (火) 00:22:24}
-4012j さんの環境では、harib27f_plus2 は動きませんでしたか・・・。ホント微妙ですねぇ。 -- ひよひよ SIZE(10){2006-08-08 (火) 00:46:46}
-Version5のbootpack.cの方で最後に一回のみstiすればいいのではないですか？ -- ''Alpha'' SIZE(10){2006-08-08 (火) 09:47:03}
-流れをよく読んでほしいのですが、Alphaさんに指摘されるまでもなく、どうすればいいのかという件についてはひよひよさんと4012jさんのおかげでほとんど分かっています。問題は「なぜそうでなければいけないか」なのです。そのヒントをつかむために、たくさん実験していただいているのです。 -- [[K]] SIZE(10){2006-08-08 (火) 10:19:50}
-OSASK wikiのひとりごと欄を拝見して、OSASK/AT ver.4.7(CD-R用)を起動させてみたところ、Athlon64x2マシンでも無事起動してしまいました。一応ご報告します。。 -- ''4012j'' SIZE(10){2006-08-08 (火) 22:40:06}
-ついに原因＆対処法完全判明！（実機でたくさん実験してきました）。・・・でも疲れてしまったので、詳細は明日かあさってに書きます。 -- [[K]] SIZE(10){2006-08-29 (火) 18:35:46}
-書き足しました。上記のバージョン6です。 -- ''K'' SIZE(10){2006-08-30 (水) 22:23:30}
-うーん、僕としては今回のバージョン6には相当な自信を持っていますが、しかし誰からも何の報告もないと不安になります。テストしてみたかたは、うまくいった、うまくいかなかったなどの報告をこちらにいただけると幸いです。 -- ''K'' SIZE(10){2006-09-03 (日) 01:14:59}
-バージョン6 Athlon 64 X2 + nForce4 でバッチリ動きました～！！ -- ''ひよひよ'' SIZE(10){2006-09-03 (日) 09:15:39}
-http://hiyos.info/HariboteOS/20060903.htm にバージョン６を適用したharib27f改造版をアップしておきました。 -- ''ひよひよ'' SIZE(10){2006-09-03 (日) 09:26:35}
-ご無沙汰しております。久々に覗いたら更新されていて目んたま飛び出ました(汗 前置きはさておき、早速試して無事起動することを確認できました！！本当に対応有難うございます。チップセット(?)共通の理由があったと分かってすっきりしました。 -- ''4012j'' SIZE(10){2006-09-22 (金) 22:13:04}
-バージョン3について、Minixソースによると0xffを送っているのはパルス出力をしているとのことだそうです -- ''azarakko'' SIZE(10){2007-02-23 (金) 22:44:09}
-すいません。もう必要なかったらいいのですが「Core 2 Duo 6600（2.40Ghz）」でチップセット「P965SS」だとはりぼてOS完成版にパッチを当てなくても動きました。 -- ''T'' SIZE(10){2007-04-06 (金) 18:34:34}
-有識者の方に質問があります。現在、最終的な対応のひとつであるバージョン4では「IN AL,0x60」を削除することしています。なぜ削除する必要があるかは解説部分に記述されているため理解できます。でも、自作本の執筆当初は、Kさんはこの記述が必要であると考えられていたかと思います。そこで、以下の2つの質問があります。(1)削除することによって、当初の目的は果たせなくなっていると思いますが、その場合に問題になることはないのでしょうか？(2)そもそも、マウスの初期化では必要ないのに、なぜ、ここ(A20GATE 信号線の有効化)では必要だったのでしょうか？ -- ''mamezo'' SIZE(10){2007-10-30 (火) 12:32:51}
-自分なりに考えてみました。(1)多少キーバッファがあっても、CPUのモードが変わっても取得するキーコードは変わらないし、32ビットモード移行後にHariMainが受けてくれるので問題ない。そもそも、本コードが実行される時点でキーバッファがたまっている可能性は低い。どうしても心配ならば、入力バッファがあるかどうかをKBCのステータスレジスタから自分で調べて、対応する。(2)マウスを初期化するときにキー入力のバッファを消す必要はないが(キーボードのことを考えると消してはだめ)、A20GATE信号線の有効化するときは、32ビットモードへの移行も控えており、16ビットモード時に入力されたキーはクリアしたほうがいい(取得するキーコードはCPUのモードが変わっても変わらないが意図しない入力バッファはなるべく排除しておいたほうがいいので)。 -- ''mamezo'' SIZE(10){2007-10-30 (火) 12:33:25}
-振り返ると、(1)と(2)に矛盾があるように感じたので質問した次第です。どうぞよろしくお願いします。 -- ''mamezo'' SIZE(10){2007-10-30 (火) 12:33:49}
-回答いたします。かなりよく考えられた質問だと思います。KBCのキーバッファをクリアしたい最大の理由は、PICを初期化することに関係があります。PICを初期化してしまうと、かりにそのときまでに未処理のIRQ1があったとしても、もう分からなくなってしまいます。キーバッファには未受信のデータが残ることになります。この状態で32bitモードになり、さらにユーザがキーを入力したとしても、普通は割り込みが起きないと思います。これを克服するには、PICの初期化後にKBCもリセットするか、もしくはmamezoさんのやり方でキーバッファが空になるまで空読みすることになると思います。 -- [[K]] SIZE(10){2007-10-30 (火) 18:56:47}
-またA20GATE信号線制御に関しては、本来ならこの設定をやる前にKBCに対してキーボード無効コマンドを送り（マウス有効の逆をキーボードに対して行う）、キー入力があっても混乱しないようにするのが本来のやり方かもしれないという懸念もありました（そうやっているOSもある）。しかしこれだとA20GATEの設定が終わった後にまた有効化コマンドを送らなければならず、本の説明が長くてややこしくなるだけかもしれないと思い、カットしてしまいました。実際これが問題になることは無いようなので、これでよかったのかもしれません。・・・その代わりに暇なときに空読みさせて気休めにしていた次第です。 -- ''K'' SIZE(10){2007-10-30 (火) 19:05:21}
-マウス有効化の際は、PICのリセットをする必要は無いので、キーバッファはそのままにしています。・・・ここからは余談です。PICの初期化時に保留していたIRQが分からなくなってしまうという問題は、PICというチップがバカだからなのではなく、PICに対する設定が「エッジトリガ」だからいけないのです。しかしIBMのおじさんはAT互換機を設計するときにエッジトリガじゃないとうまく動作しなくなるようなずさんな回路を引きました。・・・KBCのリセットに関しても余談があります。KBCのリセット方法はチップセットなどによって細かな差異があるらしく、実は私自身が確実な方法（＝どのチップセットでもうまくいく方法）をまだ把握していません。なかなかややこしそうです。 -- ''K'' SIZE(10){2007-10-30 (火) 19:16:50}
-質問範囲の「問題点」だけでなく、対処案やプラスアルファのご指導まで、詳細なご説明ありがとうございます。昨日から回答を何度も読み直して、かなり、もやもやが解消できました。合わせて、さらなるいくつかの疑問点、確認してみる必要がある点がでてきましたが、もう少しじっくり考えてみます！ -- ''mamezo'' SIZE(10){2007-10-31 (水) 21:56:29}
//-<a href= http://index2.bal-bes.ru >跪&#65533;瑩蠇 硅珮琺蔔 &#65533;鴈竦瑣蓙</a> <a href= http://index1.bal-bes.ru >藁侏 蚤菁 厥責折  藁亙?/a> <a href= http://www.bal-bes.ru >c繩 &#65533;鴈  蓁矗謌籥跏</a>  -- ''jack3_bz'' SIZE(10){2009-06-15 (月) 19:40:38}
-''バージョン3''でMonaOSがKBCに謎の0xffを送信していると書いてありますが、32ビットモードで送信するとPCが再起動するそうです(詳しい仕様は知らない(爆))。 -- [[Triangle_Ld.]] SIZE(10){2009-08-21 (金) 10:18:24}
-おしいですね。再起動なら正解は0xfeでした。これはCPUのモードに限らず、キーボードコントローラを使ってCPUにリセット信号を送る方法です。・・・ということでMonaOSの挙動は謎です。 -- [[K]] SIZE(10){2009-08-21 (金) 16:29:09}
-0xfeですか。くそぅ、1違い... -- ''Triangle Ld.'' SIZE(10){2009-08-21 (金) 20:07:19}
-OADGのリファレンスによると、KBCの出力ポートに6μsのパルスを発生させる（ビット0がリセット信号に接続されているので、0xfeで再起動）らしいです。0xff の場合はパルスをどこにも出さないので、ウェイトとして使っているのかも。 -- 名無しさん SIZE(10){2009-08-23 (日) 20:27:11}
-自分のNoize Ld.で、C言語を導入したら再起動した問題は、ここのバージョン4のパッチを当てることで見事に起動しました。自分のPCの仕様書にはAthlon64X2機であるかとか、チップセットがi810かnForceかということが書いてなかったので、どのバージョンを当てればよいのか少し迷いましたが。 -- ''Triangle Ld.'' SIZE(10){2010-01-06 (水) 10:15:54}
-本文に間違いを発見しました。バージョン5「...から考えてみると、どうやらAlthon64X2...」=>「...から考えてみると、どうやらAthlon64X2...」であると思います。場所はバージョン5の「説明しよう!」のところです。 -- ''Triangle Ld.'' SIZE(10){2010-01-07 (木) 09:41:30}
-すごいですね -- ''ｗｗｗ'' SIZE(10){2011-03-08 (火) 15:32:02}
-すごいですね -- ''ｗｗｗ'' SIZE(10){2011-03-08 (火) 15:32:04}
-すごいですね -- ''ｗｗｗ'' SIZE(10){2011-03-08 (火) 15:32:26}
-すごいですね -- ''ｗｗｗ'' SIZE(10){2011-03-08 (火) 15:32:30}

#comment

タイムスタンプを変更しない

#comment

テキスト整形のルールを表示する