Hallo Allerseits, ich habe in der Firma ein Embedded System mit ARM9 und SD-Karte, darauf läuft Linux. Leider ist es so, daß bei unseren aktuellen Micro SD-Karten (4GB Intenso irgendwas) ca. 30-50% vom System nicht erkannt werden. An verschiedenen normalen PCs ist das kein Problem. Es gibt die Information vom Softwerker, daß wohl der Linuxtreiber an einigen Stellen bezüglich Timeouts bei der Initialisierung zu pingelig ist. Mehr ist nicht bekannt. Um das Problem erstmal einzukreisen will ich nun mit einem Arduino + SD-Card Shield mal die Initialisierung zeitlich analysieren. Dazu werde ich FATfs von ELM Chan nutzen. Das habe ich alles schon in der Schublade liegen. Jetzt die Frage: Hat jemande ein paar Hinweise zum Thema? Welche Zeiten sind kritisch? Woraus sollte man sonst achten? Die Hardware ist OK, saubere 3,3V, die CPU arbeitet sowieso mit 3,3V IOs. Und bitte keine schlauen Kommentare ala "Schau doch in die SD-Spec". Das will ich erstmal vermeiden, denn ich kann und will in die Sache nicht allzu viel Zeit investieren. Außerdem sind Infos von Leuten, die Wissen und vor allem Erfahrung haben deutlich besser.
Einfach mal ein kleines Linux auf die SD-Karte vom PC/Laptop aus installieren. Je nach Kartentyp sind die SD-Karten grottig beim Random-Schreiben. Auch der Bootvorgang war nach meiner Erinnerung sehr beschaulich. Ruhig mal eine höherwertige Karte probieren. Wenn man SD-Karten als Daten-Partition mit sequentiellen Schreiben verwendet fällt es nicht so auf.
Moin, - der guenstigste Weg ist der Kauf von neuen, hochwertigen Karten (sonst wird das zum SPR-Generator[*]) und der Kunde ist nicht gluecklich. Der Weg ist erstmal herauszubekommen, ob die Karte als SD oder MMC angeklemmt ist (1Bit gegen 4bit). Direkt beim Linux-Board messen (gucke hier http://elm-chan.org/docs/mmc/mmc_e.html) Ein kleines Erklaerung: https://forum.arduino.cc/t/sd-mmc-from-the-ground-up/8376 besonders gut ist die Link-liste beim dritten Post. Gruesse Th. [*] SPR: Software Performance Report vulgo Bugreport
Falk B. schrieb: > daß bei unseren aktuellen Micro SD-Karten > (4GB Intenso irgendwas) Raus damit. Die sind hier praktisch alle vorzeitig ausgefallen. Wenn die irgendwas längerfristig Daten halten sollen, nimm Samsung oder Sandisk SDHC Karten. SD Karten verhalten sich mitunter im SPI Modus anders als im SD Mode. Kannst Du beim ARM9 System überhaupt den Bootloader o.ä. ändern?
Jim M. schrieb: >> daß bei unseren aktuellen Micro SD-Karten >> (4GB Intenso irgendwas) > > Raus damit. Die sind hier praktisch alle vorzeitig ausgefallen. Naja, es sind schon Billiggurken. Aber dort werden nur ein paar Meßdaten gespeichert. Weder sonderlich viel noch sonderlich oft, wenn man es mit einer Digitalkamera oder gar Video vergleicht. Das Problem besteht ja schon am Anfang. Sie wrden nicht erkannt. Ganz dumm ist, daß eben ein Teil erkannt wird, der dann aber im Feld nicht mehr erkannt wird. 8-0 > Wenn die irgendwas längerfristig Daten halten sollen, nimm Samsung oder > Sandisk SDHC Karten. Das stimmt sicher, ist aber im Moment nicht das Problem. > SD Karten verhalten sich mitunter im SPI Modus anders als im SD Mode. Hmm. > Kannst Du beim ARM9 System überhaupt den Bootloader o.ä. ändern? Ich kann es mangels Kenntnissen nicht, prinzipiell wäre es aber möglich. Fragt sich, wo der SD-Card Treiber sitzt. Hat der Bootloader und der Linuxkernel den gleichen oder sind die getrennt? Der ARM9 bootet von Flash, erst im Linux wird die SD-Karte genutzt.
Beitrag #7103432 wurde von einem Moderator gelöscht.
DerEinzigeBernd schrieb im Beitrag #7103432: > Wenn die Karten 4 GB groß sind, sollten es SDHC-Karten sein; Das sind sie. Die Karten sind schon OK, nix Hack oder so. Nur halt eher billig. Aber jeder PC kann sie lesen, nur der pissige Linux-Treiber nicht! > Kann man so kleine Karten überhaupt noch neu kaufen, Ja. > oder ist das ein > Museumsbestand? Nein.
Von Intenso SPI-Mode kann ich nur abraten. Was haben denn deine Karten so für Manufacturer IDs? Alle mit 0x00 können in die Ablage Elektroschrott, falls du SPI nutzt.
dummschwaetzer schrieb: > Von Intenso SPI-Mode kann ich nur abraten. > Was haben denn deine Karten so für Manufacturer IDs? Keine Ahnung. Hat noch nie einer ausgelesen. > Alle mit 0x00 können in die Ablage Elektroschrott, falls du SPI nutzt. Der ARM9 redet in 4 Bit, ganz normal, nix SPI.
Falk B. schrieb: > > Der ARM9 redet in 4 Bit, ganz normal, nix SPI. [Frueher schrubst Du:] > Um das Problem erstmal einzukreisen will ich nun mit einem Arduino + > SD-Card Shield mal die Initialisierung zeitlich analysieren. Dazu werde > ich FATfs von ELM Chan nutzen. Das habe ich alles schon in der Schublade > liegen. Dann ist Dein Ansatz mit Arduino und Timing testen am Ende: Arduino benutzt SPI. Gruesse Th.
Falk B. schrieb: > ARM9 und SD-Karte, darauf > läuft Linux. Geht das bitte etwas genauer? ARM9-SoC gibt es Tausende verschiedene. Und Linux gibt es seit ca. 30 Jahren in verschiedensten Versionen (aktuell wird an v5.19 gebaut)... Also: welches Board, welcher SoC, welche Linux-Kernel-Version, welcher User-Space?
Hast du die Karte mal vollständig gelöscht und dann einen Linux-Zugriff versucht? Mit blkdiscard kann man den internen Löschvorgang im Controller der SD-Karte auslösen. Das geht allerdings meistens nur, wenn die Karte in einem richtigen MMC/SD-Slot steckt. Mit USB->SD-Adapter geht es oft nicht, wenn der Adapter den Befehl nicht weiterreichen kann.
MaWin schrieb: > Hast du die Karte mal vollständig gelöscht und dann einen Linux-Zugriff > versucht? Nein. Wozu auch? Die Karte ist auf anderen Systemen (PC) problemlos lesbar. Es das Timingproblem des Treibers ist bekannt.
Falk B. schrieb: > das Timingproblem des Treibers ist bekannt. Ich habe noch nie ein "Timingproblem" mit einem Treiber bei SD-Karten gehabt. Was soll das sein? Ich halte das für ziemlichen Quatsch. Ich habe aber sehr wohl fehlfunktionierende Karten gehabt, die nach einem blkdiscard-Urlöschen wieder korrekt funktionierten. Außerdem habe ich nur auf die Ursprungsfrage geantwortet: "Initialisierung einer SD-Karte".
Nikolaus S. schrieb: >> ARM9 und SD-Karte, darauf >> läuft Linux. > > Geht das bitte etwas genauer? > ARM9-SoC gibt es Tausende verschiedene. > Und Linux gibt es seit ca. 30 Jahren in verschiedensten Versionen > (aktuell wird an v5.19 gebaut)... Jaja, alles richtig. Es ist relativ alter Kram. Das SoC wurde um 2008 entwickelt und läuft seitdem bei uns in diversen Geräten. Das Linux bzw. der Kernel ebenso. Da wurde zwar noch einige Jahre dran gearbeitet, aber ich glaub der Kernel ist jetzt locker 10 Jahre praktisch unverändert. Er läuft und tut das, was er soll. Fast. > Also: welches Board, welcher SoC, welche Linux-Kernel-Version, welcher > User-Space? Es ist im Prinzip das Ding hier, aber wir produzieren es selber, anderes LCD, in Summe DEUTLICH preiswerter ;-) Keine Ahnung, wie das bei DEM Preis heute noch marktfähig sein soll? Ist vielleicht nur der Preis für Einzelstücke im Onlineshop. Egal. https://www.taskit.de/produkte/embedded-produkte/hmi/83/panel-card-57-with-5.7-tft-640x480-pixels?c=41 Die exakte Linuxversion kenne ich nicht, müßte ich mal das Bootlog anschauen. Das ganze Kram läuft glaub ich als root. Ist aber egal, denn es funktioniert ja alles. Auch mit den meisten SD-Karten. Aber halt nicht mit einigen. Bisher hat man einfach die nicht funktionierenden aussortiert, jetzt kocht das Problem aber hoch, wie zu erwarten 8-0 Ich werde erstmal Tests mit dem Arduino (SPI) machen und hoffen, da ein paar Unterschiede zu sehen. Dann klemm ich mal den Logicanalyzer an das originale Board (SDIF) und versuche dort was zu sehen. Dauert ein paar Tage. Erstmal vielen Dank für alle Hinweise.
Es gibt auch viele Nieten. H2testw 1.4 hilft evtl. sie zu erkennen. https://www.heise.de/download/product/h2testw-50539
MaWin schrieb: >> das Timingproblem des Treibers ist bekannt. > > Ich habe noch nie ein "Timingproblem" mit einem Treiber bei SD-Karten > gehabt. > Was soll das sein? Es soll wohl eine Wartezeit im Treiber recht knapp sein. Mehr Infos habe ich nicht. http://elm-chan.org/docs/mmc/mmc_e.html "The card initiates the initialization process when a CMD1 is received. To detect end of the initialization process, the host controller needs to send CMD1 and check the response until end of the initialization. When the card is initialized successfuly, In Idle State bit in the R1 response is cleared (R1 resp changes 0x01 to 0x00). The initialization process can take hundreds of milliseconds (large cards tend to longer), so that this is a consideration to determin the time out value. After the In Idle State bit cleared, the card gets ready to accept the generic read/write commands." Hier vermute ich das Problem.
oszi40 schrieb: > Es gibt auch viele Nieten. H2testw 1.4 hilft evtl. sie zu > erkennen. > https://www.heise.de/download/product/h2testw-50539 Was soll das bringen? Es gibt kein Problem mit falscher Speichergröße, die Karte wird vom Zielsystem nicht erkannt! Bzw. manchmal wird sie es, manchmal nicht! Am PC wird sie IMMER erkannt! Ergo. Die Karte ist nicht defekt, bestenfalls etwas zickig.
ich würde das mit einem Logicanalyzer prüfen, dann siehst du ob die Antwort zu lange ausbleibt.
Falk B. schrieb: > Es das Timingproblem des Treibers ist bekannt. Wenn es bekannt und wirklich nur ein Timingproblem ist, wird es mit an Sicherheit grenzender Wahrscheinlichkeit auch einen Patch geben. Möglicherweise ist der sogar schon lange im Treiber eingebaut und wartet nur darauf, irgendwie aktiviert zu werden. Entweder zur Compilezeit oder zur Laufzeit. Nur die Lektüre des Treiber-Quelltextes könnte hier weiterhelfen, auf irgendwelche Dokumentationen der Aktivierung solcher Patches (also welcher, die wahrscheinlich bei Aktivierung den Treiber rein formal nicht mehr standardgerecht machen würden) ausserhalb der Quelltexte kannst du lange warten, u.U. bis in alle Ewigkeit. Wenn du in den Quelltexten "deines" Linux nicht fündig wirst, solltest du zum Vergleich die des Raspi-OS zu Rate ziehen. Da wurde bei der SD-Unterstützung im Laufe der Jahre erheblich in Richtung besserer Kompatibilität nachgebessert. Wenn du da dein Timingproblem findest (also vielmehr: die Lösung dafür), dann musst du das halt in "deinem" Linux entsprechend nachbauen.
Falk B. schrieb: > Bzw. manchmal wird sie es, manchmal nicht! Dann wird wohl eher ein zeitliches, ein Spannungsproblem od. ein simples Kontaktproblem vorliegen? Jedenfalls könnte man den Inhalt 1:1 auf andere SD kopieren und testen? Ein Disk-Editor wäre evtl. auch ein Versuch, die Unterschiede zu ergründen? Nicht jede SD-Karte hat genau den gleichen Controller und schafft alles mit der gleichen SW zum Speicherchip.
Falk B. schrieb: > An verschiedenen normalen PCs ist das kein Problem. : : > Aber jeder PC kann sie lesen, Vergleiche doch mal den Linux(SD-Treiber) Stand der auf dem PC läuft (aktuell von 202X) mit dem eurens Embedded Linux(SD-Treiber) von vor einem Jahzehnt+. Dazwischen hat sowas wie Evolution stattgefunden. Jede Wette da ist die Erklärung zum Problem zu finden! Deine PCs laufen doch mit Linux, oder? Du schrubst nix davon... Ist es am Ende doch BSD? Die SD-Karten-Brauer (ich will extra nicht panscher sagen) produzieren ihre Produkte nämlich auch nicht mehr exakt so wie vor einem Jahzehnt+. Wg. Evolution und so; der Produkte UND deren Produktionsverfaren. (SD vs. SDHC, SPI vs. MMC, 1bit vs. 4bits, usw.) Entsprechend sind die zugehörigen Anpassungen im Linux-SD-Treiber ganz bestimmt geschehen. Andere Linux/ARM9 Macher/Nutzer/Integratoren haben das sicher auch benötigt und ihre Systeme nachgezogen. Das ist ja gottlob dank OpenSource möglich, da müsst ihr keinesfalls auf irgendein "Hersteller" warten der zu faul ist nochmals "build" zu machen oder seine Spielechen auf "dem Markt" treiben will. Ihr hattet es ja vor einem Jahrzehnt+ auch geschafft, also einfach nochmals den selben euer eigenen Prozess von damals nochmals durcharbeiten und schwupps habt ihr ein aktuelles Linux aus der aktuellen Dekade! Dazu bekommst auch interessierten Support von der Kernel- und Treiber- Maintainertruppe. Eher als zum Stand von vor einem Jahrzehnt+. --- Ansonsten: bei einer Schachtel nicht ganz masshaltingen Maschinenschrauben macht auch niemand ein Fass auf: da wird der Restbestand ausm Lager einfach weggekippt (gerne auch 18kg aufs Mal) und neue, richtige gekauft. Genau so solltet ihr mit euren zickigen SD-Karten vorgehen, weil selbe Preisgrössenordnung. Das wurde Dir oben bereits geschrieben. Jede deiner Arbeitsstunden, sich mit den zickigen Teile abzumühen, ist ein Grosses vielfaches teurer als das Material. Ausser eure Stückzahlen gehen weit in die Hunderttausende - aber auch hiervon schrubst Du nix.
Klugschnacker der IXte schrieb: > Genau so solltet ihr mit euren zickigen SD-Karten vorgehen, weil selbe > Preisgrössenordnung. Das wurde Dir oben bereits geschrieben. > Jede deiner Arbeitsstunden, sich mit den zickigen Teile abzumühen, ist > ein Grosses vielfaches teurer als das Material. > Ausser eure Stückzahlen gehen weit in die Hunderttausende - aber auch > hiervon schrubst Du nix. Oder das Kartenproblem taucht beim Kunden auf. Das fällt dann auf das Produkt zurück auch wenn es eigentlich an der SD-Karte liegt.
Angehängte Dateien:
-
LCD.jpg
260 KB
Sooo, ich denke ich habe das Problem gefunden. Es ist die Antwortzeit auf das Initialisierungskommando, wie schon vermutet. Beitrag "Re: Intitialisierung einer SD-Karte" In der Funktion DSTATUS mmc_disk_initialize (void); im FATfs gibt es ein 1000ms Timeout bei der Antwort für das Initialisierungskomando. Das habe ich auf 2500ms erweitert und speichere den gemessenen Wert in einer globalen Variable zur Ausgabe. Ich habe 5 Karten von Intenso, welche im Zielsystem nicht erkannt werden. Die haben Antwortzeiten von 700-1110ms! Pro Karte schwankt diese aber nur wenig, zwischen 0-60ms. Dagegen haben 5 gute Karten der gleichen Marke und Baureihe 210-450ms. Ich vermute mal, daß im Linuxtreiber ein 500ms Timeout besteht. Wenn ich noch ein paar Dutzend Karten teste, finde ich vielleicht welche, die knapp über 500ms liegen und nicht erkannt werden. Ein Test mit 10 Stück von ATP (Industriequalität, SLC, 4GB) liefert für ALLE Karten konstant 210ms! Für den Test habe ich das 1,8'' LCD vom Arduino "leicht" modifiziert, neudeutsch "gehackt". Siehe Anhang ;-) Die 3,3V für die SD-Karte und den Pegelwandler sind per MOSFET geschaltet, diverse andere Kleinigkeiten wurden vorher schon korrigiert. Damit habe ich dann je 10 Tests pro Karte gemacht. Ich habe auch die Temperaturabhängigkeit der Antwortzeit getestet. Eine der schlechten Karten mit 710ms konnte man mit Eisspray auf ca. 670ms drücken und mit Warmluft (80°C) auf ca. 810ms erhöhen. Eine edle Karte von ATP stieg bei Kälte von 210ms auf 220ms, Wärme hatte keinen Einfluß. Hmmm.
Das ist die edle Karte von ATP, 4GB, Class 10, UHS-1 U1, SLC https://de.rs-online.com/web/p/products/1839390/ Das hier die von Intenso, 4GB, Class 10 https://www.intenso.de/produkte/speicherkarten/sd-karte-class-10
Falk B. schrieb: > Sooo, ich denke ich habe das Problem gefunden. Es ist die Antwortzeit > auf das Initialisierungskommando, wie schon vermutet. > > Beitrag "Re: Intitialisierung einer SD-Karte" > > In der Funktion > > DSTATUS mmc_disk_initialize (void); > > Antwortzeiten von 700-1110ms! Pro Karte schwankt diese aber nur wenig, > zwischen 0-60ms. Dagegen haben 5 gute Karten der gleichen Marke und > Baureihe 210-450ms. Ich vermute mal, daß im Linuxtreiber ein 500ms Es haengt empfindlich an dem internen Controller der SD-Card. Ich haette aber nicht gedacht, dass solche Streuung in einer Charge auftreten (vielleicht ist es nicht eine Charge, sondern vom Verkaeufer gemischt). Wenn Du so oder so schon Deinen Testaufbau hast: Abhaengigkeit der Init-Zeit von der Speicherkapazitaet der Karte. Denn Dein Linux-Board laeuft (nach Deiner Aussage) seit 10 Jahren. Und es waere sicherlich schon vor 10 Jahren aufgefallen wenn Du 50% Ausschuss bei den Karten haettest. Sind die Karten so schlecht geworden? Gruesse Th.
Thomas W. schrieb: > Es haengt empfindlich an dem internen Controller der SD-Card. Ich haette > aber nicht gedacht, dass solche Streuung in einer Charge auftreten > (vielleicht ist es nicht eine Charge, sondern vom Verkaeufer gemischt). Kann sein. > Wenn Du so oder so schon Deinen Testaufbau hast: Abhaengigkeit der > Init-Zeit von der Speicherkapazitaet der Karte. Ich hab keine anderen Karten. > Denn Dein Linux-Board laeuft (nach Deiner Aussage) seit 10 Jahren. Und > es waere sicherlich schon vor 10 Jahren aufgefallen wenn Du 50% > Ausschuss bei den Karten haettest. Da gab es jahrelang keine Probleme. Das ist erst in den letzten 1-2 Jahren aufgetreten. > Sind die Karten so schlecht geworden? Keine Ahnung.
Noch ein Testergebnis. Die 710ms Karte hatte nach der Wärmebehandlung 810ms Antwortzeit. Die ging aber nach der Abkühlung nicht mehr runter! Statt dessen STEIGT diese nach ca. 10 Power OFF/ON Zyklen um 10ms bis auf 1100ms und fällt dann wieder auf 590ms und das Spiel beginnt von vorn! Eine andere mit 1050ms macht das auch, allerdings mit deutlich weniger Änderung / Power-Zyklus, dort sind es nur ca. 10ms/100. Das geht auch bis knapp 1100ms und fällt dann auf 960ms zurück. Das klingt nach diversen Tricks mit dem Flash / Defect Management.
@Falk, Beschreibe mal eine SD-Karte mit schlechter Antwortzeit komplett mit nachfolgenden Kommando unter Linux badblocks -wsv /dev/device und teste danach nochmal die Antwortzeit der Initialisierung. Und Zeit für das Kommando mitbringen.
noreply@noreply.com schrieb: > @Falk, > > Beschreibe mal eine SD-Karte mit schlechter Antwortzeit komplett mit > nachfolgenden Kommando unter Linux > > badblocks -wsv /dev/device Würde ich gern tun, wenn ich denn ein Linuxsystem hätte. Auf der embedded Kiste ist nur ein Minimalsystem drauf. > und teste danach nochmal die Antwortzeit der Initialisierung. Und Zeit > für das Kommando mitbringen. Was soll das Kommando oben bewirken? Die Karten sind nagelneu und funktionieren auf einem System, das es nicht so furchbar eilig beim Initialisieren hat.
Falk B. schrieb: > Was soll das Kommando oben bewirken? Alle Blöcke einmal durchbeschreiben, damit die Karte bei der nächsten Initialisierung was zu tun hat. Dann nachschauen, was für einen Unsinn die Karte beim nächsten Start treibt. Aber scheinbar debuggst du ein Linuxsystem ausschließlich mit Windows, das macht das natürlich schwierig. Überhaupt liest sich der gesamte Thread entweder als "wir haben keine Ahnung und probieren einfach rum" oder die Teile, die eure Strategie intelligent aussehen lassen, fehlen. Mit einer SPI-Schnittstelle ein Timing-Problem im SD-Modus finden zu wollen ist jedenfalls sportlich. Ich bin jedenfalls erstaunt, dass du da überhaupt was sinnvolles rausgefunden hast. Gute Arbeit. Könnt ihr den Kernel für euer ARM9-System überhaupt noch selbst bauen? Weil wenn ihr schon vorher wusstet, dass euer Treiber in einen Timeout läuft, dann würde ich erstmal den Timeout erhöhen und gucken, was passiert.
:
Bearbeitet durch User
S. R. schrieb: > Aber scheinbar debuggst du ein Linuxsystem ausschließlich mit Windows, > das macht das natürlich schwierig. Ich teste die SD-Karte. > Überhaupt liest sich der gesamte > Thread entweder als "wir haben keine Ahnung und probieren einfach rum" Naja. Ich spiele mal wieder Feuerwehr. Ich bin weder der Linux-Fachmann geschweige denn Kernelexperte. > Mit einer SPI-Schnittstelle ein Timing-Problem im SD-Modus finden zu > wollen ist jedenfalls sportlich. Ich bin jedenfalls erstaunt, dass du da > überhaupt was sinnvolles rausgefunden hast. Gute Arbeit. Und etwas Glück. > Könnt ihr den Kernel für euer ARM9-System überhaupt noch selbst bauen? Im Moment nicht mehr, der Softwerker ist nicht mehr an Bord. Aber selbst wenn er es noch wäre, würde er mangels freier Kapazitäten das Problem auch nicht debuggen können, den Zustand hatten wir ja lange Zeit 8-0 > Weil wenn ihr schon vorher wusstet, dass euer Treiber in einen Timeout > läuft, Was heißt "vorher"? Nein. Das Ding lief jahrelang ohne Zicken, das Problem tauchte erst vor ca. 1-2 Jahren sporadisch, jetzt deutlich gehäuft auf! > dann würde ich erstmal den Timeout erhöhen und gucken, was > passiert. Sicher. Dazu braucht man aber jemanden, der einen Kernel bauen kann und Zeit hat. Haben wir nicht! Also der Workaround! Parallel wird versucht, externe Experten für den Patch zu finden.
Falk B. schrieb: > Naja. Ich spiele mal wieder Feuerwehr. > Ich bin weder der Linux-Fachmann geschweige denn Kernelexperte. Das wäre wichtig gewesen. :-) >> Könnt ihr den Kernel für euer ARM9-System überhaupt noch selbst bauen? > Im Moment nicht mehr, der Softwerker ist nicht mehr an Bord. Aber selbst > wenn er es noch wäre, würde er mangels freier Kapazitäten das Problem > auch nicht debuggen können, den Zustand hatten wir ja lange Zeit 8-0 Das macht es echt schwierig, eine Lösung für das Problem zu basteln. Mehr als "viel Glück" wünschen kann ich da nicht...
S. R. schrieb: > Falk B. schrieb: >> Was soll das Kommando oben bewirken? > > Alle Blöcke einmal durchbeschreiben, damit die Karte bei der nächsten > Initialisierung was zu tun hat. Dann nachschauen, was für einen Unsinn > die Karte beim nächsten Start treibt. Alles mal durchschreiben, damit der Controller auf der SD-Karte alle Blöcke mal sieht und Blöcke korrigieren kann. Nicht, daß der Controller bei der Initialisierung noch in eine Fehlerkorrektur reinläuft. Ist aber nur eine Vermutung und könnte ein Workaround sein. Wenn badblocks wirklich schlechte Blöcke erkennt, ist es einfacher, die Karte wegzuschmeissen. Treiberkorrektur ist natürlich besser. Aber die Softwerker sind alle verhungert, weil die Firmen dachten, die Community macht das schon. ;-)
Falk B. schrieb: >> badblocks -wsv /dev/device > > Würde ich gern tun, wenn ich denn ein Linuxsystem hätte. Auf der > embedded Kiste ist nur ein Minimalsystem drauf. Laptop mit zusätzlichen USB-Stick/USB-Festplatte/Partition und eine Installation machen. badblocks ist seit langer Zeit in den Distributionen enthalten.
vielleicht findet man den Timeoutwert auch mit dem Hexeditor und patched das einfach. Vertrauen in die Karte schafft das aber nicht gerade.
Falk B. schrieb: > Ich habe 5 > Karten von Intenso, welche im Zielsystem nicht erkannt werden. Die haben > Antwortzeiten von 700-1110ms! Wie die anderen Foristen schon schrieben: Man muß auch mal ein paar kg falsche Schrauben wegwerfen dürfen. Allerdings sollte Deine künftige SW diese müden SD-Typen gleich aussortiren. Es könnte nämlich auch sein, dass kaputte Sektoren ausgelagert werden (was Zeit braucht) und 3 Tage später der Rest kaputt ist. Dann sind diese kranken SDs beim Kunden und Du hast den großen Zonk.
Thomas O. schrieb: > vielleicht findet man den Timeoutwert auch mit dem Hexeditor und patched > das einfach. Dream on! Das ist kein C64!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.