先に見せるとこんな感じ

フォントの描画をできるようにする前に前回のブログで話した
カーネル空間とユーザー空間の分離について解説しよう

最初にカーネル空間とユーザー空間は何なのかについて解説する
まずはカーネル空間について解説する
カーネル空間が行う処理はこんな感じだ

• メモリ管理(どのプロセスがどの領域を使うかを割り当て、不要になった領域を解放する)
• プロセス管理(複数のプログラムが同時に動けるようにスケジューリングを行う)
• ドライバ管理(キーボードやディスクなどをアプリで使えるようにする)

• アプリが動作する領域
• プログラムは直接ハードウェアにアクセスできないのでシステムコールなどを使用する
• セキュリティや安定性のため制限が掛かっている

この画面はUIの開発と何らかの理由でデスクトップ画面の背景が映せない場合のみに代わりとなる背景だ

この本を使って背景カラーの色を選んだ
色は江戸切子だ

これでユーザー空間側での画面描画の処理とUIを作る準備は終了

今は設計もPCなどでできるが私は紙で行った方が考えが浮かびやすい

 

フォントの描画つまり文字表示で問題になるのが多言語化だ

 

これは設計図にもある通り各言語(β版では主にメジャー)の.langファイルを使用して多言語化を行う

自作OSの多言語化は最初にテストで10言語で「こんにちは 世界」と表示できるようにする

まずは.langファイルの作成だ
写真にあるようにスプレッドシートで各言語を書き、JSONファイルに変換、
その後Pythonを使用してJSONファイルを読み込ませてKey配列を取得し、各言語ごとに.langファイルを作成するようにした

スプレッドシートから.langファイルの変換はこのサイトを利用した
↓

Excelから貼り付けてJSONに変換するツール。入れ子にも対応 | Hep Hep!ExcelデータからJSONに変換するためのツール。エクセル、またはGoogleスプレッドシートでJSON形式に対応したデータをコピーして貼り付けるだけで簡単にJSONデータを作成できる便利ツール。hep.eiz.jp

これでひとまず.langファイルを作成することができた


次は自作OSが言語ファイルを取り扱えるようにした
さっきは言語ファイルを作っただけだからね😅
なので言語ファイルの読み込み、初期化、終了を行えるようにした。
後にかなり面倒なことになるんだけどね😓

ただ、修正した後もやっていることは変わらないので解説していく

まずは、言語ファイルの読み込みだ
これは仮想のファイルシステムから言語ファイルを読み込み、メモリに展開する処理だ。また、言語ファイルにある各言語の翻訳も読み込んでいる
これを行うことによって自作OSが言語ファイルに触れるようになるのだ

次は初期化だ

これは内部テーブルをリセットし、日本語ファイルを読み込む処理だ。
これで自作OSが多言語に対応する感じだ👍
また、今は日本語ファイルを読み込むようにしているが、今後は初期設定で設定された言語を読み込むように変更する

次は終了だ
これは言語ファイルがメモリに展開されているので、リセットしてキャッシュを破棄、次回起動時にクリーンな状態から再読み込みできる処理だ。
これで次に起動するときに前の翻訳された文字などが出なくなるのだ😉

これで言語ファイルを自作OSが取り扱えるようになった

次はフォントの読み込みと描画だ
これも言語ファイルと一緒で後でトラブルが起こるんだけどね😉
フォントはかなり前のブログでNotoSansとNotoSansJPを使うことにしたんだよね

 

『自作OSのフォントを決めて、インストールした話』はい、miku_JK_Jbです今回は私が開発している自作OSのフォントを決めて、インストールした話をしていこう。最近忙しくて、ブログやYoutube動画の作成…ameblo.jp

 

使い分けとしては、日本語はNotoSansJPをそれ以外の言語はNotoSansで分けている
本当は日本語、韓国語、中国語を一緒にしたNotoSansCJKを使いたかったが何故か見つけることができなかったので、NotoSansJPで日本語専門、それ以外の言語はNotoSansと言う使い分けになってしまった。
また、フォントの描画にはFreeTypeを使用する
FreeTypeとは、NotoSans達はビットマップフォントではなく、OTFやTTFフォントだ
それら(OTF、TTFフォント)を読み込んで画面に描画するためのフォントエンジンだ。
MacやiOS、Android、ChromeOSにも使われている。有名な奴だ
ちなみにFreeTypeのラインセンスは2つあってGPLv2とFTLだ。
勿論私はFTLを選択した。

それじゃあフォントの読み込みと描画処理について解説する
まずはフォントの読み込みだ
これは言語ファイルみたいに仮想のファイルシステムからフォントを探して読み込み、メモリ上に展開する。また、フォントは日本語はNotoSansJPをそれ以外の言語はNotoSansをメモリ上に展開する。
これを行うことによって描画するためのフォントの準備が整う👍

次はフォントの描画だ
これは後ほど解説する動的リンカーからFreeTypeを読み込み、UTF-8,16,32をデコードして、描画する。フォントの描画も図形の描画と一緒でバックバッファ(画面の裏)で先に描画し、画面の幅や内部幅が一致したなら描画した物を一気にまとめてコピーし、表示するようにしている
これを行うことで自作OSがフォントを描画することができるのだ😁

次はフォントの各種設定だ
これはサイズの変更、太字、下線、イタリック、取り消し線、簡易的な色覚補正だ。
まあ、フォントの大きさだったり、色だったり、書き方を変更する感じだね
これで様々な文字に対応することができるね🥹

これで自作OSはフォントを描画できるようになるはずだ

ただ、自作OSはFreeTypeを動的リンクで動かしている。
そしてglibcも動的リンクだ。
だからカーネルに動的リンクのライブラリーを読み込ませる必要がある。
そのために動的リンカーを作成した

それじゃあ動的リンカーの処理について解説する

まずはライブラリの管理だ
これは指定されたファイルパスにある共有ライブラリをメモリに読み込み、実行可能にする処理だ。
この処理を行うことで動的ローダーの内部状態を初期化して、ライブラリをロードする準備が整うのだ😁
 

次にライブラリのロード
これは指定されたパスのファイルを読み込み、ファイルサイズを取得してメモリに割り当て、ファイルが有効なELF形式で共有オブジェクトかを検証、ELFのプログラムヘッダーを解析し、ライブラリのロードに必要なメモリ領域を計算・確保し、ファイルの内容をそのメモリ領域にコピー、共有ライブラリを任意のメモリ位置にロードできるようにし、ロードされたライブラリの情報を格納する処理だ。
これでカーネルや他のアプリが、そのライブラリの機能を利用するための基盤が構築されるのだ。

次にシンボルの解決だ
これはロードされたライブラリハンドルとシンボル名を受け取り、ライブラリ内の ダイナミックシンボルテーブルと文字列テーブルを走査。シンボル名が一致した場合、シンボルの値にライブラリのベースアドレスを加えてその関数/データの実アドレスを計算して返す処理だ。
この処理を行うことでアプリは名前ではなくアドレスを通じて、そのライブラリの機能を直接呼び出すことができるようになるのだ。

次にライブラリのアンロード
これは指定されたライブラリハンドルに関連付けられたメモリを解放する処理だ。
この処理を行うことでアプリがライブラリの使用を終了した後も、メモリが効率的に再利用されるようになるのだ。

最後にシステムライブラリのロード
これはOSの動作に不可欠な以下のライブラリをロードし、特定の関数のポインタをグローバル変数に解決する処理だ。
この処理を行うことで標準的なC/C++の機能や、フォント描画などの高度な機能にアクセスできるようになるのだ。

これが動的リンカーの処理と実装だ！！
かなりてんこ盛りな処理でしょ😁
くっそ大変だったわ🤪

これで自作OSがフォントを描画できるようになるはず！！

ってあれ？？
フォントが表示されない...

シリアルログを見てみると

言語ファイルとFreeTypeの読み込みに失敗している！！

原因は？

ブートローダーが受け渡すexFAT情報を使っていなかった
Rootディレクトリを開くことができていなかった(こいつが中々の難敵だった)

ってことで直していこうか

まずはブートローダーの修正だ
これはexFAT の BPB を解析し、FAT/クラスタヒープ/ルートクラスタなどのメタ情報をブートのボリュームに追加。EFIのBlock-IOからボリューム全体をメモリへスナップショットし、その物理アドレスとサイズを格納してカーネルへ渡すようにした
これを行うことによってメタデータ提供: exFATの構造情報をブートボリュームに詰めることでカーネルの構造解析時間を短縮。ディスク全体をスナップショットすることで、ディスクファイルシステムは物理I/Oコードを必要とせず、単なるメモリアクセスとして動作できるになるのだ😁

次に共有ヘッダーの拡張だ
これはブートローダーとカーネルで共通に使う構造体を拡張させた
これを行うことによってブートローダー側とカーネル側の開発を完全に分離でき、構造体を拡張することにより、カーネルとブートローダーの整合性を保証できるのだ

次にRootディレクトリをカーネル側でも開けられるように修正
これはスナップショットメモリを使ってセクタ読み込みを行い、exFAT の FAT チェイン・ディレクトリを解析して Rootディレクトリを開けるようにした。
また、私の自作OSはRootを仮想化しているので、仮想ファイルシステムがインメモリだけでなく、ヒットしなかったパスをディスクファイルシステムに任せる仕組みを作成した
これを行うことによってメモリ上のアドレス指定でセクタの読み書きをエミュレートできるから、非常に高速なファイルアクセスが可能になる。また、Rootの仮想化ができ、インメモリファイルと物理ディスクファイルを統合することができるのだ
これが修正の中で一番大変だった🥺

最後にカーネルで
これはカーネルが起動したら仮想ファイルシステムを起動させてディスクファイルシステムを有効にしてからユーザー空間に移るようにした
これを行うことによってカーネルが起動に必要なファイルを読み込むことが可能になるのだ。

これが行った修正だ！！

これも中々大変だったわ

それじゃあ多言語化が可能になったか見ていこう！！

結果は？

 

あーー🤦

ダメだ

起こっている問題はstart_image() returned Out of Resourcesだね
これはUEFIでメモリ不足が起こっていたり、スタック不足でする際に起こるエラーだ
原因はブートローダーのスナップショットをボリューム全体にしていたのだが

実機検証などで使っているASUS P8Z77-Vのマザボは初期のUEFIを搭載していてメモリマップがかなりシビアなものだから、メモリ不足などが発生してしまい、結果的にstart_jmage() returned Out of Resourcesが出てしまったというわけだ

それじゃあ直していこう！！
修正する場所はブートローダーだ

 

まずはスナップショット数をボリューム全体から1GBにまでサイズをダウンして見た

結果は案の定start_image() returned Out of Resourcesだった

 

それならば極端ではあるがスナップショットのサイズを256MBに下げて見た
 

結果は

FreeType経由でフォントや文字の描画がされていないが起動はした

FreeTypeが動作しない原因はスナップショットを256MBにしたせいでFreeTypeがいる475MBの場所が範囲外であったため
動作がしなかった。うん。みんなは1GBから急に256MBに下げたりしないで段階的に量を減らしていくんだぞ。ダイエットと同じだ

ってことでFreeTypeを動かせるようにするために

スナップショットのサイズを512MBにするのではなく、1GBがダメなら512GB、384MB、256MBにする段階フォールバックを実装した。また、FreeTypeなどが範囲外の場合は仮想ファイルシステムから読み込んで動作させるというバックアップ方式に修正した。これでちゃんとユーザー空間でFreeTypeが動作し、文字の描画などができるようになるはずだ！！

 

結果は

 

動wかwなwいw

あー、うぜ〜

 

でもねフォントの初期化のコードを一時的にコメントアウトして無効化すると

デスクトップの表示はできる
デスクトップUIは前回のブログで書いたけど、実はこのフォント描画や動的リンカーの作成の方が長いのである
時系列バグっててすまんこ

ん？ここでようやく気づいた
FreeTypeに必要なライブラリをリンクしてなくね？FreeTypeちゃんずっと寂しい寂しい🥲ってなってたのでは？と

ってことでFreeTypeが必要としているライブラリを探すと

libpng16.so.16、libz.so.1、libharfbuzz.so.0、libbrotlidec.so.1、libc.so.6を欲しているらしい
今の所ロードしているのはlibcとlibmとFreeTypeなので残りのlibpngとlibzとlibharfbuzzとlibbrotlidecを読み込めばいいね

ってことで修正します💪

 

修正は単純でFreeTypeやglibcなどと一緒でブートローダーのスナップショットの範囲内であればそのまま動的リンカーを使って読み込み、範囲外であれば仮想ファイルシステムから探して動的リンカーを使って呼び出す方式なのでパスを仮想ファイルシステムとブートローダーでカーネルとライブラリを一緒に読み込ませるファイルに設定した
これを行うことにより、スナップショット内にライブラリがあるとディスクI/Oを発生させずに、すでにメモリ上にあるライブラリをそのまま利用することができ、速度が向上する。また、スナップショット内にライブラリが無い場合でも起動直後に必要になったライブラリを仮想ファイルシステム経由で持ってくるので拡張性は損なわない構造になる。
従来のOSの起動プロセスでは初期の実行環境から本格的な運用環境に一気に切り替わるが、自分の設計ではその境界をわざと曖昧にしている。


↑
写真で表すとこんな感じになるね。

要するにスナップショットをキャッシュみたいにも扱うという感じ

さあこれで動くようになるか！？

結果は

クラッシュ！！

あーうぜー

シリアルログを見てみると
原因が判明

今度はFreeTypeなどの例外関数が未実装だったためクラッシュしている

なので未実装であった関数を実装するのみ

実装したので再度動くのか検証！！

さあ、結果は？

なぜかUIだけ描画されたｗ

なんか色ずれが直ってるんだけどｗ

多分メモリマッピング関係も少しいじったのでその影響だな

FreeTypeが動かない理由は？
brkが-1を返していた
-1を返す理由は自作の動的リンカーでbrkをカーネル実装にバインドしていなかった😅

 

これで動くかな？と思いきや
結果は動かなかったわ

 

原因は
FreeTypeの初期化を2回行っていた。
初期化を2回行ったことでリソースリークが起き、FreeTypeの内部状態で不整合になってしまっていた。

なので間違えて追加されていた2回目のFreeTypeの初期化の処理を削除した

これで動くはずだ！！

結果は！？



うおおおおおなんか違うぅぅぅぅぅ！！

多言語デモで10か国でHello Wrold!! (こんにちは 世界)が表示されてねぇ！！
というかフォントが描画されてねぇぇぇぇぇ！！

ってことでちゃんとフォントが描画されるように修正するか

フォントが描画されていない原因は？

単純にNotoSans NotoSans-JPのフォントファイルを読み込めていなかった。

それじゃあ直していこう
これはFreeTypeやglibcなどと一緒でブートローダーのスナップショットの範囲内であればそのまま読み込み、スナップショットの範囲外であれば仮想ファイルシステムを経由してフォントを読み込むように修正した。これで確実性も上がる

さあ、結果は？



ダメでしたｗ

シリアルログを見ると？



FreeTypeが複数回ロードされている！！

何が問題なのか？
FreeTypeが複数回ロードされることで、最初はリロケーションされていた関数が、上書きされてしまい、未リロケーションとして処理されてしまい、FreeTypeが必要としている関数にアクセスすることができなくなり、クラッシュしたり、ちゃんと動かなくなってしまう

それじゃあ修正していく😁
行った修正は、多重ロード防止のキャッシュ機構を追加だ
これを追加することで、既に同じファイル名のライブラリがロード済みかどうかをチェックし、
ロード済みなら新たにロードせず、既存のハンドルを返すようにした。
また、ファイル名（leaf名）だけで比較しているので、絶対パスや区切り文字（/や\）の違いも吸収できる。
これにより、同じライブラリは一度だけロードされ、以降はキャッシュされたハンドルが返るようになった。

んで、フォントが描画されようになったのか？

結果は？



😊😊
あーーうぜー。

シリアルログを見てみると？👀

まだFreeTypeに必要な関数が足りない！！

と言うことで必要な関数を追加していく

 

まあ追加したのはいいのだが私は気づいてしまった。

 

メモリマッピングの不足と違反を

 

ってことでそこも修正する

修正した点はこの3つ

・FreeTypeから見える位置に関数がなかったので、見えるようにした

・シンボルのマッピングミスとメモリアドレス空間のマッピングミス

・フォントファイルのマッピングミス
だ

まずはFreeTypeから見える位置に関数がなかったので、見えるようにしたことについて解説する
これは動的ロードされたユーザー空間にとって必要なのは、

• メモリ管理係、
• FreeType初期化や face 操作用の関数
• glyph 読み込み周辺の関数

のような外部シンボルだが、自作した動的リンカーで十分に解決されていなかったので、呼び出しがNULLになったり、変な所にすっ飛んでたりしていたので、修正した。

次に、シンボルのマッピングミスとメモリアドレス空間のマッピングミスの修正について解説する
これは動的リンカーのリロケーション処理で、JUMP_SLOT だけに当てるべき外部上書きを GLOB_DAT にまで広げていて、ユーザー空間自身の内部参照まで、動的リンカーのアドレスに置き換わり、本来は関数アドレスであるべき場所に、変数のアドレスが入る状態になっていたため、修正した。

最後にフォントファイルのマッピングミスの修正について解説する
これはフォントファイルの実体はブートイメージ由来で、最初はカーネルの仮想アドレスのまま、FT_New_Memory_Faceに渡していた。だが、FreeTypeが動いているのはユーザー空間なので、ユーザー空間にそのままカーネル空間の仮想アドレスとユーザー空間からの保証されていないバッファを渡すのは非常に危険なので、フォントデータをユーザー空間のヒープと安全なバッファコピーをし、そのポインタをFreeTypeに渡すように修正した。
 

結果は！？

 

フォントの描画ができた！！

けど

韓国語だけ上手く表示されてない！！


原因は？

原因は使用しているフォントのNotoSans-JPとNotoSansは韓国語(ハングル文字)には完全には対応していないとの事、なので韓国語専用のNotoSans-KRを追加することにした


フォントの追加は少し前に解説した時と一緒で、仮想のファイルシステムからフォントを探して読み込み、メモリ上に展開するようにした。

結果は？



ちゃんとフォントが映った！！

これで自作OSが多言語とフォントの描画に対応した！！

これが高校生が自作OSをライブラリの改変なしでFreeType経由で文字を描画できるようになった話でした✨
ということでmiku_JK_Jbでした
次回は高校生の間に行った自作OSの作業について解説しようかな

今回は自作OSがユーザー空間でデスクトップUIを描画できるようにした作業について解説していくよ

先にデスクトップUIを見せるとこんな感じ

まずはスタンダードモードだ

続いてシンプルモードだ

どうだ！これが自作OSのUIだ！！

まぁシンプルモードで色ずれが発生していたり、アプリケーションバーが表示されていなかったりとまだ改善点はたくさんあるんだけどね

それじゃあどうやってデスクトップのUIを描けるようになったのかについて解説するぞう🐘

まず最初にやったのはもろちん設計だ

設計では主にデザインやどのモードをどのデザインにするか、マウスカーソルの形などを決めた

これがデスクトップUIの設計だ

次にUIのパーツを作っていく
これはユーザーが自分で好きなUIにカスタマイズできるようにするために各UIのパーツをモジュール化していった

作ったパーツはこんな感じだ

• タスクバー
• 上部バー
• WiFiマーク
• サウンドマーク
• ハンバーガーメニュー(３本のメニュー線)
• 電池残量系
• 通知ベルマーク

これを作成した

正直これは3本のメニュー線(ハンバーガーメニュー)以外の完成度が💩なのでグラフィカルに美しくしたい

次にUIモードの判別処理を作成した

これはデスクトップUIがスタンダードモードなのかシンプルモードなのかユーザーがカスタマイズしたカスタマイズモードなのかを判別してそのモードを表示できるようにする処理を実装した
まあ今はカスタマイズモードのカスタマイズするアプリを実装していないので、実質スタンダードモードなのかシンプルモードなのかの判別処理になっている

後はカーネルに追加して終了だ！！
まあこれは単純でカーネルにさっき紹介した作業の関数を呼び出してデスクトップ画面を描画できるようになる処理の実装だ

これでデスクトップUIが表示できるようになった


ちなみにこれは完全にカーネル空間から独立してユーザー空間で処理が行われている
カーネル空間とユーザー空間の分離の作業はすでに終わっているが次回のブログで紹介する
今はFreeType経由での多言語化とフォント描画の対応で自作した動的リンカーが動かない問題に四苦八苦している

これが自作OSがユーザー空間でデスクトップの描画ができるようになった作業についての解説でした✨
ということでmiku_JK_Jbでした
次回はFreeType経由で多言語化とフォント描画ができるようになったらいいな🤤

商品はこんな感じのデザインです

これはAmazonのブラックフライデーで5999円と６千円を切っている

オーディオミキサーとしてはかなり安いよね

FIFINE ゲーミングオーディオミキサー オーディオインターフェース PC/PS4/PS5対応 ゲーム用オーディオミキサー ポッドキャスト ミキサー RGB機能付き ボイスチェンジャーボタン カスタム効果音 配信 実況 白 FIFINE AmpliGame SC3W

Amazon（アマゾン）

 

FIFINE ゲーミングオーディオミキサー オーディオインターフェース PC/PS4/PS5対応 ゲーム用オーディオミキサー ポッドキャスト ミキサー RGB機能付き ボイスチェンジャーボタン カスタム効果音 配信 実況 XLR接続 FIFINE AmpliGame SC3

Amazon（アマゾン）

 

さあ、これがどのくらい使えるのかを見ていこうか！！

まずは機能を見ていく


主な機能はこんな感じだ

• ボイスチェンジャー (男、女、ロボット、モンスター、赤ちゃん、お年寄り)
• 声のトーンを12基調で変更
• カスタムボタン(A,B,C,D)で効果音の割り当て

と言った感じで値段の割にはかなり高機能と言ったところ

実際のナレーションの音声やボイチェンの声の変わり方は私のYouTubeを見てね

- YouTubeYouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。youtu.be

 

付いているポートはこんな感じだ

• PCに接続するためのUSB Type-Cの接続口
• マイク、ヘッドフォン、ライン入力、ライン出力の3.5ミリのオーディオジャック
• ダイナミックマイクとコンデンサーマイクの切り替えスイッチ
• XLRケーブルの接続端子となっている

• 説明書
• 3.5ミリのオーディオケーブル
• USB Type-C to TypeAのケーブル

この商品はこれからもYouTubeのナレーションなどで活用していく
ということで以上miku_JK_Jbでした

使った商品のリンク

 

FIFINE ゲーミングオーディオミキサー オーディオインターフェース PC/PS4/PS5対応 ゲーム用オーディオミキサー ポッドキャスト ミキサー RGB機能付き ボイスチェンジャーボタン カスタム効果音 配信 実況 XLR接続 FIFINE AmpliGame SC3

Amazon（アマゾン）

 

 

FIFINE ゲーミングオーディオミキサー オーディオインターフェース PC/PS4/PS5対応 ゲーム用オーディオミキサー ポッドキャスト ミキサー RGB機能付き ボイスチェンジャーボタン カスタム効果音 配信 実況 白 FIFINE AmpliGame SC3W

Amazon（アマゾン）

 

 

【公式ブランド・1年保証】オーディオミキサー オーディオインターフェース ポッドキャスター ボイスチェンジャー デジタルミキサー サウンドカード XLR接続 パソコン スマホ 生配信 ゲーム実況 白 ホワイト 「 送料無料 1年保証 」 FIFINE AmpliGame SC3

楽天市場

 

 

今回はiPhone17Proを1ヶ月使った感想について話していきます

今回購入したiPhone17Proはこんな感じ

スペックは256GBの一番安いモデルだね

まあ今まで128GBのスマホを使っていた身としては2倍になったので、困ることはないかな。

前の128GBでも全然足りたし

ちなみにお値段は17万9800円と高い！！

高校生だけど漢の1活払い😤

それじゃあ1ヶ月使った感想を話していく

ここからは超個人的な感想です

今まで使っていたスマホはGoogle Pixel6aと言うことも頭に入れておいてね

まずはメリットから

• バッテリー持ちがめっちゃ良い
• 発熱が全く気にならずめっちゃ冷える
• カメラがクッソ綺麗

これ8倍ズームで撮ったけどバカ綺麗じゃない！？

自分は動画の撮影で少しズームをして撮影するんだけど8倍もあれば2倍とかのズームも鬼綺麗だろっていう結構安直な理由で買ったんだけど8倍ズームでこれはもう1眼レフカメラとかドンドン消えていくのでは？って言う疑問が生まれたね

 

これがメリット

世の中全ての製品に良い所と悪い所がある

次はそのデメリットについて解説しよう

デメリットはこんな感じだ

• 結構重たい(重量が)
• カメラボタンそこまで使わん
• 右にも戻るボタンが欲しい

これがデメリットだ
３番目の右にも戻るボタンが欲しいのは今まで使っていたPixelの名残だ
それじゃあ順番に解説していこう

 

まずは重量が結構重いことだ
これは言葉通りで重量が重い
使っているiFaceなども主な原因になっているだろう
それにしてもまあ重い。今まで使っていたPixelがポケットティッシュくらいの重さに感じてしまう。
腕や手首の筋トレになるのなら、メリットに入れてやってもいいだろう

 

次はカメラボタンをそこまで使わないことだ
これはiPhone16にも言えてしまうが「わーー！！やべー！！カメラカメラ！！」ってなることがあるなら、カメラボタンがあってもイイだろう。
でもさ、そんな場面って多いか？って言われたら「うん。ほぼない」って言えてしまう。
あと地味にズームの微調整がしずらいのでいらない。

最後に右にも戻るボタンが無いことだ
これはPixel6aを使用した癖でもあるのだが。
右にクイッと画面をスワイプするとiPhoneの場合では進む(PCのマウスで言う)
Pixelでは戻るだった(PCのマウスで言う)。正直iPhoneも同じだろうと思って購入したのだが、まさかの逆だった。まあこれは慣れればいいだろう

これがiPhone17Proを1ヶ月使用して感じた感想だ

徐々に慣れて大事に使っていきますよ
ということで以上miku_JK_Jbでした。

今回購入した商品はこちらから

iFace MagSafe 対応 First Class Standard iPhone 17 Pro ケース MagSynq (ホワイト)【アイフェイス 17proアイフォン 17pro用 iphone17pro カバー 耐衝撃 マグネット搭載 マグセーフ対応 スマホケース ストラップホール】

Amazon（アマゾン）

 

 

スマホリング goBelt C1 黒 薄型 1mm ワイヤレス充電対応 スマホスタンド ドイツ製 ブラック 1個

Amazon（アマゾン）

 

 

【覗き見防止】MAGIC JOHN 対応 iPhone 17 Pro ガラスフィルム 2枚セット マジックガイド枠付き 自動吸着 貼り付け簡単 ズレなく 気泡レス 指紋防止 飛散防止 耐衝撃 9H硬度 強化ガラス 保護フィルム

Amazon（アマゾン）

 

 

 

 

 

 

 

• メモリ管理のミス
• ハードウェアの故障
• ドライバのバグ
• 回復不可能なエラー

これが主にカーネルパニックを引き起こす原因である
簡単に言えばカーネルが予測していない例外が起こったと考えればいいだろう

それでは順番に解説していこうか
まずはメモリ管理のミスについて解説していこう
これはカーネルが使用できない未マップ領域にアクセスしてしまうと例外が発生してカーネルパニックを引き起こしてしまう。

次にドライバのバグについて解説していく
これは互換性のないドライバを使用したり、するとメモリ管理のミスと同様に未マップの領域にカーネルがアクセスしてしまう。その例外を処理することができないとカーネルパニックを引き起こす。
また、デバイスの初期化や解放処理が行われず、カーネルの状態が崩れてしまい、カーネルパニックを引き起こしてしまうことがある。

次にハードウェアの故障について解説しよう
これはメモリ、CPU、ストレージ、マザーボードや電源の故障などでもカーネルパニックを引き起こす。
そもそもカーネルはハードウェアが正常に動作するのが前提として開発されているので、故障したハードウェアが返す不正な値はカーネルが処理できずにパニックを起こす。

最後に回復不可能なエラーについて解説しよう
これはカーネルがこれは安全に復旧することができないと判断したエラーで、これ以上動作を続けてしまうと、データの破壊などと言った致命的なダメージが起こりうる際にもカーネルパニックが発動する

これがカーネルパニックの原因だな😁

それじゃあどうやってカーネルパニックを修正したかについて解説していこう
私の自作OSのカーネルパニックの原因はこんな感じだった

• bssセクション、dataセクションが正しくマップされていなかった
• ページングの初期化漏れ
• NULLやゴミアドレスに参照していた

それじゃあ順番修正内容を解説していくぜ

まずは未マップ領域のアクセスとページングの修正について解説しよう
これはリンカスクリプトとページングの初期化を修正した。
これにより、未マップ領域にアクセスしたりカーネルが使うメモリの範囲がページングされていないという問題は無くなった。

これがカーネルパニックの修正だ！！

ただ、カーネルパニックは直ったが、カーネルが起動しているかを一目で確認するのは難しいので、カーネルが起動かを確認する処理を追加した

それじゃあ解説していく
これはUEFIブートローダーから受け渡されたFrameBufferを使用して白い画面を映すようにした。これが成功するとカーネルが起動している且つカーネルにFrameBufferが受け渡されているということが分かる。他にも解像度や物理アドレス、ピクセルフォーマットも正常に受け渡されているということが分かる。

てことで見ていこう

結果は

変わらず起動しなかった

えーー( ﾟДﾟ)

原因を探ると


前回ブートローダーに搭載したMS x64 ABIからSysV ABIに変換する処理がカーネルにもあった

これがあるとカーネルがSysV ABIに変換する処理を行おうとするが、すでに変換されているので、MS x64 ABIが発見できずにパニックになってしまう
全く可愛い子だな🤭

ってことでカーネル側の変換処理を削除

すると


ちゃんとカーネルが起動した！！

これでカーネルパニックの修正は終了！！

次はカーネルのシリアル出力の対応化解説していくぜ
まずはシリアル出力に対応させるために行った作業を紹介しよう

• IOポートにアクセスする処理の実装
• シリアルの初期化処理の実装
• 文字列などの送信処理の実装

それじゃあ順番に解説していこうか

まずはIOポートにアクセス処理の実装について解説する
これはマザボのなどのUSBやらシリアルポートの端子やらにアクセスする処理だ
これを行わないとそもそもカーネルがシリアルにアクセスすることすらできない。
なのでx86_64アーキテクチャのCPUではメモリ空間とは別でIOポートの空間があるので、そこにアクセスを行うように処理を実装したというわけだ
アクセス方法はinとoutでinがデバイスにデータを読み込む命令、outがデバイスにデータを書き込む命令となっている
名前通りだな😁

次にシリアルの初期化の実装について解説しよう
これは通信速度、データビット数、パリティ、ストップビットを設定したり、FIFOバッファや制御信号線を正しく立てて、送受信できる状態にする、UARTを有効化する処理だ
初期化の手順は、最初に割り込みを無効化してボーレート(周波数)を115200bpsに設定し、通信フォーマットの設定を8ビットに設定してFIFOを有効化して受信と送信をクリアにして、モデム制御でDTR RTS OUT2を有効化する
かなり手順が多いがこれらを行うことによってシリアルを初期化できるってわけだ😁

次に文字列などの送信処理の実装について解説する
これはシリアルポートから文字列を送信して、受信側に文字列が映るようにする処理だ
送信処理の手順は、送信レジスタが空いているかをLSRで確認、文字化け防止のためにビットを5に設定して送信バッファを空にするぜ
これで文字が送信されるってわけだな😁

それじゃあシリアル出力がでるかを見ようか

結果は


やったね！！ちゃんと表示された！！

ちなみに環境は自作OSの動作確認用のPCとノートPCを繋いでノートPC側のTeraTermを使っている

これでシリアル出力の対応化は終了！！

最後に図形の描画を行うようにした作業を紹介するぜ
まずは行った作業を紹介する

• 長方形、正方形、三角系、円形、線の描画対応
• 色補正処理の実装
• 描画処理の高速化

まずは長方形、正方形、三角形、円形、線の描画に対応させた作業について解説する
これは図形を描画できるようにしたって感じだ
描き方としては、画面を一個一個塗って点を描き、直線を隣り合うマスを順に決めて塗っていき、四角や三角は高さを計算して一個一個塗っていく描き方で、図形を描画させた
まあチマチマと描かせている感じだ😫

それじゃあ図形を描画できるようになったから見ていこう


こんな感じでしっかりと描画ができている！！

次に色補正処理の実装だ
色補正とは人によって色の見え方は違うから、それに合わせてOSの表示する色も変えるといった感じだ。画面一つ一つのピクセルはRGB、赤(R)、緑(G)、青(B)の組み合わせで色を表している。色補正処理ではそれを特別なルールで混ぜ直している。そして画面を混ぜ直した色で描画するといった処理だ
実装のやり方は、さっきも言ったが、画面一つ一つのRGB、赤(R)、緑(G)、青(B)の組み合わせの色を混ぜ直している感じだな。

色補正を行ったので見ていこうか

• UEFIのファームウェア
• 鍵ファイル
• 署名付きのバイナリファイル
• SBAT情報

となっている
意外と少ないでしょ？

それじゃあ順番に解説していこうか
まずはUEFIのファームウェアから解説しよう
これはさっきも書いているが、セキュアブートはUEFIの機能なので、従来のBIOSでは使うことができない。そのためUEFIに対応するマザーボードなどが必要になってくる

次に鍵ファイルについて解説しよう
鍵ファイルはソフトウェアが信頼できる製作者によって作成される改ざんされていないことを証明する認証システムだ
また、鍵ファイルは主に2つで構成される

秘密鍵と公開鍵だ

秘密鍵は自作OSのブートローダーなどのバイナリファイルに製作者が「これは自分が作成したオリジナルのファイルです」と証明するための物だ
また、秘密鍵は絶対に外部に漏らしてはいけない物だ
万が一漏らしてしまうと、第三者が「正規品に見える不正なコード」を作れてしまう
要はぼんくらがパチモンを作っても騙せちゃうってことだな😁

公開鍵は秘密鍵を検証するための物だ
PCを起動するときに、UEFIがブートローダーに付与された秘密鍵を検証する必要があるこの検証をするために秘密鍵に対応する公開鍵がUEFIの「信頼しているデータベースに登録されるのだ
これらを行うことによってUEFIが署名を復号・チェックして、ブートローダーが本物であることを確認するのだ

次に署名付きのバイナリファイルについて解説しよう
これは起動させたいブートローダーなどのソフトウェア自身だ
こいつらはさっき解説した秘密鍵で署名されている必要がある
また、UEFIはこれらのバイナリファイルが読み込まれる際に署名を検証するのだ

最後にSBAT情報について解説しよう
これは既知の脆弱性に対処するために重要となるもので、ブートローダーのバージョン情報を示すメタデータだ。
また、古いブートローダーを無効化させるもので、セキュリティ問題が発見された時に、古いバージョンを「禁止リスト」に登録することで新しい署名鍵を発行しなくても、脆弱性のある古いバージョンでの起動を防ぐものだ
要するに古いバージョンの物を出禁にするってことだな😁

では自作OSをどうやってセキュアブートに対応させたかについて解説しよう
主に行った作業はこんな感じだ

• 鍵ファイルの作成
• SBATセクションの作成
• ブートローダーの署名
• ShimとMokManagerの導入
• 公開鍵の登録

これも意外と少ないでしょ？

これも順番に解説していこうか

まずは鍵ファイルの作成だ
これは秘密鍵と公開鍵を作成した
作成自体は簡単でWSLのコマンドを使用して作成した
ちなみに公開鍵は有効期限を設定する必要があるので15年間有効に設定した
秘密鍵には有効期限が無いが、流出したらすぐに失効する必要がある

次にSBATセクションの作成だ
これも作成自体は簡単でWSLのコマンドを使用して作成した

次にブートローダーの署名だ
これも同じく簡単でWSLのコマンドを使用して署名した
署名する際は秘密鍵と公開鍵、署名したブートローダーの出力先を設定して署名を行う

次にShimとMokManagerの導入だ
Shimはセキュアブートの環境で、自作や配布元が違うブートローダーを起動させるものだ。Ubuntuなども利用している
また、ShimはMicrosoftに署名されているので、セキュアブート有効環境では必ずと言ってもいいくらい起動する
MokManagerは鍵の登録を行う際に使用する。また、MokManagerはShimがロードされる過程で起動する
ただし、ShimとMokManagerは開発時の際に使用し、リリースする際はMicrosoft UEFI Third-Party CAに署名してもらうことにする
Microsoft UEFI Third-Party CAは一般の個人開発者でも受け付けしている
ちなみにMicrosoft UEFI Third-Party CAに署名してもらう際は、ブートローダーをMicrosoftが出している署名条件に満たす必要が出てくる
まあ、私は最初から視野に入れていたから今の状態でも条件を満たしているんだな😁

最後に公開鍵の登録だ
これはPCを起動させて、ShimがMokManagerを起動させる。
起動したMokManagerで公開鍵の登録を行う
ちなみに鍵ファイルを登録したら再起動する必要がある
登録している所は私のYouTubeの動画から見てくださーい

これが自作OSをセキュアブートに対応させるために行った作業だ！！
全体的に簡単な作業が多いというイメージだった

次は自作OSのブートローダーの機能を強化した作業について解説しよう

ブートローダーの機能を強化するために行ったはこんな感じだ

• ELFローダーで.text .data .bssセクションを物理メモリに展開させる処理の追加
• MSx64 ABIからSysV ABIに変換する処理の追加
• ブートローダーのシリアル出力の追加
• スタック領域の確保を行う処理の追加
• CR3に新しいPML4のロードの追加
• SysV ABIに合わせてカーネルを起動させる処理の追加

こんな感じで、かなり大幅にブートローダーの機能を向上させたね

それじゃあ順番に解説していこうか

まずはELFローダーで.text .data .bssセクションを物理メモリに展開させる処理の追加について解説していこう
これはELF形式のカーネルを解析して、実行に必要なセクションを正しい物理アドレスに配置するようにした
これを行うことにより、実際にカーネルが期待するメモリのレイアウト再現することができ、カーネルがデータなどに正しくアクセスすることができるようになる
また、.textセクションはカーネルが行う命令で、.dataセクションは初期値を持つグローバル変数や、静的変数が格納されたもので、.bssセクションは初期値を持たないグローバル変数や、静的変数が書くのされたもの

次はMSx64 ABIからSysV ABIに変換する処理の追加について解説しよう
これはUEFIは、MSx64 ABIで動いているが、自作OSのカーネルはSysV AVIを前提に書いているので、この差をなくすためにMSx64 ABIからSysV ABIに変換する処理だ
これを行うことにより、カーネルがUEFIに縛られずに移植性や拡張性が上がるのだ

次はブートローダーのシリアル出力の追加について解説しよう

これは元々実装してあったが、エラーが発生した際にしか表示されなかったが、
今回の変更によって、ブートローダーの処理がどこまで進んだかを分かるようにした

次はスタック領域の確保を行う処理の追加について解説しよう
これはカーネルの実行用の専用スタックを確保し、カーネルにジャンプする前にRSPを切り替える処理だ
RSPとは64bit環境のCPUで、スタックポインタとして機能する汎用型のレジスタの事だ。また、スタックはメモリ上に確保される特別なデータ構造だ　　　
カーネル実行用のスタックを確保することにより、UEFI側のスタックを汚さずに済んで、カーネルが安定して動作し、カーネル側の関数の呼び出しや割り込み処理の基礎が整う

次はCR3に新しいPML4のロードの追加について解説しよう
これは自作のページテーブルをCPUに適用させて、仮想アドレス空間をカーネル用に切り替える処理だ
CR3とは主にIntel,AMDのCPUが持つコントロールレジスタの1つで、メモリ管理においてとても重要な役割を持っている。また、主にページングや仮想アドレス空間の切り替えを行う
PML4はx86_64で使用される、ページングの構造の最上位レベルのテーブルだ
レクサスで言うLSってとこだな😁

次はSysV ABIに合わせてカーネルを起動させる処理の追加について解説しよう
これは今まではただカーネルのアドレスにジャンプさせるだけで、カーネルを起動させていたが、今回からはSysV ABIの規約に従って引数をレジスタにセットし、カーネルを起動させるように変更した
これにより、カーネルが期待通りの初期引数を受け取り、初期化や描画処理などを自力で始めることができるようになる　　　　　

これがブートローダーの機能を大幅に強化した作業だ！！

実際にブートローダーが動くとこんな感じになる


ちなみに赤・黄・水色・紫・オレンジ色の小さい四角が表示されているが、
これはブートローダーの処理ががどこまで進んだかを簡単に分かるようにしている

ちなみに画像ではカーネルは起動していない
理由は

＿人人人人人人人人人人人人人人人＿
＞　カーネルパニックを起こした　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

ってことで次回カーネルパニックを直して画面を描画できるようになった乞うご期待
ということで以上miku_JK_Jbでした

はい、miku_JK_Jbです
今回は自作OSを色々なPCに対応させるために行った作業を紹介していくよ

これまた久しぶりのブログ更新だな。いつも通り自作OSのエラーが多かったり私生活が忙しかったので投稿が遅くなった🥺

自作OSが起動したことが気になると思うので先に起動した画面を見せるとしよう

これが自作OSが起動した画面だ！！

まずは検証用のPC

前使っていたサブ機


CHUWIのミニPC

は？？起動しているの？？

っと見ている人は思っただろう。

大丈夫だ問題ない。

これが正常だ。

理由はカーネルが起動した後にグラフィックを描画するようにしていないからだ。

じゃあこの - みたいなのは何だって?

これはUEFIブートローダーで設定されたフレームバッファの状態がそのまま表示されているのだ。

カーネルを起動したら画面をクリアするようにしたら消える。

ただ、私はカーネルが起動しているかを確認するために消していない

じゃあこの - みたいなのが無いのもあるって?

これはUEFIの仕様によって出るPCと出ないPCがある
ASRockP67固有のUEFI仕様・制限・初期化順序がログ出力や描画を妨げている状態
 

さて、自作OSが起動した画面を見せたのでそろそろ開発記録を紹介していくとするか

まずは1日目

この日は前使っていたサブ機で自作OSが起動するかを試した

結果は

PCに自作OSの存在すら認識されなかった😭

原因はマザボのメーカーが違うので上手くELFを読めてない？
ちなみに前回自作OSが起動したときに使ったメーカーはASRock P67Pro3で
今回検証したPCのマザボのメーカーがASUS P8Z77-V

ELFを上手く読ませるためにUEFIアプリケーションで使用されるファイルを読み込んでメモリ上に展開する処理を追加し、カーネルに読み込む処理に統合した

これによりブートローダーがカーネルのバイナリを取得でき、
二日目に実装するELFヘッダを解析し、
セグメントをメモリに展開する処理の前提となる

処理の中身はこんな感じ
・ファイルサイズを取得する
・ファイルサイズ分のメモリを確保
・ファイル内容をメモリに読み込む
・読み込んだバッファとサイズを呼び出し元に返す

この処理をカーネルを読み込む処理と統合したことで、
カーネルの読み込み処理が、よりスムーズに行えるようになった
この日は二日目に実装するELFの解析まで実装したかったけど
風邪をひいて熱が出ていたので作業を中断した

2日目
 

この日はELFを解析する処理を追加し、BootServiceから抜ける処理と統合した

処理の流れはこんな感じ

・ELF形式のカーネルを読み込む
・プログラムヘッダーに従って必要なセグメントをメモリに配置
・BootServicesから抜ける処理を呼び出してUEFIの制御を終了

この処理を追加することで、ELF形式のバイナリを
実行可能なメモリレイアウトに変換しカーネルが実行可能な状態になる

これが2日目に行った作業だ

 

3日目

この日は自作OSが起動するかをリベンジした

結果は

BIOSに戻された😭😭
 

ちなみにBIOSから抜けると一瞬だけ画面が表示されて
またすぐにBIOSに戻される
 

原因を探っていくと以下のものが判明した
・ブートローダーに.relocセクションが無い
・ELFを解析する処理でPIEに対応していない

ブートローダーに.relocセクションが無いと、ブートローダーがPIE形式のカーネルが正しくリロケーションされず、ブートローダーがクラッシュする可能性がある

また、ELFを解析する処理でPIEに対応していないとそもそも、リロケーションの処理すらできない

PIEとは位置独立実行形式と言って、任意のメモリアドレスにロードされても正しく動作するバイナリ形式だ

ブートローダーに.relocセクションを追加するために行った作業はこんな感じ
・ブートローダーに.relocセクションを追加した
relocセクションを追加した理由は、カーネルをどこにロードされても動くようになるから
 

relocセクションを追加した作業は、使用するリンカを変更しリンカオプションの調整を行って追加した

ちなみに本来は.relocセクションを避けるのが一般的だが、.reloc特有のアドレスを補正を活用して、異なるUEFIでもブートローダーの挙動が安定するようにした
relocセクションが避けられる理由は、
本来のUEFIブートローダーは固定アドレスでロードされる設計なので
そもそもアドレスの補正が不要且つ、挙動が不安定になる場合があるからだ。

では何故避けられる.relocセクションを追加したのか？
UEFIの挙動はマザボやFWによって異なるので、万が一カーネルをロードするアドレスがずれた場合に.reloc特有のアドレス補正を使って、正しい場所にロードできるようにしたからだ
 

これは完全に.relocセクションの弱点を逆手にとって、 ブートローダーの安定性と柔軟性を高めた
 

次にELFを解析する処理でPIEに対応させた作業について
行った作業はこんな感じ
・カーネルをPIE形式でビルドされるように変更
・ELFファイル内に.relaセクションの追加
・ブートローダーに.relaをパースして再配置処理を追加
・仮想アドレスから実アドレスに補正させる処理を追加

この処理を追加することで万が一カーネルが違う場所にロードされても、正しいアドレスに補正してくれてるようになった
これが3日目に行った作業だ

4日目

この日は3日目に追加した処理がちゃんと動いて自作OSが起動するかを試した

結果は

ちゃんと起動した
画面が黒いのは序盤で説明したから説明は不要だよね

次にミニPCでも起動するかを試した

結果は

エラーが出て起動しなかった😭

原因はPCIを使用したGPUの特定とELFの解析でエラーが出ている

まずはPCIを使用したGPUの特定のエラーを修正していくぞ
エラーの原因はこんな感じ

・PCI上にGPUが無い場合は処理を中断していた

このせいでPCI上にGPUが無いPCでは内臓GPUを使うことができずに
ブートローダーがクラッシュしてしまう状態になっていた

エラーを修正するために行った作業はこんな感じ
・GPUが見つからなくても処理を中断しない
・見つからない場合はGOPを使用して描画

こうすることでPCI上にGPUが無くても、

内臓GPUを利用して画面を描画することができるようになり、グラボが無いPCにも対応させた
 

PCIを使用したGPUの特定のエラーを解決したので
起動するかを試した

結果はGPUの特定エラーが直り、ELFの解析のエラーだけ残った状態になった

それじゃあELFの解析のエラーを修正していくぞ
・.relaセクションの補足で0x25になっていたので正しい0x08に変更 
・セグメントマッピングの追加
・未確保領域への書き込みを防止追加
・セグメントごとの実アドレスを正確に算出するように変更

こうすることで未確保領域への書き込みを防止し、
どんなメモリ配置でも起動可能になり、再配置処理が設計に統合され実機に対する対応力が上がった
 

ELFの解析のエラーを修正したので起動するかを試した

結果は

ちゃんと起動した😉
画面が黒いのはさっきと同じ
 

これが自作OSを色々なPCで、起動するようにした作業だよ

次回はセキュアブートに対応させたいな

ということで以上miku_JK_Jbでした

今回は自作OSを起動させることができたので、起動させるまでの開発記録を紹介していく

これまた久しぶりのブログ更新だな。自作OSのエラーが多かったり私生活が忙しかったので投稿が遅くなった🥺

自作OSが起動したことが気になると思うので先に起動した画面を見せるとしよう。

これが自作OSが起動した画面だ！！

は？？起動しているの？？

っと見ている人は思っただろう。

大丈夫だ問題ない。

これが正常だ。

理由はカーネルが起動した後にグラフィックを描画するようにしていないからだ。

じゃあこの - みたいなのは何だって？

これはUEFIブートローダーで設定されたフレームバッファの状態がそのまま表示されているのだ。

カーネルを起動したら画面をクリアするようにしたら消える。

ただ、私はカーネルが起動しているかを確認するために消していない

動画でも自作OSが動いているのを見ることができるよ

さて、自作OSが起動した画面を見せたのでそろそろ開発記録を紹介していくとするか

まずは1日目

この日は以前ビルドしていたブートローダーとカーネルを実機で起動するかを検証した

↓検証した際の動画

ちなみになぜ実機で検証しているのかと言うと、QEMUなどの仮想マシンとかを使うよりも開発している雰囲気が出るじゃん？笑

検証結果はPCにそもそも自作OSの存在を認識されなかった🤪

クソが😮‍💨

ってことでエラーの理由を探っていくとすぐにエラーの原因を発見

ちなみに1日目とは違うPCを使って検証している

理由は1日目の検証で使用したPCは設定が面倒なため

 

結果は黒い画面に赤い点線が出た

 

考えられる原因はフレームバッファの描画処理で問題が起こっている？

もしくはカーネルのビルド設定に問題がある？

 

ってことでエラーの理由を探っていくと致命的なミスを発見

写真にもデカデカと書かれているがカーネルを静的リンクではなく動的リンクにしていた
はぁ😮‍💨このお馬鹿さんは一体何をやっているのか😩

ってことでカーネルを静的リンクで再ビルド
 

で、結果は

全く変わらず黒い画面上部に赤い点線が出る状態に

ってことで別の方法で試すことに

考えられる原因は検証用PCにグラボが刺さっているから、GPUを特定してGOPを取得する幅を広げればいいのではと考えた
 

GOPを超簡単に説明するとOSがグラフィックを描くようにする奴

処理の流れはこんな感じ

PCIデバイスのスキャン
↓
スキャンで取得したクラスコードを元に手動で検出
↓
GPUを見つけたらBARを読み込みメモリを初期化

流れとしては最初にPCIデバイスのスキャンを行い、取得したクラスコードもとに手動で検出、GPUを見つけたらBARを読み込み、メモリを初期化といった流れ

こうすることで内蔵GPUと外部GPUの両方が存在しても、それぞれを識別して任意に選べて、複数のGPUがぶら下がってても、優先順位を決めて描画デバイスを選べるはず！！

中々実装も大変で1週間以上かかった。PCIのクラスコードの取得やBARを取得の機能自体は元々実装してあったのでそこだけは唯一の救いだった

だが、結果は全く変わらなかった
 

次にカーネルのようにブートローダーにもビルドミスが無いかをチェックした

結果は

ブートローダーがEFI形式ではなく、ELF形式でビルドされていた＼(^o^)／

ってことで修正していく

修正した内容は以下の通り

・コンパイラ g++からclang++に変更
・リンカ ldからld.lldに変更
・リンカスクリプトを独自に変更
・ターゲット形式 .EFI固定から elfからEFI形式に変換するように変更

こうすることでしっかりとブートローダーをEFI形式でビルドすることができた

ちなみにコンパイラの変更やリンカの変更を行ったので3週間近く掛かってしまった

だが、それでも変わらなかった。

次に描画設定を詰め込む処理を修正した

詰め込んでいる描画処理の設定はこんな感じ
・ピクセルの書き込み先アドレス
・解像度
・1ラインあたりのピクセル数

・ ピクセルの並び順

ピクセルの書き込み先アドレスや1ラインあたりのピクセル数が分からない人向けに説明すると
ピクセルの書き込み先アドレス = 画面
1ラインあたりのピクセル数 = ピッチ
ピクセルの並び順 = RGBなど
 

修正した内容は以下の通り
・戻り値をvoid型からEFI_STATUSを返すように修正

・GOP, FBC に対してNULLチェックをするように修正

・汎用ポインタで扱えるように修正
 

修正内容をざっくりと伝えると

戻り値をVOID型からEFI_STATUSを返すように修正して関数の呼び出し元が、
「何が悪かったか」を明確に検出できるようになった

GOP, FBCにたいしてNULLチェックを行うことでクラッシュした時の耐性を向上させた

汎用ポインタで扱えるようにして、読み書き型依存性をなくすようにした
 

尚、結果は変わらない模様

最後にBIOSの設定でフルスクリーンロゴを有効にさせた


フルスクリーンロゴはこんな感じ


フルスクリーンロゴを有効にした所、無事に起動した

では、なぜフルスクリーンロゴを有効にしたら起動したのだろうか？

原因は主に2つ
・GOPが初期化されていない
・コンソールモードの初期状態が異なる

GOPが初期化されていない点について解説していくと

• フルスクリーンロゴが有効な場合だと、UEFIが自動的にGOPを初期化してくれ、画面を表示する準備をしてくれるので、先にGOPの初期化が済んでいる状態になる

ちなみにフルスクリーンロゴが無効な場合だと、UEFIがGOPの初期化をしないことがあるので、ブートローダーでもGOPの取得に失敗することがある

コンソールモードの初期状態が異なる点ついて解説していくと

• フルスクリーンロゴを有効にすると、UEFIが最初にコンソール出力を非表示にして、ロゴを表示させるので、
  文字出力やフォントの扱いに独特な状態遷移が起こる

ちなみにフルスクリーンロゴを無効にすると、設定が異なるので、コンソールの出力ポインタであるConOutと、コンソールの出力モードのSetModeの呼び出しが崩れてしまう

そう考えると意外とフルスクリーンロゴを有効にすることって大事なんだな

尚、EFI形式でビルドした後のソースコードを修正を行わずに、フルスクリーンロゴの設定を有効にした状態で、起動するか検証したが、起動することはなかった。

これが自作OSのカーネルを起動するまでの作業内容だったよ
これでようやくスタートラインに立った

​​​次回はブートローダーの開発で苦労した点について解説していくよ
ということで以上miku_JK_Jbでした