Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Introduction for developping UEFI app/driver
Search
orumin
May 25, 2014
Programming
1
780
Introduction for developping UEFI app/driver
UEFIを,UDK(EDKII)で開発するための最初のステップについて
解説+α
orumin
May 25, 2014
Tweet
Share
More Decks by orumin
See All by orumin
ヴィンテージマシンと付き合う - kernel/vm online 5
orumin
0
1k
むかしの RISC、むかしの Unix
orumin
7
3.4k
Fundamental of architecture to implementing OS on AArch64
orumin
3
4.7k
Kernel/VM Kansai #9
orumin
0
890
Kernel/VM #14 発表資料
orumin
1
540
Unikernels report
orumin
2
430
第13回Kernel/VM勉強会発表資料
orumin
1
1.5k
第12回カーネル/VM探検隊
orumin
0
340
第11回 Kernel/VM探検隊 発表資料
orumin
1
530
Other Decks in Programming
See All in Programming
rails newと同時に型を書く
aki19035vc
5
710
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
250
PicoRubyと暮らす、シェアハウスハック
ryosk7
0
220
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
940
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
870
情報漏洩させないための設計
kubotak
5
1.3k
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
300
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
170
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.4k
非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards
petamoriken
0
430
ASP.NET Core の OpenAPIサポート
h455h1
0
120
良いユニットテストを書こう
mototakatsu
11
3.6k
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
240
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
How STYLIGHT went responsive
nonsquared
96
5.3k
GitHub's CSS Performance
jonrohan
1030
460k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
960
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
Done Done
chrislema
182
16k
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
Producing Creativity
orderedlist
PRO
343
39k
Rails Girls Zürich Keynote
gr2m
94
13k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Transcript
自己紹介 • orumin – 学生 • sepcamp2012, GSoC(now) • twitter:
@kotatsu_mi
自己紹介 • orumin – 学生 • sepcamp2012, GSoC(now) • twitter:
@kotatsu_mi • 側転できなさそうな顔の人とか TL 大破とか
自己紹介 • orumin – 学生 • sepcamp2012, GSoC(now) • twitter:
@kotatsu_mi • 側転できなさそうな顔の人とか TL 大破とか • ておくれではない
ておくれではないので, みんなにわかりやすいネタ, やります 既に知ってたらごめんなさい
ておくれではないので, みんなにわかりやすいネタ, やります 既に知ってたらごめんなさい
UEFI
Introduction for developping UEFI app/driver
UEFI • 初出 - “Play with UEFI” カーネル VM 関西
4 • “ いじぇくと的ななにか” カーネル /VM 探検隊 第九回
UEFI • ベタ C 移植 ? • Python? • EFI
Protocol? • なぞのシェル
UEFI • わからん • どう開発してるのか • どう動くのか • ておくれ
UEFI • UEFI は真面目に利便性の高いもの • ておくれてないよ !
UEFI( 加筆 ) • そもそも UEFI とは, BIOS をおきかえるもの •
UEFI 自体にブートローダーやシェルのような ものが実装されている • 自作のアプリケーション,ドライバが簡単に作 れ動かせる ← ココ重要
First Step
First Step • まずは SDK のインストール 今回は UDK について説明します UDK
は EDK(II) の stable で,現在 2014 が最新 (syuu1228 さん,情報提供ありがとうございます )
First Step $ mkdir ~/src $ cd ~/src $ svn
co https://edk2.svn.sourceforge.net/svnroot/ edk2/trunk/edk2 $ make -C edk2/BaseTools $ cd ~/src/edk2 $ export EDK_TOOLS_PATH=$HOME/src/edk2/BaseTools $ source edksetup.sh BaseTools
FirstStep • ${EDK_TOOLS_PATH}/Conf • TOOLS_CHAIN_TAG 変数 • ACTIVE_PLATFORM 変数
FirstStep • ${EDK_TOOLS_PATH}/Conf/target.txt • TOOLS_CHAIN_TAG 変数 -> GCC47 • ACTIVE_PLATFORM
変数 -> FooPkg/FooPkg.dec
FirstStep • ${EDK_TOOLS_PATH}/Conf/target.txt • TOOLS_CHAIN_TAG 変数 -> GCC47 • ACTIVE_PLATFORM
変数 -> FooPkg/FooPkg.dec • 準備完了
FirstStep • ${EDK_TOOLS_PATH}/Conf/target.txt • TOOLS_CHAIN_TAG 変数 -> GCC47 • ACTIVE_PLATFORM
変数 -> FooPkg/FooPkg.dec • 準備完了 • build コマンドでビルドしはじめる
Second Step
Second Step • プロジェクトの設定 • 設定ファイルは基本的には ini ファイルの変種
Second Step • プロジェクトの設定 • 設定ファイルは基本的には ini ファイルの変種 • UNIX-Like
OS で開発してても,滲み出る そこはかとない Windows っぽさ
Second Step • *.dec [Defines] DEC_SPECIFICATION = 0x00010005 PACKAGE_NAME =
AppPkg PACKAGE_GUID = B3E3D3D5-D62B-4497-A175-264F489D127E PACKAGE_VERSION = 0.01
Second Step • たった 4 行 • 設定ファイルのバージョン • プロジェクト名
• UUID • プロジェクトのバージョン
Second Step • *.dsc [Defines] PLATFORM_NAME = AppPkg PLATFORM_GUID =
0458dade-8b6e-4e45-b773-1b27cbda3e06 PLATFORM_VERSION = 0.01 DSC_SPECIFICATION = 0x00010006 OUTPUT_DIRECTORY = Build/AppPkg SUPPORTED_ARCHITECTURES = IA32|IPF|X64 BUILD_TARGETS = DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT
Second Step • プロジェクト名 • UUID(*.dec とは違うもの ) • プロジェクトのバージョン
• 設定ファイルのバージョン • ビルドの出力先 • ターゲットアーキテクチャ • ビルドターゲット
Second Step • まだまだ続く
Second Step [LibraryClasses] UefiApplicationEntryPoint| MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf ShellCEntryLib| ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf UefiDriverEntryPoint| MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
Second Step • この LibraryClasses セクションは, foo|path/to/libraryfolder という形 • foo
はなんでも良いけれど, UDK 内の既存プ ロジェクトに従ったほうが良い
Second Step • 最初の 3 つはエントリポイントについての ライブラリをプロジェクトに読み込む • これをしないとエントリポイントつくれない •
3 つのエントリポイントの違いは後ほど
Second Step BaseLib|MdePkg/Library/BaseLib/BaseLib.inf BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf UefiLib|MdePkg/Library/UefiLib/UefiLib.inf PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf MemoryAllocationLib| MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf UefiBootServicesTableLib|
MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf UefiRuntimeServicesTableLib| MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
Second Step • その他必要ライブラリのみなさん • 必ずしもこれらが必要なわけではない • UDK 内の既存プロジェクトとそのヘッダを 見てどんなユーティリティがあるか判断
None
Second Step [Components] AppPkg/Applications/Hello/Hello.inf …
Second Step • [Components] セクション • プロジェクトを更にモジュール毎に分割した 小さいプロジェクトの設定ファイルのパス この設定ファイルは *.inf
Second Step • dsc ファイルについて最後に • libc とか web socket
を使う場合だけ !include StdLib/StdLib.inc !include AppPkg/Applications/Sockets/Sockets.inc • この 2 行で設定の読み込みが必要
Second Step
Second Step [Defines] INF_VERSION = 0x00010006 BASE_NAME = Hello FILE_GUID
= a912f198-7f0e-4803-b908-b757b806ec83 MODULE_TYPE = UEFI_APPLICATION VERSION_STRING = 0.1 ENTRY_POINT = ShellCEntryLib
Second Step • inf ファイルの [defines] セクション • dsc の
[defines] と大差なし • ポイントは,ここで MODULE_TYPE と ENTRY_POINT を指定
Second Step • MODULE_TYPE は UEFI_APPLICATION か UEFI_DRIVER • ENTRY_POINT
は dsc ファイルに書いて 読み込んだ 3 つ, ShellCLibEntryPoint UefiApplicationEntryPoint UefiDriverEntryPoint
Second Step [Sources] Hello.c [Packages] MdePkg/MdePkg.dec ShellPkg/ShellPkg.dec [LibraryClasses] UefiLib ShellCEntryLib
Second Step • リンク / コンパイルするソース全て • 使用するライブラリを含むパッケージの プロジェクト設定へのパス •
LibraryClasses ここでは, dsc に既に書いたので省略形で 記述
Second Step • dsc の Components でモジュール分割するほどのプ ロジェクトでなければ, dsc のほうに
MODULE_TYPE やら ENTRY_POINT や ら書いてしまって, inf には [Sources] だけというのも可能 • inf を応用して,ソースコードだけ別フォルダに 分けるときに使うという使用方法もあり
エントリポイントについて UefiApplication 〜は UEFI の API 独自の作法に 従うエントリポイント EFI_IMAGE_HANDLE,EFI_SYSTEM_TABLE という型の引数で呼ばれる
エントリポイントについて • ShellCLib 〜の場合は普通の main から スタート • ほぼ完全にコード変更なしに pure
C が動作 • UEFI Protocol(API) を呼ぶのがちと面倒
エントリポイントについて • UefiDriver 〜はいわずもがな, UEFI ドライバを記述するときの エントリポイント • 引数は UefiApplication
〜と同様 • ドライバはこれしかない • UnEntryPoint の設定も必要
Let's coding
Let's coding • さあ後はコーディングするだけ ! • inf に適宜ソースファイル追加しつつ コーディングしましょう
Let's coding • さあ後はコーディングするだけ ! • inf に適宜ソースファイル追加しつつ コーディングしましょう •
Happy Hacking!!!
おわり
なワケないでショー !?
なワケないでショー !?
Let's coding • UEFI Protocol について • UEFI の API
のこと • なんで Protocol なんでしょうね • データ駆動型 API です
Let's coding • 基本的には, HandleProtocol() で特定の デバイス等の Handle を取得 •
その Handle を OpenProtocol() にぶちこんで Protocol 構造体にデータを詰め込んでもらう • 構造体に詰められた関数ポインタを通して API コール
None
Let's coding typedef struct { EFI_TABLE_HEADER Hdr*; CHAR16 *FirmwareVendor; UINT32
FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut;
Let's coding EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; EFI_RUNTIME_SERVICES *RuntimeServices; EFI_BOOT_SERVICES *BootServices;
UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; •
Let's coding EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; EFI_RUNTIME_SERVICES *RuntimeServices; EFI_BOOT_SERVICES *BootServices;
UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; •
Let's coding • gST,gRS,gBS … 既に宣言 • gBS が特に重要 LocateHandle()
, Open/CloseProtocol() 他にも LoadImage() , StartImage() ExitBootServices() 等 • 最悪 EFI_SYMPLE_FILE_SYSTEM_PROTOCOL と EFI_BOOT_SERVICES だけでブートローダ書ける
• ドライバの場合,加えてヘッダで自身の プロトコルのデータ構造を公開 • DRIVER_BINDING_PROTOCOL で プロトコルをデバイスに対して使えるかの チェック,プロトコル開始時の資源確保, プロトコル終了時の資源解放を記述
Let's coding • 実際のコードを見てみよう https://github.com/tianocore/edk2-FatPkg *.dec と *.dsc と *.inf
が設定, Fat.h に各種宣言, Fat.c が EntryPoint 他にも Fat.c でつかわれる Lock が Misc.c デバイスのアロケートを Init.c Read/Write を ReadWrite.c… という具合
おわりに • 駆け足だったので伝わらない部分もあったはず • スライド上げとくのでどうぞ読み直して下さい • デモ用意できませんでした • 最小限のプロジェクトのテンプレートを GitHub
に上げとく ( 予定 )
おわりに • UDK は VisualStudio でも使えます (Windows ユーザーさんどうぞ ) •
UNIX Like な OS で動作させる前提のツールは gnu-efi のほうが楽かもしれません GrowBuffer() や LocateHandlebyDiskSignature() とか • rEFInd とか参考にしてね ! http://sourceforge.net/projects/refind/files/
余談 • Hibernation 中の swap パーティションの snapshot を UEFI app
で弄ったりして, secure boot の secure さを壊せるのでは ? https://lkml.org/lkml/2013/8/22/218 • 発端 http://lists.opensuse.org/opensuse-kernel/ 2013-09/msg00068.html