Gerätebaum - Devicetree
In der Berechnung wird ein devicetree (auch geschrieben Gerätebaum ist) eine Strukturdaten die Hardware - Komponenten eines bestimmten Computers beschreibt , so dass das Betriebssystem ist Kernel diese Komponenten verwenden und verwalten können, einschließlich der CPU oder CPUs, den Speicher , die Busse und die Peripherie .
Der Gerätebaum wurde von SPARC-basierten Computern über das Open Firmware- Projekt abgeleitet. Die aktuelle Devicetree-Spezifikation zielt auf kleinere Systeme ab, wird aber immer noch bei einigen Serverklassensystemen verwendet (z. B. denen, die in der Power Architecture Platform Reference beschrieben sind ).
Personalcomputer mit der x86- Architektur verwenden im Allgemeinen keine Gerätebäume, sondern verlassen sich stattdessen auf verschiedene Autokonfigurationsprotokolle (zB ACPI ), um Hardware zu erkennen. Systeme, die Gerätebäume verwenden, übergeben normalerweise einen statischen Gerätebaum (vielleicht im ROM gespeichert ) an das Betriebssystem, können aber auch einen Gerätebaum in den frühen Stadien des Bootens generieren . Als Beispiel können Das U-Boot und kexec beim Starten eines neuen Betriebssystems einen Gerätebaum übergeben. Auf Systemen mit einem Bootloader, der keine Gerätebäume unterstützt, kann zusammen mit dem Betriebssystem ein statischer Gerätebaum installiert werden; der Linux-Kernel unterstützt diesen Ansatz.
Die Devicetree-Spezifikation wird derzeit von einer Community namens devicetree.org verwaltet , die unter anderem mit Linaro und Arm verbunden ist .
Gerätebaumformate
Ein Gerätebaum kann jede Art von Daten enthalten, da er intern ein Baum aus benannten Knoten und Eigenschaften ist . Knoten enthalten Eigenschaften und untergeordnete Knoten, während Eigenschaften Name-Wert-Paare sind .
Gerätebäume haben sowohl ein Binärformat für die Verwendung durch Betriebssysteme als auch ein Textformat für die bequeme Bearbeitung und Verwaltung.
Verwendung unter Linux
Mit dem richtigen Gerätebaum kann derselbe kompilierte Kernel verschiedene Hardwarekonfigurationen innerhalb einer größeren Architekturfamilie unterstützen. Der Linux - Kernel für die ARC , ARM , C6x , H8 / 300 , Microblaze , MIPS , NDS32, Nios II , OpenRISC , PowerPC , RISC-V , SuperH und Xtensa Architekturen liest Gerätebaum Informationen; auf ARM sind seit 2012 Gerätebäume für alle neuen SoCs obligatorisch . Dies kann als Abhilfe für die große Anzahl von Forks (von Linux und Das U-Boot) angesehen werden, die in der Vergangenheit erstellt wurden, um (geringfügig) unterschiedliche ARM-Boards zu unterstützen . Der Zweck besteht darin, einen erheblichen Teil der Hardwarebeschreibung aus der Kernel-Binärdatei in den kompilierten Gerätebaum-Blob zu verschieben, der vom Bootloader an den Kernel übergeben wird , wobei eine Reihe von Board-spezifischen C- Quelldateien und Kompilierungsdateien ersetzt werden. Zeitoptionen im Kernel.
Sie wird in einer Devicetree-Quelldatei (.dts) angegeben und über den Devicetree-Compiler (DTC) in eine Devicetree-Blob- oder Gerätebaum-Binärdatei (.dtb) kompiliert. Gerätebaum Quelldateien umfassen andere Dateien, die als Gerätebaum Quelle enthält.
Bei ARM-basierten Linux-Distributionen war es üblich , einen Bootloader mitzuliefern, der notwendigerweise für bestimmte Boards, zum Beispiel Raspberry Pi oder Hackberry A10, angepasst wurde . Dies hat den Entwicklern von Linux-Distributionen Probleme bereitet, da ein Teil des Betriebssystems speziell für jede Board-Variante kompiliert oder aktualisiert werden muss, um neue Boards zu unterstützen. Einige moderne SoCs (z. B. Freescale i.MX6 ) verfügen jedoch über einen vom Hersteller bereitgestellten Bootloader mit Gerätebaum auf einem separaten Chip vom Betriebssystem.
Ein proprietäres Konfigurationsdateiformat, das für ähnliche Zwecke verwendet wird, das FEX-Dateiformat, ist ein De-facto-Standard unter Allwinner- SoCs.
Verwendung in Windows
In Windows wird vom Plug-and-Play-Manager eine ACPI-Gerätestruktur verwaltet, um beispielsweise zu bewerten, ob Geräte sicher ausgeworfen werden können.
Beispiel
Beispiel für das Devicetree Source (DTS)-Format:
/dts-v1/;
/ {
soc {
flash_controller: flash-controller@4001e000 {
reg = <0x4001e000 0x1000>;
flash0: flash@0 {
label = "SOC_FLASH";
erase-block = <4096>;
};
};
};
};
Im obigen Beispiel bedeutet die Zeile Version 1 der DTS-Syntax.
/dts-v1/;
Der Baum hat vier Knoten: /(Root-Knoten), soc(steht für „ System auf einem Chip “) flash-controller@4001e000und flash@0(Instanz von Flash, die den Flash-Controller verwendet). Neben diesen Knotennamen haben die letzteren zwei Knoten Etiketten flash_controller und flash0jeweils.
Die letzten beiden Knoten haben Eigenschaften , die Name/Wert-Paare darstellen. Property labelhat einen String-Typ, Property erase-blockhat einen Integer-Typ und Property regist ein Array von Ganzzahlen (32-Bit-Werte ohne Vorzeichen). Eigenschaftswerte können über ihre Phandles auf andere Knoten im Gerätebaum verweisen . Phandle für einen Knoten mit Label flash0würde als &flash0. Phandles sind ebenfalls 32-Bit-Werte.
Teile der Knotennamen nach dem "at"-Zeichen ( @) sind Geräteadressen . Einheitenadressen geben die Adresse eines Knotens im Adressraum seines Elternknotens an.
Der obige Baum könnte mit dem Standard-DTC-Compiler in das binäre DTB-Format oder in eine Assembly kompiliert werden . In Zephyr RTOS werden DTS-Dateien jedoch in C-Header-Dateien (.h) kompiliert , die dann vom Build-System verwendet werden, um Code für ein bestimmtes Board zu kompilieren .