UEFI- und BIOS-Optionen nachvollziehbar dokumentieren: Wie erfasse ich Menüpfade, Parameterwerte, Abhängigkeiten und Auswirkungen tabellarisch?

Methodik für reproduzierbare Firmware-Dokumentation: Menüpfad, exakte Bezeichnungen, Default-Ermittlung, Versionierung

Reproduzierbare Firmware-Dokumentation setzt eine Methodik voraus, die sowohl die Benutzeroberfläche (Menüs, Untermenüs, Optionstexte) als auch den technischen Zustand (tatsächlich wirksame Parameter im NVRAM) eindeutig beschreibt. Da UEFI-Setups je nach Hersteller, Mainboard-Revision, BIOS/UEFI-Version, aktivierten Modi (z. B. EZ/Advanced) und sogar Sprache variieren, muss die Erfassung präzise normalisieren: gleicher Blickwinkel, gleiche Benennungen, gleiche Beweiskraft. Ziel ist ein Datensatz, der nach einem Update, nach einem CMOS-Reset oder auf einem zweiten System vergleichbar bleibt.

Erfassungsrahmen: Voraussetzungen, Kontrollvariablen und Identität des Setups

Vor der eigentlichen Aufnahme muss der Firmware-Kontext eingefroren werden. Dazu gehören Boardmodell, PCB-Revision, CPU-Stepping, bestückte RAM-Topologie, eingesetzte NVMe/SATA-Geräte und die verwendete Firmware-Buildnummer inklusive Build-Datum. Ebenso relevant sind Setup-Modi wie Advanced Mode, ein eventuell aktives Profil-Feature (z. B. gespeicherte User-Profile) und die Spracheinstellung, weil einige Hersteller Optionstexte sprachabhängig kürzen oder umbrechen. Für Vergleichbarkeit empfiehlt sich eine feste Systemsprache (typischerweise Englisch), sofern die Dokumentation auf exakten Strings basiert.

Die Aufnahme startet idealerweise aus einem definierten Ausgangszustand: entweder „Optimized Defaults“ oder ein zuvor gesichertes Profil. Wichtig ist die Trennung von „Default laut Hersteller“ und „Default auf diesem System“ (etwa durch automatische Memory-Training-Ergebnisse oder durch erkannte Geräte). Diese Unterscheidung verhindert, dass Geräteerkennung (z. B. ein im Setup als „Enabled“ sichtbares TPM durch aktiviertes Firmware-TPM) fälschlich als unveränderter Hersteller-Default interpretiert wird.

• Identifikatoren: BIOS Version, Build Date, Board Revision, ME/AGESA/SMU Version (sofern im Setup ausgewiesen) als feste Kopfzeile jeder Tabelle.
• Kontextfixierung: Setup-Sprache, Modus (EZ Mode vs. Advanced), aktivierte Profile (User Profile 1 etc.) und Boot-Modus (UEFI vs. CSM) als globale Metadaten.
• Beobachtungsfenster: Änderungen nur in einem Parameterblock pro Iteration; danach Speichern, Neustart, erneute Verifikation, um Nebenwirkungen (Training, Auto-Rules) sichtbar zu machen.

Menüpfad und Optionsname: String-Treue statt Paraphrase

Für die spätere Diagnose muss jede Option mit ihrem exakten Menüpfad erfasst werden. Empfehlenswert ist eine Pfadnotation mit klarer Trennung der Ebenen und stabiler Bezugnahme auf die sichtbaren Menülabels, beispielsweise Advanced \ CPU Configuration \ Intel Virtualization Technology oder Settings \ IO Ports \ Above 4G Decoding. Bei Herstellern mit Registerkarten-Struktur sollte die oberste Ebene als Tab-Name dokumentiert werden. Falls ein Menüpunkt erst nach Entsperrung erscheint (z. B. durch „Advanced/Expert“-Toggle), ist diese Vorbedingung als Abhängigkeit zu notieren, nicht als Teil des Pfads.

Optionsbezeichnungen dürfen nicht in Funktionsbeschreibungen umformuliert werden. „CSM Support“ ist nicht gleichbedeutend mit „Legacy Boot“. Ebenso muss zwischen ähnlich klingenden Optionen unterschieden werden, etwa Intel VT-x vs. Intel VT-d oder Memory Fast Boot vs. Fast Boot. Wenn die UI den Text abschneidet, sollte der vollständige String über Foto/Export verifiziert oder als „UI-abgeschnitten“ markiert werden, ohne zu raten.

Default-Ermittlung: „Optimized Defaults“ vs. dynamische Auto-Werte

Default-Werte lassen sich nur dann belastbar dokumentieren, wenn die Quelle des Defaults angegeben wird. „Optimized Defaults“ ist ein definierter UI-Vorgang, aber kein Garant für identische resultierende Werte, weil viele Optionen intern auf Auto stehen und erst zur Bootzeit anhand von CPU, RAM-SPD/EXPO/XMP, PCIe-Topologie und Security-Status aufgelöst werden. Daher benötigt die Default-Spalte zwei Teilwerte: den sichtbaren UI-Default und den wirksamen Runtime-Zustand, sofern er ohne Spekulation ermittelbar ist.

Für die UI-Defaults gilt: CMOS löschen, erstes Boot ins Setup, „Load Optimized Defaults“, speichern, erneut ins Setup, dann erst dokumentieren. Für den Runtime-Zustand empfiehlt sich eine zusätzliche Evidenzspur aus Betriebssystem-Telemetrie, wo verfügbar. Beispiele sind Virtualisierung (sichtbar über CPU-Flags), Boot-Mode, Secure-Boot-Status oder IOMMU-Aktivierung. Wo ein OS-Signal mehrdeutig ist, wird es nicht als Default-Fakt verwendet, sondern als „Beobachtung nach Boot“ gekennzeichnet.

• UI-Default-Prozedur: Clear CMOS → erstes Setup → Load Optimized Defaults → Save & Exit → erneutes Setup für die Ablesung.
• Runtime-Evidenz (Windows, Beispiele): Confirm-SecureBootUEFI
msinfo32.exe (Felder „BIOS-Modus“, „Sicherer Startzustand“)
• Runtime-Evidenz (Linux, Beispiele): bootctl status
mokutil --sb-state
dmesg | grep -i -E "DMAR|IOMMU"

Versionierung und Änderungsverfolgung: Firmware-Updates, Profile und Drift

Firmware-Updates verändern nicht nur Defaults, sondern häufig auch Optionsnamen, Menühierarchien und Abhängigkeiten. Reproduzierbarkeit erfordert daher eine Versionierung auf mindestens drei Ebenen: Firmware-Version, Dokumentationsrevision und Exportzustand (Profil/Setup-Screenshot/Var-Export). Jede Tabelle sollte eine stabile interne Kennung erhalten, die sich nicht aus dem Menüpfad ableitet, weil Pfade bei Updates wandern können. Bei Abweichungen empfiehlt sich ein „Rename/Move“-Vermerk statt einer stillen Überschreibung, um historische Diagnosefälle nachvollziehbar zu halten.

Für die Praxis bewährt sich ein diff-fähiges Format als Primärquelle (z. B. CSV/JSON außerhalb der Firmware), während die veröffentlichte Tabelle als Snapshot fungiert. Wenn das Mainboard eine Exportfunktion für User-Profile anbietet, dient diese Datei als ergänzende Evidenz, ersetzt aber keine UI-String-Erfassung, da Profile je nach Hersteller nicht alle Optionen enthalten oder bestimmte Felder hardwareabhängig neu berechnen. Bei sicherheitsrelevanten Einstellungen (z. B. Secure Boot, TPM) muss zusätzlich dokumentiert werden, ob ein Update Schlüsselmaterial oder Statusflags zurücksetzt; diese Beobachtung ist strikt von „Default geändert“ zu trennen.

Tabellarische Referenz: CPU- und RAM-Parameter (Virtualisierung, SMT, C-States, XMP/EXPO, Gear Modes, Command Rate) mit Abhängigkeiten und typischen Fehlbildern

CPU- und RAM-Optionen im UEFI/BIOS wirken direkt auf Initialisierungspfad, Microcode-/AGESA-Trainingsabläufe, ACPI-Expose sowie auf die vom Betriebssystem nutzbaren Instruktions- und Energiesparzustände. Die Dokumentation dieser Parameter erfordert deshalb neben Menüpfaden und Default-Werten auch eine saubere Erfassung von Abhängigkeiten (z. B. zu IOMMU, Secure Boot/TPM nur indirekt, aber häufig in Troubleshooting-Ketten relevant) und typischen Fehlbildern, die sich als Boot-Loops, WHEA-Fehler, sporadische Reboots oder Hypervisor-Ausfälle äußern.

CPU-Features: Virtualisierung, SMT/Hyper-Threading, C-States (inkl. Abhängigkeiten)

Virtualisierung im UEFI besteht meist aus zwei Ebenen: CPU-Virtualisierung (Intel VT-x bzw. AMD SVM) und I/O-Virtualisierung (Intel VT-d bzw. AMD IOMMU). Erst die Kombination ermöglicht typische Hypervisor-Funktionen wie Gerätepassen (PCIe Passthrough) oder stabile VBS/HVCI-Konfigurationen unter Windows. SMT/Hyper-Threading steuert die logische Kernverdopplung und beeinflusst Scheduler-Topologien sowie L1/L2-Shared-Resource-Contention. C-States und Package-C-States greifen in die Power-Management-Policy ein, beeinflussen Latenzspitzen (Exit-Latenzen) und werden bei instabiler Spannungsversorgung oder aggressiven RAM-OC-Profilen häufig als erste Stellgröße testweise begrenzt.

RAM-Profilierung: XMP/EXPO, Training, Gear Modes, Command Rate

XMP (Intel) und EXPO (AMD) liefern SPD-basierte Profile für Takt, Primär-/Sekundärtimings und Spannung. Die Übernahme setzt ein stabiles Memory Training voraus; dieses wird durch BIOS-Version, IMC-Qualität, DIMM-Topologie (1DPC/2DPC), Rank-Konfiguration und SOC/IMC-Spannungsparameter beeinflusst. Gear Modes (Intel, je nach Plattform/DDR-Generation) bzw. MCLK:UCLK:FCLK-Teiler (AMD, plattformabhängig) steuern den Taktbezug zwischen Memory Controller und DRAM, während Command Rate (1T/2T, teils als CR geführt) die Befehlsadressierungstaktung und damit Stabilitätsreserven beeinflusst.

Diagnose- und Abhängigkeitsmatrix: typische Ketten aus Ursache, Einstellung und Symptom

Fehlkonfigurationen zeigen sich häufig nicht dort, wo die Ursache liegt. Ein instabiler RAM-Trainingszustand kann Virtualisierungsausfälle provozieren, weil Hypervisor-Workloads Speicherzugriffe deterministischer und aggressiver ausführen. Umgekehrt kann ein aktiviertes IOMMU bei bestimmten Plattformen zusätzliche Komplexität in den DMA-Pfaden einführen und Grenzstabilität sichtbar machen, die unter reinem Desktop-Betrieb unauffällig bleibt. Deshalb sollten Tabellen nicht nur Einzeloptionen, sondern auch typische Abhängigkeitsketten dokumentieren.

• Hypervisor startet nicht (Windows): Firmware-Virtualisierung prüfen: Intel (VMX) Virtualization Technology/SVM Mode; bei aktivierter VBS/Hyper-V Status via systeminfo („Virtualisierung in Firmware“).
• PCIe-Passthrough in Linux scheitert: Kombination aus IOMMU und CPU-Virtualisierung aktivieren; zusätzlich auf IOMMU-Expose im Kernel achten (z. B. Boot-Parameter intel_iommu=on oder amd_iommu=on nur, wenn das Betriebssystem-Setup dies erfordert).
• Boot-Loop nach Aktivierung von XMP/EXPO: zuerst Command Rate auf 2T oder Gear/Controller-Teiler auf Auto setzen; danach Taktstufe reduzieren, statt Timings blind zu verschärfen.
• Idle-Freezes oder Reboots ohne Last: tiefe Zustände in Package C-State Limit testweise begrenzen; wenn Stabilität zurückkehrt, Spannungs-/Training-Parameter (SoC/IMC, DRAM) und BIOS-Version als Primärursache erfassen.
• Unerwartet hohe Latenzen trotz hohem DRAM-Takt: bei Intel Gear Mode (Gear 2) bzw. bei AMD MCLK:UCLK (1:2) dokumentieren; solche Teiler können Bandbreite erhöhen, aber Round-Trip-Latenz verschlechtern.

Tabellarische Referenz: PCIe-, Storage- und Boot/Security-Optionen (Above 4G Decoding, Re-Size BAR, AHCI/RAID, CSM, Secure Boot, TPM) inklusive Auswirkungen auf Kompatibilität und Sicherheit

Die folgenden Tabellen erfassen typische UEFI-Menüoptionen, wie sie auf aktuellen Desktop- und Workstation-Plattformen (AMD Ryzen/Threadripper, Intel Core/Xeon-W) üblich sind. Menüpfade und Bezeichnungen variieren je nach Hersteller; entscheidend sind Funktionsname, zulässige Parameterwerte, Default-Verhalten und Abhängigkeiten. Für Diagnosezwecke sind insbesondere Wechselwirkungen zwischen CSM, Secure Boot, TPM, Above 4G Decoding und Re-Size BAR relevant, weil sie Boot-Ketten, Treibermodus (UEFI vs. Legacy), Adressraumverwaltung und Sicherheitsmerkmale gemeinsam beeinflussen.

PCIe/PCI Subsystem: Adressraum, BAR-Größen, Initialisierung

PCIe-Geräte benötigen MMIO-Adressraum, der beim POST durch Firmware-Ressourcenzuweisung festgelegt wird. Hochleistungs-GPUs, mehrere NVMe-Controller, Capture-Karten oder SR-IOV-fähige NICs erhöhen den Bedarf an 64‑Bit-MMIO deutlich. Above 4G Decoding (auch „64-bit MMIO“) schaltet die Zuweisung oberhalb der 4‑GiB-Grenze frei und ist damit Grundvoraussetzung für viele moderne Konfigurationen, insbesondere in Kombination mit Re-Size BAR und großen VRAM-Mappings.

• Diagnosehinweis (Windows): Relevante Boot- und Firmwareindikatoren lassen sich ohne Eingriff über msinfo32 (Felder „BIOS-Modus“, „Sicherer Startzustand“) und über Get-Tpm in PowerShell prüfen.
• Diagnosehinweis (Linux): UEFI-Modus ist typisch über das Vorhandensein von /sys/firmware/efi erkennbar; PCIe-Link-Status und AER/WHEA-Äquivalente werden u. a. via lspci -vv und Kernel-Logs ausgewertet.
• Interoperabilität: Bei Problemen nach Aktivierung von Re-Size BAR zuerst CSM deaktivieren/UEFI erzwingen, danach Above 4G Decoding aktivieren, anschließend Slot-/Link-Speed auf Auto zurücksetzen und nur bei Bedarf gezielt absenken.

Storage: AHCI, RAID, NVMe-Boot und Treiberbindung

Storage-Optionen beeinflussen weniger die Rohleistung einzelner NVMe-SSDs als vielmehr Bootfähigkeit, Treiberpfad und Wiederherstellbarkeit. Bei SATA-Ports entscheidet SATA Mode (AHCI vs. RAID) darüber, ob das Betriebssystem den Standard-AHCI-Treiber nutzt oder an einen herstellerspezifischen RAID-/VMD-Stack gebunden wird. Ein späterer Wechsel des Modus führt häufig zu Bootfehlern, weil der benötigte Treiber zum Bootzeitpunkt nicht geladen wird.

Boot, CSM und Security-Bausteine: Secure Boot, TPM/fTPM, Boot-Policy

CSM (Compatibility Support Module) schaltet Legacy-Bootmechanismen frei, einschließlich 16‑Bit/Legacy-Option-ROM-Ausführung. Das verbessert Kompatibilität zu älteren Erweiterungskarten, durchbricht aber das konsistente UEFI-Startmodell und steht häufig im Konflikt mit Secure Boot. Secure Boot validiert im UEFI-Bootprozess signierte Komponenten (z. B. Bootloader) anhand von Schlüsseldatenbanken. TPM 2.0 (diskret oder Firmware-TPM wie Intel PTT/AMD fTPM) dient als Root of Trust für Messungen/Schlüsselmaterial und ist Voraussetzung für Funktionen wie BitLocker mit TPM-Schutz sowie diverse Attestation- und Credential-Mechanismen.

• Schlüssel- und Update-Implikation: Secure Boot hängt von aktuellen Sperrlisten (dbx) ab; Firmware-Updates können die akzeptierten Bootloader-Versionen einschränken, was bei älteren Rettungsmedien zu Startabbrüchen führt.
• Kompatibilitätsmuster: UEFI-Installation auf GPT verlangt CSM = Disabled und Boot Mode = UEFI Only; Legacy-MBR-Installationen verlangen das Gegenteil und vertragen sich nicht mit Secure Boot.
• TPM-Lifecycle-Risiko: Aktionen wie Clear TPM oder Wechsel von PTT/fTPM zu diskretem TPM ändern die Trust-Basis; Schutzmechanismen wie BitLocker reagieren dann typischerweise mit Recovery-Anforderung.