ich habe ein Problem mit einem Raspberry PI 3 B+. Der wird bei uns in der Firma in kleinen Stückzahlen eingesetzt. Bisher lief alles. Jetzt zickt er rum, das Image bootet nicht! Es ist der 7'' TFT der Raspberry PI Foundation angeschlossen. Dazwischen klemmt eine Platine, welche die 5V sowie diverse Anschlüsse bereitstellt.
Der Fehler sieht so aus, daß die grüne LED 4x lang und 7x kurz blinkt. Gemäß diverser Meldungen im Netz bedeutet 7x kurz, daß er das Image nicht gefunden hat. Siehe Anhang. Das ist aber vorhanden. Das Image der SD-Karte lief bisher problemlos und wurde auch nicht verändert. Es wird direkt mit dem Raspberry PI Imager 1.7.2 auf die SD-Karte geschrieben, das lief bisher problemlos.
Die SD-Karten sind sehr gute von ATP, 4GB, SLC, industry quality.
Ein Test mit einer anderen Karte gleichen Typs aber mit einem wahlfrei erstellten Image (PINN, multi boot OS installer) funktioniert! Der Raspberry Pi startet, der Bildschirm zeigt was an, man kann den auch per Touch bedienen! D.h. die Hardware ist OK!
Ich hab diverse Hinweise aus dem Netz gefunden und versucht zu berücksichtigen.
Die Stromversorgung ist OK, der Schaltregler der Zwischenplatine liefert 2A@5V. Eine Speisung per Micro-USB ergibt die gleiche Reaktion. Auf dem RasPi hab ich die 5V, 3,3V und 1,2V mit dem DMM gemessen, alles OK.
Kabel etc. scheiden aus, denn mit dem Test-Image läuft es ja!
IC habe die Karte mittels SD-Formater von sdcard.org vollständig neu formatiert, gleiches Ergebnis!
Wie gesagt, an Hard- und Software wurde nichts geändert, aber der Raspberry Pi startet nicht mehr. Ich habe 3 Raspberry hier liegen, alle drei gleiches Verhalten. Ich habe 3 SD-Karten im Test.
Anbei der Inhalt der FAT32 Partition der SD-Karte. Die andere Partition kann ich mangels Linux nicht lesen. Ebenso das Blinken als Video.
Was ist hier los? Wie kann man den Fehler weiter eingrenzen?
b) ein neuer RPi bootet nicht mehr ein altes Image
Hört sich eher nach b) an. Damit wäre as alte Image nicht kompatibel mit der (potentiel) neuen Hardware(-version). Hier https://forums.raspberrypi.com/viewtopic.php?t=52683 (ist zwar schon alt, aber wer weiss) wird empfohlen, das Image auf einer älteren, funktionierenden Hardware zu booten, upgraden und zurückschreiben. Dann in der neuen HW testen. Oder Image auf Basis einer neuen Distro neu erstellen.
Was ich noch nicht ganz verstanden habe ist. Den Bootfehler zeigen 3 Raspis mit ihrer jeweiligen Orignalkarte zeitgleich? Oder zeigt nur die eine Originalkarte in allen 3 Raspis den gleichen Bootfehler?
Wenn man das Backup Image der Originalkarte auf eine neue Karte schreibt, hat man dann immer noch den Bootfehler?
Der
Raspberry Pi startet, der Bildschirm zeigt was an, man kann den auch per
Touch bedienen! D.h. die Hardware ist OK!
Also ist die HW OK (zumindest sie bootet und das Display funktioniert).
IC habe die Karte mittels SD-Formater von sdcard.org vollständig neu
formatiert, gleiches Ergebnis!
Wie gesagt, an Hard- und Software wurde nichts geändert, aber der
Raspberry Pi startet nicht mehr. Ich habe 3 Raspberry hier liegen, alle
drei gleiches Verhalten. Ich habe 3 SD-Karten im Test.
Anbei der Inhalt der FAT32 Partition der SD-Karte. Die andere Partition
kann ich mangels Linux nicht lesen. Ebenso das Blinken als Video.
Du berichtet den Start einen funktionsfaehigen Computers :-)
Und das Image (Deine eigene SW?) ist OK? Denn das waere jetzt mein Kandidat. Also: Klemme einen USB-RS232-Converter an und gucke, was die Console sagt. Hast Du die Console deaktiviert, aktiviere sie.
Denn ich glaube nicht, dass Du drei Raspberries geschrottet hast. Ist ein Zertifikat ausgelaufen?
Da muss man aber an die Konsole ran. Davon versteh ich zu wenig und außerdem läuft auf dem angepaßten Linux nur die Applikation mit GUI, kein Desktop.
Dann
in der neuen HW testen. Oder Image auf Basis einer neuen Distro neu
erstellen.
Klingt nach einem Plan, muss aber ein Linuxfachmann machen.
Ich habe weiter getestet. Die neuen Karten laufen auf einer alten Hardware! Diese hat einen anderen RAM, siehe Bild! Die neuen Raspberry PIs haben andern RAM von Micron! Klingt nach einer heißen Spur.
Damit sind die SD-Karten erstmal OK.
Ist aber schon merkwürdig. Die Einträge im Forum sind von 2013! Der angepaßte Kernel wurde vor ca. 3 Jahren erstellt und von ca. 1 Jahr endgültig freigegeben (neudeutsch released). Sollte da sich trotzdem ein altes Stück Software für die Speicherinitialisierung reingeschmuggelt haben?
Was ist hier los? Wie kann man den Fehler weiter eingrenzen?
Wenn andere Systeme starten und 3 verschiedene SD-Karten auf 3 Boards dasselbe "Nicht-Boot-Verhalten" zeigen, liegt doch der Verdacht nahe, daß der Master zur Erstellung der SD-Karten beschädigt ist.
Also zuerst mal alle Dateien wie bootcode.bin und die Hardwareteile, die überall identisch benutzt werden, binär miteinander vergleichen.
Dann die cmdline.cfg anschauen und nach und nach abspecken.
Das wäre zumindest meine Methode.
Die andere Partition kann ich mangels Linux nicht lesen.
Das vereitelt die weitere Fehlersuche.
Mag sein, aber so weit kommt der Startvorgang gar nicht. Der Kernel liegt auf der sehr kleinen (40MB!) FAT32 Partition, der wird aber nicht gefunden bzw. ein anderer Fehler signalisiert.
Starte den Raspi mit einem Raspian auf einer SD-Karte. Schliesse die
SD-Karte mit einem USB-SDCard-Adapter an.
Was ist hier los? Wie kann man den Fehler weiter eingrenzen?
Wenn andere Systeme starten und 3 verschiedene SD-Karten auf 3 Boards
dasselbe "Nicht-Boot-Verhalten" zeigen, liegt doch der Verdacht nahe,
daß der Master zur Erstellung der SD-Karten beschädigt ist.
Wenn ich die Datei dir.txt mit dem Inhalt der Bootpartion richtig verstehe, sind alle Dateien außer cmdline.txt und config.txt Standarddateien von der Raspberry foundation. Was spricht dagegen alle diese Dateien für einen Test durch neuere Versionen zu ersetzen, vorzugsweise von Systemen, die die neuere Hardware verkraften?
Wenn ich die Datei dir.txt mit dem Inhalt der Bootpartion richtig
verstehe, sind alle Dateien außer cmdline.txt und config.txt
Standarddateien von der Raspberry foundation.
Kann sein.
Was spricht dagegen alle
diese Dateien für einen Test durch neuere Versionen zu ersetzen,
vorzugsweise von Systemen, die die neuere Hardware verkraften?
Hab ich gerade gemacht, hab alle außer kernel7.img drübergebügelt. Das System startet ein wenig, der Bildschirm zeigt was an (Regenbogentest), dann kommt ne Konsole mit diversen Fehlermeldungen. Ich sag mal, es bewegt sich in die richtige Richtung. Den Rest muss ein Linuxprofi reparieren, ich bin nur der Drahtzieher.
Hab ich gerade gemacht, hab alle außer kernel7.img drübergebügelt.
Der sollte nach meiner Meinung aber ebenfalls benutzt werden. Es ist doch so, daß bootcode.bin den Code für den Grafikprozessor enthält. Der schaut, was für Hardware drinsteckt und sucht von der Bootpartition die dazu passenden Programme heraus, lädt sie ins RAM und startet erst dann die ARM-CPU. Die findet dann ihren Code auf der Linux-Partition vor. Insofern würde ich schon annehmen, daß kernel7.img ebenfalls in der neueren Version gebraucht wird, da auf der FAT32 die ganzen Dinge stehen, die der Grafikprozessor der ARM-CPU ins RAM stopft, damit die mit der durchaus unterschiedlichen Hardware zurechtkommt. Sicher bin ich aber nicht.
Um an die Details zu kommen. Du kannst dann in einer chroot-Umgebung die SD mounten und die Installation reperieren und updaten.
Workaround bietet eventuell auch die config.txt. Da koennte eine Variable anders gesetzt sein bevor eine automatische Abfrage im (zwischenschritt) boot-Kernel implementiert wurde.
So, das Problem wurde behoben. Wie schon von Michael ganz am Anfang vermutet, war es eine Inkompatibilität zwischen der Bootsoftware und der neuen Hardwarerevision.
Mein Plan war, den normalen Update auf der alten Revision durchzuführen. Leider ging das nicht. sudo raspi-config funktionierte nicht über SSH. Keine Ahnung warum. Bin kein Linuxer.
Also habe ich mit dem Raspberry Pi Imager ein Standardimage für Raspberry PI OS erstellt und die Startdateien aus der kleinen FAT32 Startpartition in die Startpartition meines Images kopiert. Und siehe da, die Software startet! ;-)
Es ist abhängig welche SD Karte verwendet wurde. Es gibt da eine Seite wo eine Liste gibt mit SD Karten die Probleme machen und Karten die gehen. Siehe hier.
Und weil es so schön war, hier noch eine kleine Detektivgeschichte. An dem Ding ist ein Drehgeber mit Tastfunktion angeschlossen. Der Taster ging noch nach dem Update der Bootfiles, die Drehfunktion nicht mehr. Drama in der Firma! 8-0
Aber nach reichlich 2 Tagen Fummelei, Googeln und Stirnrunzeln die Lösung.
Der Fehler steckt in der Zeile in config.txt, welche von der Bootsoftware gelesen wird und diverse devices aktiviert.
Der alte Bootloader hat die Zeile nach 80 Zeichen abgeschnitten (findet man beim googeln), also nach lin. Damit hat er den letzen Parameter nicht korrekt erkannt und den default-Wert 0 benutzt. In der Software gehen also alle Eingaben an Axis 0 (REL-X). Den fehlerhaften Parameter erkennt man nur, wenn man das Boot-Log über UART aktiviert, was ich im Laufe der Test gemacht habe.
Der neue Bootloader verkraftet längere Zeilen und liest den Parameter korrekt, damit landen aber die Eingaben auf der falschen Achse! D.h. die alte Boot-Software hatte ZWEI Fehler, die sich gegenseitig kompensiert haben! Wenn gleich die Softwerker bei der Entwicklung stutzig geworden sein müßten, daß die konfigurierte Achse 9 keine Daten liefert.
Ja was macht er denn, außer den als zu teuer zu reklamieren?
In der Anwendung, die wir haben, braucht es a) keinen Raspberry PI 4 (mit gescheiter Programmierung würde der 1er reichen!) und b) auch keinen Mini-PC. Für unseren Kram (Gerätesteuerung, HMI) ist das Ding schon ganz gut. Vorher hatten wir dafür einen für uns entwickelten SBC drin, auch aus Berlin ;-)
Nein, wir bezahlen ganz sicher NICHT den Preis ;-)
Das Ding ist über 15 Jahre alt, Zeit für was Neues, bevor die Abkündigung kommt. Von der CPU-Leistung / Speicher würde das Ding auch heute noch ausreichen. Auf dem Ding läuft sogar Doom recht flüssig! Das hat vor Ewigkeiten mal einer aus dem Forum für uns umgesetzt.
Eine einseitige Betrachtung. Naja, vielleicht mal die Perspektive wechseln.
Wenn der „Gebrauchte“ genauso zuverlässig funktioniert - also 3 Jahre 24/7 Betrieb - wie der RasPi und mit so wenig Energiebedarf…
Derartige Probleme hatte ich bisher nur 1 oder 2 Mal in den letzten 8 Jahren. Ansonsten war die Community immer sehr hilfreich, der große Vorteil dieser Plattform - der Preis und die Performance sind eben nicht die einzigen Parameter.
