UEFI edkI vs edkII

其實由intel和這種大企業制定的標準，本來就會比較OOXX。
現在又來個大改版，更加模組化。
光看資料的長相就大不同。

UEFI從edk到edkII，來小小整理一下，希望不要理解錯誤

UFEI是個interface，跟windows很像((畢竟就是這些人訂的
像是FV->folder, FFS->file，
所有描述的方式都是為了讓UFEI"認識"這是什麼東西。

到了edkII，又多了一個package，要讓他更模組化。
以往寫的driver或是module，就是一隻一隻的，沒有模組的概念。
現在可以把這些driver包起來變成一package。
蠻直觀，EX: Securitypkg，那大概裡面放的都是跟security有關的driver，
裡面會有自己的dsc，也可以分開build 這些package。
如果你發現package folder裡面沒有dsc檔，那是因為bios vendor幫你auto generate。
而且是for 整個project，我覺得失去edk2的原意，但你還是可以自己寫code去build。

缺點，是我覺得讓整個CODE又更加肥大了。

為了這樣的改變，就必須多一些描述，讓UEFI認識這些新東西。
像是inf裡面
[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
[Pcd]
  gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber    ## SOMETIMES_CONSUMES
  gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressRuntimeCodePageNumber     ## SOMETIMES_CONSUMES
  gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable            ## CONSUMES
  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxEfiSystemTablePointerAddress         ## CONSUMES

多了packages and PCD的描述

至於PCD，platform configuration database，又讓code海更加茫茫。
翻開SPEC可用的protocol很簡單，不是get就是set。

我暫時簡單理解他像Setup variable那樣，也實際佔了ROM size，只是用途不同，可以runtime改變這些PCD的值((透過PCD的PROTOCOL去存取。
實作上還完全不明白。

DEC
定義PCD的entry，PCD entries會被build tool自動產生成 autogen.h autogen.c。

待續

EFI OVERVIEW

• CPU RESET ENTRY 在fffffff0 ，正好在SEC CORE的位置，擺在ROM的最上面，SEC在CRB實際上也只有一行CODE，他只是一個MODULE而已，他與PEI放在一起，看成一個特殊的PEI MAIN就好。 EFI則是放在BIOS的最下面。
  
• IA32，X64，3.5之後的CODE之後target processor都是用x64。
  
• PEI_MAIN、NVSTORAGE(存放DATA的地方)、FV_DYNAMIC、FV_BACKUP、FV_RECOVERY。
  
• 每一隻MODULE都是一個FILE
  
• EFI想像成小型OS，想像HD是BIOS ROM，FV就是partition，Region name就是他的name。會有幾個partition呢，請看FLASHMAP。
  
• DSC FILE 描述你有什麼COMPONENT
  ENV檔為COMPONENT的DEFINE
  
• ENTRY點都在ASM裡幾乎不會去變動，做PROJECT出錯，要找RESET點，要去哪裡找呢，在IA32的resetvec.asm
  
• 建立STACK才可以做FUNCTION CALL
  
• package定義component type，告訴他是POST CODE，才不會COMPILER出錯(DSC檔中)
  
• 為什麼第四個phase BDS不是擺在最後面，在CODE的前面先出現呢，BDS其實是做DRIVER的CONNECT，DXE只是載入記憶體，有些DRIVER需要CONNECT才可以開始啟動，想像成WINDOWS的DEVICE MANAGER，可以每個DRIVER ENABLE、DISABLE。
  
• BDS想像為一個DXE DRIVER (PWR ON->SEC->PEI(Pre EFI initialization)->DXE(Driver Execution Environment)->BDS(Boot Device Selection)->OS)
  
• 在SEC階段 SS可用 DS不可用，不要去動，在C中不要加入STATIC，不然會被放到DS中
  
• SEC會LINK PEI MAIN載入它，這時想像PEI是個小型的OS， 此時有很多的FUNCTION CALL可以用，例如FV SERVICE。基本上是一個檔案一個檔案載入進來，順序是系統決定，以PEI來講，大致上跟我們寫的順序一樣，除非有特殊的DEPENDENCY。
  
• 所謂的BOOT FV，就是放PEI MAIN的地方，包含PEI CORE 和 MODULES。沒有他就找不到NEXT FV。
  
• PEI CODE大部分在ROM執行，但後面可能可以進到MEMORY了
  
• Driver 有沒有進去可以看FVMAIN.INF 裡面會列出所有的component
  
• FILE就是FILE拉~
  
• 每一個INF檔是一個COMPONENT 被放在FVMAIN裡面
  
• flashmap.h有所有的flash region的base、size、offset，sub region也有。
  
• 有了GUID，PPI即可找到相對的記憶體位置
  
• 不要把兩個INF檔放再同一個目錄
  
• PEI沒有RAM，怎麼擺資料結構呢 ：用STACK去建立HOB LIST
  
• 一個PPI，就是一個GUID加上一個POINTER
  
• proto type: 定義一個 function應該傳入什麼參數。
  
• PEI到PXE的階段，必須把記憶體位址的INFORMATION PASS 給PXE
  
• DXE想像為比PEI大一點的小型OS
  
• DXE DEPENDENCY的概念：dxs檔描述他需要哪些PROTOCOL
  
• 要看DXE DRIVER，先看INF檔描述的ENTRY POINT，傳HANDLE和SYSTEM TABLE，
  SYSTEM TABLE，
• EFI的概念中，所有的檔案都是EFI檔，都可以執行，不僅可以放在ROM裡，還可以放在HD中，那我們要傳些什麼給他呢，就是一個PATH，有點像是C:\xxx\xxx，在EFI中，我們需要比較完整的路徑，稍後詳述。
  
• DXE階段，有TIMER、EVENT的觀念。
  
• 8259的IRQ1(KB)幾乎都是被DISABLE的，由於進入PROTECTED MODE，INT一進來我們看到的是32BIT的IDT，那KB是怎麼被抓進來呢，哈我聽不太懂= =，只說是有POOL的概念，參考SPEC的CH5。重聽(5)26:00
  
• PROTOCAL