Banana Pi BPI-M6 will nicht von SD Karte booten - mehr Debugging

Als kleiner Einstieg in die Thematik empfehle ich, meine vorhergehenden Artikel zu lesen. Zum einem die allgemeine Vorstellung des neu auf den Markt gekommenen Banana Pi BPI-M6, dann meine Anleitung, wie man Images, also Betriebssystemabbilder wie die Android Tablet Firmware ins eMMC hochlädt / flasht.

Mein Problem derzeit ist, dass es ein neues Ubuntu Linux Image gibt, dass allerdings nur von SD-Karte gebootet werden kann und sich mein Banana Pi M6 bisher standhaft weigerte, von SD Karte zu booten. Solch ein Unterfangen wurde immer mit einem dwcmshc_send_cmd, wait command 0 complete time out! quittiert und abgebrochen.

Da ich irgendwie den Verdacht hatte, dass mein Board einen Fehler bei den Leitungen zum SD-Port hat, habe ich im letzten Artikel den Bootvorgang mittels FTDI-Adapter gedebuggt. Das heißt, ich habe mir über einen FTDI-Adapter an der seriellen Schnittstellte die Debug-Meldungen ausgeben lassen und gemutmaßt, was diese im Zusammenhang mit dem Fehlverhalten wohl bedeuten werden.

Die scheinbar unbrauchbar gewordenen SD-Karten

Da das Gerücht umgeht, dass der Banana Pi BPI-M6 wohl nicht jede SD-Karte zum Booten akzeptiert, habe ich das Ubuntu Linux Image auf einige unterschiedliche µSD-Karten mit der von Banana Pi Org empfohlenen Etcher Software gebrannt. Jedesmal zur Sicherheit mit Verify. Immer war das Image laut Etcher richtig geschrieben, auf 32, 64 und 128 GB Karten von Lexar, Noname und Markenkarten von Samsung und auch SanDisk. Die letztere soll laut Banana Pi Org wohl am besten funktionieren und diese setzen sie selbst bei Tests ein.

Immer war der Versuch, von einer SD auf dem BPI-M6 zu booten erfolglos. Immer gab es als letzte Fehlermeldung im UART-Debug-Log ein Und es tat sich ein weiteres Problem auf. Immer wenn ich eine Karte, die nicht im BPI-M6 booten wollte (oder andersherum der M6 wollte die Karte nicht), hatte diese ein sehr seltsames Format. Denn wenn ich die Karte in meinen USB 3-Kartenleser, den ich gewöhnlich zum Kartenschreiben und -lesen benutzte, einsteckte, verschwand urplötzlich das entsprechende Laufwerk aus Windows und sogar aus der Datenträgerverwaltung. Die ist sogar dadurch abgestürzt, als ich nach neuen Geräten gesucht habe und ich musste neu booten.

Ich hatte schon die Befürchtung, dass ich die Karten abschreiben könnte, aber dann benutzte ich meinen günstigen, kompakten USB3-Stick-Kartenleser von AliExpress, der nur SD und µSD Slots hat und glücklicherweise verschwand hier das Laufwerk nicht, ich konnte die Partitionierung einsehen und auf der ersten Partitionen waren sogar ein paar Dateien drauf. Mit dem Stick konnte ich die µSD-Karten kann auch wieder formatieren und brauchbar machen.

Aber mal ehrlich: was ist das für ein Format, dass die Laufwerke mit bestimmten Kartenlesern verschwinden lässt? Ich benutze diesen Kartenleser täglich, habe schon viele, viele Raspberry-Pi-Images und andere exotische Sachen geschrieben und gelesen, aber das ein Format dazu führt, dass sich das komplette Laufwerk aus Windows ausklinkt, das hatte ich noch nie.

Mein Tipp also für Leute, die das gleiche Problem haben: Schmeißt die Karten nicht gleich weg, vielleicht tut es ein anderer Kartenleser, evtl. sogar der billigste wie bei mir. Mein Transcend USB-Stick-Kartenleser, also ein Markengerät tat es übrigens auch.

Der Lösungsvorschlag vom Support

Der Support von Banana Pi Org, der sich bemüht, mich zu unterstützen, meinte der dwcmshc_send_cmd-Timeout sei die Fehlermeldung, die kommt, wenn man eine inkompatible SD Karte verwendet.

Statt der angeblich inkompatiblen SD Karten sollte ich doch mal eine andere ausprobieren, im Test würde man SanDisk Ultra 16G Class 10 SD Card benutzen (links):



Also habe ich eine Karte vom selben Hersteller SanDisk, auch eine Ultra, auch eine Class 10 versucht. Auch das führte zu keinem anderen Ergebnis: es konnte nicht davon gebootet werden. Es ist allerdings eine XC I und keine HC I. Ich glaube, dass ist ein anderer Standard. Und in dem Source-Code oben gibt es ja auch die Funktion namens sdhci_request. Eventuell kann der M6 nur mit HCI-Karten umgehen?

Die 100% als kompatibel bestätigte SD-KArte von SanDisk

Wie heißt es so schön? Die Hoffnung stirbt zuletzt, also habe ich mir von einem deutschen Elektrofachmarkt eine SanDisk Ultra HC I Class 10 mit 32 GB bestellt, genau wie die empfohlene, auch HCI, halt nur mit 32 GB statt 16 GB. Und das ist auch genau die Karte, von der radek im Banana Pi M6-Forum sagt, das er sie benutzt und davon Ubuntu booten konnte:

---

Also exakt die selbe Karte wie radek sie benutzt und von der er booten konnte: eine der empfohlenen µSD SanDisk Ultra HCI Class 10 Karten.

Also wieder mit Etcher das Image darauf gebrannt und verifiziert, diesmal zur Sicherheit mit dem China-USB-Lesegerät. Und dann frischen Mutes in den Banana Pi M6 gesteckt. Jetzt sollte doch alles klappen und das Image booten, oder?

Voller Spannung die Debug-Kabel eingesteckt, den SPI-Taster haltend dem Banana Pi 6 Power gegeben und wieder lesen müssen: dwcmshc_send_cmd, wait command 0 complete time out! Wie ärgerlich! Der Aussage vom Support, dass der Meldung wegen Inkompatibilität der Karte kommt: sie stimmt wohl nicht. Denn jetzt war es ja exakt die verlangte und bewiesenermaßen funktionierende Kartentyp. Wenn ich eins hasse, ist es für dumm verkauft, nicht ernst genommen und mit billigen Ausreden abgespeist zu werden. Wie das in letzter Zeit so um sich greift: man bekommt irgendwelche Standard-Textbausteine, die nichts mit der Sache zu tun haben. Dieses Gefühl, so behandelt zu werden, stellt sich gerade bei mir ein.

Aber grundsätzlich bin ich der Mensch, der Fehler eigentlich immer zuerst bei sich selbst sucht anstatt vorschnell die Fehlersuche einzustellen und zu sagen: die anderen sind schuld. Foren-Mitglied radek von oben bekommt übrigens scheinbar sein Ethernet-Port nicht zum Laufen. Ich hoffe und ich glaube es eigentlich auch nicht, aber was wäre, wenn Banana Pi Org sich gedacht hat: Ach, die Journalisten und Blogger da draußen, die machen sicher nur ein paar Fotos von der Platine und schreiben einen kurzen Artikel, denen fällt es bestimmt nicht auf, wenn wir denen die Boards schicken, die ein paar kleine Fehler haben und durch den Endtest gefallen sind? Also wer weiß, ganz billig sind die BPI-M6 ja auch nicht.

Analyse des Debug-Log vom Entwicklungsteam bei Banana Pi Org

Mit letzter Mail vom Support habe ich auch ein Debug-Log von dem bootenden M6 vom Entwicklerteam bei Banana Pi bekommen, dass ich mir ein wenig näher angeschaut habe. Auf die interessanten Dinge will ich hier eingehen.

Den gelb markierten I2C-Fehler haben die also auch. Das verhindert das Booten also nicht.

Den grünen Bereich betreffend, kommt bei mir immer nach MMC is SD sofort die Fehlermeldung dwcmshc_send_cmd, wait command 0 complete time out! und danach rebootet der M6 neu. Der Pi vom DevTeam allerdings macht hier weiter und greift auf die SD-Karte zu, findet - wenn auch nicht auf Anhieb - die Boot-Partition auf der SD und legt dann mit dem booten los.

Genau an diesem Punkt hapert es bei mir: Jegliche Kommunikation mit der SD-Karte schlägt bei meinem M6 fehl.

Nachdem der MiniLoader das Image gefunden hat, geht es weiter mit einem Loader namens U-Boot: Und danach wird der Linux Kernel gefunden und geladen: Danach werden die ganzen Treiber geladen und das Linux-System gestartet, bis schließlich Ubuntu fertig geladen ist: So sollte es normalerweise laufen. Nur zu blöde, dass bei mir gar kein Bootvorgang von SD startet.

Dass das System eigentlich soweit (bis auf eben die SD) okay ist, zeigt ja, dass ich Android von eMMC booten kann. Da gibt es zwar auch einige I2C-Fehler, aber die scheinen auch nicht schlimm zu sein, denn diese kommen auch im Log von DevTeam vor: Mein eigentliches Problem liegt also "nur" im Bereich der SD-Karten-Kommunikation.

Löschen, Flashen und Testen der unterschiedlichsten Images

Das Log vom DevTeam gibt schon mal einen gewissen Überblick darüber, wie der Boot-Vorgang abzulaufen hat. Trotzdem bin ich nicht hundertprozentig sicher, ob nicht vielleicht doch irgendwas bei mir in der Firmware fehlt. Der U-Boot 2019.10-armbian (Nov 20 2023 - 14:06:35 +0000)-Teil kann es ja eigentlich nicht sein, das späte Datum lässt darauf schließen, dass es sich bereits auf der SD in dem neuen Imagr befindet. Und die nachfolgenden Teile dann natürlich auch bzw. sind sie nicht relevant, weil der Bootvorgang bei mir erst gar nicht weit läuft.

Trotzdem versuche ich noch ein paar Optionen mit dem Senary SOC System Tool:

• ich lösche das eMMC über Erase MMC
• ich setze den Haken bei MDK, weil ich da etwas mit UBoot lese. Dazu muss ich allerdings auch was brennen. Ich wähle das EraseEMMC aus den System Tool Images
• ich versuche den obigen Punkt noch einmal ohne die Option den freibleibenden Platz in einer UserData Partition zur Verfügung zu stellen.
• ich brenne wieder das Android-Image ins eMMC, das immer noch tadellos davon bootet

Danach teste ich erneut den MPI-M6 am seriellen Debugger-Port. Immer mit dem selben Ergebnis, der letzten Zeile dwcmshc_send_cmd, wait command 0 complete time out!. Ich komme zu dem Schluss, dass all das nur den eMMC Speicher ändert und keine Auswirkungen auf das Booten von SD hat. Wahrscheinlich musste ich das BIOS, oder wie man die Firmware auf unterster Ebene nennen möchte via SPI Flash flashen. Aber das scheint mir gar nicht nötig, noch weiß ich, wie das geht.

Test des SD-Karten-Ports via Android Image Gallery

Eine Idee, um zu testen, ob mein SD-Karten-Slot überhaupt funktioniert, kommt mir noch: Die Gallery im Android Image. Hier sollte Android genau wie es die Bilder auf USB-Stick erkennt, eine eingeschobene, nochmal auf FAT formatierte SD-Karte erkennen und die Bilder darauf anzeigen.



Allerdings ergibt sich folgendes Bild: Während der USB-Stick gleich erkannt wird, und die Bilder automatisch in einem Grid View angezeigt werden (linkes Bild), tut sich beim Einstecken der SD-Karte mit Bildern rein gar nichts (rechtes Bild).

Das heißt: Entweder kann Android auf den SD-Slot gar nicht zugreifen, oder eben der SD-Slot ist kaputt.

Blick in den Block-Schaltplan

Irgendwo in den zum Banana Pi M6 von mir heruntergeladenen Ressource finde ich auch das PDF mit den Schaltbildern wieder, denn ich will es ein bisschen genauer wissen und z. B. meine Frage, ob die SD über I2C, also über SDA und SCL, angesprochen wird, blieb ja vom Support unbeantwortet. Also versuche ich mir selbst zu helfen.

Herausgefunden habe ich: Der SD-Port ist nur mit 4 Datenleitungen (Data0 bis Data3) angebunden und hat damit nur die halbe Bandbreite wie das eMMC mit 8 Datenleitungen.



Außerdem gibt es noch ein paar Steuerleitungen. Die meisten der Leitungen sind direkt mit dem VS680 SoC verbunden. Leider ist der Schaltplan nicht sonderlich ausführlich, aber ich schätze mal, das CLK für Clock steht, also den Steuerimpuls, damit alles im Takt bleibt. CMD steht bestimmt für Command. Ich schätze, hier gehen die SD-Kommandos drüber. Die 4 Datenleitungen werden auch von der CLK abhängig sein und die Binärdaten transportieren. CDn könnte dafür stehen, ob eine SD-Karte präsent, also eingesteckt ist. Dafür gibt es einen extra kleinen Sensor im SD-Slot. Und WP könnte für Write Protection stehen, ein Feature, das zwar vorhanden ist, aber niemand bei µSD nutzt.



Diese Anschluss-Pins finden sich natürlich auch in dem Molex-Adapter für den SD-Card-Slot wieder. Der Slot wird mit einer Spannung von 1.8 Volt betrieben, die wie rechts gezeigt aus der 3.3V Schiene erzeugt wird.

Hardware defekt?

Jetzt wäre als nächste Maßnahme - sollte ich mich noch weiter reinknien und in den Kaninchenbau abtauchen wollen - eine Messung der Leitungen direkt am SD-Card-Slot angesagt. Um zu schauen, ob da überhaupt ein Takt ankommt, wie die Spannungen sind und ob da etwas übertragen wird.

Dazu müsste ich den SD-Card-Slot an mein Oszilloskop anschließen. Dass das bei den Winz-Verbindungen kein Spaß ist, dürfte auf der Hand liegen. Ohne eine Art Breakout-Board, also eine µSD-Karte, die man einschieben kann und auf der anderen Seite Pins zum Anklemmen von Meßleitungen hat, wird das nichts.

Ich will mal schauen, ob es sowas günstig zu kaufen gibt. Damit könnte man der Fehlerursache dann näher kommen.

Vielleicht reichen aber auch einfache Tests von anderen Leuten, die vielleicht Bilder auf SD-Karten im Android Image angezeigt bekommen oder die mir sagen, was sie für eine Fehlermeldung bekommen, wenn sie eine leere FAT formatierte SD einlegen und versuchen davon zu booten? Nämlich vielleicht kein Timeout-Error, sondern soetwas wie ein "Partion not found"-Error?

Am einfachsten wäre es natürlich, die Banana Pi Org könnte mir ein 100% getestetes Board schicken, ich habe auch schon angefragt, aber es hieß, dass das nicht ginge, weil gerade alle ausverkauft wären.

Update 2024-01-24

Der Support bei Banana Pi Org hat mir versichert, dass alle Boards in der Fabrik getestet werden, bevor sie herausgeschickt werden. Das schließt die SD-Funktionen ein. Eventuell sei etwas bei dem Transport kaputtgegangen, schreibt man. Wobei ich mich jetzt wirklich nicht beschweren kann, dass das schlecht verpackt gewesen wäre, wie man ja auch im Unboxing Video sehen kann

Und man will mir ein neues Board schicken, sobald wieder welche verfügbar sind. Was ich ja sehr nett finde. Trotzdem heißt die Devise jetzt erst einmal wieder warten. Ich muss euch deshalb leider noch ein wenig vertrösten, um euch das Linux Ubuntu Image für den Banana Pi M6 vorzustellen. Aber wenn das neue Board da ist, gibt es natürlich einen ausführlichen Artikel darüber und auch wieder ein Video.

Update 2024-02-06

Das Micro SD Card Sniffer Board ist aus China angekommen. Im nächsten Artikel schaue ich dem SD-Card-Slot meines Banana Pi M6 mal mit dem Oszilloskop auf die Bits; dann weiß ich definitiv Bescheid, was Sache ist.

Quellen, Literaturverweise und weiterführende Links