Sind PCIe-Geräte für den Einsatz in mehreren Plattformen und Architekturen ausgelegt?

Question 1

Dies sind die Probleme mit PCI-Option-ROMs auf der ARM-Architektur:

Ein in x86-Assembler geschriebenes Option-ROM kann von einer ARM-CPU nicht verstanden werden.
Option-ROMs, die vom PC-BIOS ausgeführt werden sollen (solche ROMs beginnen mit 0x55AAund enthalten einige Bytes für die Prüfsumme und zusätzliche Informationen), setzen Low-Level-Details der PC-Architektur voraus, wie etwa VGA-Hardware, Intel-CPU-E/A-Anschlüsse usw.
Das gesamte BIOS-Konzept war eng mit der x86-CPU und PC-Architektur verbunden und wurde nie für ein ARM-System verwendet.

Jetzt ...

UEFI, der Nachfolger des BIOS, ist für die Verwendung auf anderen CPUs als x86 vorgesehen.
Die Lösung für die oben genannten Probleme warEFI-Bytecode– ein Bytecode, der von einer Laufzeit im UEFI interpretiert würde, wodurch der Code CPU-unabhängig würde.
ARM-Systeme, die UEFI verwenden, sind relativ neu (das Surface RT ist möglicherweise sogar das einzige derartige System). Die meisten ARM-Systeme verwenden CFE, U-Boot oder andere Boot-Firmware, die nicht wie PC-BIOS funktionieren.

Wenn ich es jetzt an eine ARM-Maschine anschließe, kann die Initialisierung des PCIe-Geräts dann fehlschlagen?

Sie hätten nicht einmal eine Chance, es sei denn, das ARM-System würde UEFI verwenden. Wenn dies der Fall wäre, würde Ihr System wahrscheinlich beim Booten hängen bleiben. EBC wird in Boot-ROM-Firmware nicht häufig verwendet.

Auch wenn das Boot-ROM nicht funktionieren würde, würde ein später gestartetes Betriebssystem die Hardware dennoch erkennen und problemlos nutzen können.

Was macht ein Boot-ROM?

Das alte BIOS vor UEFI implementierte eine API über den x86-Interruptmechanismus. Ihr Programm müsste verschiedene x86-Register als Parameter festlegen und dann eine x86- INTAnweisung ausgeben.

INTveranlasst die x86-CPU, eine Adresse in einer Tabelle nachzuschlagen und ihr dann die Kontrolle zu übertragen (dies nennt manSoftware-Interrupt- Die Hardware kann dies verursachen, indem sie mit einem Interrupt-Controller kommuniziert, der ebenfalls an die CPU angeschlossen ist).

Vor der Verarbeitung von Option-ROMs füllt das BIOS diese Tabelle mit verschiedenen Adressen, die zurück zum BIOS gehen und API-Funktionen ausführen.

MS-DOS verwendet Tabellen in großem Umfang und verlässt sich bei der ursprünglichen Funktion auf das BIOS - eineBasicICHEingabe/ÖAusgabeSystem. Andere Betriebssysteme verwenden keine BIOS-Aufrufe, sobald sie die Kontrolle haben, sondern verwenden ihre eigenen Treiber und Mechanismen zum Ansteuern der Hardware.

Da sich diese Interrupt-Tabelle im RAM befindet, kann sie geändert werden. Option-ROMs könnten sich in die Interrupt-Tabelle einklinken – indem sie die Adresse eines bestimmten Interrupts durch etwas im ROM überschreiben – und dafür sorgen, dass BIOS-API-Aufrufe zuerst an das Option-ROM gehen.

Ein BIOS-API-Aufruf, den das BIOS selbst verwendet, ist 13h: Dieser Aufruf liest einen Sektor von einem Festplattengerät. Er ist erforderlich, um Sektor 0 von einer Festplatte zu laden, um ein Betriebssystem (sogar MS-DOS) zu starten.

Das BIOS kann mit Disketten- und IDE-Geräten kommunizieren, aber sonst nichts. Eine SCSI-Karte hätte ein Option-ROM, das neu geschrieben oder „eingehängt“ werden könnte 13h– und das es ermöglicht, von einem SCSI-Laufwerk zu booten. Wenn das Betriebssystem MS-DOS ist, könnte MS-DOS mit dem SCSI-Laufwerk arbeiten, da es 13hfür Festplattenoperationen verwendet würde.

Auch beim Netzwerkbooten kommen Option-ROMs zum Einsatz.

Wenn ja, ist es möglich, die Treiber so zu gestalten, dass sie sich stattdessen darum kümmern?

Ja, und das tun sie. BIOS-Option-ROMs unterstützen eigentlich nur das Booten eines Betriebssystems und optional ein Konfigurationsmenü (die Anweisung „Drücken Sie Strg-A, um die RAID-Konfiguration aufzurufen“ stammt aus dem Option-ROM und wird an der Stelle angezeigt, an der das BIOS seinen Initialisierungscode aufruft).

Wenn ich mich richtig erinnere, kümmert sich Linux wieder um die Aufzählung der Geräte und ignoriert die Informationen aus dem x86-BIOS weitgehend.

Windows macht das auch. Das x86-BIOS (und der x86-Realmodus) blieben ebenso lange bestehen wie die MS-DOS-Unterstützung.

Answer

Dies sind die Probleme mit PCI-Option-ROMs auf der ARM-Architektur:

Ein in x86-Assembler geschriebenes Option-ROM kann von einer ARM-CPU nicht verstanden werden.
Option-ROMs, die vom PC-BIOS ausgeführt werden sollen (solche ROMs beginnen mit 0x55AAund enthalten einige Bytes für die Prüfsumme und zusätzliche Informationen), setzen Low-Level-Details der PC-Architektur voraus, wie etwa VGA-Hardware, Intel-CPU-E/A-Anschlüsse usw.
Das gesamte BIOS-Konzept war eng mit der x86-CPU und PC-Architektur verbunden und wurde nie für ein ARM-System verwendet.

Jetzt ...

UEFI, der Nachfolger des BIOS, ist für die Verwendung auf anderen CPUs als x86 vorgesehen.
Die Lösung für die oben genannten Probleme warEFI-Bytecode– ein Bytecode, der von einer Laufzeit im UEFI interpretiert würde, wodurch der Code CPU-unabhängig würde.
ARM-Systeme, die UEFI verwenden, sind relativ neu (das Surface RT ist möglicherweise sogar das einzige derartige System). Die meisten ARM-Systeme verwenden CFE, U-Boot oder andere Boot-Firmware, die nicht wie PC-BIOS funktionieren.

Wenn ich es jetzt an eine ARM-Maschine anschließe, kann die Initialisierung des PCIe-Geräts dann fehlschlagen?

Sie hätten nicht einmal eine Chance, es sei denn, das ARM-System würde UEFI verwenden. Wenn dies der Fall wäre, würde Ihr System wahrscheinlich beim Booten hängen bleiben. EBC wird in Boot-ROM-Firmware nicht häufig verwendet.

Auch wenn das Boot-ROM nicht funktionieren würde, würde ein später gestartetes Betriebssystem die Hardware dennoch erkennen und problemlos nutzen können.

Was macht ein Boot-ROM?

Das alte BIOS vor UEFI implementierte eine API über den x86-Interruptmechanismus. Ihr Programm müsste verschiedene x86-Register als Parameter festlegen und dann eine x86- INTAnweisung ausgeben.

INTveranlasst die x86-CPU, eine Adresse in einer Tabelle nachzuschlagen und ihr dann die Kontrolle zu übertragen (dies nennt manSoftware-Interrupt- Die Hardware kann dies verursachen, indem sie mit einem Interrupt-Controller kommuniziert, der ebenfalls an die CPU angeschlossen ist).

Vor der Verarbeitung von Option-ROMs füllt das BIOS diese Tabelle mit verschiedenen Adressen, die zurück zum BIOS gehen und API-Funktionen ausführen.

MS-DOS verwendet Tabellen in großem Umfang und verlässt sich bei der ursprünglichen Funktion auf das BIOS - eineBasicICHEingabe/ÖAusgabeSystem. Andere Betriebssysteme verwenden keine BIOS-Aufrufe, sobald sie die Kontrolle haben, sondern verwenden ihre eigenen Treiber und Mechanismen zum Ansteuern der Hardware.

Da sich diese Interrupt-Tabelle im RAM befindet, kann sie geändert werden. Option-ROMs könnten sich in die Interrupt-Tabelle einklinken – indem sie die Adresse eines bestimmten Interrupts durch etwas im ROM überschreiben – und dafür sorgen, dass BIOS-API-Aufrufe zuerst an das Option-ROM gehen.

Ein BIOS-API-Aufruf, den das BIOS selbst verwendet, ist 13h: Dieser Aufruf liest einen Sektor von einem Festplattengerät. Er ist erforderlich, um Sektor 0 von einer Festplatte zu laden, um ein Betriebssystem (sogar MS-DOS) zu starten.

Das BIOS kann mit Disketten- und IDE-Geräten kommunizieren, aber sonst nichts. Eine SCSI-Karte hätte ein Option-ROM, das neu geschrieben oder „eingehängt“ werden könnte 13h– und das es ermöglicht, von einem SCSI-Laufwerk zu booten. Wenn das Betriebssystem MS-DOS ist, könnte MS-DOS mit dem SCSI-Laufwerk arbeiten, da es 13hfür Festplattenoperationen verwendet würde.

Auch beim Netzwerkbooten kommen Option-ROMs zum Einsatz.

Wenn ja, ist es möglich, die Treiber so zu gestalten, dass sie sich stattdessen darum kümmern?

Ja, und das tun sie. BIOS-Option-ROMs unterstützen eigentlich nur das Booten eines Betriebssystems und optional ein Konfigurationsmenü (die Anweisung „Drücken Sie Strg-A, um die RAID-Konfiguration aufzurufen“ stammt aus dem Option-ROM und wird an der Stelle angezeigt, an der das BIOS seinen Initialisierungscode aufruft).

Wenn ich mich richtig erinnere, kümmert sich Linux wieder um die Aufzählung der Geräte und ignoriert die Informationen aus dem x86-BIOS weitgehend.

Windows macht das auch. Das x86-BIOS (und der x86-Realmodus) blieben ebenso lange bestehen wie die MS-DOS-Unterstützung.

Question 2

Die meisten PCIe-Geräte mit integrierter Firmware sind x86-spezifisch.
Die integrierte Firmware ist für die Zusammenarbeit mit einer Intel-kompatiblen Umgebung konzipiert.

Es gibt Geräte für andere Architekturen. Hauptsächlich GPU-, Speicher-/RAID- und Netzwerkkarten. Bei einigen davon kann die Firmware sogar durch Flashen von einer Architektur zur anderen gewechselt werden. Andere sind Dual-Firmware und können je nach Bedarf zwischen den Architekturen wechseln.
Ich habe sogar einige RAID-Controller gesehen, die (beim Booten aus der UEFI-Umgebung) mit der passenden Firmware für die Architektur geladen werden konnten, in der sie installiert wurden. Die
meisten davon sind für Rechenzentren geeignet und sehr teuer. Nichts, was der durchschnittliche Benutzer in freier Wildbahn jemals antreffen wird.

Bei Geräten ohne integrierte Firmware (oder besser gesagt: mit integrierter Firmware, die nicht mit dem Hostsystem interagiert) ist es möglich, dass sie in jeder Architektur funktionieren, für die es Treiber gibt.

Answer

Die meisten PCIe-Geräte mit integrierter Firmware sind x86-spezifisch.
Die integrierte Firmware ist für die Zusammenarbeit mit einer Intel-kompatiblen Umgebung konzipiert.

Es gibt Geräte für andere Architekturen. Hauptsächlich GPU-, Speicher-/RAID- und Netzwerkkarten. Bei einigen davon kann die Firmware sogar durch Flashen von einer Architektur zur anderen gewechselt werden. Andere sind Dual-Firmware und können je nach Bedarf zwischen den Architekturen wechseln.
Ich habe sogar einige RAID-Controller gesehen, die (beim Booten aus der UEFI-Umgebung) mit der passenden Firmware für die Architektur geladen werden konnten, in der sie installiert wurden. Die
meisten davon sind für Rechenzentren geeignet und sehr teuer. Nichts, was der durchschnittliche Benutzer in freier Wildbahn jemals antreffen wird.

Bei Geräten ohne integrierte Firmware (oder besser gesagt: mit integrierter Firmware, die nicht mit dem Hostsystem interagiert) ist es möglich, dass sie in jeder Architektur funktionieren, für die es Treiber gibt.

Question 3

OptionROM kann mehrere Codebilder haben

Die UEFI-Spezifikation enthält einige Erklärungen zum Zweck eines solchen Multi-Image-ROM:

The following is a list of the image combinations that may be placed in a PCI option
ROM. This is not an exhaustive list. Instead, it provides what will likely be the most common PCI option
ROM layouts. EFI complaint system firmware must work with all of these PCI option ROM layouts, plus
any other layouts that are possible within the PCI Firmware Specification. The format of a Legacy Option
ROM image is defined in the PCI Firmware Specification.
• Legacy Option ROM image
• IA-32 UEFI driver
• x64 UEFI driver
• AArch32 UEFI driver
• AArch64 UEFI driver
• Legacy Option ROM image + x64 UEFI driver
• Legacy Option ROM image + x64 UEFI driver + AArch64 UEFI driver
• x64 UEFI driver + AArch64 UEFI driver
• Itanium Processor Family UEFI driver
• EBC Driver
In addition to combinations of UEFI drivers with different processor binding, it is also possible to include
multiple drivers of different function but the same processor binding.

(https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf)

Wie Sie sehen, kann OptionROM Bilder für verschiedene Architekturen haben. Beispielsweise kann ein PCI-Gerät Codebilder sowohl für ARM als auch für x86 haben.

Die System-Firmware kann die Headerstrukturen von Code-Bildern analysieren und nach dem richtigen Maschinentyp suchen.

Aber obwohl dieses Feld in edk2 definiert ist: https://github.com/tianocore/edk2/blob/0ecdcb6142037dd1cdd08660a2349960bcf0270a/MdePkg/Include/IndustryStandard/Pci22.h#L845 es scheint nicht, dass es tatsächlich verwendet wird: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c

Aktualisieren:

Lesen Sie diesen Leitfadenhttps://www.workofard.com/2020/12/aarch64-option-roms-for-amd-gpus/

Es wird erklärt, wie der AMD AARCH64 Gop-Treiber als weiteres Code-Image zum OptionROM der PCI-Grafikkarte hinzugefügt wird, damit die Grafikkarte beim Booten in AArch64-Systemen funktioniert.

Answer