summaryrefslogtreecommitdiff
path: root/flash-memory/mtd
diff options
context:
space:
mode:
authorHans J. Koch <hjk@linutronix.de>2010-06-25 15:21:14 +0200
committerHans J. Koch <hjk@linutronix.de>2010-06-25 15:21:14 +0200
commitb63b2df4a687bf3b15cd59871135027a2654c848 (patch)
treec221b2e09b03d3b750f24f1050659fac845023c6 /flash-memory/mtd
parentecd735479cab27c836c53ad752eae9dddcd64e34 (diff)
Created handout paper for MTD
German handout paper covering the MTD topic. Initial version. Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Diffstat (limited to 'flash-memory/mtd')
-rw-r--r--flash-memory/mtd/handout_mtd_de.tex129
-rw-r--r--flash-memory/mtd/pres_mtd_de.tex30
2 files changed, 149 insertions, 10 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}
diff --git a/flash-memory/mtd/pres_mtd_de.tex b/flash-memory/mtd/pres_mtd_de.tex
index d530b94..217689a 100644
--- a/flash-memory/mtd/pres_mtd_de.tex
+++ b/flash-memory/mtd/pres_mtd_de.tex
@@ -6,7 +6,7 @@
\usepackage{graphicx}
\usepackage{lxextras}
-\title{Block \lq Was ist Linux?\rq}
+\title{Block \lq Memory Technology Devices (MTD) unter Linux\rq}
\institute{Linutronix GmbH}
\begin{document}
@@ -15,10 +15,30 @@
% ----- Slide ------------------
\begin{frame}
-\begin{figure}[h]
-\centering
-\includegraphics[width=8cm]{images/myimage.jpg}
-\end{figure}
+\frametitle{Memory Technology Devices}
+\begin{itemize}
+\item NAND
+\pause
+\item NOR
+\pause
+\item Schnittstellen: Parallel, SPI...
+\end{itemize}
+
+\end{frame}
+
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{MTD subsystem im Kernel}
+\begin{itemize}
+\item Einheitliche Schnittstelle zum Userspace
+\pause
+\item Partitionierung
+\pause
+\item Vermeidung von Code-Duplizierung in den Treibern
+\pause
+\item Vereinheitlichung der Treiber
+\end{itemize}
+
\end{frame}