tom/kernel_dell_tom
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

UPD MTD support, completed

Browse Source
This commit is contained in:
Thomas Kuschel
2024-02-09 02:01:44 +01:00
parent f0959f3d8f
commit 3368d0c50d
2 changed files with 216 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

214
documentation/linux_configuration_15_device_drivers.tex
View File

@@ -1495,6 +1495,220 @@ Die Unterstützung ist sehr experimentell und bietet keinen Zugriff auf Schreibo
\paragraph{OneNAND Device Support ---}$~$\\
CONFIG\_MTD\_ONENAND [=n] \textbf{[~]}\\*
Dies ermöglicht die Unterstützung des Zugriffs auf alle Arten von OneNAND"=Flash"=Geräten.
\paragraph{Raw/Parallel NAND Device Support \texorpdfstring{$\rightarrow$}{->}}$~$\\
CONFIG\_MTD\_RAW\_NAND [=m] \textbf{[M]}\\*
Dies ermöglicht die Unterstützung des Zugriffs auf alle Arten von rohen/parallelen NAND"=Flash"=Geräten.
Für weitere Informationen siehe \url{http://www.linux-mtd.infradead.org/doc/nand.html}.
\subparagraph{*** Raw/parallel NAND flash controllers ***}$~$\\
\textit{(Rohe/parallele NAND"=Flash"=Kontroller)}
\subparagraph{Denali NAND controller on Intel Moorestown}$~$\\
CONFIG\_MTD\_NAND\_DENALI\_PCI [=n] \textbf{[~]}\\*
Aktivieren Sie den Treiber für NAND"=Flash auf Intel Moorestown, unter Verwendung des
Denali NAND"=Controller"=Kerns.
\subparagraph{OLPC CAF \boldmath${\sim}$I NAND controller}$~$\\
CONFIG\_MTD\_NAND\_CAFE [=n] \textbf{[~]}\\*
Verwenden Sie NAND-Flash, das mit dem CAF $\sim$I-Chip verbunden ist, der für den OLPC"=Laptop entwickelt wurde.
\subparagraph{Macronix raw NAND controller}$~$\\
CONFIG\_MTD\_NAND\_MXIC [=n] \textbf{[~]}\\*
Damit wird der Macronix Raw-NAND"=Controller"=Treiber ausgewählt.
\subparagraph{GPIO assisted NAND controller}$~$\\
CONFIG\_MTD\_NAND\_GPIO [=n] \textbf{[~]}\\*
Dies ermöglicht einen NAND"=Flash"=Treiber, bei dem Steuersignale mit GPIO"=Pins verbunden
sind und Befehle und Daten über eine Memory"=Mapped"=Schnittstelle übertragen werden.
\subparagraph{Generic NAND controller}$~$\\
CONFIG\_MTD\_NAND\_PLATFORM [=n] \textbf{[~]}\\*
Dies implementiert einen generischen NAND"=Treiber für On-SOC"=Plattformgeräte. Sie müssen
plattformspezifische Funktionen über platform\_data bereitstellen.
\subparagraph{Support for Arasan NAND flash controller}$~$\\
CONFIG\_MTD\_NAND\_ARASAN [=n] \textbf{[~]}\\*
Aktiviert den Treiber für den Arasan NAND"=Flash"=Controller auf Zynq Ultrascale+ MPSoC.
\subparagraph{*** Misc ***}$~$\\
\textit{(Sonstiges)}
\subparagraph{Support for NAND Flash Simulator}$~$\\
CONFIG\_MTD\_NAND\_NANDSIM [=m] \textbf{[M]}\\*
Der Simulator kann verschiedene NAND"=Flash"=Chips für die MTD"=Nand"=Schicht simulieren.
\subparagraph{Ricoh xD card reader}$~$\\
CONFIG\_MTD\_NAND\_RICOH [=n] \textbf{[~]}\\*
Unterstützung für den xD"=Kartenleser Ricoh R5C852 aktivieren.
Sie müssen auch entweder die \glqq NAND SSFDC (SmartMedia) Nur"=Lese"=Übersetzungsschicht\grqq{}
oder die neue experimentelle, schreibbare \glqq SmartMedia/xD new translation layer\grqq{} aktivieren.
\subparagraph{DiskOnChip 2000, Millennium and Millennium Plus (NAND reimplementation)}$~$\\
CONFIG\_MTD\_NAND\_DISKONCHIP [=n] \textbf{[~]}\\*
Dies ist eine Neuimplementierung von M-Systems DiskOnChip 2000, Millennium und Millennium Plus
als Standard"=NAND"=Gerätetreiber, im Gegensatz zu den früheren eigenständigen MTD"=Gerätetreibern.
Dies sollte unter anderem den korrekten JFFS2"=Betrieb auf diesen Geräten ermöglichen.
\paragraph{SPI NAND device Support ---}$~$\\
CONFIG\_MTD\_SPI\_NAND [=n] \textbf{[~]}\\*
Dies ist der Grundrahmen für die SPI-NAND-Gerätetreiber.
\paragraph{ECC engine support \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{(ECC-Motorunterstützung)}
\subparagraph{Software Hamming ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_HAMMING [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung der Software"=Hamming"=Fehlerkorrektur. Diese Korrektur
kann bis zu 1~Bitfehler pro Chunk korrigieren und bis zu 2~Bitfehler erkennen.
Während sie bei alten Bauteilen weit verbreitet war, erfordern neuere NAND"=Chips in der
Regel eine stärkere Korrektur und in diesem Fall wird BCH oder RS bevorzugt.
\subsubparagraph{NAND ECC Smart Media byte order}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_HAMMING\_SMC [=y] \textbf{[Y]}\\*
Software-ECC gemäß der Smart"=Media"=Spezifikation. Bei der ursprünglichen
Linux"=Implementierung waren Byte 0 und 1 vertauscht.
\subparagraph{Software BCH ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_SW\_BCH [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung der Software"=BCH"=Fehlerkorrektur. Binäre BCH"=Codes
sind leistungs"-fähiger und rechenintensiver als traditionelle Hamming"=ECC"=Codes.
Sie werden bei NAND"=Geräten verwendet, die mehr als 1~Bit Fehlerkorrektur benötigen.
\subparagraph{Macronix external hardware ECC engine}$~$\\
CONFIG\_MTD\_NAND\_ECC\_MXIC [=y] \textbf{[Y]}\\*
Dies ermöglicht die Unterstützung für die Hardware"=ECC"=Engine von Macronix.
\subsubsection{LPDDR \& LPDDR2 PCM memory drivers \texorpdfstring{$\rightarrow$}{->}}
\textit{(LPDDR \& LPDDR2 PCM-Speichertreiber)}
\paragraph{Support for LPDDR flash chips}$~$\\
CONFIG\_MTD\_LPDDR [=n] \textbf{[~]}\\*
Diese Option ermöglicht die Unterstützung von LPDDR"=Flash"=Chips (Low Power Double Data Rate).
Synonym für Mobile"=DDR. Es handelt sich um einen neuen Standard für DDR"=Speicher, der für
batterie"-betriebene Systeme gedacht ist.
\subsubsection{SPI NOR device support \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MTD\_SPI\_NOR [=m] \textbf{[M]}\\*
Dies ist der Rahmen für den SPI NOR, der von den SPI"=Gerätetreibern und dem SPI NOR"=Gerätetreiber
verwendet werden kann.
\paragraph{Use small 4096 B erase sectors}$~$\\
CONFIG\_MTD\_SPI\_NOR\_USE\_4K\_SECTORS [=y] \textbf{[Y]}\\*
Viele Flash"=Speicher unterstützen das Löschen von kleinen Sektoren ($\qty{4096}{\byte}$). Je nach
Verwendung kann diese Funktion im Vergleich zum Löschen ganzer Blöcke ($\num{32}$/$\qty{64}{\kibi\byte}$)
einen Leistungsgewinn bringen. Das Ändern eines kleinen Teils des Flash"=Inhalts ist mit kleinen
Sektoren normalerweise schneller. Andererseits sollte das Löschen schneller sein, wenn
$\qty{64}{\kibi\byte}$-Blöcke anstelle von 16~$\sim$W $\qty{4}{\kibi\byte}$-Sektoren verwendet werden.
Bitte beachten Sie, dass einige Tools/Treiber/Dateisysteme möglicherweise nicht mit einer
Löschgröße von $\qty{4096}{\byte}$ arbeiten (z.~B. UBIFS benötigt mindestens $\qty{15}{\kibi\byte}$).
\paragraph{Software write protection at boot (Disable SWP on flashes
w/ volatile protection bits) \texorpdfstring{$\rightarrow$}{->}}$~$\\
\textit{Für diese Option gibt es keine Hilfe.}
\subparagraph{Disable SWP on any flashes (legacy behavior)}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_DISABLE [=n] \textbf{[~]}\\*
Mit dieser Option wird der Software"=Schreibschutz für alle SPI"=Flashes beim Booten deaktiviert.
Je nach Flash"=Chip werden dadurch entweder die Blockschutzbits gelöscht oder ein
\glqq Global Unprotect\grqq{}"=Befehl ausgeführt.
Verwenden Sie diesen Befehl nicht, wenn Sie beabsichtigen, den Software"=Schreibschutz Ihres
SPI"=Flashs zu verwenden. Dies dient nur dazu, die Abwärtskompatibilität zu erhalten.
\subparagraph{Disable SWP on flashes w/ volatile protection bits}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_DISABLE\_ON\_VOLATILE [=y] \textbf{[Y]}\\*
Einige SPI"=Flash"=Geräte verfügen über flüchtige Blockschutzbits, d.~h. nach dem Einschalten oder
einem Reset ist das Flash"=Gerät standardmäßig softwaremäßig schreibgeschützt.
Mit dieser Option wird der Software"=Schreibschutz für diese Art von Flashs deaktiviert, während er
für alle anderen SPI"=Flashs, die nichtflüchtige Schreibschutzbits haben, aktiviert bleibt.
Wenn der Software"=Schreibschutz je nach Flash deaktiviert wird, werden entweder die Blockschutzbits
gelöscht oder ein \glqq Global Unprotect\grqq{}"=Befehl ausgegeben.
Wenn Sie unsicher sind, wählen Sie diese Option.
\subparagraph{Keep software write protection as is}$~$\\
CONFIG\_MTD\_SPI\_NOR\_SWP\_KEEP [=n] \textbf{[~]}\\*
Wenn Sie diese Option wählen, wird der Software"=Schreibschutz eines SPI"=Flashs nicht geändert.
Wenn Ihr Flash über einen Software"=Schreibschutz verfügt oder nach dem Einschalten automatisch
über einen Software"=Schreibschutz verfügt, müssen Sie ihn manuell entsperren,
bevor Sie darauf schreiben können.
\subsubsection{Enable UBI -- Unsorted block images \texorpdfstring{$\rightarrow$}{->}}
CONFIG\_MTD\_UBI [=m] \textbf{[M]}\\*
UBI ist eine Softwareschicht über der MTD"=Schicht, die die Verwendung von LVM"=ähnlichen logischen Volumes
auf MTD"=Geräten zulässt, einige Komplexitäten von Flash"=Chips wie Abnutzung und fehlerhafte Blöcke
verbirgt und einige andere nützliche Funktionen bietet. Weitere Einzelheiten finden Sie auf der MTD"=Website
(\url{www.linux-mtd.infradead.org}).
\paragraph{UBI wear-leveling threshold}$~$\\
CONFIG\_MTD\_UBI\_WL\_THRESHOLD [=4096] \textbf{[4096]}\\*
Dieser Parameter legt die maximale Differenz zwischen dem höchsten Löschzählerwert und dem niedrigsten
Löschzählerwert der Löschsperren von UBI"=Geräten fest. Wenn dieser Schwellenwert überschritten wird,
beginnt das UBI mit dem Verschleißausgleich, indem es Daten von Löschblöcken mit niedrigem Löschzähler
zu Löschblöcken mit hohem Löschzähler verschiebt.
Der Standardwert sollte für SLC"=NAND"=Blitzgeräte, NOR"=Blitzgeräte und andere Blitzgeräte mit einem
Löschblock"=Lebenszyklus von \num{100000} oder mehr in Ordnung sein.
Bei MLC-NAND"=Blitzgeräten, die in der Regel eine Lebensdauer von weniger als \num{10000} haben,
sollte der Schwellenwert jedoch herabgesetzt werden (z.~B. auf 128 oder 256, obwohl er keine Potenz
von 2 sein muss).
\paragraph{Maximum expected bad eraseblock count per 1024 eraseblocks}$~$\\
CONFIG\_MTD\_UBI\_BEB\_LIMIT [=20] \textbf{[20]}\\*
Diese Option gibt an, wie viele fehlerhafte physische Eraseblocks UBI auf dem MTD"=Gerät erwartet
(pro 1024~Eraseblocks). Wenn der zugrundeliegende Flash keine schlechten Eraseblocks zulässt (z.~B. NOR-Flash),
wird dieser Wert ignoriert.
In den NAND"=Datenblättern wird oft die minimale und maximale NVM (Number of Valid Blocks) für die Lebensdauer
des Flashs angegeben. Die maximal zu erwartenden fehlerhaften Löschblöcke pro 1024~Löschblöcke können dann
berechnet werden als \glqq $1024 \cdot (1 - \mathit{MinNVB} / \mathit{MaxNVB})$\grqq{}, was für die meisten NANDs 20 ergibt
(MaxNVB ist im Grunde die Gesamtzahl der Löschblöcke auf dem Chip).
Anders ausgedrückt, wenn dieser Wert 20 ist, wird UBI versuchen, etwa $\qty{1,9}{\percent}$ der
physischen Eraseblocks für die Behandlung schlechter Blöcke zu reservieren. Und das sind
$\qty{1,9}{\percent}$ der Eraseblocks auf dem gesamten NAND"=Chip, nicht nur auf der MTD"=Partition,
die UBI zuordnet. Das bedeutet, dass, wenn Sie z.~B. einen NAND"=Flash"=Chip haben, der maximal
40~Bad Eraseblocks zulässt und auf zwei MTD"=Partitionen derselben Größe aufgeteilt ist,
UBI 40 Eraseblocks reserviert, wenn es eine Partition anhängt.
Diese Option kann durch den UBI-Modulparameter \texttt{mtd=} oder durch den ioctl \texttt{attach}
außer Kraft gesetzt werden.
Lassen Sie den Standardwert, wenn Sie unsicher sind.
\paragraph{UBI Fastmap (Experimental feature)}$~$\\
CONFIG\_MTD\_UBI\_FASTMAP [=n] \textbf{[~]}\\*
Wichtig: Diese Funktion ist bisher experimentell und das On"=Flash"=Format für Fastmap kann sich
in den nächsten Kernel"=Versionen ändern Fastmap ist ein Mechanismus, der das Anhängen eines
UBI"=Geräts in nahezu konstanter Zeit ermöglicht. Anstatt das gesamte MTD"=Gerät zu scannen,
muss nur ein Kontrollpunkt (Fastmap genannt) auf dem Gerät lokalisiert werden.
Die On"=Flash"=Fastmap enthält alle Informationen, die zum Anhängen des Geräts benötigt werden.
Die Verwendung der Fastmap ist nur bei großen Geräten sinnvoll, bei denen das Anschließen durch
Scannen lange dauert. UBI installiert nicht automatisch eine Fastmap auf alten Images, aber Sie
können den UBI"=Modulparameter fm\_autoconvert auf 1 setzen, wenn Sie dies wünschen.
Bitte beachten Sie, dass fastmap"=fähige Images auch mit UBI"=Implementierungen ohne
fastmap"=Unterstützung verwendbar sind. Auf typischen Flash"=Geräten passt die gesamte Fastmap
in ein PEB. UBI reserviert PEBs, um zwei Fastmaps zu speichern.
Im Zweifelsfall sagen Sie N.
\paragraph{MTD devices emulation driver (gluebi)}$~$\\
CONFIG\_MTD\_UBI\_GLUEBI [=n] \textbf{[~]}\\*
Diese Option aktiviert gluebi -- einen zusätzlichen Treiber, der MTD"=Geräte auf
UBI"=Volumes emuliert: für jedes UBI"=Volume wird ein MTD"=Gerät erstellt, und alle
E/A an dieses MTD"=Gerät werden auf das UBI"=Volume umgeleitet. Dies ist praktisch,
um MTD"=orientierte Software (wie JFFS2) auf UBI"=Volumes laufen zu lassen.
Aktivieren Sie dies nicht, es sei denn, Sie verwenden Legacy"=Software.
\paragraph{Read-only block devices on top of UBI volumes}$~$\\
CONFIG\_MTD\_UBI\_BLOCK [=n] \textbf{[~]}\\*
Mit dieser Option wird die Unterstützung von UBI"=Block"=Geräten mit Lesefunktion aktiviert.
UBI"=Blockgeräte werden über UBI"=Volumes gelegt, was bedeutet, dass der UBI"=Treiber Dinge
wie schlechte Eraseblocks und Bitflips transparent behandelt. Sie können jedes
blockorientierte Dateisystem auf UBI"=Volumes im Nur"=Lese"=Modus legen (z.~B. ext4), aber
es ist wahrscheinlich am praktischsten für Nur"=Lese"=Dateisysteme, wie squashfs.
Wenn diese Option ausgewählt ist, wird diese Funktion in den UBI"=Treiber integriert.
Im Zweifelsfall sagen Sie N.
\subsubsection{HyperBus support ---}
CONFIG\_MTD\_HYPERBUS [=n] \textbf{[~]}\\*
Dies ist der Rahmen für den HyperBus, der vom HyperBus"=Controller"=Treiber zur Kommunikation
mit HyperFlash verwendet werden kann. Siehe Cypress HyperBus Spezifikation für weitere Details.
%%
%% \texorpdfstring{$\rightarrow$}{->}
%% \textit{Für diese Option gibt es keine Hilfe.}