Internen eMMC mit dd genullt und nun ist der eMMC nicht mehr sichtbar

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich Kontext meines Bootproblems im neuen 09-06 RaspianOS Image von nvme habe ich dummerweise gedacht ich loesche mal eben meinen internen eMMC Storage per dd if=/dev/zero of=/dev/sdf bs=2GiB count=10 um was zu testen. Der eMMC Stoarge ist seitdem weg und ich bekomme ihn weder per mass-storage-gadgets aus den usbtools noch einem von nvme gebooteten RaspbianOS per sudo blkid zu sehen :wallbash: Ich sehe nur noch den nvme Storage.

    Ist keine gute Idee den eMMC so zu clearen ... nur so als Warnung an jeden CM4 Nutzer ...

    Anyhow: Ich habe in dem Issue gefragt wie ich den Storage wieder sichtbar bekomme. Ich warte noch bis Anfang der Woche. Dann werde ich entweder im usbboot git einen Issue erstellen oder im ComputeModule Subforum im Raspberry Foundation Forum einen Thread dazu.

    Vermutlich muss ich nur wieder den eMMC partitionieren. Falls jemand weiss wie das geht bin ich ueber jeden Hinweis dankbar. Irgendwie nervt es mich und ich will das Problem moeglichst schnell gefixed haben. Aber das im git busy Entwickler taetig sind mache ich dort erst mal keinen Stress.

    @__ deets__ Dich habe ich im internationalen CM Forum gefunden. Hast Du eventuell einen Tipp?

    EDIT: So wie mir scheint hat sich __deets__ vom Forum verabschiedet :-/

  • Internen eMMC mit dd genullt und nun ist der eMMC nicht mehr sichtbar? Schau mal ob du hier fündig wirst!

  • Ich Kontext meines Bootproblems im neuen 09-06 RaspianOS Image von nvme habe ich dummerweise gedacht ich loesche mal eben meinen internen eMMC Storage per [tt]dd if=/dev/zero of=/dev/sdf bs=2GiB

    Das ist grundsätzlich keine gute Idee of=/dev/sdf irgendwie über dd mit Nullen zu beschreiben, weil dann vom ersten bis zum letzten Sektor das ganze Device (und nicht nur eine Partition überschrieben wird. Jedes Blocjdevice ist davon betroffen, egal, ob USB Stick, HD, SSD, oder eben eMMC. So hast Du auch die ersten Sektoren, wo die Partitionstabelle steht, geNULLd und Du musst wieder eine neue Partition Table erstellen. [Oder die GPT Kopie zurückspeichern]

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Das ist grundsätzlich keine gute Idee of=/dev/sdf irgendwie über dd mit Nullen zu beschreiben

    Im Rahmen meiner Tests mit raspiBackup habe ich immer wieder das Problem meine Medien die das restorte Image erhalten sollen zu cleanen - also jungfraeulich zu machen. Das funktionierte bislang immer ohne jegliche Probleme mit SD Karten wie auch Platten und USB Sticks. Die werden vom OS immer wieder erkannt als uninitialisierte Geraete und man kann sie mit fdisk oder anderen Partitionierern neu zum leben erwecken. Deshalb dachte ich auch dass das beim CM4 so machbar ist. Fehlanzeige :wallbash:

    Der externe Zugriff auf die Devices ist beim CM4 etwas komplizierter: Man muss dazu usbboot und dort das mass-storage-gadget flashen damit man von einem Windows oder Linux auf die Partitionen von extern zugreifen kann. Vermutlich greift die Erkennung nur wenn schon eine Partitionstabelle existiert. Ich habe keine Ahnung wie der mass-storage-gadget Code aussieht.

    Wie meinst Du sollte man ein Device loeschen statt mit dd /dev/zero?

  • Ich habe keinen CM4. Wenn du mittels sudo ./rpiboot den CM4 via bootest, erscheint dann ein neues Gerät unter /dev/sdX? Falls ja, dann ist nur die Partitionstabelle erwartungsgemäß nicht vorhanden. Dann kann man unter Linux einfach eine neue Partitionstabelle mittels fdisk erstellen. Das Schlimme ist nur, wenn sich gar kein neues Blockgerät meldet.

    So wie ich das verstanden habe, wird ein minimaler Bootcode über den USB-Debugport des CM4 geladen, der lediglich das eMMC Blockgerät dem USB-Host exponiert. Es soll dann wohl als Massenspeicher erkannt werden. So kann man dann partitionieren, formatieren oder ein Image übertragen.

    Letztlich ist das Überschreiben mit Nullen kein Problem und darf auch kein Problem sein. Wenn ein Image übertragen wird, wird das Blockgerät anstatt nur mit Nullen, mit Nullen und Eisen überschrieben. Der Inhalt der Daten wird vom eMMC nicht interpretiert. Der eMMC weiß weder was von einer Partitionstabelle, noch es kennt der Speicherchip die unterschiedlichen Dateisysteme. Was mir unbekannt ist, wie schnell die eMMC altern.

  • Wenn du mittels sudo ./rpiboot den CM4 via bootest, erscheint dann ein neues Gerät unter /dev/sdX?

    Nein. Leider nicht mehr :no_sad:

    Dann kann man unter Linux einfach eine neue Partitionstabelle mittels fdisk erstellen.

    Jupp. Nur leider muss der eMMC im OS sichtbar sein. Mit sudo blkid ist der eMMC aber nicht sichtbar und somit auch nicht per /dev/mmcblk.. zugreifbar mit fdisk :no_sad:

    So wie ich das verstanden habe, wird ein minimaler Bootcode über den USB-Debugport des CM4 geladen, der lediglich das eMMC Blockgerät dem USB-Host exponiert.

    Ja genau. Ich nutze dazu immer das mass-storage-gadget vom usbboot repo da ich sonst den nvme Storage nicht zu sehen bekomme. Der eMMC war aber bislan so auch zugreifbar.

    Was mir unbekannt ist, wie schnell die eMMC altern.

    Hm ... das kann natuerlich sein dass mein dd /dev/zero dem eMMC den Rest gegeben hat. Mir wurde das CM4 gespendet damit ich nvme Support einbauen konnte. Wie alt das Modul ist, ob genraucht oder neu und wie oft auf den eMMC geschrieben wurde weiss ich nicht. Ich bin mal positiv eingestellt und nehme an dass der eMMC nicht dead ist sondern das Zugriffsproblem woanders liegt :)

  • Jupp. Nur leider muss der eMMC im OS sichtbar sein. Mit sudo blkid ist der eMMC aber nicht sichtbar und somit auch nicht per /dev/mmcblk.. zugreifbar mit fdisk :no_sad:

    Gibt es Meldungen des Kernels?

    Bevor du den CM4 anschließt, mittels sudo dmesg -c den Buffer löschen und nachdem der CM4 angeschlossen und in dem speziellen Modus gebootet ist, mit sudo dmesg die neuen Meldungen ausgeben lassen.

    So hat man zumindest einen Anhaltspunkt, was erkannt worden ist.

    Eine Möglichkeit gibt es nach, erfordert aber ein bisschen Arbeit mit dem Lötkolben:

    https://github.com/jeffmakes/pi-data-recovery

    Falls das auch nicht hilft, kann man immer noch den eMMC auswechseln.

    Dafür benötigt man aber entsprechende Hardware und Geduld.

    Schade, dass die nicht gesockelt sind.

  • Da hängt auch das Protokoll noch dazwischen. Es gibt Befehle zum Lesen von Blöcken und zum Schreiben und noch viele andere, die im Standard vorhanden sind. Der verwendete SoC hat dafür eine Schnittstelle, die der elektrischen Spezifikation von SD-Karten entspricht. Im SoC ist die Logik zur Ansteuerung der eMMC/SD-Karte implementiert und über den Linux-Treiber wird die Schnittstelle angesprochen.

    Wenn z.B. die Initialisierung des eMMC nicht mehr funktioniert, dann bekommt der Host-Controller gar keine Daten mehr.

    Auf einem Mikrocontroller mit Micropython würde das einen OSError auslösen.

    Wenn sich also der eMMC nicht meldet, ist das ein Hinweis darauf, dass auch der Host-Controller des SoC keine gültige Antwort vom eMMC bekommt. Das ist so, als würde man einen USB-Stick mit kaputten Flash-Speicher anschließen. Die Logik funktioniert weiterhin, aber der Flash-Speicher meldet sich nicht, ergo wird auch kein neues Blockgerät erkannt.

  • Es ist mir jetzt echt peinlich - aber das ist ein ganz einfach ein PEBKAC Problem :blush:

    Aus mir unverstaendlichen Gruenden dachte ich man sieht auch mit sudo blkid Blockdevices die keine Partitionen enthalten.. Nachdem auch deets in dieselbe Kerbe wie RTFM und @DeaD_EyE gehauen hat und schrieb mit lsblk kann man alle Devices sehen habe ich mich noch mal schlaugemacht: Und - blkid zeigt nur Devices mit Partitionen an waehrend lsblk auch Devices ohne Partitionen anzeigt. Sprich - der eMMC Storage ist zugreifbar - nur habe ich mich so bloed angestellt und den falschen Befehl fuer die Anzeige genutzt :@

    Eben habe ich erfolgreich ein RaspbianOS Image auf eMMC geflashed und gebootet :)

    Noch einmal vielen Dank an alle fuer die tatkraeftige Unterstuetzung und Hilfe. Irgendwie war ich echt nervoes weil beim dd /dev/zero auf den eMMC sich der Befehl aufgehaengt hat und ich das Konsolfenster schliessen musste. Offensichtlich mag das mass-storage-gadget nicht wenn man ihm unter der Decke die Partitionen wegzieht.

    Die ganze Sache werde ich wohl genauso wenig vergessen wie eine Sache bei meinem ersten C Projekt: Ich habe mich gewundert warum der folgende Code nicht so lief wie ich wollte :lol:

    Code
    int a,b;
    
    ... assign some values to a and b ...
    
    if (a = b) {
       ... do something if a and b are equal ...
    } else {
       ... do something if a and b are unequal
    }
  • blkid zeigt nur Devices mit Partitionen an waehrend lsblk auch Devices ohne Partitionen anzeigt.

    Das wusste ich auch nicht, habe aber die Angewohnheit Kernel-Meldungen zu lesen.

    Deswegen wäre mir dieser Unterschied gar nicht aufgefallen.

  • Das wusste ich auch nicht

    Da gibt es sicherlich noch mehr die das nicht wissen. Deshalb habe ich ja fuer diejenigen noch mal explizit darauf hingewiesen :)

    Angewohnheit Kernel-Meldungen zu lesen.

    Die habe ich schon gelesen. Aber beim CM4 gibt es offensichtlich noch weitere emmc Devices die mich irritiert haben. Ich lösche nachher noch mal den internen emmc und zeige die Bootmeldungen.

  • Wer genau lesen kann ist eindeutig im Vorteil :blush: Die ersten beiden Zeilen habe ich irgendwie ueberlesen. Da steht eindeutig dass eine eMMC Karte mit 32GB erkannt wurde. Die drei letzten Zeilen haben mich irgendwie davon abgelenkt denn die gibt es bei dem Raspberry nicht.

    Code
    [    3.288987] mmc0: new DDR MMC card at address 0001
    [    3.297236] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB 
    [    3.304514] Run /sbin/init as init process
    [    3.317091] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB
    [    3.324514] mmcblk0boot0: mmc0:0001 BJTD4R 4.00 MiB 
    [    3.334492] mmcblk0boot1: mmc0:0001 BJTD4R 4.00 MiB 
    [    3.344076] mmcblk0rpmb: mmc0:0001 BJTD4R 4.00 MiB, chardev (242:0)

    Ich habe dass vollstaendige UART Bootlog incl der OS Bootmeldungen der Vollstaendigkeit halber noch angehaengt falls es jemanden interessieren sollte :)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!