# Firmware Overview This repository is a recovered source-oriented view of a Lenovo HR650X server BIOS built on AMI Aptio V and Intel Purley platform code. It is not a pristine vendor source tree. The current layout combines decompiled C, reconstructed headers, generated function inventories, IDA artifacts, and analyst notes that were regrouped by package path where debug/assert/PDB/source-path evidence was available. Use this document as the top-level map for the firmware. For provenance of the package layout itself, see [original_layout_recovery.md](original_layout_recovery.md) and [original_layout_evidence.json](original_layout_evidence.json). ## Platform Identity - System family: Lenovo HR650X server firmware. - Silicon generation: Intel Purley server platform. - Firmware framework: AMI Aptio V / UEFI PI. - Build evidence visible across modules: `HR6N0XMLK`, `DEBUG_VS2015`, IA32 PEI modules, and X64 DXE/SMM modules. - Source status: recovered/decompiled module source. Function names, types, and structures are a mixture of original symbols, debug-path hints, EDK II/AMI conventions, and analyst reconstruction. ## Major Package Areas | Package | Role in this tree | | --- | --- | | `MdePkg`, `MdeModulePkg`, `UefiCpuPkg` | UEFI PI core services, DXE/PEI/SMM infrastructure, CPU and common library code. | | `AmiModulePkg` | AMI platform services: setup, NVRAM, flash, secure boot, TCG, CSM, PCI, terminal, storage, generic event log, and runtime support. | | `AmiIpmiPkg` | IPMI and BMC integration across PEI, DXE, and SMM. | | `AmiNetworkPkg` | UEFI network stack, PXE/HTTP/iSCSI, BMC LAN setup, and Redfish-related modules. | | `AmiTsePkg` | AMI text/setup environment and Aptio setup UI. | | `AmiCryptoPkg` | Crypto service initialization in PEI/DXE/SMM-facing components. | | `LenovoServerPkg` | Lenovo HR650X server integration: setup defaults, POST/status handling, system inventory, SMBIOS updates, ready-to-boot hooks, and OEM platform policy. | | `PurleyPlatPkg`, `PurleySktPkg`, `PurleyRpPkg` | Intel Purley platform, socket, south-cluster, ME/SPS, RAS, FPGA, SKU, board, and riser/platform-update logic. | | `CpPlatPkg`, `CpRcPkg` | Configuration/register access, WHEA, and platform support code used by the Purley server stack. | | `Build/GuidArtifacts` | GUID-named recovered artifacts whose original module identity remains incomplete or ambiguous. | ## Execution Model The firmware follows the standard UEFI PI boot shape: 1. SEC transfers into PEI. 2. PEI Core dispatches PEIMs, publishes PPIs, builds HOBs, discovers firmware volumes, and initializes memory. 3. DXE IPL discovers and loads the DXE Core, creates the x64 handoff context, and transfers the HOB list into DXE. 4. DXE Core installs the boot-service execution environment: protocol database, handle database, memory services, image loading, events, timers, firmware volume services, and driver dispatch. 5. DXE drivers initialize platform, storage, network, setup, security, BMC, ME/SPS, SMBIOS, ACPI, and runtime services. 6. SMM IPL loads the SMM Core into SMRAM. SMM drivers then register SMI handlers for flash, NVRAM, IPMI, storage, RAS, chipset, and runtime work. 7. BDS and setup select boot policy, maintain `Boot####` variables, and launch the selected boot option. 8. Runtime services, ACPI tables, SMBIOS tables, SMM handlers, and BMC/ME interfaces remain relevant after `ExitBootServices`. The recovered core anchors are: - `MdeModulePkg/Core/Pei/PeiMain/PeiCore/README.md` for PEI dispatch, PPIs, HOB creation, memory initialization, and firmware-volume discovery. - `MdeModulePkg/Core/DxeIplPeim/README.md` and `MdeModulePkg/Core/DxeIplPeim/DxeIpl.md` for DXE core discovery, LZMA decompression, page table creation, and transfer to DXE. - `MdeModulePkg/Core/Dxe/SectionExtraction/CoreSectionExtraction/README.md` for the recovered DXE Core evidence. - `MdeModulePkg/Core/PiSmmCore/PiSmmIpl/README.md` and `MdeModulePkg/Core/PiSmmCore/PiSmmCore/README.md` for SMM loading, SMRAM management, SMM communication, and SMI dispatch. - `PurleySktPkg/Override/IA32FamilyCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm/README.md` for the CPU-side SMM execution component. ## Behavioural Themes ### Platform Bring-up Purley PEI/DXE modules initialize CPU, memory, PCH, GPIO, PCIe/IIO, FPGA, ME/SPS, watchdog, and board-specific SKU data. The tree contains both generic Intel/AMI infrastructure and Lenovo/Purley board overlays. Important areas include: - `PurleySktPkg/SouthClusterLbg/SiInit/Pei/SiInitPreMem` - `PurleySktPkg/SouthClusterLbg/SiInit/Pei/SiInit` - `PurleySktPkg/Me/Heci/*` - `PurleySktPkg/Me/Sps/*` - `PurleySktPkg/Smm/*` - `PurleyRpPkg/Uba/UbaMain/Dxe/Type*` - `LenovoServerPkg/POSTStatus/*` - `LenovoServerPkg/OemPlatformEarlyPhasePei` - `LenovoServerPkg/OemPlatformDxePhase` ### Security and Measured Boot The firmware contains multiple security layers: - Boot Guard PEI support validates FV Main hash material early in PEI and can set a PCD to block boot on mismatch. - TCG/TPM modules initialize TPM 2.0, expose `EFI_TCG2_PROTOCOL`, extend PCRs, manage event logs, and update TPM ACPI objects. - Secure Boot DXE reads `SecureBootSetup`, provisions PK/KEK/db/dbx/dbt/dbr variables from firmware-volume data, and sets `SetupMode`. - SMM and secure-flash modules provide privileged update paths and runtime handlers that should be treated as high-impact code. Primary evidence: - `PurleyPlatPkg/BootGuard/ExtendBtGSupportToDxe/Pei/BootGuardPei/README.md` - `AmiModulePkg/TCG2/Common/TcgDxe/Tcg2Dxe/README.md` - `AmiModulePkg/SecureBoot/SecureBootDXE/README.md` - `AmiModulePkg/Flash/SmiFlash/README.md` - `AmiModulePkg/SecureFlash/SecSMIFlash/README.md` ### Management Controller Integration BMC/IPMI behaviour is a first-class part of the firmware. The IPMI stack spans PEI, DXE, and SMM: - PEI initializes BMC access early enough for watchdog, boot flags, and status reporting. - DXE initializes KCS transport, runs BMC self-test, checks BMC firmware, installs SMBIOS Type 42/SPMI records, and coordinates BMC setup options. - SEL/status-code modules forward platform health and POST events. - SMM modules keep BMC event-log and IPMI command paths available after boot. - Lenovo inventory modules collect platform data and likely report it to BMC and SMBIOS consumers. Primary evidence: - `AmiIpmiPkg/Ipmi/PeiIpmiInitialize/PeiIpmiBmcInitialize/PeiIpmiBmcInitialize/README.md` - `AmiIpmiPkg/Ipmi/IpmiInitialize/DxeIpmiBmcInitialize/DxeIpmiBmcInitialize/README.md` - `AmiIpmiPkg/Ipmi/SmmIpmiBmcInitialize/README.md` - `AmiIpmiPkg/Ipmi/DxeSelStatusCode/README.md` - `AmiIpmiPkg/Ipmi/SmmBmcElog/README.md` - `LenovoServerPkg/SystemInventory/SystemInventory/README.md` ### Setup, Policy, and Boot Selection Setup behaviour is split between AMI UI infrastructure, Lenovo setup forms and defaults, platform setup-update modules, and BDS boot-option handling: - `AmiTsePkg/EDK/MiniSetup/AMITSE` implements the Aptio setup UI, menu database parsing, boot-option management, HDD/security policy hooks, and display/input interaction. - `LenovoServerPkg/Setup`, `ServerMgmtSetup`, `SocketSetup`, and `SetupDefaults` define HR650X-specific setup variables and defaults. - `PurleyRpPkg/Uba/UbaMain/Dxe/Type*/SetupConfigUpdateDxe` modules specialize setup data by board/riser/SKU type. - Boot policy is represented through UEFI variables such as `Boot####`, `BootOrder`, `BootNext`, `Timeout`, and setup variables. Primary evidence: - `AmiTsePkg/EDK/MiniSetup/AMITSE/README.md` - `LenovoServerPkg/Setup/README.md` - `LenovoServerPkg/ServerMgmtSetup/README.md` - `LenovoServerPkg/SetupDefaults/SetupDefaultLoad/README.md` - `PurleyRpPkg/Uba/UbaMain/Dxe/TypeNeonCityEPRP/SetupConfigUpdateDxe/README.md` ## Reading Guidance - Treat module READMEs as summaries of recovered evidence, not as independent proof of vendor intent. - Prefer claims supported by function names, strings, GUIDs, protocols, variables, source paths, or multiple module notes. - Keep PEI, DXE, SMM, BDS, and runtime behaviours separate. Similar module names often describe different execution contexts. - For sensitive areas such as flash, variable services, secure boot, TPM, BMC, SMM communication, and RAS error handling, inspect the `.c`, `.h`, and sidecar `.md` files before making security conclusions.