by shigemk2

当面は技術的なことしか書かない

UEFI #kernelvm

@kotatsu_mi

Unified Extensible Firmware Interface - Wikipedia

カーネルVM 関西4

UEFI

ベタC移植? Python

わからんし、どう開発したらいいの

UEFIは利便性が高い

導入

SDKのインストール

ビルドして試す

  • プロジェクトの設定が面倒
  • iniファイルの変種

  • *.dec

[Defines]
DEC_SPECIFICATION
PACKAGE_NAME
PACKAGE_GUID

uuidgen

  • 4行の設定
  • 設定ファイルのバージョン

dscの設定が厄介

OUTPUT_DIRECTORYの指定とか

ビルドのターゲット、リリース

DECファイル

(設定は3行)

[LibraryClasses]

UefiApplicationEntryPointなど

LibraryClassesセクション

foo|path/to/libraryforlder

エントリポイントについてのライブラリをプロジェクトに読み込む

API

ライブラリのパス

UDK内の既存プロジェクトとそのヘッダを見てどんなユーティリティがあるか判断

あとは、仕様書を読むとか。

[Components]

プロジェクトを更にモジュールごとに分割したアレ

標準C言語とか。

infファイルの[Define]セクション

MODULE_TYPEはUEFI_APPLICATIONとか

INFファイルとは 「inf file」 インフファイル: - IT用語辞典バイナリ

エントリポイントとは 【 entry point 】 〔 エントリーポイント 〕 - 意味/解説/説明/定義 : IT用語辞典

独自の作法に従った初期化

infファイルのモジュール分割

UefiApplicationはUEFIのAPI独自の作法に従うエントリポイント

ShellCLib の場合は普通のmainからスタート

UefiDriver はいわずもがな、UEFIドライバを記述するときのエントリポイント

適宜コードを書く。

Let's coding

  • UEFI Protocolについて
  • UEFIのAPIのこと
  • なぜProtocolなのか

  • HandleProtocol()で特定のデバイスなどのHandleを取得

Image Handle

EFI_LOADED_IMAGE_PROTOCOL EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL ...

typedef struct {
  EFI_TABLE_HEADER Hdr*;
}

標準出力などをプロトコルでハンドリング

gST,gRS,gBS....すでにグローバル変数として宣言されている gBSが特に重要 LocateHandle()など Open/CloseProtocol()など ExitBootSevices()で開放

EFI_SYMPLE_FILE_SYSTEMなど

ドライバの場合、加えてヘッダで自身のプロトコルのデータ構造を公開

DRIVER_BINDING_PROTOCOLでプロトコルがデバイスに対して使えるかのチェック

EFI_STATUS
EFIAPI
FatEntryPoint {
  ....
}

EFI_STATUS
EFIAPI
// 資源確保、開放
FatDriverBindingSupported {
  ....
}

...
EFI_STATUS
EFIAPI
EFI_DRIVER_BINDING_PROTOCOL gFatDriver Binding = {
  FatDriverBindingSupported,
  ....
}

// エントリポイントの実装
....

ディスクの資源をとってくる

Status = LocateHandleByDiskSignature

シグネチャ - Wikipedia

プログラミングで、メソッドや関数の、名前・戻り値や引数の型などの組み合わせ。

最小限のプロジェクトのテンプレートをGitHubに上げる予定。

UDKはVisualStudioやMacでも使える

UNIX LikeなOSで動作させる前提のツールはgnu-efiのほうが楽かも

rEFIndとか参考にしてね

The rEFInd Boot Manager