Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ich verfolge dieses Problem nur am Rande, aber vielleicht sind bei diesem Schadensbild gar nicht [immer] die Schreibzyklen des Chips erschöpft (die sind laut Datenblatt relativ hoch bei diesen kleinen Dingern!) und er ist einfach nur "voll"? Quasi wie ein zu 100% gefülltes Dateisystem, weil ursprünglich keine Bereinigungslogik implementiert wurde. Und aus welchem Grund auch immer sperrt die Firmware in diesem Zustand halt komplett bzw. bleibt in einem undefinierten Zustand hängen, wodurch ohne externes Flashing kein Zugriff mehr möglich ist.
Genau das ist die Frage. Der Hersteller sagt halt nein, ist kaputt. Vielleicht ist das eben nur die halbe Wahrheit. Wenn der Chip ohne externe Programmiergeräte nicht mehr beschreibbar ist und man eine Pressemeldung rausgeben will, die den Sachverhalt selbst für DAUs ausreichend klar rüberbringt, dann ist "kaputt" wohl die beste Zusammenfassung, selbst wenn die Wahrheit ist, dass der Chip eben *nicht* kaputt ist, sondern nur eine "professionelle" Reparatur benötigt. Das wäre eine Möglichkeit.
Die andere wäre, dass der Typ, der die Idee hatte, die Chips durch externes Flashen wieder zum Leben zu erwecken, zufällig mit dem einen Chip (er hat es AFAIK ja nur ein einziges Mal probiert) getestet hat, der noch gar nicht vollständig totgeschrieben war. Dass sein Account bei Reddit gelöscht und seine Posts weg sind, macht es auch nicht vertrauenswürdiger. Und dass die ersten Tests hier im Forum wenig Erfolg hatten, ebenso. Aber klar, kaputt sind die Boards schon, einen Versuch ist es wert. Kaputter als kaputt kann es vereinfacht gesagt ja auch nicht werden.
Extern flashen hilft. Eventuell zuerst mit --erase durchwischen.
Beim T480 bei drei Boards durchexerziert, die entsprechende Symptome aufwiesen (Akku lädt nicht mehr oder nur noch extrem langsam, oder es wird angezigt, dass das verbundene [65W-]Netzteil einen zu geringen Anschlusswert hat).
Auf welchen Hersteller beziehst du dich hier? Lenovo oder den Hersteller des EEPROM?
Ich gehe auch eher wie du davon aus, dass sich die Erklärung "ist defekt" nämlich tatsächlich an den DAU orientiert, analog zu dem PC Spezialisten um die Eck, der einem wenn er nicht mehr weiter weiss mit dem Satz ".. das Mainboard ist defekt" begegnet.
Jeder weiss, dass man selbst SPI Chips wie ein EEPROM mit dem passenden Lötzeugs auch physisch wechseln kann, selbst wenn er tatsächlich defekt ist.
Davon ist aber nicht auszugehen, da KB19 schon Recht hat.
Durch bloßes Schreiben sind die Dinger nicht so einfach totzukriegen. Deswegen hat ja auch Lenovo dies als Bug bezeichnet, mit einem Fix, den man einspielen kann. (nochmal als Recap) → Das Zeitfenster für diesen SW Fix ist allerdings recht klein, denn wenn der Bug sich bereits in der HW manifestiert hat (langsames Laden, keine Reaktion von den Buchsen, etc) dann zeigt der Fix von Lenovo keinen Effekt mehr. Was Adam da in seinem Gitrepo beschrieben hat ist halt nur der manuelle Hands-on Weg, der man gehen muss, wenn das Zeitfenster bereits verstrichen ist. Und in der Theroie macht das durchaus Sinn.
Die andere wäre, dass der Typ, der die Idee hatte, die Chips durch externes Flashen wieder zum Leben zu erwecken, zufällig mit dem einen Chip (er hat es AFAIK ja nur ein einziges Mal probiert) getestet hat, der noch gar nicht vollständig totgeschrieben war.
Möglich. Auch ich habe den TB Chip eines T480 mal dieser Prozedur unterzogen. Aber rein aus prophylaktischen Gründen. Defekt war er nicht. @iks230@ppk Hattet ihr den Flashvorgang auf einem (teil)defekten EEPROM ausgeführt gehabt?
Zumindest der User in Post #21 scheint damit Erfolg gehabt zu haben.
Und jetzt kam auch prompt die Bestätigung von @xxxx.
In dem Fall würde ich dir @poiu empfehlen den Prozess erneut auszuführen. Du kannst nur sichergehen, dass der Flashvorgang geklappt hat, wenn du die sha256 Summen vorher und nacher mit einander vergleichst. Also immer wieder neu einlesen und mehrmals mit der gepaddeten .bin File vergleichen.
Das habe ich auch vorher ausgeführt, ist halt Best Practice und schaden tuts nicht.
Beitrag automatisch zusammengeführt:
Btw, der Thunderbolt Bug wird auch vom coreboot Projekt als solches anerkannt. Ich gehe also schon stark davon aus, dass es mehrere Boardrettungen gegeben haben muss.
Stimmt, Accounts löschen kommt immer mal wieder vor. Aber die wenigsten machen vorher alle ihre bisherigen Beiträge unbrauchbar. Warum auch? Gerade bei solch informativen Beiträgen macht es wenig Sinn.
Eine kurze Suche scheint es aber zu bestätigen, dass man da gegen Reddit rebelliert und seine Texte durch Texte aus diesem Textgenerator ersetzt: https://zompist.com/gen.html
Stimmt. Und das ist doch mal eine sehr gute Nachricht. Nämlich, dass diese Boards bzw. Geräte verhältnismäßig einfach zu retten sind. Kein Boardwechsel nötig, keine Lötkünste erforderlich, keine zusätzliche Tausch-Hardware (neuer EEPROM) zu besorgen, einfach "nur" neu flashen - mit Komponenten, die so mancher Bastler sogar schon da hat.
Btw, der Thunderbolt Bug wird auch vom coreboot Projekt als solches anerkannt. Ich gehe also schon stark davon aus, dass es mehrere Boardrettungen gegeben haben muss.
ich würde immer den Chip zuerst neu flashen. Wenn es dabei Probleme gibt oder wenn das ursprüngliche Problem damit nicht behoben ist, dann würde ich im nächsten Schritt den Chip tauschen.
