MikanOSのUSBドライバは現時点でUSBハブに対応していない。

物理端子としてルートハブポートが露出している機種ならうまく動くが，そうでない機種もあるようだ。 例えばAcer Aspire E1-572-A54Dという機種はxHCIを積んでいるが，ルートハブポートは直接は露出しておらず， ノートパソコン内蔵のUSBハブを経由する構造になってしまっている。

そのような機種でMikanOSを使うためにはUSBハブに対応する必要がある。

小さい問題ですが、ExitBootServicesのあとはSystemTable->ConOutがNULLになるっぽいです。(原文:On success, several fields of the EFI System Table should be set to NULL. These include ConsoleInHandle, ConIn, ConsoleOutHandle, ConOut, StandardErrorHandle, StdErr, and BootServicesTable. 221ページ 4行目) そのため https://github.com/uchan-nos/mikanos/blob/59251b6d0eb76f6e21b164cae91eb28cdad55a8e/MikanLoaderPkg/Main.c#L434 の部分のPrintは表示されません。 ExitBootServicesより先に実行させたほうがいいかと思われます。

簡易テキストエディタアプリケーション tedit を追加します。

• 編集するファイル名をコマンドラインで指定して起動する
  • ファイル名を指定しなくても起動はできるが、保存はできなくなる
• Ctrl+S で上書き保存
• 編集後保存せずに閉じようとすると、確認ダイアログを表示する
  • マウス左クリックまたはAlt+(選択肢の頭文字)で選択

(例えば)以下には対応していません。

• 別名保存
• テキストのコピペ
• 検索・置換
• 横スクロール

std::vector でメモリを確保して fwrite でファイルに出力するアプリケーションを作りました。

https://github.com/mikecat/mikanos/blob/a3bd848bd27b9be017a028e15b29040ab89fa757/apps/fwrite/fwrite.cpp

これである程度の大きさのファイルを作り、その内容をcatで出力しようとすると、動作が止まりました。

この機能によるメリット

UEFIで遊ぶ余地ができる他、ブートプロセスで行っているメモリマップ取得をブートメニュー上に移植を行えば、メモリマップ取得を任意で行うことができるようになる可能性。RuntimeServiceの機能を使えば、そこからシャットダウン、再起動を行うことができる可能性が出て来ると考えています。

詳細

機能

現在MikanOSブートメニューとUEFIのサポート情報などを表示する画面を実装してあります。対応する数字のキーを押すことでメニューの機能が実行されます。

ロゴに関して

ジェネレーターなどを使うとライセンスなどの影響が出ることを考慮し、テキストエディタで自作しました。

右下の余白に関して

ここにはMikanOSのアイコンなどを作成し、おけると思い隙間を作っております。

watchdogタイマの無効化

bootmenuを表示する関数内で無効化を行っています。

fix #39

以下のコマンドにおいて、長さがわかっているデータの出力に PrintToFD 関数を使わないようにします。

• cat
• usbtest

これにより、以下の効果が得られます。

• PrintToFD 関数の脆弱性 (vsprintf 関数によるバッファオーバーラン) の影響を受けず、長いデータを出力できる
• 値 0x00 のバイトを含むデータでも出力できる

マンデルブロ集合描画アプリ mandel

mandel コマンドでマンデルブロ集合が描画されたウィンドウを表示するだけのアプリです。

マンデルブロ集合は、計算の規則自体はシンプルであるにも関わらず視覚的に楽しい数学的対象の一例です。そのため、本アプリは規模としては小さいながらもシンプルに美しいという良さがあります。

また、このアプリは「ゼロからのOS自作入門」における22章終了時点までのMikanOSの機能で動作します。同書籍の学習者が学習中に自作アプリを作るときのヒントになる可能性もあります。

how-to-send-pull-request.mdに下記の記載がありましたので、プルリクで画像をお送りいたします。 画像サイズはスクリーンショットのままですので、適宜、変更いただければと思います。

「どなたか、mikanos リポジトリに関して本記事の手順を実行し、スクリーンショットを提供していただけませんか？」

表題の通り、細かな修正を含んでいます。 それぞれ個別の pull req を作成した方が良いということでしたら分割しますのでお申し付けください。

printf-like 関数については、 __attribute__((format(printf, ..))) によりコンパイル時に誤りを検出できるようにしています。 非標準機能ですが本書では clang/clang++ 8+ を利用することを前提としているため利用して問題ないと考えました。

実行環境

• Ubuntu 20.04

生じた問題

day03_b の写経をしていたところ、ビルドしたときに

/home/yudai/edk2/MikanLoaderPkg/Main.c:150:3: error: implicit declaration of function 'FreePool' is i
nvalid in C99 [-Werror,-Wimplicit-function-declaration]                                              
  FreePool(gop_handles);                                                                             
  ^                                                                                                  
1 error generated.    

というエラーが生じてビルドできませんでした。これはosbook_day03_b タグの Main.c 内の

https://github.com/uchan-nos/mikanos/blob/3d021f27e474ceb1d3f15b0185955b5d67ff7be0/MikanLoaderPkg/Main.c#L131

で生じていました。

解決方法

とりあえず、私の環境では該当部分を

gBS->FreePool(gop_handles);

に変更したことでビルドは通り、QEMU で実行したときの挙動も書籍のようになったのですが、この対処法は正しいでしょうか？

MikanOSのビルドはLLVM 7（llvm-7, lld-7, clang-7）で動作確認しているが， ふとした思いでtviewアプリをLLVM 10でビルドしたらカーネル側でページフォルトが起きることが分かった。

カーネルをLLVM 7，tviewをLLVM 10でビルドし，QEMUで起動させ，tview jpn.txt を実行するとページフォルトが発生する。例外時の RIP は 0x14efb4 であった。その周辺の逆アセンブル結果は次。

  14efac:       4c 8b 6e 70             mov    r13,QWORD PTR [rsi+0x70]
  14efb0:       4c 8b 76 78             mov    r14,QWORD PTR [rsi+0x78]
  14efb4:       48 0f c3 47 40          movnti QWORD PTR [rdi+0x40],rax
  14efb9:       4c 0f c3 47 48          movnti QWORD PTR [rdi+0x48],r8
  14efbe:       4c 0f c3 4f 50          movnti QWORD PTR [rdi+0x50],r9

例外が起きたのは movnti 命令。例外が起きたときのスクリーンショットは下図。

Bmax B2S での検証において、port_reset_change が1の状態で ResetPort() を実行すると、 PortStatusChangeEvent が発生せず、初期化プロセスが止まってしまうことがありました。 この事象が発生すると、addressing_port による制御の影響で他のデバイスの初期化もできなくなってしまいます。

そこで、Port::Reset() において port_reset_change もクリアすることで、 PortStatusChangeEvent が発生するようにし、この事象を回避するようにしました。

修正前 (事象の影響でUSBの初期化が止まり、挿している起動用のUSBメモリを認識できていない)

修正後 (事象を回避し、起動用のUSBメモリを認識できている)

実機での動作検証において、新しいファイルに書き込む際に #PF が出て動作が止まる現象が発生しました。

検証の結果、この時クラスタ 0xffff0000 に書き込もうとしていることがわかりました。 これは、削除済みエントリに first_cluster_high に 0xffff が書き込まれているものが存在し、これを初期化せずに利用するため FirstCluster() の上位が 0xffff になることが原因であると考えられます。

よって、ファイルの作成時に確保したディレクトリエントリをゼロクリアすることで、意図しないクラスタに書き込まないようにします。

USB CDCの挙動を改善し、 usbtest コマンドで公式のArduino UNOのUSB-シリアル変換を通じたシリアル通信ができるようにします。

void setup() {
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
  Serial.begin(9600);
}

bool isHigh = false;

void loop() {
  int c = Serial.read();
  if (c >= 0) {
    Serial.write((c + 1) % 256);
    isHigh = !isHigh;
    digitalWrite(13, isHigh ? HIGH : LOW);
  }
}

• ~~ConfigurationDescriptorReader::Next() が次のディスクリプタではなく今のディスクリプタを返すようにします。~~
  • ~~変更前は、コンフィグレーションディスクリプタが読み飛ばされていました。~~
    ~~ここにはインターフェイスディスクリプタの個数などがあり、将来役立つかもしれません。~~
• 3引数の NewClassDriver() において、エンドポイントディスクリプタのみをエンドポイントとして数えるようにします。
  • ファンクショナルディスクリプタを数えないようにし、エンドポイントディスクリプタを規定数読み込んでからループを抜けるようにします。
    確実にエンドポイントの情報を得られるようになり、またファンクショナルディスクリプタの情報も得られるようになります。
• CDCDriver::SetLineCoding() において、 if_data ではなく if_comm の interface_number を用いるようにします。
  • Bmax B2Sと公式のArduino UNOの組み合わせにおいて、 setup_data.index に 1 を入れるとStall Errorとなってしまいましたが、 0 を入れるとうまく動きそうでした。
    if_comm の interface_number が 0 で辻褄が合うので、採用しました。
    本当に適切かはわかりません。
• 初期化時に通信設定を取得し、ボーレートが0の場合は適当に設定を行うようにします。
  • 初期状態ではシリアル通信が動作しませんでしたが、 setbaud コマンドを実行すると動作するようになりました。
    パケットキャプチャの結果を見ると、最初はGET LINE CODINGの結果が全て0となっていました。
    そこで、初期化時に通信設定を取得し、ボーレートが0の場合は設定を行うようにすることで、明示的に setbaud コマンドを実行しなくても9600bpsで通信できるようにしました。
• 受信を送信とは独立に行い、受信完了時に次の受信を行うようにします。
  • 変更前は、送信時に受信も1回行うようになっていました。
    送信しないと受信できないというのは不自然だと考え、MikanOSがHIDではどのように受信しているのかを調べたところ、受信完了時に次の受信を行っているようでした。
    そこで、CDCでも同様に受信完了時に次の受信を行うようにしました。
• usbtest コマンドが、送信した長さ分受信するまで受信するようにします。
  • 受信完了のログを出力するとうまく動くようでしたが、ログを出力しないと数文字しか受信できませんでした。
    これは、変更前の usbtest コマンドは正の長さのデータを1回受信できたら受信を打ち切る仕様になっているためであると考えられます。
    さらに、次の usbtest コマンドの実行時に前の usbtest コマンドで受信したかったデータが読み込まれ、不自然な挙動となりました。
    そこで、送信した長さ分受信するまで受信する仕様にすることで、これを改善しました。

この修正前は、以下の問題が発生していました。

• hex2bin において、6バイトのファイルの16進ダンプが出力されない
• hex2bin において、 61 62 63 をバイナリに変換した結果が0バイトになる
• cp において、NIGHT.BMP が最後までコピーできない
• grep、sort、more において、改行文字が無い1行のファイルを入力すると結果が出力されない

これらは、最後に改行を出力しないため、内部のバッファに入ったままのデータを出力しないままアプリケーションが終了してしまうためであると考えられます。 main() 関数から戻った後、 SyscallExit() のかわりに exit() を用いて終了することで、改善するようです。