Dieser Post ist Teil der Serie über mein privates BeagleBone-Black-Projekt. Die Serie hat bereits Yocto-Build (Meta-Layer & BSP), ein eigenes Kernel-Modul und Cross-Kompilierung behandelt — aber nicht, was beim ersten Zusammenspiel von eigenem Image, eigener Hardware-Erweiterung (Cape) und Kernel-Konfiguration typischerweise schiefgeht. Genau diese Schnittstelle zwischen "Board bootet nicht" und "Software falsch konfiguriert" ist erfahrungsgemäß der frustrierendste Teil eines Embedded-Projekts.

Boot-Reihenfolge verstehen

Bevor man Fehler eingrenzen kann, muss klar sein, was überhaupt in welcher Reihenfolge passiert:

BeagleBone-Black-Boot-Kette
StufeAufgabe

ROM-Code

Fest im SoC verdrahtet, unveränderlich. Liest die Boot-Pins (SYSBOOT), entscheidet: eMMC oder SD-Karte

SPL (MLO)

Minimaler erster Bootloader — initialisiert nur das Nötigste (DDR-RAM, Takt), lädt U-Boot nach

U-Boot (u-boot.img)

Vollständiger Bootloader — lädt Kernel-Image und Device-Tree-Blob, übergibt Kernel-Kommandozeile

Linux-Kernel

zImage + .dtb — ab hier laufen Treiber, Device-Tree-Overlays, eigene Kernel-Module

Die Boot-Pins (drei Widerstände auf der Platine bzw. per SW-Strap) entscheiden, ob von eMMC oder SD gebootet wird. Ein häufiger erster Fehler bei eigenen Boards/Capes: eine Boot-Pin-Leitung wird versehentlich durch das eigene Cape belegt und verändert damit die Boot-Reihenfolge, ohne dass das sofort ersichtlich ist.

Kein Lebenszeichen über UART-Konsole

Bring-up-Entscheidungsbaum: kein Lebenszeichen über UART

Der systematische Eingrenzungsweg, sobald die UART-Konsole (Standard: 115200 8N1) still bleibt:

  1. Power-Rail prüfen — Multimeter an die 3V3- und 5V-Testpunkte. Kein Signal hier bedeutet Hardware-Ursache (Netzteil, Lötstelle, Kurzschluss durch das eigene Cape) — noch bevor überhaupt Software ins Spiel kommt.

  2. Boot-Pins / Baudrate prüfen — Power liegt an, aber die Konsole bleibt still: falsche Baudrate ist der häufigste Anfängerfehler, dicht gefolgt von einem falsch angeschlossenen UART-zu-USB-Adapter (RX/TX vertauscht).

  3. SPL/U-Boot-Ausgabe sichtbar? — wenn ja, ist die Hardware-Seite grundsätzlich in Ordnung, das Problem liegt im Bootloader-Image oder danach.

  4. Kernel hängt nach U-Boot — an dieser Stelle wird es interessant, siehe nächster Abschnitt.

Ein UART-zu-USB-Adapter mit 5V-Pegel statt 3V3 auf den BeagleBone-Debug-Pins zu betreiben, kann die UART-Transceiver-Pins beschädigen. Vor dem ersten Anschluss den Pegel des eigenen Adapters prüfen — dieser Fehler zeigt sich nicht sofort, sondern oft erst als sporadisch flackernde/korrupte Konsolenausgabe Wochen später.

Board bootet, aber Kernel hängt

Wenn U-Boot sauber durchläuft, aber danach nichts mehr auf der Konsole erscheint, gibt es zwei grundverschiedene Fehlerklassen — die sich nur durch gezieltes Vorgehen unterscheiden lassen:

SymptomDevice-Tree-Overlay-FehlerFehlerhaftes eigenes Kernel-Modul

Wann tritt es auf

Sofort beim Kernel-Start, vor jeglichem User-Space

Meist erst nach User-Space-Start, beim insmod/Autoload des Moduls

Typische Ursache

Overlay referenziert ein nicht vorhandenes Pin/eine falsche Adresse, Overlay wird gar nicht geladen (uEnv.txt-Eintrag fehlt)

NULL-Pointer-Zugriff, doppeltes gpio_request auf bereits belegtem Pin (siehe Kernel-Modul-Post)

Eingrenzung

dmesg direkt nach dem Boot zeigt Device-Tree-Fehler meist explizit (“of_overlay_apply failed” o. ä.)

dmesg zeigt einen Kernel-Oops/Stack-Trace mit Modulname — Modul isoliert testen (laden/entladen ohne weitere Module aktiv)

Der pragmatischste erste Schritt bei "Kernel hängt": den eigenen Kernel-Konfigurationsstand testweise auf ein bekanntes Referenz-Image (offizielles BeagleBone-Debian-Image) zurücksetzen. Bootet das Referenz-Image sauber, ist der Fehler mit hoher Sicherheit in der eigenen Yocto-Konfiguration oder dem eigenen Kernel-Modul zu suchen, nicht in der Hardware selbst.

Eigenes Cape wird nicht erkannt

Ein eigenes Hardware-Erweiterungs-Board (Cape), das nicht erkannt wird, hat in der Praxis meist eine von zwei Ursachen:

  • I2C-EEPROM-ID-Problem — jedes offizielle Cape trägt ein I2C-EEPROM mit einer eindeutigen ID, die der BeagleBone beim Boot ausliest, um passende Device-Tree-Overlays automatisch zu laden. Ein eigenes Cape ohne (korrekt beschriebenes) EEPROM wird schlicht nicht automatisch erkannt — das ist kein Fehler, sondern erwartetes Verhalten ohne manuellen Overlay-Load.

  • Device-Tree-Overlay nicht geladen — selbst mit korrektem EEPROM kann der Overlay-Eintrag in uEnv.txt fehlen oder falsch benannt sein. Diagnose: cat /proc/device-tree/chosen/overlays (bzw. das äquivalente Capemgr-Interface je nach Kernel-Version) zeigt, welche Overlays tatsächlich geladen wurden.

Für die eigene Entwicklung ist ein manuell per uEnv.txt erzwungenes Overlay-Laden pragmatischer als ein korrekt beschriebenes EEPROM — das EEPROM lohnt sich erst, wenn das Cape mehrfach/an wechselnden Boards zum Einsatz kommt.

Systematische Eingrenzung

Der rote Faden durch alle oben genannten Fälle ist immer derselbe: von außen nach innen prüfen, bevor man den Softwarestand verdächtigt.

SchrittWerkzeug

1. Power-Rail

Multimeter

2. Boot-Signal

UART-Konsole (korrekte Baudrate/Pegel)

3. Bootloader-Fortschritt

SPL-/U-Boot-Ausgabe auf der Konsole

4. Kernel-/Treiber-Ebene

dmesg, Device-Tree-Overlay-Status, isoliertes Testen des eigenen Kernel-Moduls

Diese Reihenfolge ist keine BeagleBone-Spezialität, sondern die allgemeine Bring-up-Methodik — vom Multimeter zum Protokoll-Analyzer, hier konkret auf ein reales Projekt angewendet.

Zusammenfassung

SymptomErster Verdacht

Kein Lebenszeichen über UART

Power-Rail per Multimeter prüfen, bevor die Software verdächtigt wird

SPL/U-Boot fehlt auf der Konsole

Boot-Pins/Baudrate/Kabel — häufigster Anfängerfehler ist die falsche Baudrate

Kernel hängt nach U-Boot

dmesg unterscheidet Device-Tree-Overlay-Fehler von einem fehlerhaften eigenen Kernel-Modul

Eigenes Cape unerkannt

I2C-EEPROM-ID fehlt/falsch vs. Overlay-Eintrag in uEnv.txt fehlt — zwei unabhängige Ursachen