UPD MTD support
This commit is contained in:
Binary file not shown.
@@ -10570,6 +10570,115 @@ aktiviert werden, wenn Userland so konfiguriert ist, dass das MemoryOverwriteReq
|
||||
beim sauberen Herunterfahren gelöscht wird, nachdem die Geheimnisse entfernt wurden, da sie
|
||||
sonst auch bei sauberen Neustarts ausgelöst wird.
|
||||
|
||||
\paragraph{EFI Runtime Configuration Interface Table Version 2 Support}$~$\\
|
||||
CONFIG\_EFI\_RCI2\_TABLE [=y] \textbf{[Y]}\\*
|
||||
Zeigt den Inhalt der Runtime Configuration Interface Table Version~2 auf
|
||||
Dell EMC PowerEdge"=Systemen als binäres Attribut \glqq rci2\grqq{} im
|
||||
Verzeichnis \texttt{/sys/firmware/efi/tables} an.
|
||||
Die RCI2"=Tabelle enthält BIOS HII im XML"=Format und wird zum Auffüllen der
|
||||
BIOS"=Setup"=Seite im Dell EMC OpenManage Server Administrator"=Tool verwendet.
|
||||
Die BIOS"=Setup"=Seite enthält BIOS"=Tokens, die konfiguriert werden können.
|
||||
Geben Sie hier Y für Dell EMC PowerEdge"=Systeme an.
|
||||
|
||||
\paragraph{Clear Busmaster bit on PCI bridges during ExitBootServices()}$~$\\
|
||||
CONFIG\_EFI\_DISABLE\_PCI\_DMA [=n] \textbf{[~]}\\*
|
||||
Deaktivieren Sie das Busmaster"=Bit im Kontrollregister auf allen PCI"=Brücken, während Sie
|
||||
ExitBootServices() aufrufen und die Kontrolle an den Laufzeitkernel übergeben. Die
|
||||
System"=Firmware kann die IOMMU so konfigurieren, dass böswillige PCI"=Geräte nicht in der
|
||||
Lage sind, das Betriebssystem über DMA anzugreifen. Da die Firmware jedoch nicht garantieren
|
||||
kann, dass das Betriebssystem IOMMU"=fähig ist, wird sie die IOMMU"=Konfiguration abbauen,
|
||||
wenn ExitBootServices() aufgerufen wird. Dadurch bleibt ein Zeitfenster, in dem ein
|
||||
feindliches Gerät noch Schaden anrichten kann, bevor Linux die IOMMU erneut konfiguriert.
|
||||
Wenn Sie hier Y angeben, wird der EFI"=Stub das Busmaster"=Bit auf allen PCI"=Brücken
|
||||
löschen, bevor ExitBootServices() aufgerufen wird. Dadurch wird verhindert, dass böswillige
|
||||
PCI"=Geräte DMA durchführen können, bis der Kernel das Busmastering nach der Konfiguration
|
||||
der IOMMU wieder aktiviert.
|
||||
Diese Option kann bei einigen Geräten mit schlechtem Verhalten zu Fehlern führen und sollte
|
||||
nicht ohne Test aktiviert werden. Die Kernel"=Befehlszeilenoptionen
|
||||
\texttt{efi=disable\_early\_pci\_dma} oder \texttt{efi=no\_disable\_early\_pci\_dma} können
|
||||
verwendet werden, um diese Option außer Kraft zu setzen.
|
||||
|
||||
\paragraph{Load custom ACPI SSDT overlay from an EFI variable}$~$\\
|
||||
CONFIG\_EFI\_CUSTOM\_SSDT\_OVERLAYS [=y] \textbf{[Y]}\\*
|
||||
Ermöglicht das Laden eines ACPI-SSDT-Overlays aus einer EFI"=Variablen, die durch eine
|
||||
Kernel"=Befehlszeilenoption angegeben wird.
|
||||
Siehe Documentation/admin-guide/acpi/ssdt-overlays.rst für weitere Informationen.
|
||||
|
||||
\paragraph{Disable EFI runtime services support by default}$~$\\
|
||||
CONFIG\_EFI\_DISABLE\_RUNTIME [=n] \textbf{[N]}\\*
|
||||
Erlaubt es, die Unterstützung der EFI-Laufzeitdienste standardmäßig zu deaktivieren.
|
||||
Dies kann bereits durch die Verwendung der Option \texttt{efi=noruntime} erreicht werden,
|
||||
aber es könnte nützlich sein, diese Voreinstellung ohne einen Kernel"=Befehlszeilenparameter zu haben.
|
||||
Die EFI"=Laufzeitdienste sind standardmäßig deaktiviert, wenn PREEMPT\_RT aktiviert ist, da Messungen
|
||||
gezeigt haben, dass einige EFI"=Funktionsaufrufe zu viel Zeit benötigen, um abgeschlossen zu werden,
|
||||
was zu großen Latenzen führen kann, was ein Problem für Echtzeit"=Kernel darstellt.
|
||||
Diese Voreinstellung kann mit der Option \texttt{efi=runtime} außer Kraft gesetzt werden.
|
||||
|
||||
\paragraph{EFI Confidential Computing Secret Area Support}$~$\\
|
||||
CONFIG\_EFI\_COCO\_SECRET [=y] \textbf{[Y]}\\*
|
||||
Confidential Computing"=Plattformen (z.~B. AMD SEV) ermöglichen es dem Gastbesitzer, während
|
||||
des Starts der Gast"=VM auf sichere Weise Geheimnisse einzubringen. Die Geheimnisse werden in
|
||||
einem bestimmten reservierten EFI"=Speicherbereich abgelegt.
|
||||
Um die Geheimnisse im Kernel verwenden zu können, muss der Ort des geheimen Bereichs (wie in
|
||||
der EFI"=Konfigurationstabelle veröffentlicht) beibehalten werden.
|
||||
Wenn Sie hier Y angeben, wird die Adresse des EFI"=Geheimbereichs für die Verwendung im Kernel
|
||||
beibehalten. Dadurch kann das Modul \texttt{virt/coco/efi\_secret} auf die Secrets zugreifen,
|
||||
was wiederum Userspace"=Programmen den Zugriff auf die injizierten Secrets ermöglicht.
|
||||
|
||||
\subsubsection{Qualcomm firmware drivers ---}
|
||||
\textit{(Qualcomm-Firmware-Treiber)}
|
||||
|
||||
\subsubsection{Tegra firmware drivers ---}
|
||||
\textit{(Tegra-Firmware-Treiber)}
|
||||
|
||||
\subsection{GNSS receiver support \texorpdfstring{$\rightarrow$}{->}}
|
||||
CONFIG\_GNSS \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Sagen Sie hier Y, wenn Sie einen GNSS"=Empfänger (z.~B. einen GPS"=Empfänger) haben.
|
||||
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
|
||||
Das Modul wird \texttt{gnss} genannt.
|
||||
|
||||
\subsubsection{Mediatek GNSS receiver support}
|
||||
CONFIG\_GNSS\_MTK\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Sagen Sie hier Y, wenn Sie einen Mediatek"=basierten GNSS"=Empfänger haben, der eine
|
||||
serielle Schnittstelle verwendet.
|
||||
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul wird
|
||||
\texttt{gnss-mtk} genannt.
|
||||
Wenn Sie unsicher sind, wählen Sie N.
|
||||
|
||||
\subsubsection{SiRFstar GNSS receiver support}
|
||||
CONFIG\_GNSS\_SIRF\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Sagen Sie hier Y, wenn Sie einen SiRFstar"=basierten GNSS"=Empfänger haben, der eine
|
||||
serielle Schnittstelle verwendet.
|
||||
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: Das Modul
|
||||
wird \texttt{gnss-sirf} genannt.
|
||||
Wenn Sie unsicher sind, wählen Sie N.
|
||||
|
||||
\subsubsection{u-blox GNSS receiver support}
|
||||
CONFIG\_GNSS\_UBX\_SERIAL \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Sagen Sie hier Y, wenn Sie einen GNSS-Empfänger von u-blox haben, der eine serielle
|
||||
Schnittstelle verwendet.
|
||||
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
|
||||
Das Modul wird \texttt{gnss-ubx} genannt.
|
||||
Wenn Sie unsicher sind, wählen Sie N.
|
||||
|
||||
\subsubsection{USB GNSS receiver support}
|
||||
CONFIG\_GNSS\_USB \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Geben Sie hier Y ein, wenn Sie einen GNSS-Empfänger haben, der eine
|
||||
USB-Schnittstelle verwendet.
|
||||
Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M:
|
||||
Das Modul wird \texttt{gnss-usb} genannt.
|
||||
Wenn Sie unsicher sind, sagen Sie N.
|
||||
|
||||
\subsection{Memory Technology Devices (MTD) support \texorpdfstring{$\rightarrow$}{->}}
|
||||
CONFIG\_MTD \colorbox{yellow!80}{[=m] \textbf{[~]}}\\*
|
||||
Memory Technology Devices sind Flash-, RAM- und ähnliche Chips, die häufig für
|
||||
Solid"=State"=Dateisysteme auf eingebetteten Geräten verwendet werden. Diese Option
|
||||
bietet die allgemeine Unterstützung für MTD"=Treiber, um sich beim Kernel zu registrieren,
|
||||
und für potenzielle Benutzer von MTD"=Geräten, um die vorhandenen Geräte aufzulisten und
|
||||
einen Zugriff auf sie zu erhalten. Sie ermöglicht es Ihnen auch, individuelle Treiber für
|
||||
bestimmte Hardware und Benutzer von MTD"=Geräten auszuwählen.
|
||||
Wenn Sie unsicher sind, sagen Sie N.
|
||||
|
||||
\end{document}
|
||||
|
||||
\texorpdfstring{$\rightarrow$}{->}
|
||||
|
||||
Reference in New Issue
Block a user