Server mit freier Firmware - D16 - Teil 2.2

In Teil 1 bin ich, soweit in der Kürze möglich, auf die Eigenheiten des KGPE-D16 Mainboards von Asus eingegangen. Teil 2.1 zeigt in groben Schritten den Buildprozess des aktuellen Libreboot und dessen essenzielle Grundlagen auf.

Dieser Teil enthält die wichtigsten Eigenheiten in Bezug auf das D16. Auch für diesen Kurzartikel gilt:

Fast alle Angaben in diesem Artikel beziehen sich lediglich auf das D-16 und sind nur als grober Anriss zu betrachten. Alles andere würde den Rahmen eines Blogbeitrags bei weitem übersteigen.

Anpassungen

PIKE - Erweiterungen

Anbei noch einmal die Kurzfassung der bereits in Teil 1 unter PIKE - Erweiterungen erläuterten Punkte.

Um die auf dem Bord des KGPE-D16 o.a. SAS Steckplätze zu verwenden, wird ein PIKE Module benötigt. Ist eine SAS v2 Nutzung vorgesehen, kommt nur das ASUS PIKE 2008 infrage. Die Geschwindigkeiten, sind natürlich dem Releasejahr des Bords entsprechend.

Jedoch sind 120MByte/sec (Netto) pro HDD/SDD bei einer Verwendung von 4 Festplatten auf einen SAS Anschluss, je nach Einsatzzweck, völlig ausreichend.

Hinweis: Die Firmware der jeweiligen Karten ist immer proprietär (D-16).

The optional PIKE add-on cards use ARM cores to handle the SAS protocol, though this firmware is directly loaded from a Flash chip on the module and does not involve any non-local components (e.g. the main CPU never touches the firmware on these modules outside of a manual reflash operation). Raptor Engineering is currently unaware of any SAS controllers that operate without a secondary processor or use libre firmware; the protocol is simply too complex to handle via a mask ROM, and as there are only one or two suppliers of SAS controllers there is very little incentive to release the source code to the firmware. Writing a libre firmware to replace the existing firmware may technically be possible, however it is extremely unlikely this will ever happen due to the man-decades required.

Quelle: https://www.coreboot.org/Board:asus/kgpe-d16#Processor_Summary

Libreboot

Da das jeweilige PIKE Modul eine PCI-Erweiterungskarte ist, wird sie während des Bootvorgangs initialisiert. Dazu wird dessen Rom geladen. Genau in diesem Moment friert Libreboot ein. Um diesen Bug zu umgehen, wird im verwendeten Libreboot-Rom die Anweisung hinterlegt, dass alle PCI-Steckplätze bis zum Ende des Bootprozesses (des Libreboot-ROMs) nicht betrachtet werden. Genauer gesagt werden die sogenannten Option-ROMs der jeweiligen PCI-Karten nicht geladen und somit auch nicht initialisiert.

Für die Beeinflussung dessen während der Laufzeit ist die Option pci-optionrom-exec verantwortlich.
Regulär wurde diese Option im Stable-Zweig (2016) und im jetzigen Testing-Zweig von Libreboot auf 2 gesetzt.

Die Optionen sind:

• 0 => es werden keine Option-ROMs geladen
• 1 => es werden nur VGA-ROMs geladen
• 2 => es werden alle Option-ROMs geladen

Daher muss bei einer Nutzung diese Option auf 0 gesetzt werden. Hierfür wird das cbfstool genutzt.

Es liegt, sobald coreboot, wie in Teil 2.1 beschrieben, heruntergeladen und cbutils mit ./build module cbutils gebaut wurde, in ~/lbmk/coreboot/default/util/cbfstool/cbfstool vor.

In Bezug auf das gebaute Rom bietet das cbfstool viele Möglichkeiten. Es können Dateien jedweder Art hinzugefügt, entpackt, angezeigt sowie einzelne Texte (chars, int, etc.) hinzugefügt werden. Darüber hinaus bietet es noch viele weitere nicht genannte Möglichkeiten. Einen groben Umriss liefert die Ausgabe von:

./coreboot/default/util/cbfstool/cbfstool -h

Um sich einen kleinen Überblick zu verschaffen, lassen sich alle innerhalb des ROMs enthaltenen Dateien mit folgendem Befehl abbilden:

./coreboot/default/util/cbfstool/cbfstool print

Um den genannten Wert eines bereits gebauten ROMs zu überprüfen, wird die Datei pci-optionrom-exec aus diesem entpackt:

./coreboot/default/util/cbfstool/cbfstool bin/grub_kgpe-d16-rdimm_2mb_libgfxinit_txtmode_deqwertz.rom extract -v -n etc/pci-optionrom-exec -f pci-optionrom-exec

Da der Inhalt jedoch hexadezimal codiert ist, erfolgt keine aufschlussreiche Ausgabe mit einem Standardeditor. Daher kann man sich durch hexdump behelfen:

hexdump pci-optionrom-exe

Dieses Rom wird also ohne weitere Konfiguration automatisch alle Option-ROMs laden die es findet. Um die Option auf 0 zu setzten und somit das Laden vollständig auszuschliessen, kann einfach der integer Wert geändert werden.

Schematischer Befehl:

cbfstool §libreboot.rom add-int -i 0 -n etc/pci-optionrom-exec 

Befehl in Bezug auf mein Beispiel:

./coreboot/default/util/cbfstool/cbfstool bin/grub_kgpe-d16-rdimm_2mb_libgfxinit_txtmode_deqwertz.rom add-int -i 0 -n etc/pci-optionrom-exec

Wird sich für diese Lösung entschieden, muss das zum Booten verwendete Linux jedoch an den Standard SATA Ports angeschlossen werden.

Weiterhin ist zu bedenken, dass bei einer Vollverschlüsselung, die Passworteingabe blind eingegeben werden muss, da die interne Grafikkarte lediglich im Textmodus arbeitet und das externe Option-ROM (der externen Grafikkarte) erst nach der Initialisierung des Linux Kernels und somit erst nach der richtigen Eingabe des Passworts geladen wird.

Bei Libreboot unstable (2016 - 2020) ist das Laden von Option-ROMs deaktiviert. In früheren Releases mit SeaGRUB (20160818-20160907) jedoch nicht. Wie im oberen Bereich aufgezeigt, ist diese Option in der aktuellen lbmk Version (Stand 14.08.2021) auf den Wert 2 gesetzt.

Nur das Option-Rom des PIKE-2008 Moduls laden:

Unter SeaBios besteht auch die Möglichkeit, ganz bestimmte externe Option-ROMs auszulassen und somit nicht zu laden. Hierzu wird die Product ID und die Vendor ID des gewünschten ROMs benötigt. Diese lassen sich mit lspci -nn anzeigen.

In meinem Fall erhalte ich in Bezug auf das PIKE 2008 folgende Ausgabe:

05:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03)

Interessant ist dieser Teil der Zeile: [1000:0072]. Der erste Teil gibt die Vendor ID an und der zweite die Product ID. Nun ist es lediglich erforderlich eine leere Datei nach dem Schema pciVVVV:DDDD.rom zu erstellen.

In meinem Beispiel lege ich die Datei mit touch pci1000:0072.rom an und füge diese dem bereits in Teil 2.1 erstellen Rom kgpe-d16-rdimm_2mb.rom hinzu.

Schematisch:

cbfstool $your.rom add -n $pciVVVV,DDDD.rom -f $pciVVVV,DDDD.rom -t raw

Der Befehl lautet also:

./coreboot/default/util/cbfstool/cbfstool bin/seabios_grubfirst_kgpe-d16-rdimm_2mb_libgfxinit_txtmode_deqwertz.rom add -n pci1000:0072.rom -f pci1000:0072.rom -t raw

Wenn bei einem Bootvorgang, die leere Datei $pciVVVV:DDDD.rom innerhalb des CBFS gefunden wird, lädt SeaBIOS diese Datei, anstatt zu versuchen, ein Option-ROM aus dem im Namen dieser Datei adressierten Gerät zu extrahieren.

Zusätzlich zu dieser Umgehung ist eine Verwendung dieser Option sinnvoll, um Option-ROMs für On-Board-Geräte, die keine eigenen ROMs speichern, bereitzustellen.

Aussicht

In weiteren Teilen werde ich etwas genauer auf den Aufbau des Coreboot Filesystems (CBFS) und Flashmap (FMAP) eingehen.

Auch können weitere Teile über die allgemeine Verwendung des cbfstools folgen.