Flash-Speicher "weg" ? (Internal Storage 0MB in TWRP) nach Crash des OS

[ReactivateMe347]

Bitte Danke

 

[siggi%%44]

Kurze Antwort: Du hast recht, ich nicht.

Du betreibst TWRP ausschließlich aus deinem RAM. Im folgenden sind nur Textstellen aus deinem Kernel Log. Die wichtigen Stellen sind fett markiert.

Der Kernel registriert zwar, dass es einen Speicher gibt...

<6>[ 4.244610] c1 mshci: Mobile Storage Host Controller Interface driver
<6>[ 4.244645] c1 mshci: Copyright (c) 2011 Samsung Electronics Co., Ltd
<6>[ 4.244824] c1 dw_mmc dw_mmc: clock source 0: sclk_dwmci (40000000 Hz)
<3>[ 4.246116] c1 mmc0: Version ID 0x5342240a.
<6>[ 4.249057] c1 mmc0: FIFO WMARK FOR RX 0x80 WX 0x40. ###########
<6>[ 4.250576] c1 mmc0: MSHCI controller on samsung-mshci [dw_mmc] using IDMA

...kann aber nicht mit ihm kommunizieren:

<3>[ 4.292972] c0 mmc0: cmd 8 response timeout error
<3>[ 4.297035] c0 mmc0: cmd 5 response timeout error
<3>[ 4.301715] c0 mmc0: cmd 5 response timeout error
<3>[ 4.306386] c0 mmc0: cmd 5 response timeout error
<3>[ 4.311068] c0 mmc0: cmd 5 response timeout error

Mehr Infos gibt es dazu nicht. Ist aber trotzdem schon aussagekräftig genug, wie ich finde. Falls es dich tröstet, die restliche Hardware läuft tadellos.

Interessant ist, dein USB-Port befindet sich im EDL Mode (Emergency Download Mode) und müsste am PC im Windows Gerätemanager als Qualcomm HS-USB QDLoader 9008 (COM<Port>) erscheinen (Linux: lsusb):

<7>[ 5.310166] c0 s5p-ehci s5p-ehci: port 2 high speed
<7>[ 5.310207] c0 s5p-ehci s5p-ehci: GetStatus port:2 status 001005 0 ACK POWER sig=se0 PE CONNECT
<7>[ 5.385826] c0 usb 1-2: default language 0x0409
<7>[ 5.386204] c0 usb 1-2: udev 2, busnum 1, minor = 1
<6>[ 5.386235] c0 usb 1-2: New USB device found, idVendor=05c6, idProduct=9008
<6>[ 5.386279] c0 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[ 5.386328] c0 usb 1-2: Product: QHSUSB__BULK
<6>[ 5.386355] c0 usb 1-2: Manufacturer: Qualcomm CDMA Technologies MSM
<7>[ 5.386737] c0 usb 1-2: usb_probe_device
<7>[ 5.386770] c0 usb 1-2: configuration #1 chosen from 1 choice
<7>[ 5.387080] c0 usb 1-2: adding 1-2:1.0 (config #1, interface 0)
<7>[ 5.387367] c0 qcserial 1-2:1.0: usb_probe_interface
<7>[ 5.387401] c0 qcserial 1-2:1.0: usb_probe_interface - got id
<6>[ 5.387445] c0 check_chip_configuration: usb product name = QHSUSB__BULK
<6>[ 5.387484] c0 mdm9x15 boot protocol = SAHARA
<6>[ 5.387512] c0 qcserial 1-2:1.0: Qualcomm USB modem converter detected
<6>[ 5.387994] c0 usb 1-2: Qualcomm USB modem converter now attached to ttyUSB0

 

[ReactivateMe347]

Danke für die Rückmeldung. Die Frage ist, was bringt der EDL? "Downloaden" also flashen kann er ohne Ziel ja nicht.

Ich für meinen Teil bin zurück bei "Kalte Löstelle? zerlegen, in den Backofen und das beste hoffen." - ich glaube nicht, dass ein generischer Handy-Schrauber sowas kann, die tauschen ja zumeist nur Bildschirme und Akkus. Und die, die das könnten (Samsung Store oder so) nehmen dafür sicherlich lächerliche Preise.

Nachtrag: Das hier https://jo-so.de/2021-07/Note-2-MMC-Ausfall.html macht ein bisschen Hoffnung. Werde ich mir am Wochenende mal ansehen. Hab ich finden können, weil du die relevanten Zeilen isoliert hast.

mmc0: cmd 8 response timeout error

habe ich zwar auch verstanden,

c1 mmc0: FIFO WMARK FOR RX 0x80 WX 0x40.

allerdings ist mir völlig unklar.

 

[siggi%%44]

Danke für die Rückmeldung. Die Frage ist, was bringt der EDL? "Downloaden" also flashen kann er ohne Ziel ja nicht.

Ehrlich gesagt bin ich etwas verwirrt. Der EDL Mode ist ein eigenes Ding von Qualcomm. Du hast aber eine Exynos CPU. Soweit ich weiß, haben die beiden nix miteinander zu tun.
Jedenfalls kannst du im EDL Mode über ein bestimmtes Protokoll direkt mit der CPU kommunizieren, um bei einem defekten Bootloader diesen ersetzen zu können. Normalerweise gibt das Gerät in diesem Modus keinen Pieps mehr von sich und du erkennst den Mode nur daran, dass das Gerät als Qualcomm HS-USB QDLoader 9008 erkannt wird.
Dein Problem ist aber nicht ein defekter Bootloader, sondern der gesamte Speicher. Das System erkennt aber nur, dass der Bootloader nicht ansprechbar ist und startet somit den EDL Mode. Einen Nutzen hat das natürlich nicht für dich, weil du auch in dieser Situation nichts auf den Speicher flashen kannst.

Momentan kann ich auch nichts zu den Fehlercodes sagen. Ich weiß aber, woher sie kommen, nämlich vom Mobile Storage Host Controller Interface (mshci). Das ist ein Kernel Modul und ich versuche mal, etwas brauchbares bzgl. deines Problems herauszufinden. Glücklicherweise ist Android quelloffen und das gilt auch für alle Kernel Codes der Hersteller. Ich melde mich zeitnah wieder.

 

[ReactivateMe347]

Danke dir. Die Frage wäre ja, ob man auch Ebene des EDL um den Freeze des mmc herumkommt und die Informationen dumpen kann. Bei funktionierenden Geräten scheint das zu gehen, wenn ich mir https://cellebrite.com/en/accessing-encrypted-mobile-device-evidence-using-edl/ ansehe (Cellebrite stellt Tools zum forensischen Auslesen von Mobilgferäten bereit und dem Link nach scheint eine der Methoden via EDL zu sein.)

 

[siggi%%44]

Du kannst mit diesem Tool versuchen dein Handy auszulesen. Habe es selber schon benutzt und kann nur sagen, dass es derzeit mit Abstand das beste Tool ist für solche Zwecke. Es setzt zwar ein Linux-Betriebssystem voraus, aber das spricht im Grunde für sich.

 

[ReactivateMe347]

Wo sollte denn "Qualcomm HS-USB QDLoader 9008" auftauchen? im Windows-Geräte-Manager sehe ich als "USB-Gerät" GT-N7105. Das ist per MTP Zugreifbar, hat dann aber keine Partition (was zu erwarten ist). Unter COM & LPT steht ein COM-Device (dein empfhlones Tool hat in der Readme stehen, man könne den Windows COM-Treiber verwenden, daher die Vermutung COM), das verschwindet aber beim abstecken des Handies nicht, ist also was anderes.

Wo siehst du die Notwendigkeit für Linux, die Readme.md listet doch eine Installation für Windows - oder ist die funktionseingeschränkt?

Danke.

 

[siggi%%44]

Hab eben auch gesehen, dass der USB-Port von Qualcomm

status 001005 0 ACK POWER sig=se0 PE CONNECT
<7>[ 5.385826] c0 usb 1-2: default language 0x0409
<7>[ 5.386204] c0 usb 1-2: udev 2, busnum 1, minor = 1
<6>[ 5.386235] c0 usb 1-2: New USB device found, idVendor=05c6, idProduct=9008
<6>[ 5.386279] c0 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[ 5.386328] c0 usb 1-2: Product: QHSUSB__BULK
<6>[ 5.386355] c0 usb 1-2: Manufacturer: Qualcomm CDMA Technologies MSM
<7>[ 5.386737] c0 usb 1-2: usb_probe_device
<7>[ 5.386770] c0 usb 1-2: configuration #1 chosen from 1 choice
<7>[ 5.387080] c0 usb 1-2: adding 1-2:1.0 (config #1, interface 0)
<7>[ 5.387367] c0 qcserial 1-2:1.0: usb_probe_interface
<7>[ 5.387401] c0 qcserial 1-2:1.0: usb_probe_interface - got id
<6>[ 5.387445] c0 check_chip_configuration: usb product name = QHSUSB__BULK
<6>[ 5.387484] c0 mdm9x15 boot protocol = SAHARA
<6>[ 5.387512] c0 qcserial 1-2:1.0: Qualcomm USB modem converter detected
<6>[ 5.387994] c0 usb 1-2: Qualcomm USB modem converter now attached to ttyUSB0

auf ADB wechselt:

[ 6.929656] c3 init: Starting service 'recovery'...
<7>[ 6.931444] c3 usb: enable_store enabled=0, !dev->enabled=1
<7>[ 6.931508] c3 usb: usb_gadget_disconnect
<5>[ 6.931637] c3 init: Starting service 'adbd'...
<7>[ 6.932944] c3 usb: enable_store enabled=1, !dev->enabled=1
<7>[ 6.933031] c3 usb: enable_store vendor=18d1,product=d001,bcdDevice=226
<7>[ 6.933124] c3 ,Class=0,SubClass=0,Protocol=0
<7>[ 6.933187] c3 usb: enable_store next cmd : usb_add_config
<6>[ 6.937238] c1 max77693_charger_irq: INT_OK(0x5d), THM(0x0), CHGIN(0x3), CHG(0x8), BAT(0x3), ST2(0x41)
<6>[ 6.940707] c0 adb_open
<7>[ 6.940763] c0 usb: android_bind_enabled_functions f:adb
<6>[ 6.940837] c0 adb_bind_config
<7>[ 6.940913] c0 usb: usb_gadget_connect

In diesem Moment wird die Recovery, bzw. TWRP gestartet.

Ergänzung (7. Mai 2022)

Wo siehst du die Notwendigkeit für Linux, die Readme.md listet doch eine Installation für Windows

Dann war das ein anderes Tool. Nutze dieses nur in Linux, deswegen hatte ich das verwechselt.

In TWRP könntest du per ADB-Befehl adb reboot edl oder in TWRP selber im Terminal twrp reboot edl den EDL Mode starten. Ich weiß aber nicht, ob sich danach TWRP wieder starten lässt, bzw. du aus dem EDL Mode rauskommst.

 

[ReactivateMe347]

Die schlechte Nachricht: twrp reboot edl bootet zum üblichen Bootlogo, also womöglich nicht zu EDL, sondern zum normalen Boot. Ich sehe weder einen COM noch ein USB-Gerät im Gerätemanager.
Die gute Nachricht: Ich komme auch weiterhin ins Recovery.

Ergänzung (7. Mai 2022)

Dann war das ein anderes Tool. Nutze dieses nur in Linux, deswegen hatte ich das verwechselt.

Oder evtl. wurde die Kompatibilität auch ergänzt. Danke für die Info.

Und vor allem auch für die wichtige Warnung.





Könnte der Logeintrag evtl bedeuten, dass als generisches recovery nur versucht wird, den EDL zu starten und das in Wahrheit gar nicht passiert?

 

[siggi%%44]

@ReactivateMe347 Falls es interessiert, so sähe es korrekt aus:

<6>[ 2.208868] c0 mshci: Mobile Storage Host Controller Interface driver
<6>[ 2.208904] c0 mshci: Copyright (c) 2011 Samsung Electronics Co., Ltd
<6>[ 2.209106] c0 dw_mmc dw_mmc: clock source 0: sclk_dwmci (40000000 Hz)
<3>[ 2.209389] c0 mmc0: Version ID 0x5342240a.
<6>[ 2.209638] c0 mmc0: FIFO WMARK FOR RX 0x80 WX 0x40. ###########
<6>[ 2.210108] c0 mmc0: MSHCI controller on samsung-mshci [dw_mmc] using IDMA
<6>[ 2.210436] c0 sdhci: Secure Digital Host Controller Interface driver
<6>[ 2.210472] c0 sdhci: Copyright(c) Pierre Ossman
<6>[ 2.210604] c0 s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (88888888 Hz)
<6>[ 2.210879] c0 mmc1: vtf_2.8v regulator found
<3>[ 2.240840] c0 mmc0: cmd 52 response timeout error
<3>[ 2.241684] c0 mmc0: cmd 52 response timeout error
<3>[ 2.245711] c0 mmc0: cmd 8 response timeout error
<3>[ 2.246552] c0 mmc0: cmd 5 response timeout error
<3>[ 2.247378] c0 mmc0: cmd 5 response timeout error
<3>[ 2.248205] c0 mmc0: cmd 5 response timeout error
<3>[ 2.249029] c0 mmc0: cmd 5 response timeout error
<3>[ 2.249868] c0 mmc0: cmd 55 response timeout error
<3>[ 2.250708] c0 mmc0: cmd 55 response timeout error
<3>[ 2.251549] c0 mmc0: cmd 55 response timeout error
<3>[ 2.252388] c0 mmc0: cmd 55 response timeout error
<4>[ 2.284007] c2 mmc0: Voltage range not supported for power class.
<3>[ 2.284044] c2 mmc0: power class selection to bus width 8 failed
<4>[ 2.284261] c2 mmc0: Voltage range not supported for power class.
<3>[ 2.284297] c2 mmc0: power class selection to bus width 8 ddr 2 failed
<6>[ 2.284459] c2 mmc0: new high speed DDR MMC card at address 0001
<6>[ 2.284975] c2 mmcblk0: mmc0:0001 MAG2GA 14.6 GiB
<6>[ 2.285204] c2 mmcblk0boot0: mmc0:0001 MAG2GA partition 1 2.00 MiB
<6>[ 2.285417] c2 mmcblk0boot1: mmc0:0001 MAG2GA partition 2 2.00 MiB
<6>[ 2.289179] c2 mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
<6>[ 2.293076] c2 mmcblk0boot1: unknown partition table
<6>[ 2.294023] c2 mmcblk0boot0: unknown partition table

Quelle: gist.github.com

Hier steht zwar auch kurz der Fehler "cmd XX response timeout error", aber der Speicher wird kurz danach erkannt.
Soweit ich das herausfinden konnte, ist "cmd XX" nur ein Testbefehl. Es werden halt verschiedene numerierte Befehle abgesetzt, um den genauen Speichertyp definieren zu können. Je nach Antwort bestimmt der Kernel die Kompatibilität des Speichers.

Könnte der Logeintrag evtl bedeuten, dass als generisches recovery nur versucht wird, den EDL zu starten und das in Wahrheit gar nicht passiert?

Der Kernel macht folgendes:
Zuerst wird der USB-Port initialisiert...

<6>[ 3.574758] c0 usbcore: registered new interface driver asix

...und danach werden die einzelnen Modi abgefragt, z.B. OTG oder Mass Storage.

Dann merkt der Kernel, dass mmc0 nicht existiert...

<3>[ 4.470058] c0 mmc0: error -110 whilst initialising MMC card
...
<6>[ 4.513990] c0 sdhci_set_ios : MMC Card OFF samsung-hsmmc

...und deaktiviert den USB-Port, um ihn erneut zu initialisieren:

<6>[ 4.646892] c0 usb usb2: USB disconnect, device number 1 by usb_remove_hcd+0x110/0x1d8
...
<6>[ 4.766541] c0 usb usb1: USB disconnect, device number 1 by usb_remove_hcd+0x110/0x1d8
...
<6>[ 4.945051] c0 s5p-ehci s5p-ehci: USB 0.0 started, EHCI 1.00

Nur diesmal wird der USB-Port als Power und EDL Mode initialisiert. Bis dann die Recovery gestartet und ADB aktiviert wird.

Wie startest du eigetlich TWRP? Startet es automatisch? Denn irgendwie muss der Kernel in den RAM geladen worden sein. Von der Partition /recovery kann er nicht gelesen werden.

 

[ReactivateMe347]

@siggi%%44 Ich starte den über die Tastenkombination (Vol+, Home und Power). Startet man das Gerät normal, so bleibt er im Bootlogo (Kein Bootloop)

 

[siggi%%44]

@ReactivateMe347 Bedeutet, entweder wird dein boot.img oder mit Tastenkombi TWRP geladen. Im RAM kann aber nur ein einziger Kernel abgelegt werden und nicht zwei gleichzeitig. Also wählt der Bootloader den passenden Kernel von /boot oder /recovery aus, um ihn dann in den RAM zu laden. Anders geht es nicht.

Der Kernel im boot.img ist ein anderer als im twrp.img und dein kmsg.log zeigt den Kernel von TWRP. Könnte sein, dass es dein boot.img schafft, den Speicher zu mounten. Nur leider kannst du bei normalem Boot kein Log ziehen, um dir das anzusehen.