Hier sind die Probleme mit PCI-Options-ROMs in der ARM-Architektur:
- Ein in x86-Assembly geschriebenes Options-ROM kann von einer ARM-CPU nicht verstanden werden.
- Option-ROMs, die von PC-BIOSen ausgeführt werden sollen (solche ROMs beginnen mit
0x55AAund verfügen über ein paar Bytes für Prüfsumme und zusätzliche Informationen), gehen von Details der PC-Architektur aus, z. B. VGA-Hardware, Intel-CPU-E / A-Ports usw. - Das gesamte BIOS-Konzept war eng mit der x86-CPU- und PC-Architektur verbunden und wurde für kein ARM-System verwendet.
Jetzt ...
UEFI, der BIOSes-Nachfolger ist für andere CPUs als x86 vorgesehen.
Die Lösung für die oben genannten Probleme war EFI-Bytecode - ein Bytecode, der von einer Laufzeit in der UEFI interpretiert werden würde, wodurch der Code unabhängig von der CPU wurde.
ARM-Systeme, die UEFI verwenden, sind relativ neu (die Surface RT könnte sogar das einzige derartige System sein). Die meisten ARM-Systeme verwenden CFE, U-Boot oder andere Boot-Firmware, die nicht wie PC-BIOS funktionieren.
Wenn das PCIe-Gerät jetzt in eine ARM-Maschine eingesteckt wird, konnte es nicht initialisiert werden?
Sie hätten nicht einmal eine Chance, es sei denn, das ARM-System würde UEFI verwenden. Wenn ja, würde Ihr System wahrscheinlich beim Booten hängen bleiben. EBC wird in der Boot-ROM-Firmware nicht häufig verwendet.
Während das Boot-ROM nicht funktionieren würde, würde ein Betriebssystem, das später bootet, die Hardware immer noch erkennen und verwenden können.
Was macht ein Boot-ROM?
Das alte BIOS vor UEFI implementierte eine API über den x86-Interrupt-Mechanismus. Ihr Programm muss verschiedene x86-Register als Parameter festlegen und dann eine x86- INTAnweisung ausgeben .
INTveranlasst die x86-CPU, eine Adresse in einer Tabelle nachzuschlagen, und überträgt die Steuerung darauf (dies wird als Software-Interrupt bezeichnet - Hardware kann dazu führen, dass mit einem Interrupt-Controller gesprochen wird, der ebenfalls mit der CPU verbunden ist).
Vor der Verarbeitung von Options-ROMs füllt das BIOS diese Tabelle mit verschiedenen Adressen, die wieder in das BIOS gehen und API-Funktionen ausführen.
MS-DOS verwendet Tabelle ausgiebig auf der BIOS für seine ursprüngliche Funktion zu verlassen - ein B asic I Nput / O utput S ystem. Andere Betriebssysteme verwenden keine BIOS-Aufrufe, wenn sie die Kontrolle haben. Sie verwenden ihre eigenen Treiber und Mechanismen zum Treiben von Hardware.
Da sich diese Interrupt-Tabelle im RAM befindet, kann sie geändert werden. Option-ROMs könnten sich in die Interrupt-Tabelle "einhaken" - die Adresse eines bestimmten Interrupts mit etwas im ROM überschreiben - und dazu führen, dass BIOS-API-Aufrufe zuerst an das Option-ROM gehen.
Ein BIOS-API-Aufruf, den das BIOS selbst verwendet 13h- dieser Aufruf liest einen Sektor von einem Plattengerät. Es ist erforderlich, Sektor 0 von einer Festplatte zu laden, um ein Betriebssystem (auch MS-DOS) zu starten.
Das BIOS kann mit Disketten- und IDE-Geräten sprechen, aber sonst nichts. Eine SCSI-Karte hätte ein optionales ROM, das neu geschrieben oder "angehängt" werden würde, 13hund das das Starten eines SCSI-Laufwerks ermöglichte. Wenn das Betriebssystem MS-DOS ist, kann MS-DOS mit dem SCSI-Laufwerk arbeiten, da es 13hfür Festplattenoperationen verwendet wird.
Netzwerkstart ist eine andere Situation, in der Option-ROMs verwendet werden.
Wenn ja, könnten die Treiber stattdessen dafür ausgelegt werden?
Ja, und sie tun es. BIOS-Options-ROMs unterstützen eigentlich nur das Booten eines Betriebssystems und optional eines Konfigurationsmenüs ("Drücke Strg-A, um die RAID-Konfiguration aufzurufen" befindet sich im Option-ROM und Sie sehen es an dem Punkt, an dem das BIOS seinen Initialisierungscode aufruft).
IIRC Linux kümmert sich erneut um die Aufzählung von Geräten und ignoriert die Informationen des x86-BIOS
Windows macht das auch. Das x86-BIOS (und der x86-Realmodus) hing so lange herum wie für die MS-DOS-Unterstützung.