10-Watt DeskMini X600 + FreeBSD

Für den Fall, dass außer mir noch jemand FreeBSD auf dem 10-Watt-Mini (c’t 17/24) installieren möchte, habe ich hier ein paar Tipps.

Sowohl die Ryzen 8000G CPUs („Phoenix“-Familie) als auch die Peripherie des X600-Boards werden grundsätzlich von FreeBSD ab Version 13 unterstützt. Ich empfehle die aktuelle Release 14.1.

NETZWERK:

Für den Onboard-Netzwerkchip (RealTek RTL8125) ist leider kein Treiber im Basissystem enthalten, aber es gibt einen Herstellertreiber für FreeBSD, der als Port und als fertiges FreeBSD-Paket verfügbar ist („realtek-re-kmod“).

Hier gibt es natürlich ein Henne-und-Ei-Problem: Ohne Treiber kein Netz, ohne Netz kann man den Treiber nicht herunterladen. Ein einfacher Trick ist es, vorübergehend über sein Smartphone zu tethern, um Netz zu bekommen. Das geht so: Auf dem Smartphone USB-Tethering aktiviere und es per USB mit dem DeskMini verbinden, dann sollte es unter FreeBSD als Netzwerkinterface „ue0“ erscheinen. Dann einfach in einer root-Shell das Kommando „dhclient ue0“ eingeben, um eine IP-Adresse und Route zu konfigurieren. Dann kann man mit „pkg install realtek-re-kmod“ das erwähnte Paket mit dem RealTek-Treiber herunterladen und installieren. Anschließend kann man das Tethering wieder beenden. Wenn das RealTek-Kernelmodul geladen ist, erscheint das 2,5-Gbit-Interface unter dem Namen „re0“. Es unterstützt Jumbo-Frames mit 9000 Bytes MTU.

Alternativ kann man natürlich auch einen USB-Ethernet-Adapter verwenden, wenn man so etwas herumliegen hat. Wer sich extra einen kaufen möchte, dem kann ich das Modell von Ugreen empfehlen (Modellnr. 50922). Es basiert auf dem ASIX AX88179A Controller und wird von FreeBSD gut unterstützt (Treiber axge).

Von dem WLAN-Modul, das man optional für den DeskMini kaufen kann, würde ich abraten. FreeBSD unterstützt hier leider nur 802.11 b/g/a mit maximal 54 Mbps brutto. Wer unbedingt WLAN benötigt, sollte zu einer externen Lösung greifen.

ENERGIE:

FreeBSD ist schon von Haus aus relativ energieeffizient, ähnlich wie Linux. Aber es gibt noch ein paar Maßnahmen, mit denen man noch ein Quentchen herauskitzeln kann.

Per default verwendet FreeBSD eine Scheduler-Frequenz von 1000 Hz. In den meisten Fällen benötigt man keinen so hohen Wert. Meine Empfehlung ist, in die Datei /boot/loader.conf die folgende Zeile einzufügen:

Mit dem nächsten Reboot wird diese Änderung wirksam.

In die Datei /etc/rc.conf habe ich die folgenden Zeilen hinzugefügt:

Zum Aktivieren muss man nicht unbedingt rebooten, sondern kann auch (in einer root-Shell) das Kommando „service powerd start“ eingeben. Damit wird die Taktfrequenz der CPU dynamisch heruntergeregelt, wenn die CPU idle ist, und wieder heraufgeregelt, sobald sich etwas tut. Beim Ryzen 7 8700G zum Beispiel geht es bis 1600 MHz herunter und bis 4200 MHz herauf (der Core-Boost ist hier nicht mit eingerechnet und kommt ggf. noch extra dazu, wenn man ihn nicht im BIOS disabled hat).

Beide Maßnahmen zusammen drücken in meiner Messung (Ryzen 7 8700G) den Idle-Verbrauch um 1,2 Watt. Die CPU-Performance (unter Last) wird dadurch nicht beeinträchtigt.

Übrigens, allein der Link auf einem Netzwerk-Interface verbraucht Strom – auch wenn keine Pakete übertragen werden, sogar wenn gar keine IP-Adresse konfiguriert ist. Wenn ich das Kabel aus dem 2,5Gbit-Port ziehe, sinkt die Stromaufnahme sofort um etwa 1 Watt.

Wenn man an dieser Stelle optimieren möchte und die volle Geschwindigkeit von 2,5 Gbit nicht jederzeit benötigt, kann man das Interface auf 1 Gbit oder sogar auf 100 Mbit herunterkonfigurieren – und spart damit rund 0,5 Watt Idle-Verbrauch, denn die Stromaufnahme eines RJ45-Netzwerkports hängt direkt von der Geschwindigkeit des Links ab.

TEMPERATUREN:

Ok, ich habe oben geschwindelt. Es gibt eine Kleinigkeit, die von FreeBSD (noch) nicht unterstützt wird: der Temperatursensor im Inneren der CPU. Eigentlich ist der Treiber amdtemp(4) dafür zuständig, diese Sensoren bei AMD-Prozessoren auszulesen und per sysctl verfügbar zu machen, nur leider fehlt für die „Phoenix“-Serie – dazu gehören die Ryzen 8000G – noch die Unterstützung.

Es gibt zwar einen funktionierenden Patch dafür:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280942
Aber dieser Patch hat bisher noch nicht seinen Weg in das offizielle Source-Repository gefunden. Wer sich damit auskennt, wie man einen eigenen Kernel aus den Sourcen compiliert, kann den Patch natürlich selbst anwenden, aber das würde an dieser Stelle vermutlich zu weit führen.

Immerhin kann man den Temperatursensor der M2-SSDs auslesen. Üblicherweise haben diese zwei Sensoren: einen direkt im Controller-Chip und einen „Ambient“-Sensor, der sich an unterschiedlichen Stellen des M2-Kärtchens befinden kann. Letzterer ist auch geeignet, um (indirekt) die allgemeine Temperatur im Inneren des DeskMini zu überwachen.

Hierzu muss man das Paket smartmontools installieren. Das Kommando „smartctl -a /dev/nvme0“ (für die zweite M2-SSD auf der Unterseite: /dev/nvme1) liefert dann diverse Gesundheitsdaten, unter anderem die Temperaturen der beiden Sensoren:

Hierbei ist zu beachten, dass sich die erste M2-SSD direkt neben der CPU befindet, während sich die zweite M2-SSD auf der Unterseite des Boards befindet und somit zu einem gewissen Grad thermisch vom Rest des Systems entkoppelt ist. Man sieht dies sehr schön, wenn man einen rein CPU-lastigen Job startet (ohne I/O): Die Temperatur der ersten SSD beginnt relativ zügig, der allgemeinen Erwärmung des Systems zu folgen. Bei der zweiten SSD dagegen tut sich zunächst nicht viel, und erst nach einer Weile beginnt auch ihre Temperatur langsam anzusteigen.

Falls man ein oder zwei SATA-SSDs eingebaut hat, kann man natürlich auch deren Temperatursensoren mit smartctl abfragen.

GRAFIK:

Die GPUs der „Phoenix“-Ryzen (8000G) werden vom drm-kmod-Paket unterstützt (zum aktuellen Zeitpunkt: drm-61-kmod). Damit funktioniert die grafische Oberfläche via X11 / Xorg problemlos.

Eine Alternative, falls man drm-kmod aus irgendeinem Grund nicht nutzen kann oder will, ist der EFI-Framebuffer-Treiber (Paket xf86-video-scfb). Hierbei ist es wichtig, dass der Monitor während des Boot-Vorgangs eingeschaltet ist, damit das EFI-BIOS dessen unterstützte Auflösungen abfragen kann. Damit FreeBSD den Framebuffer in der bestmöglichen Auflösung nutzt, kann man folgende Zeile in /boot/loader.conf hinzufügen:

Modus 0 entspricht i.allg. der nativen Auflösung des Monitors. Wenn man neugierig ist, kann man im Boot-Menü den Loader-Prompt aufrufen (Punkt 4) und das Kommando „gop list“ eingeben; man erhält dann eine Liste aller Modi, die das EFI-BIOS in Kombination mit dem Monitor unterstützt.

Nachteil des Framebuffer-Treibers ist, dass nicht alle Features der GPU unterstützt werden, insbesondere gibt es keine Hardware-Beschleunigung. Für gewöhnliche Office-Aufgaben und Web-Browsen (ohne Videowiedergabe) ist es aber vollkommen ausreichend.

Das Setzen des Framebuffer-Modus („gop set <N>“) ist auch interessant für diejenigen, die gar keine grafische Oberfläche (Xorg) benötigen, denn dadurch kann man die verbesserte Auflösung auch in der gewöhnlichen Text-Konsole von FreeBSD nutzen. Per default wird hier nämlich aus Kompatibilitätsgründen nur eine geringe Auflösung verwendet, etwa der klassische SVGA-Modus 800×600.

AUDIO:

Sowohl der Onboard-Sound (Realtek ALC269, verbunden mit den Klinkenbuchsen am Gehäuse) als auch der GPU-Sound (via HDMI zum Monitor oder TV) werden direkt unterstützt und funktionieren out-of-the-box. Wem das nicht genügt, der kann natürlich eine USB-„Soundkarte“ nachrüsten.

Falls mir noch etwas einfällt, werde ich es als Antwort zu diesem Beitrag ergänzen.