Die meisten SOM sind mit Flash-Speichern in NAND-Technologie bestückt. Bekanntlich ist es problematisch den Programmcode im NAND-Flash zu speichern um ihn dann in der Bootphase ins RAM zu kopieren. Bitkipper müssen durch aufwendige Verfahren (ECC) rausgerechnet werden. Ist meine Einschätzung richtig, dass das nur in Verbindung mit einem Betriebssystem (Windows CE, Embedded Linux, Android etc.) möglich und sinnvoll ist, wenn man nicht aus der Fehlerkorrektur ein eigenes Projekt machen möchte? Oder unterstützt z.B. die at91lib die Fehlerkorrektur eines NAND-Flashs?
Der Som (kirgisisch/russisch Сом) ist die Währung Kirgisistans. Wir benutzen MCs (8051, AVR, ARM7) mit internem Flash. Bisher ist noch nie ein Bitkipper untergekommen. Unzuverlässige Speicher würde ich nie kaufen.
Ich dachte auch der ganze Wald-und-Wiesen-Flash wäre NAND-Flash. Kann es sein dass dann gerade dieser so unzuverlässig ist?
SOM ... System-on-Module, sollte den Insidern ein Begriff sein :-). Bei der Speicherauswahl bin ich also an das gebunden, was die Modulhersteller draufnageln. Ja, die ganzen Wald-und-Wiesen-Flashes sind NAND, klein, schnell, billisch. Das heißt aber noch lange nicht, dass sie deshalb besonders zuverlässig sind. Das Gegenteil ist der Fall. Software kostet nichts und so ist es durchaus sinnvoll mit Softwareaufwand Unzulänglichkeiten der Hardware aufzufangen.
16 Bit Prüfsummen hatte schon Intel im Jahre 1978. Damit kann man schnell und zuverlässig Bitkipper erkennen. ECC ist ein anderer Schuh. Den kann man beliebig komplex machen. Aber mit 12 Bytes Korrektur per 512 Bytes Nutzdaten wurden schon die ersten Festplatten abgesichert, ohne dass der 2MHz Z80 ins Stolpern kam. Aber sieh dir mal die Datenblätter der billigen Flash Bausteine an. Die sind deutlich besser als du glaubst. Die werden Millionenfach verbaut (ohne spezielle Korrektur), ohne dass die Welt untergeht.
Ich denke mal, die Flash in den 64GB Sticks werden explizit im Datenblatt drin stehen haben, daß sie nur mit speziellen ECC-Controllern zu verwenden sind. Die normalen Flash im MB-Bereich sind was völlig anderes, die müssen zuverlässig sein.
Georg G. schrieb: > 16 Bit Prüfsummen hatte schon Intel im Jahre 1978. Damit kann man > schnell und zuverlässig Bitkipper erkennen. > ECC ist ein anderer Schuh. Den kann man beliebig komplex machen. Aber > mit 12 Bytes Korrektur per 512 Bytes Nutzdaten wurden schon die ersten > Festplatten abgesichert, ohne dass der 2MHz Z80 ins Stolpern kam. > Aber sieh dir mal die Datenblätter der billigen Flash Bausteine an. Die > sind deutlich besser als du glaubst. Die werden Millionenfach verbaut > (ohne spezielle Korrektur), ohne dass die Welt untergeht. NOR-Flash ja (d.h. die meisten internen Flash-Speicher, SPI-Flash-Bauteile, etc.). Bei NAND hängt es stark von der Strukturgröße und der Bauart SLC vs. MLC ab, ohne Fehler-Korrektur, Bad-Block-Erkennung (die Hersteller garantieren nur eine bestimmte Anzahl fehlerfreier Blöcke bei Auslieferung) und gelegentlichem neuschreiben etc. geht es bei keinem NAND... http://download.micron.com/pdf/technotes/nand/tn2917.pdf
Da steht, die read-cycle-time wäre ein Kriterium für die Zuverlässigkeit von NAND-Speicher! Habe ich Tomaten auf den Augen und bin total hinterm Mond??
NAND Flashes brauchen ECC Punkt. Am Anfang eines NAND Flashes ist zwar ein Bereich vom Hersteller als gültig garantiert, aber auch nur wenn mit ECC gelesen wird. Allerdings sind NAND Flashes ohnehin Blockdevices, d.h. einfach an Addressdaten/bus anschliessen und den Resetvektor darauf zeigen zu lassen geht ohnehin nicht. (Mit NOR Flashes geht das, die sind aber ohne ECC verwendbar). Um vom NAND booten zu können braucht es einen Bootlooader im ROM. Sie auch hier: http://www.micron.com/~/media/Documents/Products/Software%20Article/SWNL_implementing_ecc.pdf Was manche Prozessorhersteller in den letzten Jahren kalt erwischt hat, ist dass aktuelle SLC Nandflashes mindestens eine 4 Bit Korrektur pro 512 Bytes brauchen (bei MLC war das schon immer der Fall). Vorher kam man mit einem einem einfachen Hammingcode für bit ECC aus. Im TI Forum gibt es auch jede Menge Discussion zu dem Thema. z.b. http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/62495/230165.aspx#230165
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.