--- a/slide/slide.md	Mon Feb 15 22:41:04 2021 +0900
+++ b/slide/slide.md	Tue Feb 16 06:12:58 2021 +0900
@@ -36,21 +36,36 @@
     - 琉球大学工学部
 
 ---
-<!-- class: slide -->
+
 # OSとアプリケーションの信頼性を高めたい
 
 - Meta計算を用いて信頼性を高めるGearsOSを提案している
 - x.v6を元にRaspberry Pi上で動くGearsOSを実装中
-- BIOSからBootしているのでUEFIに移行したい
+- キーボードやマウスが使えない
+- デバイスドライバを作る必要がある
 ---
-<!-- class: slide -->
-# UEFI採用の利点
+# BIOS問題
+- x.v6の起動はBIOSを使っている
+- IntelがCompatibility Support Module(CSM)をやめた
+- BIOSを前提としたOSが動かなくなるかも
+- キーボードやマウスはUSB
+- USBドライバを作るのは難しい
+---
+# <!--fit--> Gears OSをUEFIでBootさせよう
+---
+# UEFIへの移行
 - CPUなどの機種依存性を避けることができる
 - GearsOSはCbC(Continuation based C)で記述されていて、CPUやデバイスに影響されない
 - 様々な組み込みシステムに対してGearsOSを応用できる様になる
+- UEFIのApplicationによりUSBドライバ開発が簡単になる
 
 ---
-<!-- class: slide -->
+# 研究の成果
+- UEFIの開発環境をSingularityで作成した
+- gnu-efiで作成したUEFI Applicationをqemu-system-armで動かすことができた
+- RaspberryPiにUEFIをファームウェアとして設定し、実行することができた
+- ミニマムなKernel Loaderを調査しARM xv6用に書き直した
+---
 # CbC(Continuation based C)
 - 並列信頼研究で開発されているプログラミング言語
 - C言語の下位言語
@@ -58,46 +73,45 @@
 - 関数の代わりにCodeGearという単位でプログラミングを行う。
 
 ---
-<!-- class: slide -->
+
 # GearsOS
 - 並列信頼研究で開発されているOS
 - 信頼性と拡張性がテーマ
 - CbCによって記述されている
 - x.v6をCbCで書き直して実装している
 ---
-<!-- class: slide -->
+
 # UEFI
 - Unified Extensible Firmware Interfaceの略
 - OSとプラットフォームファームウェアの間のソフトウェアインタフェースを定義する仕様
 - Intel、AMD、Apple、Microsoftなどの企業からなるUnified EFI　Forumの元で開発
 - BIOSの後継
 ---
-<!-- class: slide -->
-# UEFIのここがすごい
+
+# UEFIの利点
 - CPUやドライバに依存しない
 - 2TBを超える大きなディスクからBootできる
-- ネットワークにつながる
 - メモリも64bitなら理論上16EB
-- 高速でBoot
-- 仕様だから開発が簡単
+- BIOSより高速でBoot
+- オープン仕様だから開発が簡単
 
 ---
-<!-- class: slide -->
+
 # UEFI 開発環境
-- edk2
+- EDK2
 - gnu-efi
 - qemu
-- singularity
+- Singularity
 
 ---
-<!-- class: slide -->
+
 # gnu-efi
 - システムのネイティブGCCでUEFIアプリケーションをコンパイルできる
 - UEFI　Applicationをリンクするためのライブラリがある
 - UEFI Applicationの開発に特化している
 - EDK2のファームウェアがベース
 ---
-<!-- class: slide -->
+
 # qemu
 - 異なるアーキテクチャのプログラムを動かすエミュレータ
 - 本開発ではX86上でARMを動かした
@@ -105,14 +119,12 @@
 
 
 ---
-<!-- class: slide -->
 # singularity
 - ユーザーが自身の計算環境を完全再現し、保持できる様にしたLinuxコンテナ
 - 学科の新システムで利用できる
 - CbC GCC ARM CrossCompile環境を作った
 - UEFIの開発環境を作った
 ---
-<!-- class: slide -->
 # UEFI Application
 - UEFI Boot Managreがロード、実行するプログラムのこと
 - C言語で記述可能
@@ -136,7 +148,28 @@
 }
 ```
 ---
-BootLoader.c
+# Gears OS UEFI Bootの課題
+- UEFIからx.v6はBootできない
+- x.v6はUEFIに対応されてない
+- x.v6のBootLoaderが必要
+- BootLoaderを作成する 
+---
+# Boot Loader
+
+- OSをLoadしてBootさせる役割をもつプログラム
+- UEFI ApplicationとしてC言語で実装できる
+---
+# Boot Loaderの役割
+1. 電源が入る
+1. UEFIが立ち上がる
+1. Boot ManagerからBootLoaderが起動する
+1. BootLoaderがOSのKernelをメモリにLoadさせる
+1. Kernelがinitプロセスを起動
+1. initプロセスがOSのBootプロセスを起動
+1. OSがBootされる
+
+---
+# BootLoader.c
 - efi_mainの引数設定
 
 ```
@@ -157,25 +190,42 @@
     Print(L"Hello, EFI!\n");
 ```
 ---
-- OSファイルのファイルパスを代入している
+- uefi_call_wrapperでプロトコルを呼び出している
+
 ```
     Status = uefi_call_wrapper(BS->OpenProtocol, 6, ImageHandle, &
     LoadedImageProtocol,(void**)&LoadedImageParent, 
     ImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+```
+- エラー文
+```
     if (EFI_ERROR(Status)) {
         Print(L"Could not get LoadedImageProtocol handler %r\n", Status);
         return Status;
     }
+```
+---
+- xv6.imgのデバイスパスをPathに格納している
+- このデバイスパスはKernelをLoadするときに使う
+```
     Path = FileDevicePath(LoadedImageParent->DeviceHandle, L"\\xv6.img");
+```
+- エラー文
+```
     if (Path == NULL) {
         Print(L"Could not get device path.");
         return EFI_INVALID_PARAMETER;
     }
 ```
 ---
-- KernelをLoadしている
+- ここでデバイスパスを使いKernelをLoadする。
+- これでKernelがメモリに展開される。
 ```
-    Status = uefi_call_wrapper(BS->LoadImage, 6, FALSE, ImageHandle, Path, NULL, 0, &Image);
+    Status = uefi_call_wrapper(BS->LoadImage, 6, FALSE, ImageHandle,
+     Path, NULL, 0, &Image);
+```
+- エラー文
+```
     if (EFI_ERROR(Status)) {
         Print(L"Could not load %r", Status);
         FreePool(Path);
@@ -183,9 +233,11 @@
     }
 ```
 ---
-- ImageをLoadしてKernelを起動している
+- LoadしたKernelイメージについてLoadedImageProtocolを入手
+- LoadOptionsに起動オプションを指定し、Kernel コマンドラインを指定
 ```
-    Status = uefi_call_wrapper(BS->OpenProtocol, 6, Image, &LoadedImageProtocol, 
+    Status = uefi_call_wrapper(BS->OpenProtocol, 6, 
+    Image, &LoadedImageProtocol, 
     (void**)&LoadedImage, ImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
     if (EFI_ERROR(Status)) {
         Print(L"Could not get LoadedImageProtocol handler %r\n", Status);
@@ -196,8 +248,12 @@
     LoadedImage->LoadOptions = Options;
     LoadedImage->LoadOptionsSize = (StrLen(LoadedImage->LoadOptions)+1) * sizeof(CHAR16);
     Print(L"Hello,6!\n");
+```
+---
 
-    
+- Loadされたイメージを起動
+- Kernelが起動する
+```    
     Status = uefi_call_wrapper(BS->StartImage, 3, Image, NULL, NULL);
     uefi_call_wrapper(BS->UnloadImage, 1, Image);
     FreePool(Path);
@@ -206,17 +262,6 @@
 }
 ```
 ---
-# Boot Loader
-- UEFIが起動
-- Boot Managerから起動される
-- OSのKernelをメモリにLoadさせる
-- Kernelがinitプロセスを起動
-- initプロセスがOSのBootプロセスを起動
-- OSがBootされる
-
-
-------
-<!-- class: slide -->
 # 大変だったこと
 - EDK2は汎用的だがARMのConfigなどの書き換えが困難
 - UEFI開発の情報が少なく、偏りがあった
@@ -224,21 +269,13 @@
 - 低レベルの開発に慣れていなかった
 
 ---
-<!-- class: slide -->
 # 今後の課題
 
 - Singularity上のqemu-system-armにgdbを接続する
-- そのgdbでKernel Loaderをでバックする
+- そのgdbでKernel Loaderをデバックする
 - xv6 KernelにUEFIからBootするコードを入れる
 - xv6を書き換えたGearsOSを実装する
 - USB Driverを実装し、キーボードやマウスを使える様にする
 
-
-
 ---
-<!-- class: slide -->
-# 研究の成果
-- UEFIの開発環境をSingularityで作成した
-- gnu-efiで作成したUEFI ApplicationをQEMU-ARMで動かすことができた
-- RaspberryPiにUEFIをファームウェアとして設定し、実行することができた
-- ミニマムなKernel Loaderを調査しARM xv6用に書き直した
+# ご清聴ありがとうございました

Binary file slide/slide.pdf has changed