was ist die Verwendung von Flattened-device-tree - Linux-Kernel

Gehe ich durch das Uboot & kernel-Start-Prozess. Was genau ist die Verwendung der FDT (Flat device tree) ?

Viele link habe ich gelesen, Sie behaupten, dass uboot das board & SOC-Konfiguration Informationen zu Kernel in form von FDT

https://wiki.freebsd.org/FlattenedDeviceTree

Warum kernel müssen die board-Konfiguration Informationen ?

Ich Stelle diese Frage, weil, Wann immer wir machen-Gerätetreiber in linux, die wir verwenden, initialisieren Sie das Gerät an der Sonde() oder module_init () - Aufruf & verwenden request_mem_region() & ioremap () - Funktion, um die Bandbreite der Adresse
& dann legen Sie die Uhr & andere register der Fahrer.

Was bedeutet request_mem_region() tatsächlich tun, und wenn es erforderlich ist?

Nun, ob mein Gerät Treiber für onchip & offchip-Geräte sind dabei die Vollpension Initialisierung.

Was ist dann die Verwendung von flattened device tree für den kernel ?

  • Einige Ihrer Konzepte wie ein Gerätetreiber konfiguriert ist, die nun veraltet sind mit dem Geräte-Baum. Nichts für ungut, aber hier ist ein video von der Absicht, mit dem Geräte-Baum. Thomas Petazzoni hat auch einige dia-Vorträge in Freie Elektronen.
  • also Sie bedeutet, zu sagen, dass prob(0 & module_init() oder init_module() diese Funktionen sind nicht für Treiber-Initialisierung ... aber ich habe mit dem gleichen Konzept auf meinem RPi Hardware .. bedeutet das erstellen einer ladbaren Modul verwenden, um alle seine Initialisierung in init_module() Funktion ... geladen wird das Modul mit insmod() command & es verwendet ... also willst du jetzt sagen wir nicht verwenden Konzept der lodable kernel-Modul in Linux-kernel ... ? bitte empfehlen ... !!
  • "also Sie bedeutet, zu sagen, dass..." - ich wollte nicht schreiben oder andeuten, irgendetwas in der Nähe zu dem, was Sie spekulieren. Die alte Methode der board-Datei und Plattform-Daten gegen Device Tree sind eindeutig beschrieben, dass video-und dia-Vorträge schon erwähnt. Also anstatt zu raten und Wild Fehlinterpretation des einfachen Satz, den ich geschrieben habe, klicken Sie auf diese links.
  • ja, dass video erklärt alles ... eine Sache will ich gerne wissen .. welche version des Kernels war der erste Schritt in Richtung device-tree-Implementierung ... ? Nicht alle die modernen SOC in diesen Tagen Folgen Flatterned Gerät Baum, um Informationen zu kernel-oder immer noch dem alten Konzept wird in der Industrie verwendet werden ..?
  • Für ARM-das Gerät Baum erschien zuerst in Linux 3.1. Ihre zweite Frage nicht sich gegenseitig ausschließende Bedingungen auf jeder Seite der 'oder'.
  • ausschließen .. bedeutet, zu sagen, was .. ?
  • Gegenwärtig sind nur sehr wenige der großen Anzahl von SoCs unterstützt der Linux-kernel übernommen haben, der device-tree-Ansatz. Der Allgemeine Konsens ist, dass der Geräte-Bäume sind nützlich in den meisten Fällen und wird langsam angenommen.
  • Mögliche Duplikate von Wie Programm Linux .dts device tree Dateien?

InformationsquelleAutor Katoch | 2014-02-16
  1. 9

    Sind Sie richtig in der Annahme, dass die board Dateien und Gerät-Bäume sind erforderlich für die Initialisierung der on-chip-Bausteine und off-chip-Peripherie.

    1. Beim Booten die entsprechenden Treiber für alle on-chip-Bausteine einer SoC-und off-chip-Peripherie angebunden zu werden "abgetastet", d.h. geladen und aufgerufen. Auf dem bus-es-wie USB und PCI die Peripherie-Geräte erkannt werden können, die körperlich und aufgelistet und die entsprechenden Treiber sondiert. Jedoch im Allgemeinen eine solche Einrichtung NICHT zur Verfügung steht ist groß-der rest der Peripherie vom rest der Busse wie I2C, SPI usw.

    2. Zusätzlich zu den oben genannten, wenn der device-Treiber wird untersucht, benötigt man auch einige Informationen über die Art und Weise, in der wir beabsichtigen, zu konfigurieren und zu nutzen-die hardware. Diese variiert je nach Anwendungsfall. Beispielsweise die baud-rate an, die wir betreiben eine UART-port.

    Beide der oben genannten Klassen von Informationen, z.B.

    • Physikalische Topologie der hardware.
    • Optionen für die Konfiguration der hardware.

    waren in der Regel definiert als structs innerhalb der "board" - Datei.

    Jedoch mit der board-Datei-Ansatz erforderlich, einen re-build die kernel auch einfach ändern, eine konfigurierbare option, um einen anderen Wert während der Initialisierung. Auch wenn mehrere physische Platten unterschiedlicher geringfügig in Ihrer Topologie/Konfiguration existiert, wird die "board" - Datei-Ansatz wird zu umständlich zu pflegen.

    Daher das Interesse an der Erhaltung dieser Informationen separat in einem Gerät-Baum. Jedes Gerät-Treiber analysieren können die relevanten Zweige und Blätter der device-Struktur, die Informationen zu erhalten, die er benötigt.

    Bei der Entwicklung Ihrer eigenen device-Treibers, wenn Ihre Plattform unterstützt das Gerät-Baum, dann sollten Sie nutzen das Gerät Baum zum speichern des "Plattform-Daten" erforderlich, die von Ihrem Gerät-Treiber. Dies sollte Ihnen helfen, klar zu trennen :

    • dem generischen Treiber-code für Ihr Gerät in der <Treiber.c> Datei-und

    • die device config-Optionen, die speziell für diese Plattform in der device-tree.

    Einer Schritt-für-Schritt-Ansatz, um die Portierung des Linux-kernel zu einem board - /SoC sollte helfen, Sie schätzen die Nuancen und die Vorteile der Verwendung eines device-tree.

    InformationsquelleAutor TheCodeArtist
Schreibe einen Kommentar