Limitations and Known Issues - FarelRA/CSMWrap GitHub Wiki

Limitations and Known Issues

CSMWrap is a complex piece of software operating at a very low level. Due to the vast diversity in UEFI firmware implementations and hardware, users may encounter limitations and issues.

1. "Above 4G Decoding" / Resizable BAR / Smart Access Memory

  • Issue: Legacy Option ROMs (including VBIOS) and many legacy operating systems are 32-bit. They cannot access PCI device memory (BARs) that are mapped above the 4GB physical address boundary. Modern systems with "Above 4G Decoding," "Resizable BAR," or "Smart Access Memory" enabled often map GPU VRAM and other PCI resources into this high memory space.
  • Limitation: CSMWrap requires these features to be disabled in the UEFI firmware settings. If they are enabled, the VBIOS will likely fail to initialize or access VRAM, leading to black screens or boot failures.
  • Status: This is a fundamental limitation of 32-bit legacy environments.

2. Legacy Region Unlocking (0xC0000 - 0xFFFFF)

  • Issue: The legacy BIOS region (0xC0000-0xFFFFF), where Option ROMs like the VBIOS are shadowed, is often write-protected by UEFI firmware. CSMWrap needs to write the VBIOS (either SeaVGABIOS or a native Option ROM) to this area.
  • Mechanism:
    1. CSMWrap first tries to use the EFI_LEGACY_REGION2_PROTOCOL to unlock this region. This is the standard UEFI way.
    2. If the protocol is not available or fails, CSMWrap attempts chipset-specific workarounds (unlock_region.c):
      • Intel Chipsets: It tries to modify PAM (Programmable Attribute Map) registers via PCI configuration space. This is known to work for older chipsets like PIIX4, Q35, and some newer ones like Skylake, but success is not guaranteed on all Intel platforms.
      • AMD Chipsets: It attempts to configure MTRRs (Memory Type Range Registers) to make the region write-back.
  • Limitation: If neither the UEFI protocol nor the chipset-specific hacks can unlock the region, CSMWrap will fail to load the VBIOS, likely resulting in a black screen or inability to boot. Some firmwares may aggressively re-lock this region or prevent these modifications.
  • Status: Highly dependent on motherboard firmware.

3. Windows Video Modesetting Issues (XP/7)

  • Issue: Even if SeaVGABIOS initializes correctly and provides VESA modes, Windows XP and Windows 7 (especially without native GPU drivers injected into the installation) may attempt to set video modes via INT 10h in ways that are not fully compatible with the emulated environment or the underlying EFI GOP.
  • Symptoms: Flickering display, incorrect resolution, or a black screen after the initial Windows boot logo or loading screen.
  • Limitation: The exact interaction between legacy Windows INT 10h usage and the VBIOS/GOP bridge is complex and not fully understood for all scenarios.
  • Possible Workaround:
    • Try to slipstream/inject native legacy GPU drivers (if they exist for your GPU and the target OS) into your Windows installation media. This allows Windows to bypass the VBIOS for modesetting.
    • Experiment with different VBE modes if the OS installer allows.
  • Status: Known issue; improvements may require deeper VBIOS or INT 10h handling enhancements.

4. Hardware Compatibility

  • Issue: CSMWrap interacts with low-level hardware and firmware features. Variations in UEFI implementations, ACPI tables, chipset behavior, and specific peripheral controllers can lead to unexpected behavior.
  • Limitation: CSMWrap cannot guarantee compatibility with all hardware and firmware combinations.
  • Status: Ongoing effort. Community feedback on working/non-working hardware is valuable.

5. UEFI CSM Conflicts

  • Issue: If the system's native UEFI CSM is enabled, it might conflict with CSMWrap's operations. Both might try to manage legacy resources or initialize hardware in incompatible ways.
  • Recommendation: Generally, disable the native UEFI CSM if CSMWrap is being used. However, on some systems, the native CSM might be required for certain low-level initializations that CSMWrap doesn't perform.
  • Limitation: The interaction is firmware-dependent.
  • Status: Requires user experimentation for their specific system.

6. ACPI and SMBIOS Table Quality

  • Issue: The legacy OS relies on the ACPI tables (RSDP, FADT, DSDT, etc.) and SMBIOS tables provided. CSMWrap passes through the tables from UEFI. If these tables are malformed or contain information unsuitable for a legacy environment, the OS may behave erratically or fail to boot/install.
  • Limitation: CSMWrap does not extensively patch or modify these tables beyond basic relocation for ACPI.
  • Status: Dependent on the quality of the system's UEFI firmware.

7. Interrupt Handling

  • Issue: Legacy interrupt handling (via 8259 PIC) is different from UEFI's APIC-based handling. CSMWrap and SeaBIOS CSM set up the legacy PICs.
  • Limitation: Complex interrupt sharing scenarios or NMI handling might not be perfectly emulated.
  • Status: Generally works for common legacy OS requirements.

8. Performance

  • Issue: The thunking between UEFI mode and 16-bit real mode, along with the emulation layer, can introduce some performance overhead compared to a native BIOS or native UEFI boot.
  • Limitation: Noticeable primarily during I/O-intensive operations handled by emulated BIOS services.
  • Status: Considered acceptable for the intended use case.