BeagleBone Black: Capes verwalten (Seite 2)

DTBO-Files speichert das System im Firmware-Verzeichnis, unter Linux also in /lib/firmware, unter Android in /system/vendor/firmware. Um eigene Overlays aus einer DTS-Datei zu übersetzen, verwenden Sie das folgende Kommando:

$ dtc -O dtb -o [TleNr]-[Version].dtbo -b 0 -b 0 -@ source.dts

Dabei bezeichnet TleNr die Teilenummer, eine beliebige bislang noch nicht verwendete Zeichenkette zur Bezeichnung der Komponente. Die Version, üblicherweise eine vierstellige, bei 00A0 beginnende Hexadezimalzahl, dient der Unterscheidung verschiedener Overlay-Versionen für dieselbe TleNr. In aller Regel kommen Sie mit der Versionsnummer 00A0 aus, es sei denn, Sie verwenden mehrere Spielarten einer Hardware-Komponente, von denen jede ein spezifisches Overlay benötigt.

Der Capemgr

Booten Sie einen BeagleBone Black ohne angeschlossene Capes, sind dennoch bereits etliche Pins auf den Steckerleisten P8 und P9 für bestimmte Zwecke konfiguriert: Einige leiten wichtige Signalleitungen nach außen und lassen sich daher nicht multiplexen, andere konfiguriert der Standard-Device-Tree (Abbildung 2). Manche dienen der Stromversorgung, dritte verwenden die integrierten Capes des Boards, wie eMMC und HDMI.

Abbildung 2: Standard-Pinbelegung der Steckerleisten P8 und P9 des BeagleBone Black.

Das Erkennen und Identifizieren der einzelnen Capes sowie das Laden der zugehörigen Overlays übernimmt das bereits erwähnte Capemgr-Subsystem des Kernels. Mit seiner Hilfe binden Sie auch eigene Overlays in den Device Tree ein.

Als Benutzerschnittstelle im Userspace stellt Capemgr über das Sysfs-Dateisystem das Verzeichnis /sys/devices/bone_capemgr.* bereit, wobei die dort lagernde Datei slots das Interagieren mit dem Capemgr ermöglicht. Beim Laden eines Overlays weist Capemgr diesem einen eigenen “Slot” zu. Um herauszufinden, welche Slots derzeit ein Overlay enthalten, sehen Sie sich den Inhalt von slots an. Bei einem BeagleBone Black in Standardkonfiguration ohne angeschlossene Capes sieht das so aus wie in Listing 2. Abbildung 3 schlüsselt die Bedeutung der Datenfelder innerhalb der Slots auf.

$ cd /sys/devices/bone_capemgr.*
$ cat slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

Abbildung 3: Die Bedeutung der Datenfelder innerhalb der Capemgr-Slots.

Die ersten vier Slots mit den Nummern 0 bis 3 bleiben für angeschlossene Erweiterungs-Capes reserviert. Über die I²C-Bus-Adresse, ein Hex-Byte, fordern die Capes einen bestimmten Slot an. Bei geladenen Overlays, die nicht von einem externen Cape stammen – also beispielsweise jenen für die integrierten eMMC- und HDMI-Capes oder manuell aus dem Userspace geladenen –, lautet diese Adresse immer ff. Auf die Bus-Adresse folgt ein Statusfeld mit fünf Stellen (siehe Kasten “Slot-Statusfeld”). Die darauffolgenden Zeichenketten beschreiben die Version und den Urheber des Overlays sowie die zugehörige Hardware.

Eigene Overlays

Um ein Overlay manuell zu laden, müssen Sie es als kompilierte DTBO-Datei im Firmware-Verzeichnis des Systems ablegen. Die zum Overlay gehörende Teilenummer schreiben Sie anschließend via echo in die Datei slots. Der Capemgr versucht dann, die zur Teilenummer passende DTBO-Datei im Firmware-Ordner zu finden und zu laden. Um etwa das Overlay MY_OVERLAY-00A0.dtbo einzubinden, setzen Sie folgendes Kommando ab:

$ sudo echo MY_OVERLAY > /sys/devices/bone_capemgr.*/slots

Das Verhalten des Capemgr bei Systemstart können Sie über drei Kernel-Kommandozeilenoptionen beeinflussen, die Sie in der Konfigurationsdatei uEnv.txt des Bootloader U-Boot [5] angeben. Die erste davon, capemgr.enable_partno, erzwingt das Laden des Overlays für ein oder mehrere Capes mit spezifisch zugeordnetem Slot im Device Tree. Die zweite, capemgr.disable_partno, unterbindet explizit das Laden eines Overlays, auch wenn das zugehörige Cape vorhanden sein sollte. Die dritte Option namens capemgr.extra_override ähnelt capemgr.enable_partno, dient jedoch zum Laden von Overlays ohne speziell zugeordneten Slot. Sie ist mit Vorsicht zu genießen, denn fehlerhaft angewendet lädt sie das Overlay möglicherweise in einen falschen Slot.

Wie setzt man diese Optionen nun ein? Als Beispiel dazu sehen wir uns den Ablauf des Ladevorgangs für das integrierte HDMI-Cape des BeagleBone Black einmal näher an. Im Device Tree finden sich zwei Knoten dafür: einer für ein vollständiges Cape mit Video und Audio (BB-BONELT-HDMI) und ein zweiter ausschließlich für Videodaten (BB-BONELT-HDMIN). Für jeden der beiden gibt es ein eigenes Overlay, und Capemgr lädt auch alle zwei, da die entsprechenden Nodes das explizit vorsehen. Nutzen lässt sich aber nur eine Variante, da beide exklusiven Zugriff auf dieselbe Ressource verlangen: die Pins, die das Videosignal übertragen. Da das Overlay für das vollständige HDMI-Cape im Device Tree eine höhere Priorität hat, lädt Capemgr es zuerst. Verläuft der Ladevorgang erfolgreich, schlägt anschließend der Versuch fehl, das Nur-Video-Overlay einzubinden.

Manchmal ist es jedoch sinnvoller, statt des vollen HDMI-Overlays die Nur-Video-Variante zu verwenden: Die vier Pins (McASP0), die normalerweise das Audiosignal übermitteln, lassen sich wahlweise auch als zusätzlicher SPI-Kanal (SPI1) oder für GPIO-Signale multiplexen. Diese alternative Nutzung könnte für ein konkretes Projekt wichtiger sein als eine Audioausgabe. In diesem Fall müssen Sie Capemgr anweisen, das Video/Audio-HDMI-Overlay zu überspringen.

Das erledigen Sie mit der Kernel-Option capemgr.disable_partno (Listing 3, Zeile 1). Im Falle eines Falles lässt sich mit ihr das HDMI-Cape sogar komplett deaktivieren, indem Sie beide HDMI-Overlay-Varianten ausschließen (Zeile 2). Dadurch machen Sie nicht weniger als 24 Pins auf den Steckerleisten P8 und P9 frei, die Sie nun für eine beliebige Kombination von UARTs und GPIOs multiplexen können.

capemgr.disable_partno=BB-BONELT-HDMI
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN