summaryrefslogtreecommitdiff
path: root/flash-memory/mtd/handout_mtd_de.tex
diff options
context:
space:
mode:
Diffstat (limited to 'flash-memory/mtd/handout_mtd_de.tex')
-rw-r--r--flash-memory/mtd/handout_mtd_de.tex129
1 files changed, 124 insertions, 5 deletions
diff --git a/flash-memory/mtd/handout_mtd_de.tex b/flash-memory/mtd/handout_mtd_de.tex
index b6e7158..b11c3a5 100644
--- a/flash-memory/mtd/handout_mtd_de.tex
+++ b/flash-memory/mtd/handout_mtd_de.tex
@@ -6,14 +6,133 @@
\begin{document}
-\section*{Titel}
+\section*{Memory Technology Devices (MTD)}
-\subsection*{Abschnitt1}
+\section*{Was sind Memory Technology Devices?}
-Text
+Prinzipiell kann jedes Stück Speicher als MTD dargestellt werden,
+es gibt sogar Treiber, die einfach einen RAM-Bereich exportieren.
-\subsection*{Abschnitt2}
+Unter Linux versteht man aber unter MTD normalerweise Flash-Speicher
+in ihren unterschiedlichen Ausprägungen, beispielsweise NAND, NOR, DataFlash
+oder OneNAND. Dabei werden Flash-spezifische Eigenschaften berücksichtigt,
+wie zum Beispiel Hard- und Software-ECC oder die Tatsache, dass diese
+Chips nur Eraseblock-weise gelöscht werden können.
-Text
+Die Art, wie der Chip an den Prozessor angeschlossen ist, spielt dabei
+keine Rolle. Der Kernel unterstützt direkt am Bus angeschlossene
+NOR-Bausteine genauso wie NAND-Chips am NAND-Controller oder SPI-Flash-Chips,
+die mit einem SPI-Bus verbunden sind.
+
+\emph{Nicht} zu den MTD gehören USB-Sticks, SD-Karten oder ähnliche Geräte.
+Diese enthalten zwar auch NAND-Flash, dies wird aber bereits innerhalb
+des Geräts von einem eingebauten Controller verwaltet und erscheint für
+den Kernel als normales Block-Device (wie eine Festplatte). NAND-typische
+Eigenschaften wie die Größe eines Eraseblocks bleiben dem Kernel unbekannt.
+
+\section*{Das MTD-Subsystem im Kernel}
+
+Wie im Linux-Kernel üblich, werden die Treiber gleichartiger Geräte von
+einem eigenen Subsystem verwaltet. Diese Vorgehensweise ermöglicht eine
+einheitliche Schnittstelle dieser Geräte, ohne dass sich die einzelnen
+Treiber darum kümmern müssten. Ausserdem vereinfacht es die Entwicklung
+von Treibern, da ihre Struktur vorgegeben ist, und sie sich nicht mehr
+um immer wiederkehrenden generischen Code oder das Interface zum
+Userspace kümmern müssen.
+
+\subsection*{Was das MTD-Subsystem im Kernel macht...}
+
+Das MTD-Subsystem verwaltet zunächst die physikalische Struktur eines
+Chips, kennt also z.B. dessen Zusammensetzung aus einer gewissen Anzahl
+von Eraseblöcken bestimmter Größe, wobei jeder Eraseblock wiederum
+aus Pages bestimmter Größe bestehen kann (NAND).
+
+Jeder Chip kann wiederum in mehrere Partitionen aufgeteilt werden. Für
+jede Partition legt das MTD-Subsystem ein eigenes Device an, also
+bei drei Partitionen \cmd{/dev/mtd0}, \cmd{/dev/mtd1} und \cmd{/dev/mtd2}.
+Für den Anwender ergibt sich hier bereits die erste Abstrahierung, da er
+nicht mehr wissen muss, ob hinter diesen Devices NAND oder NOR steckt,
+oder ob es sich um einen oder mehrere Chips handelt.
+
+Anhand dieser Device-Dateien kann jetzt auf die einzelnen Partitionen
+zugegriffen werden. Dabei können Datenblöcke gelesen und geschrieben
+werden, ausserdem können Eraseblöcke gelöscht werden.
+
+\subsection*{...und was das MTD-Subsystem \emph{nicht} macht...}
+
+Das MTD-Subsystem wurde bewusst als sehr dünner Abstraktions-Layer
+angelegt. Es geht lediglich um die einheitliche Schnittstelle und
+den einfachen Zugriff auf den Flash-Speicher. Aufwendigere Techniken
+werden je nach Anwendung von anderen Teilen des Kernels erledigt.
+
+So verfügt ein mtd-Device weder über ein Dateisystem noch über
+Wear-Leveling. Bad Blocks werden zwar unterschieden, der Anwender wird
+aber nicht daran gehindert, dennoch in diese zu schreiben.
+
+Ausser der NAND-eigenen ECC-Fehlerkorrektur gibt es keine weiteren
+Schutzmechanismen, falls beim Schreiben der Strom ausfällt, gehen
+Daten verloren.
+
+\subsection*{Erweiterungen}
+
+Aus historischen Gründen verfügt der Kernel noch über den \cmd{mtdblock}-
+Treiber. Dieser emuliert für ein mtd-Device \cmd{/dev/mtd0} ein
+zugehöriges Block-Device \cmd{/dev/mtdblock0}. Da es sich dabei um ein
+normales Blockdevice handelt, können auch normale Dateisysteme wie
+ext2 oder FAT aufgebracht werden. Ausserdem kümmert sich \cmd{mtdblock}
+beim Schreiben um das Löschen der entsprechenden Eraseblocks.
+
+Da \cmd{mtdblock} aber weder Wear-Leveling noch Schutzmassnahmen einführt,
+und ausserdem vor allem durch schlechte Performance auffällt, kann von
+seinem Einsatz nur abgeraten werden.
+
+Ähnliches gilt für die ebenfalls vorhandenen Flash-Translation-Layer (FTL).
+Obwohl diese teilweise bessere Features mitbringen, gelten sie mangels
+Interesse als veraltet und schlecht gewartet.
+
+Durch die Einführung von UBI und ubifs sind derartige MTD-Erweiterungen
+für die meisten Anwendungen schlicht überflüssig geworden.
+
+\section*{MTD-Tools}
+
+Um auf mtd-Devices zugreifen zu können, haben die MTD-Entwickler eine Reihe
+von Tools entwickelt, die von den meisten Distributionen als Paket bereit
+gestellt werden. Unter Debian installiert man die Tools beispielsweise mit
+
+\begin{lstlisting}
+aptitude install mtd-utils
+\end{lstlisting}
+
+Hier eine Übersicht über die wichtigsten Befehle:
+
+Löschen einer Partition:
+\begin{lstlisting}
+flash_eraseall /dev/mtd0
+\end{lstlisting}
+
+Löschen einer Partition, gleichzeitig jffs2-Dateisystem aufbringen:
+\begin{lstlisting}
+flash_eraseall -j /dev/mtd0
+\end{lstlisting}
+
+Ein Image in eine Partition schreiben:
+\begin{lstlisting}
+nandwrite -p /dev/mtd0 myimage.bin
+\end{lstlisting}
+\emph{Beachte:} \cmd{nandwrite} ist das einzige Tool, mit dem man unter
+Beachtung von Bad Blocks direkt in ein mtd-Device schreiben kann! Wenn man mit
+konventionellen Tools wie \cmd{dd} in ein mtd-Device schreibt, so werden
+auch Bad Blocks beschrieben, ohne dass dies zu einem Fehler führen würde!
+
+Daten aus einer Partition lesen:
+\begin{lstlisting}
+nanddump -s 0x10000 -l 0x2000 -p -f data.txt /dev/mtd0
+\end{lstlisting}
+Dieser Befehl liest Daten aus \cmd{/dev/mtd0}, und zwar 0x2000 Bytes ab
+Startadresse 0x10000. Die Daten werden als lesbarer Hexdump (-p) in der
+Datei \cmd{data.txt} gespeichert.
+
+\emph{Hinweis:} Alle diese Tools kennen die Option \cmd{--help}, die alle
+verfügbaren Optionen auflistet und kurz erläutert.
\end{document}