Diese Frage ergibt sich aus meinen Versuchen zu verstehen, wie ein integrierter platform deviceTreiber beim Booten initialisiert wird.
Ich verwende eine Embedded-Linux-Distribution (Yocto) auf einem SoC (ARM + FPGA). Der Gerätetreiber ist für ein geschrieben platform deviceund die IP ist im Gerätebaum zu finden, beschrieben als Plattformgerät. Die Eigenschaft „kompatibel“ stimmt mit dem C-Treiber überein, soweit alles gut.
Zitieren der Kernel-Dokumente für Plattformgeräte[1],
Es wird im Allgemeinen angenommen, dass jeder Knoten mit der Eigenschaft „kompatibel“ ein Gerät irgendeiner Art darstellt. Außerdem kann angenommen werden, dass jeder Knoten an der Wurzel des Baums entweder direkt mit dem Prozessorbus verbunden ist oder ein sonstiges Systemgerät darstellt, das nicht anders beschrieben werden kann.Für jeden dieser Knoten weist Linux ein Plattformgerät zu und registriert es, das wiederum an einen Plattformtreiber gebunden werden kann.
aber auch
2.4 Gerätepopulation
Nachdem die Karte identifiziert und die frühen Konfigurationsdaten analysiert wurden, kann die Kernel-Initialisierung wie gewohnt fortgesetzt werden. [...] Dies ist auch der Zeitpunkt, an dem maschinenspezifische Setup-Hooks aufgerufen werden, wie die Hooks machine_desc .init_early(), .init_irq() und .init_machine() auf ARM.
[...]
Der interessanteste Hook im DT-Kontext ist .init_machine(), der hauptsächlich dafür verantwortlich ist, das Linux-Gerätemodell mit Daten über die Plattform zu füllen
und schließlich (gemäß dem Beispiel in der Dokumentation mit Tegra-Board)
Zum Zeitpunkt .init_machine() muss der Tegra-Board-Supportcode diesen DT betrachten und entscheiden, für welche Knoten Plattformgeräte erstellt werden sollen.
Und tatsächlich, wenn man sich arch/arm[2] Ich kann die Funktion finden init_machine, die in den Gerätebaum "schaut". Diese Funktion existiert jedoch nicht für die arm64-Architektur. Die machine_descStrukturexistiert nur für Armbogen.
Beim Durchsuchen des Quellcodes konnte ich einige Operationen im Gerätebaum finden, die nicht leicht zu verstehen waren und in setup_machine_fdt stattfanden [4] die anruft early_dt_scan, aber siescheinen die Geräte nicht zu bevölkern:
/* Retrieve various information from the /chosen node */
rc = of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
/* Initialize {size,address}-cells info */
of_scan_flat_dt(early_init_dt_scan_root, NULL);
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
Das Problem hierbei ist, dass, wenn ich den Bootvorgang weiter verfolge, ich zu gelange, do_basic_setupwas nacheinander driver init, bus_init, platform_bus_initund schließlich aufruft of_core_init.
Ich hatte einige Hoffnungen mit dem letzten, der ein Kset namens „Devicetree“ erstellt. Ich verstehe jedoch nicht, ob der Baum hier tatsächlich analysiert wird.
Danach werden die initcallsaufgerufen, was bedeutet, dass die Treiberinitialisierung stattfindet, aber wo war hier die DT-Analyse beteiligt? Wo wurde die Eigenschaft „kompatibel“ tatsächlich verwendet? Nochmals aus den Dokumenten:
Der Trick besteht darin, dass der Kernel an der Wurzel des Baums beginnt und nach Knoten sucht, die die Eigenschaft „kompatibel“ haben. Erstens wird im Allgemeinen angenommen, dass jeder Knoten mit der Eigenschaft „kompatibel“ ein Gerät irgendeiner Art darstellt, und zweitens kann angenommen werden, dass jeder Knoten an der Wurzel des Baums entweder direkt an den Prozessorbus angeschlossen ist oder ein sonstiges Systemgerät ist, das nicht anders beschrieben werden kann. Für jeden dieser Knoten gilt:Linux weist ein Plattformgerät zu und registriert es, das wiederum an ein Plattformlaufwerk gebunden werden kann.
Der Teil „an Plattformlaufwerk gebunden“ wird durch den im Treibercode definierten Initcall ausgeführt. Was ich nicht verstehe, ist das „Zuordnen und Registrieren eines Plattformgeräts“.