Intel FSP介绍

• 概述
  FSP（Firmware Support Package)是Intel silicon初始化代码的一个binary形式的发布包。
  FSP主要提供chipset，processor初始化代码，并且很容易集成到当前的bootloaders。
  FSP独立于bootloader，bootloader需要将FSP集成进来完成Intel silicon初始化以外的一些功能例如：
  1. 初始化其它的非intel silicon相关的硬件
  2.总线枚举，例如pci总线，usb总线等总线枚举，目的是device discovery。
  3.工业规范的支持，例如ACPI,SMBIOS等。
• FSP 格式
  1. FSP二进制格式遵循UEFI Firmware Volume Specification。
  2. FSP由几个components组成，每个component由一个或者多个FV组成。
  3. Components包括FSP-T,FSP-M,FSP-S,FSP-I,FSP-T。每个component只能有一个实例。
  4. 每个component的第一个FV的第一个ffs文件必须是FSP_INFO_HEADER（一个数据结构体)。这个结构用了传递bootloader用来和FSP binary交互所需要的信息。
  5. 每个component包含一个可配置的数据区UPD（Updateable Product Data)。这个UPD包含的是FSP component初始化参数。

• FSP Components
  FSP-T：主要目的是是初始化Temporary RAM。
  此阶段包含
  --TempRamInit API。
  FSP-M: 主要目的是初始化内存。
  此阶段包含如下FSP API
  --FspMemoryInit()
  --FspMultiPhaseMemInit()
  --FspRamExit()
  FSP-S：主要目的是CPU/IO controller等silicon相关初始化
  此阶段包含如下FSP API
  --FspSiliconInit()
  --FspMultiPhaseSiInit()
  --NotifyPhase()
  FSP-I: SMM初始化阶段
  此阶段用来初始化SMM，提供OS SMM相关runtime silicon service,例如RAS。
  此阶段包含如下FSP API
  --FspSmmInit()
• FSP Information Tables
  每一个FSP component包含一个FSP_INFO_HEADER table,至于其它table可以
  有选择地包含。
  所有的FSP tables必须遵循4 bytes 地址对齐。
  所有的FSP tables必须以DWORD signature，DWORD length field开始。
  通常来说一个通用的FSP table查找通过搜寻相应的signature，直到'FSPP' signature被发现而终止。
  FSP_INFO_HEADER

• FSP Configuration Data
  --每一个FSP component包含一个 configurable data region 用做FSP 初始化配置参数。
  --这个configurable data region称作Updateable Product Data(UPD)。
  --UPD参数可以被静态地客制化。可以利用Binary Configuration Tool(BCT)
  搭配Boot Setting File(BSF)，BSP binary来修改UPD。
  --UPD参数也可以被bootloader 动态地overrided。
  --UPD以data structure形式组织所有的配置参数。当bootloader callTempRamInit(),
  FspSiliconInit() 等FSP API时通常会将UPD配置参数以指针的形式传递给这些APIs。
  如果传递的指针是NULL，那么FSP将要用静态build-in的UPD作为API参考的参数。
  通常bootloader在call FSP APIs之前会copy build-in UPD到memory，update相关的
  memory中的UPD参数，再将updated memory中的UPD 作为指针传递给FSP APIs使用。
  UPD structure

• FSP Mode
  FSP Inteface分API Mode，Dispatch Mode。
  --UPD只能用于API mode,在dispatch mode，PPI database, PCD database用来作为
  FSP和bootloader交互，因此dispach mode仅存在于UEFI boot loader。
  --dispatch mode不是FSP强制性要求支持，API mode被强制要求支持。
  --dispach mode是FSP可选择的支持模式，用来更好的集成FSP到UEFI bootloader环境。
• FSP API Mode Interface
  关于FSP API执行环境要求如下
  -- 中断必须关闭
  -- FSP API只能被BSP执行
  -- 确保足够的堆栈空间
  x86 32 bit API mode
  --系统操作在32bit flat mode
  --代码段，数据段选择子对应的段描述符必须是4GB 范围
  x64 64 bit API mode
  --系统操作在64-bit long mode，分页机制使能
  --FSP，bootloader的地址空间映射相同（物理地址即虚拟地址）
  --段选择子被要求设置flat模式（所谓平坦模式既一个段访问整个地址空间）
  API调用约定
  调用约定体现在参数传递的方式，参数传递的顺序，寄存器环境保存等。
  --FSP API 32-bit 调用接口同c声明调用相似，也就是所有的参数是从右到左压入堆栈
  --FSP API 64-bit调用接口同EFIAPI类似
• FSP Dispatch Mode Interface
  --Dispatch mode是FSP实现的一个可选的模式，dispatch mode是用来使FSP方便容易地集成到UEFI bootloader中。
  --Dispatch mode启动流程遵循标准的PI规范，也就是遵守SEC,PEI,DXE,BDS四个PI启动流程。
  --Dispatch mode,FST-T,FSP-M,FSP-S,FSP-I等所有组件只是作为PEIM或者DXE驱动的容器，直接将这些组件中的FVs暴漏给UEFI bootloader，UEFI boot loader从这些FVs加载相应的PEIMs或者DXE驱动在UEFI bootloader的PEI/DXE执行环境执行。
  --在dispatch mode下PPI database ,PCD database, HOB等在FSP和bootloader之间共享用来交互信息。
  --在dispatch mode下UPD不再被用。
  --在dispatch mode下NotifyPhase() API也不再备用，取而代之的是FSP-S中的DXE驱动实现UEFI native callback。
  --在dispatch mode下FSP应该用DXE fundation环境提供的service中的一部分，下面这些service不应该使用
  ExitBootServices()
  SetWatchdogTimer()
  SetTime()
  SetWakeupTIme()
  UpdateCapsule()
  QueryCapsuleCapblities()
  --FSP dispatch mode完全遵循PI规范，因此大部分FSP APIs是不需要的。但是无论如何PI定义了PEI和DXE阶段module的格式，例外的是没有定义SEC阶段module的格式，因此在dispatch mode FST-T依然用FSP API模式下的TempRamInit()。
  --基于dispatch mode启动流程PEI foundation 并没有在BFV中，按照PI规范，SEC必须传递EFI_PEI_CORE_FV_LOCATION_PPI到PEI Foundation Entry Point。
  --Dispatch mode下产生FSP Temporary RAM Exit PPI，这个PPI等同于TempRamExit() FSP API，这个PPI是选择性要求。
  --Bootloader需要按照FSP-M Architectual Configuration PPI,此PPI包含FSP-M中的PEIM需要的配置数据。
• 启动流程
  
  

API Mode Boot Flow

Dispatch Mode Boot Flow

唐爱六于2023.3.123