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。

待續