Architecture-Specific Libraries and Modules Explained

Let me explain what architecture-specific libraries and modules are with examples from the EDK II codebase.

What Are Architecture-Specific Libraries and Modules?

Architecture-specific libraries and modules are implementations that are tailored for specific CPU architectures (IA32, X64, ARM, AARCH64, RISCV64, etc.) and module types (SEC, PEIM, DXE_DRIVER, SMM_DRIVER, etc.). They allow the same abstract interface to have different implementations optimized for different execution environments.

1. Architecture-Specific Libraries

Example 1: Random Number Generation (RngLib)

[LibraryClasses.IA32, LibraryClasses.X64, LibraryClasses.AARCH64]
  RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
        

Why different for different architectures?

• IA32/X64: Use RdRand instruction (Intel/AMD CPU instruction)
• AARCH64: Use RNDR instruction (ARM CPU instruction)
• RISCV64: Use Seed CSR (RISC-V Control Status Register)
• Other architectures: Use null implementation (no hardware RNG support)

Implementation Differences:

[Sources.Ia32, Sources.X64]
  Rand/RdRand.c

[Sources.AARCH64]
  AArch64/Rndr.c
  AArch64/ArmRng.h

  AArch64/ArmRng.S           | GCC

  AArch64/ArmRng.asm         | MSFT

[Sources.RISCV64]
  Riscv/Rng.c
  Riscv/Seed.S               | GCC
        

Example 2: ARM Architecture Libraries

[LibraryClasses.ARM, LibraryClasses.AARCH64]
  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
        

Why different for ARM vs AARCH64?

• ARM (32-bit): Uses ARMv7 instruction set, different memory model
• AARCH64 (64-bit): Uses ARMv8 instruction set, different register set

Implementation Differences:

[Sources.ARM]
  Arm/ArmV7Lib.h
  Arm/ArmV7Lib.c

  Arm/ArmLibSupport.S           | GCC
  Arm/ArmLibSupportV7.S         | GCC
  Arm/ArmV7Support.S            | GCC
  Arm/ArmV7ArchTimerSupport.S   | GCC

[Sources.AARCH64]
  AArch64/AArch64Lib.h
  AArch64/AArch64Lib.c

  AArch64/ArmLibSupport.S
  AArch64/ArmLibSupportV8.S
  AArch64/AArch64Support.S
  AArch64/AArch64ArchTimerSupport.S
        

2. Module Type-Specific Libraries

Example 1: PEI vs DXE vs SMM Cryptography

[LibraryClasses.common.PEIM]
  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
  TlsLib|CryptoPkg/Library/TlsLibNull/TlsLibNull.inf

[LibraryClasses.common.DXE_DRIVER]
  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
  TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf

[LibraryClasses.common.DXE_SMM_DRIVER]
  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
  TlsLib|CryptoPkg/Library/TlsLibNull/TlsLibNull.inf
        

Why different for different module types?

• PEI: Pre-EFI Initialization - limited memory, no runtime services
• DXE: Driver Execution Environment - full UEFI services available
• SMM: System Management Mode - isolated execution environment

Example 2: PEI Services Table Pointer (Architecture + Module Type)

[LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
  PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
        

Why this specific combination?

• IA32/X64: Use IDT (Interrupt Descriptor Table) to store PEI services pointer
• ARM/AARCH64: Use different mechanism (register-based or memory-based)
• PEIM only: This library is only needed during PEI phase

3. Real-World Examples from ArmVirtPkg

Platform Library Selection by Architecture:

[LibraryClasses.AARCH64]
  ArmPlatformLib|ArmVirtPkg/Library/ArmPlatformLibQemu/ArmPlatformLibQemu.inf

[LibraryClasses.ARM]
  ArmPlatformLib|ArmPlatformPkg/Library/ArmPlatformLibNull/ArmPlatformLibNull.inf
        

Why different implementations?

• AARCH64: Full QEMU virtualization support with ARMv8 features
• ARM: Null implementation (ARMv7 not fully supported in this platform)

Cryptography Library Selection by Architecture + Module Type:

[LibraryClasses.AARCH64.PEIM]
  ArmMmuLib|UefiCpuPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf

[LibraryClasses.ARM.PEIM]
  BaseCryptLib|CryptoPkg/Library/BaseCryptLibMbedTls/PeiCryptLib.inf
        

Why different cryptography implementations?

• AARCH64: Use OpenSSL-based cryptography (better performance)
• ARM: Use MbedTLS-based cryptography (smaller memory footprint)

4. How the Build System Resolves These

Resolution Priority (Most Specific Wins):

1. [LibraryClasses.ARCH.MODULE_TYPE] - Most specific (e.g., IA32.PEIM)
2. [LibraryClasses.ARCH] - Architecture-specific (e.g., AARCH64)
3. [LibraryClasses.common.MODULE_TYPE] - Module type-specific (e.g., common.PEIM)
4. [LibraryClasses] - Default/common implementation

Example Resolution Chain:

When building a PEIM module for AARCH64 that needs BaseCryptLib:

1. Check [LibraryClasses.AARCH64.PEIM] - Not found
2. Check [LibraryClasses.AARCH64] - Not found
3. Check [LibraryClasses.common.PEIM] - Found: PeiCryptLib.inf
4. Use PeiCryptLib.inf

5. Benefits of This Approach

1. Performance Optimization

• Use CPU-specific instructions (RdRand, RNDR)
• Optimize for architecture-specific memory models
• Leverage hardware acceleration features

2. Memory Efficiency

• ARM modules can use smaller MbedTLS instead of OpenSSL
• PEI modules use minimal implementations
• SMM modules use isolated implementations

3. Platform Flexibility

• Same source code works across different architectures
• Platform-specific optimizations without code duplication
• Conditional compilation based on build targets

4. Maintainability

• Clear separation of concerns
• Easy to add new architecture support
• Consistent interface across implementations

Summary

Architecture-specific libraries and modules in EDK II allow the same abstract interface (like RngLib or BaseCryptLib) to have different implementations optimized for:

• CPU Architecture: IA32, X64, ARM, AARCH64, RISCV64
• Module Type: SEC, PEI, DXE, SMM, UEFI Application
• Combination: IA32.PEIM, AARCH64.DXE_DRIVER, etc.

This system provides the flexibility to optimize performance and memory usage while maintaining a consistent API across the entire UEFI firmware stack.