diff options
Diffstat (limited to 'flash-memory')
| -rw-r--r-- | flash-memory/mtd/handout_mtd_de.tex | 80 | ||||
| -rw-r--r-- | flash-memory/ubi/handout_ubi_de.tex | 96 |
2 files changed, 88 insertions, 88 deletions
diff --git a/flash-memory/mtd/handout_mtd_de.tex b/flash-memory/mtd/handout_mtd_de.tex index 15c642f..2a304e1 100644 --- a/flash-memory/mtd/handout_mtd_de.tex +++ b/flash-memory/mtd/handout_mtd_de.tex @@ -4,92 +4,92 @@ \subsubsection{Was sind Memory Technology Devices?} -Prinzipiell kann jedes Stück Speicher als MTD dargestellt werden, +Prinzipiell kann jedes St\"uck Speicher als MTD dargestellt werden, es gibt sogar Treiber, die einfach einen RAM-Bereich exportieren. 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, +in ihren unterschiedlichen Auspr\"agungen, beispielsweise NAND, NOR, DataFlash +oder OneNAND. Dabei werden Flash-spezifische Eigenschaften ber\"ucksichtigt, wie zum Beispiel Hard- und Software-ECC oder die Tatsache, dass diese -Chips nur Eraseblock-weise gelöscht werden können. +Chips nur Eraseblock-weise gel\"oscht werden k\"onnen. Die Art, wie der Chip an den Prozessor angeschlossen ist, spielt dabei -keine Rolle. Der Kernel unterstützt direkt am Bus angeschlossene +keine Rolle. Der Kernel unterst\"utzt 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. +\emph{Nicht} zu den MTD geh\"oren USB-Sticks, SD-Karten oder \"ahnliche Ger\"ate. Diese enthalten zwar auch NAND-Flash, dies wird aber bereits innerhalb -des Geräts von einem eingebauten Controller verwaltet und erscheint für +des Ger\"ats von einem eingebauten Controller verwaltet und erscheint f\"ur den Kernel als normales Block-Device (wie eine Festplatte). NAND-typische -Eigenschaften wie die Größe eines Eraseblocks bleiben dem Kernel unbekannt. +Eigenschaften wie die Gr\"o\ss e eines Eraseblocks bleiben dem Kernel unbekannt. \subsubsection{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 +Wie im Linux-Kernel \"ublich, werden die Treiber gleichartiger Ger\"ate von +einem eigenen Subsystem verwaltet. Diese Vorgehensweise erm\"oglicht eine +einheitliche Schnittstelle dieser Ger\"ate, ohne dass sich die einzelnen +Treiber darum k\"ummern m\"ussten. 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. +Userspace k\"ummern m\"ussen. \paragraph{Was das MTD-Subsystem im Kernel macht...} -Das MTD-Subsystem verwaltet zunächst die physikalische Struktur eines +Das MTD-Subsystem verwaltet zun\"achst 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). +von Erasebl\"ocken bestimmter Gr\"o\ss e, wobei jeder Eraseblock wiederum +aus Pages bestimmter Gr\"o\ss e bestehen kann (NAND). -Jeder Chip kann wiederum in mehrere Partitionen aufgeteilt werden. Für +Jeder Chip kann wiederum in mehrere Partitionen aufgeteilt werden. F\"ur 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 +F\"ur 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. +zugegriffen werden. Dabei k\"onnen Datenbl\"ocke gelesen und geschrieben +werden, ausserdem k\"onnen Erasebl\"ocke gel\"oscht werden. \paragraph{...und was das MTD-Subsystem \emph{nicht} macht...} -Das MTD-Subsystem wurde bewusst als sehr dünner Abstraktions-Layer +Das MTD-Subsystem wurde bewusst als sehr d\"unner 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 +So verf\"ugt ein mtd-Device weder \"uber ein Dateisystem noch \"uber 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 +Schutzmechanismen, falls beim Schreiben der Strom ausf\"allt, gehen Daten verloren. \paragraph{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. +Aus historischen Gr\"unden verf\"ugt der Kernel noch \"uber den \cmd{mtdblock}- +Treiber. Dieser emuliert f\"ur ein mtd-Device \cmd{/dev/mtd0} ein +zugeh\"origes Block-Device \cmd{/dev/mtdblock0}. Da es sich dabei um ein +normales Blockdevice handelt, k\"onnen auch normale Dateisysteme wie +ext2 oder FAT aufgebracht werden. Ausserdem k\"ummert sich \cmd{mtdblock} +beim Schreiben um das L\"oschen 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 +Da \cmd{mtdblock} aber weder Wear-Leveling noch Schutzmassnahmen einf\"uhrt, +und ausserdem vor allem durch schlechte Performance auff\"allt, kann von seinem Einsatz nur abgeraten werden. -Ähnliches gilt für die ebenfalls vorhandenen Flash-Translation-Layer (FTL). +\"Ahnliches gilt f\"ur 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. +Durch die Einf\"uhrung von UBI und ubifs sind derartige MTD-Erweiterungen +f\"ur die meisten Anwendungen schlicht \"uberfl\"ussig geworden. \subsubsection{MTD-Tools} -Um auf mtd-Devices zugreifen zu können, haben die MTD-Entwickler eine Reihe +Um auf mtd-Devices zugreifen zu k\"onnen, 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 @@ -97,14 +97,14 @@ gestellt werden. Unter Debian installiert man die Tools beispielsweise mit aptitude install mtd-utils \end{lstlisting} -Hier eine Übersicht über die wichtigsten Befehle: +Hier eine \"Ubersicht \"uber die wichtigsten Befehle: -Löschen einer Partition: +L\"oschen einer Partition: \begin{lstlisting} flash_eraseall /dev/mtd0 \end{lstlisting} -Löschen einer Partition, gleichzeitig jffs2-Dateisystem aufbringen: +L\"oschen einer Partition, gleichzeitig jffs2-Dateisystem aufbringen: \begin{lstlisting} flash_eraseall -j /dev/mtd0 \end{lstlisting} @@ -116,7 +116,7 @@ nandwrite -p /dev/mtd0 myimage.bin \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! +auch Bad Blocks beschrieben, ohne dass dies zu einem Fehler f\"uhren w\"urde! Daten aus einer Partition lesen: \begin{lstlisting} @@ -127,6 +127,6 @@ 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. +verf\"ugbaren Optionen auflistet und kurz erl\"autert. \input{tailhandout} diff --git a/flash-memory/ubi/handout_ubi_de.tex b/flash-memory/ubi/handout_ubi_de.tex index e8402aa..a673a43 100644 --- a/flash-memory/ubi/handout_ubi_de.tex +++ b/flash-memory/ubi/handout_ubi_de.tex @@ -4,45 +4,45 @@ \subsubsection{Was ist UBI?} -UBI kann am ehesten als Logical Volume Manager (LVM) für mtd-Devices -bezeichnet werden. Beim Start scant UBI das mtd-Device und baut eine -Liste der vorhandenen Eraseblöcke auf. Dabei werden auch Bad Blocks +UBI kann am ehesten als Logical Volume Manager (LVM) f\"ur mtd-Devices +bezeichnet werden. Beim Start scanned UBI das mtd-Device und baut eine +Liste der vorhandenen Erasebl\"ocke auf. Dabei werden auch Bad Blocks richtig behandelt, da das MTD-Subsystem, auf dem UBI aufsetzt, diese bereits erkennt. -Dieser Gesamtvorrat an physikalischen Eraseblöcken wird jetzt im -nächsten Schritt an sogenannte UBI-Volumes verteilt. +Dieser Gesamtvorrat an physikalischen Erasebl\"ocken wird jetzt im +n\"achsten Schritt an sogenannte UBI-Volumes verteilt. \subsubsection{UBI-Volumes} UBI-Volumes entsprechen etwa den Partitionen anderer Systeme. Der von -einem mtd-Device bereitgestellte Speicher wird also in mehrere unabhängige +einem mtd-Device bereitgestellte Speicher wird also in mehrere unabh\"angige Einheiten aufgeteilt. Im Vergleich zu den Partitionen, die das MTD-Subsystem auf einem Flash anlegen kann, sind UBI-Volumes aber erheblich -leistungsfähiger und flexibler. Aus diesem Grund empfiehlt es sich, so -wenig wie möglich mtd-Partitionen anzulegen, und UBI eine möglichst große -Partition zur Verwaltung zu übergeben. +leistungsf\"ahiger und flexibler. Aus diesem Grund empfiehlt es sich, so +wenig wie m\"oglich mtd-Partitionen anzulegen, und UBI eine m\"oglichst gro\ss e +Partition zur Verwaltung zu \"ubergeben. MTD-Partitionen haben eine strikt festgelegte Zuordnung von physikalischen -Eraseblöcken zu Partitionen. UBI kann dagegen Eraseblöcke bei Bedarf +Erasebl\"ocken zu Partitionen. UBI kann dagegen Erasebl\"ocke bei Bedarf beliebig zwischen den Volumes umverteilen. Dies geschieht beispielsweise -beim Wear-Leveling, das UBI ebenfalls durchführt. Ebenso können defekte -Eraseblöcke durch andere Blöcke ersetzt werden. +beim Wear-Leveling, das UBI ebenfalls durchf\"uhrt. Ebenso k\"onnen defekte +Erasebl\"ocke durch andere Bl\"ocke ersetzt werden. Durch den von UBI verwendeten Algorithmus ist es selbst beim Neuanlegen -eines Volumes kaum vorhersagbar, welche physikalischen Eraseblöcke es auf -dem Flash belegt. Während eine MTD-Partition immer in denselben -aufeinanderfolgenden Blöcken liegt, ändert sich die Zuordnung von -physikalischen Eraseblöcken des Flash zu logischen Eraseblöcken des +eines Volumes kaum vorhersagbar, welche physikalischen Erasebl\"ocke auf +dem Flash es belegt. W\"ahrend eine MTD-Partition immer in denselben +aufeinanderfolgenden Bl\"ocken liegt, \"andert sich die Zuordnung von +physikalischen Erasebl\"ocken des Flash zu logischen Erasebl\"ocken des Volumes im laufenden Betrieb dynamisch. Ein UBI-Volume mit drei -Eraseblöcken kann also durchaus die physikalischen Blöcke 814, 27 und 1013 belegen. +Erasebl\"ocken kann also durchaus die Bl\"ocke 814, 27 und 1013 belegen. Aus diesem Ansatz ergibt sich auch der Name \emph{Unsorted Block Images}. \emph{Hinweis:} Auf klassischen Festplatten wird ein solches Verhalten -als \emph{Fragmentierung} bezeichnet und ist dort unerwünscht, da eine +als \emph{Fragmentierung} bezeichnet und ist dort unerw\"unscht, da eine mechanische Platte signifikante Seek-Zeiten aufweist. Man versucht dort, -Daten möglichst in aufeinander folgenden Blöcken zu speichern, um zu +Daten m\"oglichst in aufeinander folgenden Bl\"ocken zu speichern, um zu verhindern, dass der mechanische Schreib-/Lesekopf von einem Ende der Platte zum anderen bewegt werden muss. Auf Flash-Speichern gibt es keine Seek-Zeiten, was UBI hier zugunsten eines auf Flash optimierten Designs @@ -50,38 +50,38 @@ ausnutzt. \paragraph{Statische Volumes} -Statische Volumes sind für Anwendungen gedacht, die kein Dateisystem -benötigen. Ein praktisches Beispiel ist ein kleines Volume, das lediglich einen -Kernel enthält, der vom Bootloader geladen und gestartet wird. Mit einem +Statische Volumes sind f\"ur Anwendungen gedacht, die kein Dateisystem +ben\"otigen. Ein praktisches Beispiel ist ein kleines Volume, das lediglich einen +Kernel enth\"alt, der vom Bootloader geladen und gestartet wird. Mit einem statischen Volume muss der Bootloader keinerlei Dateisystem implementieren. Er muss lediglich aus den UBI-Headern herausfinden, welche physikalischen -Eraseblöcke zu dem statischen Volume gehören. Ausserdem erfährt er von UBI, -wie viele Bytes tatsächlich durch Daten belegt sind. Er lädt diese Daten, +Erasebl\"ocke zu dem statischen Volume geh\"oren. Ausserdem erf\"ahrt er von UBI, +wie viele Bytes tats\"achlich durch Daten belegt sind. Er l\"adt diese Daten, im Beispiel einen Kernel, ins RAM und springt sie an. Dies ist mit relativ -wenig Code (einige kB) möglich. +wenig Code (einige kB) m\"oglich. Statische Volumes enthalten also immer nur einen einzigen Datenblock, der in einem Vorgang geschrieben werden muss. \paragraph{Dynamische Volumes} -Dynamische Volumes sind dafür gedacht, ein Dateisystem zu enthalten. -Man verwendet sie also beispielsweise für ein Root-Filesystem oder für -Volumes, die Nutzerdaten enthalten. +Dynamische Volumes sind daf\"ur gedacht, ein Dateisystem zu enthalten. +Man verwendet sie also beispielsweise f\"ur ein Root-Filesystem oder f\"ur +Volumes, die Nutzerdaten enthalten. Dynamische Volumes verwendet man am Besten mit dem Dateisystem ubifs. \paragraph{UBIGLUEBI} -UBIGLUEBI ist ein Aufsatz auf UBI, der für jedes Volume wieder ein -mtd-Device bereitstellt. Dies klingt zunächst überraschend, da UBI ja schon -auf einem mtd-Device aufsetzt. Der Hintergrund ist, dass ältere -Flash-Dateisysteme wie jffs2 ein mtd-Device benötigen. Um deren Einsatz -zu ermöglichen, wurde dieser Zusatz geschaffen. +UBIGLUEBI ist ein Aufsatz auf UBI, der f\"ur jedes Volume wieder ein +mtd-Device bereitstellt. Dies klingt zun\"achst \"uberraschend, da UBI ja schon +auf einem mtd-Device aufsetzt. Der Hintergrund ist, dass \"altere +Flash-Dateisysteme wie jffs2 ein mtd-Device ben\"otigen. Um deren Einsatz +zu erm\"oglichen, wurde dieser Zusatz geschaffen. Heute gibt es ubifs, das direkt auf UBI aufsetzt und folglich kein -mtd-Device benötigt. Da ubifs ohnehin in allen Bereichen deutliche Vorteile -gegenüber jffs2 hat, wird UBIGLUEBI in der Regel nicht mehr benötigt. +mtd-Device ben\"otigt. Da ubifs ohnehin in allen Bereichen deutliche Vorteile +gegen\"uber jffs2 hat, wird UBIGLUEBI in der Regel nicht mehr ben\"otigt. \includegraphics[width=8cm]{images/ubi-big-picture.png} @@ -145,7 +145,7 @@ aptitude install mtd-utils Hier die wichtigsten UBI-Aktionen in Kurzform: -Die Kontrolle über ein mtd-Device an UBI übertragen: +Die Kontrolle \"uber ein mtd-Device an UBI \"ubertragen: \begin{lstlisting} ubiattach /dev/ubi_ctrl -m 2 \end{lstlisting} @@ -155,8 +155,8 @@ Ein Volume anlegen: \begin{lstlisting} ubimkvol /dev/ubi0 -s 3MiB -t static -N kernel -n 1 \end{lstlisting} -Hier wird ein 3MiB großes statisches Volume mit dem Namen \cmd{kernel} -angelegt. Das Volume erhält die Nummer 1. +Hier wird ein 3MiB gro\ss es statisches Volume mit dem Namen \cmd{kernel} +angelegt. Das Volume erh\"alt die Nummer 1. Daten in ein statisches Volume schreiben: \begin{lstlisting} @@ -165,21 +165,21 @@ ubiupdatevol /dev/ubi0_1 zImage Die Daten aus der Datei \cmd{zImage} werden in das statische Volume mit der Nummer 1 geschrieben. -Natürlich lassen sich komplette Volumes auch wieder entfernen: +Nat\"urlich lassen sich komplette Volumes auch wieder entfernen: \begin{lstlisting} ubirmvol/dev/ubi0 -n 1 \end{lstlisting} Das Volume mit der Nummer 1 wird entfernt. Der mit Abstand aufwendigste Befehl ist \cmd{ubinize}. Damit lassen sich -vollständige UBI-Images für ein mtd-Device anfertigen. Diese können -anschließend mit \cmd{nandwrite} in das mtd-Device geschrieben werden. -Alternativ kann das Image natürlich auch mit einem geeigneten JTAGer -in das Flash übertragen werden. Da \cmd{ubinize} sehr vielseitig ist und -relativ viele Flash- und Layout-Parameter berücksichtigt werden müssen, +vollst\"andige UBI-Images f\"ur ein mtd-Device anfertigen. Diese k\"onnen +anschlie\ss end mit \cmd{nandwrite} in das mtd-Device geschrieben werden. +Alternativ kann das Image nat\"urlich auch mit einem geeigneten JTAGer +in das Flash \"ubertragen werden. Da \cmd{ubinize} sehr vielseitig ist und +relativ viele Flash- und Layout-Parameter ber\"ucksichtigt werden m\"ussen, kann hier nur ein einfaches Beispiel gegeben werden. -Zunächst ist eine Konfigurationsdatei erforderlich, in der die einzelnen +Zun\"achst ist eine Konfigurationsdatei erforderlich, in der die einzelnen Volumes sowie die in ihnen unterzubringenden Images beschrieben werden. Diese Datei folgt in ihrer Syntax dem bekannten INI-Format. Ein Volume wird beispielsweise so angegeben: @@ -202,11 +202,11 @@ einem Befehl erzeugen, der etwa so aussieht: \begin{lstlisting} ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi-cfg.ini \end{lstlisting} -Im Beispiel wird eine Eraseblock-Größe von 128k angegeben, ausserdem eine -Pagegröße von 2048 Bytes sowie eine Subpage-Größe von 512 Bytes. Das +Im Beispiel wird eine Eraseblock-Gr\"o\ss e von 128k angegeben, ausserdem eine +Pagegr\"o\ss e von 2048 Bytes sowie eine Subpage-Gr\"o\ss e von 512 Bytes. Das fertige Image landet in der Datei \cmd{ubi.img}. -Weitere Informationen sind unter folgender URL erhältlich: +Weitere Informationen sind unter folgender URL erh\"altlich: \begin{lstlisting} http://www.linux-mtd.infradead.org/doc/general.html |