Server mit freier Firmware - D16 - Teil 2.1

In Teil 1 bin ich, soweit in der Kürze möglich, auf die groben Eigenheiten des KGPE-D16 Mainboards von Asus eingegangen.

In diesem Teil gehe ich in groben Schritten auf den Buildprozess der aktuellen Libreboot-Firmware und deren essenzielle Grundlagen ein. Im kommenden Teil 2.2 folgen 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 Asus D-16 Mainboard und sind nur als grober Überblick zu betrachten. Alles andere würde den Rahmen eines Blogbeitrags bei weitem sprengen.

Vorab möchte ich jedoch eine Ergänzung zu Teil 1 beifügen:

Für die Stromversorgung der beiden CPUs des KGPE-D-16 darf kein Adapter verwendet werden. Im geringsten Fall können spontane Reboots auftreten. Im schlimmsten Fall, können durch die Dauerbelastung Teile der Adapter starke Hitze entwickeln, auf die nicht selten eine Selbstentzündung folgt. Die Wahrscheinlichkeit eines Defektes würde ich als hoch einstufen. Daher bitte nur auf die meist der PSU beigelegten 8 pin CPU Power Connector (4+4) zurückgreifen.

lbmk - librebootmake und Struktur - grobkörnig dargestellt

Kurze Vorgeschichte

Weit vor dem Release von lbmk wurde osbmk veröffentlicht. Osboot ist durch den Fork der letzten stabilen Libreboot-Version und darauf aufbauenden tiefgreifenden Änderungen entstanden. lbmk baut auf osbmk auf, verzichtet jedoch auf Blobs (proprietäre Binaries) wie beispielsweise microcode bzw. microcode updates.

Hauptintention beider Projekte war neben der Wiederbelebung, einzelne Zweige ausgenommen,  die Gewinnung neuer Maintainer und Entwickler für Libreboot. Nun ist ein relativ sanfter Übergang von coreboot über osboot zu Libreboot erkennbar.

Während des Schreibens neuer Scripts, sowie der Anpassungen bestehender Scripts aus Libreboot von 2016, ist der jeweilige Buildprozess hauptsächlich mit Debian Buster getestet worden. Da ich u.a. vorab osbmk genutzt habe und nach der Veröffentlichung von lbmk direkt mit dessen Nutzung begann, bin ich auch nicht von Buster abgerückt. Anfangs gab es laut IRC wohl einige Probleme mit anderen Distributionen (u.a. auch Bullseye). Zum Teil sind mittlerweile Anpassungen innerhalb aller Bashscripts in lbmk vorgenommen worden, sodass auch die Nutzung auf neueren oder alternativen Betriebssystemen möglich ist (bspw. durch [/bin/bash & /usr/bin/env/bash]).

osbmk ist äquivalent in diesen Punkten.

Struktur

Diese ist relativ selbsterklärend.

Anzeige nur mit Ordnern:

Vorbereitung

Vorerst benötigen wir lediglich das Paket git, je nach Distribution muss es mit apt / pkg / oder beispielsweise dnf installiert werden. Daraufhin wird lbmk aus dem Git-Repository geklont:

git clone https://notabug.org/libreboot/lbmk.git
cd lbmk

Für ein Debian basierendes System sind für den Bau folgende Pakete erforderlich:

apt-get -y install wget
# For  documentation
apt-get -y install pandoc

# For Tianocore and iPXE
apt-get -y install uuid-dev nasm

# For building source code:
apt-get -y install build-essential

# for running the crostool script (to get mrc.bin file for t440p)
apt-get -y install sharutils curl parted e2fsprogs unzip

# to use the right software versions and links for compiling 
apt-get -y install pkg-config

# for cross-compiling ARM binaries
apt-get -y install gcc-arm-linux-gnueabi

# For cross-compiling i686 target on x86_64 host.
apt-get -y install gcc-multilib libc6-i386 libc6-dev-i386
apt-get -y install lib32stdc++6 g++-multilib dh-autoreconf
apt-get -y install lib32tinfo-dev

# Memtest86+ build dependencies
apt-get -y install build-essential python2.7

# i945-pwm build dependencies
apt-get -y install build-essential perl

# Coreboot build dependencies
apt-get -y install libncurses5-dev doxygen iasl gdb flex bison build-essential git libssl-dev gnat

# For cross-compiling i686 target on x86_64 host.
apt-get -y install lib32ncurses5-dev

# GRUB build dependencies (also requires build-essential, bison and flex)
apt-get -y install ttf-unifont libopts25 libselinux1-dev autogen m4 autoconf help2man libopts25-dev libfont-freetype-perl automake autotools-dev build-essential bison flex libfuse-dev liblzma-dev gawk libdevmapper-dev libtool libfreetype6-dev

# BucTS build dependencies (external script)
apt-get -y install build-essential

# Flashrom build dependencies (also requires build-essential)
apt-get -y install libpci-dev pciutils zlib1g-dev libftdi-dev build-essential libusb-1.0-0-dev libusb-1.0 libusb-1.0-0-dev libusb-dev

# For cross-compiling i686 target on x86_64 host.
apt-get -y install lib32z1-dev

Auch hier sind die Abhängigkeiten gerade für Einsteiger sehr übersichtlich unter den jeweiligen Programmen aufgeführt. Da lmbk die Möglichkeit bietet, ohne eine komplette Übersetzung der Quellen, nur gewünschte Programme und lediglich die hierzu zugehörigen Abhängigkeiten zu laden und zu bauen, erklärt sich auch die doppelte Nennung einzelner Ressourcen.

Alle o.g. Dependencies werden wie folgt installiert:

sudo ./build dependencies ubuntu2004

Nachfolgend benötigen wir für den Bau eines Roms mindestens coreboot, flashrom und je nach Einsatzzweck grub, seabios oder Tianocore, sowie bei Bedarf ich9utils (dazu später mehr; dies ist für den Bau des D16-Roms jedoch irrelevant) für das Einfügen der originalen MAC und memtest86plus. Es empfiehlt sich auch hier alles herunterzuladen:

./download all

Sollten nur einzelne Punkte davon benötigt werden, reicht beispielsweise ein einzelnes Laden (hier am Beispiel von Tianocore) mit:

./download tianocore

Welche Module gebaut werden können, erfährt man mit dem Befehl:

./build module list

Jetzt lassen wir die von lbmk gebrauchten Module mit folgendem Befehl bauen:

./build module all

Als Letztes müssen die Payloads gebaut werden. Wie bei download und module, lassen sich die möglichen Payloads mit list anzeigen. Gebaut werden sie mit:

./build payloads all

Build Roms

Da die Vorbereitungen nun abgeschlossen sind, kann mit dem eigentlichen Build begonnen werden. Es besteht die Möglichkeit fast alle Roms auf einmal bauen oder lediglich das Benötige auszuwählen. Ausschlaggebend sind folgende Punkte:

• die Grösse des Flashspeichers
• das Modell
• das verwendete RAM - RDIMM oder UDIMM (lediglich bei Boards der 15th Family ausschlaggebend), somit auch für das KGPE-D16

Der Hintergrund des Spilts auf rdimm und udimm wird mit einem Blick in die jeweiligen configs deutlich. Der Unterschied zwischen Beiden bezieht sich auf einen bestimmten Commit (610d1c67b2298a9840681c2b4492b6d3fdf44a46). Mit diesem laufen viele Unregistered DIMMs nicht, beziehungsweise es erfolgt keine Bildausgabe mehr.

Meines Wissens sind in den meisten D16 Boards 2MB Chips verbaut. Ein Tausch auf maximal 16MB Chips ist jedoch möglich.

Da in der Liste aus Teil 1 die verwendeten Module RDIMMs sind und auch mein BIOS Chip eine Grösse von 2MB aufzeigt, wurde das für die diese Hardware benötigte Rom kgpe-d16-rdimm_2mb gebaut:

./build boot roms kgpe-d16-rdimm_2mb

Die Roms der 15th Familie können momentan leider nur mit coreboot 4.11 erstellt werden. Alle anderen Roms basieren auf der aktuellen Stable Version 4.14.

Hintergrund ist hauptsächlich der leider momentan nicht mehr gepflegte AGESA code von AMD. Das ist u.a. auch ein Grund weshalb alle Boards dieser Familie aus dem aktuellen Stable Zweig von Coreboot entfernt worden sind.

Einen guten Kurzüberblick über die Einführung von AMD's AGESA und CIM-X sowie dessen Open Source Forks speziell für Coreboot findet man in einer interessanten Diskussion im Archiv der Mailingliste.

Weitere fehlende Implementierungen sind die neuen Features relocatable ramstage und postcar stage. Zusätzlich nutzt das D8 sowie das D16 noch die alte ROMCC Methode für den Bootblock (C_ENVIRONMENTAL_BOOTBLOCK).
Ein interessantes Interview über die Entstehung und Entwicklung von Coreboot ist auf h-online zu finden. Auf Seite drei wird explizit auf ROMCC eingegangen. Auf beijinglug.club findet man u.a. eine kleine Übersicht über die Initialisierung von Coreboot.

Bevor dieser Code nicht auf den aktuellen Stand gebracht wurde, wird die Version 4.11 verwendet, eventuelle zukünftige Bugs gefixt und nicht boardspezifische Features zurückportiert.

Die momentanen Releases von lmbk und osbmk sind lediglich Testreleases.   

Es bestehen durch aus noch einige Fehler, sei es die "einfache" Integration von Tianocore oder Rebootprobleme des T400 (nur im 20210522 Release, ein Build aus aktuellem Git-Repo ist nicht mehr betroffen) und Ausgabeschwierigkeiten einiger T400 mit zusätzlicher Grafikkarte (letzteres nur in osbmk), um nur einige zu nennen (Stand:  01.09.2021).

Ausgabe

Nachdem lbmk die gewünschte Auswahl gebaut hat, erhält man verschiedene Roms zur Auswahl:

Folgende Unterschiede bestehen zwischen den verschiedenen Roms (character-sets ausgenommen):

• grub
  Diese Roms beinhalten hauptsächlich GNU GRUB als payload. Zusätzliche Payloads wie bspw. memtest86+, SeaBIOS, Tianacore sind, falls im Buildprozess gewählt, als Menüpunkte auswählbar.
• seabios  
  Diese Roms beinhalten hauptsächlich SeaBIOS als Payload. Zusätzlich ist nur memtest86+, falls im Buildprozess gewählt, als weiteres Payload im Menüpunkt anwählbar.
• seabios_withgrub  
  ROM-Images mit seabios_withgrub im Namen, starten zuerst mit SeaBIOS, haben jedoch auch GNU GRUB im Bootmenü zur Auswahl (Menü wird durch Drücken von ESC sichtbar).
• seabios_grubfirst
  ROM-Images mit seabios_grubfirst in ihrem Namen, starten zuerst mit SeaBIOS, jedoch wird durch eine Datei im CBFS, die einen speziellen Bootbefehl zum Starten von GNU GRUB beinhaltet, direkt ohne weitere Umwege GRUB geladen. Diese Roms bieten sich für Computer an, die eine externe (beispielsweise PCI) Grafikkarte während des Bootvorgans nutzten, sich jedoch als weitere mögliche Option die interne GPU / Framebuffer-Chip mit der Nutzung von libgfxinit, offen halten möchten.

Aussicht

In Teil 2.2 folgen Anpassungen des erstellten Roms.  

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