Hier ist meine offizielle Antwort, nachdem Sie meine Kommentare beantwortet haben. Ich könnte bei einigen davon ziemlich falsch liegen und begrüße Korrekturen.
Ich bin mir nicht sicher, wann Intel begann, PCIe (eine softwarekompatible Erweiterung von PCI) in seine CPUs zu integrieren. Allerdings war es die meiste Zeit, in der es x86 gab, nicht so. PCI ist wirklich ein Teil der gesamten "PC-Plattform", die eine Reihe anderer Dinge enthält, die Standard sind und erwartet werden, wie Standard-ISA-Ports/E/A-Adressen/IRQs für Geräte und ähnliches.
Rollback ein bisschen zurück, bevor es PCI gab - im Grunde hat man, abgesehen von dem fehlgeschlagenen Versuch, mit ISAPNP einen PnP-Standard einzuführen, nicht wirklich nach einigen Geräten "geprüft". Sie müssten im Allgemeinen davon ausgehen, dass sie vorher existierten. Sie könnten natürlich Register testen und sehen, ob die Dinge wie erwartet reagieren, aber Sie bekommen dann Probleme, wenn ein anderes Gerät vorhanden ist, was möglicherweise zu Hängen führt usw. Es gab wirklich keine Möglichkeit zum "Scannen". der ISA-Bus. Oder wirklich jeder andere Bus, der PnP-Konzepte nicht standardisiert unterstützt.
Eines der Dinge, die ACPI lösen sollte, war, einige Informationstabellen bereitzustellen, die Ihnen mitteilten, welche ISA-Geräte eingebaut waren. Noch vor ACPI wurde das BIOS konsultiert, um zu entscheiden, wie viele Diskettenlaufwerke im System vorhanden waren. Aus diesem Grund sehen Sie auf älteren Systemen, selbst wenn Sie keine Diskette angeschlossen haben, ein Laufwerk A:in Windows, wenn Sie das BIOS so eingestellt haben, dass es eines gibt.
Sie fragen sich also vielleicht, wie moderne Betriebssysteme einen PCI-Chipsatz bestimmen oder mit ihm kommunizieren. Meistens erscheint der Chipsatz als Gerät am PCI-Bus selbst. Die PCI-Schnittstellenregistrierungen "vorbestehen" an bekannten Standardstellen in der PC-Plattform. Hier ist ein programmatischer Scan durch alle Geräte- und Funktionssteckplätze im PCI-Raum möglich. Nichts dergleichen existiert für ISA. Wenn das Gerät mit ISA am Bus ist, reagieren seine Register, wenn es geladen/gespeichert wird, und das war's. Mit dem Bus selbst kann man nicht wirklich sprechen.
Übrigens könnte der PCI-Chipsatz sogar die Fähigkeit haben, eine "PCI-ISA"-Brücke zu steuern und einen Teil der PnP-Funktionalität auf den ISA- (oder jetzt LPC-) Bus zu bringen. Auf sich allein gestellt, sagt ISA, dass Sie auf sich allein gestellt sind.
Es gibt keine solche Standardplattform für ARM. Jedenfalls noch nicht. Es gibt viele einzigartige Plattformen, auf denen ARM-CPUs laufen. PCI-, I2C- und SDIO-Busse (und möglicherweise mehr, von denen ich nichts weiß) sind eine Gemeinsamkeit zwischen einigen von ihnen, aber auch hier gibt es ARM-Plattformen, die keine davon haben. ACPI ist auf ARM AFAIK nicht implementiert, außer auf dem Microsoft Surface RT. Ohne die Arbeit mit einem standardisierten Bus, der PnP unterstützt, gibt es wirklich keine Möglichkeit, irgendetwas zu "sondieren". Sie müssen außerhalb des Systems Vorwissen über die Hardware haben, die dort sein soll. U-Boot ist ein häufig verwendeter ARM-Bootloader, der Unterstützung für die spezifische Plattform benötigt und für diese entwickelt werden muss, auf der er ausgeführt werden soll. Es ist so etwas wie ein Standard, aber selbst dann wird es nach meinem Verständnis normalerweise pro Plattform erstellt.
Einiges kurzes Googeln verrät, dass dieses Gerät einen „Mali 400“-Videochipsatz hat. Eine weitere Suche bringt die Mali-GPU-Treiber-Quellcode-Site. Ich bin ein wenig eingerostet auf meinem C, aber ich habe es mir angesehen. Es scheint, was Sie tun sollten, wenn Sie den Treiber erstellen, ihm die Adressen mitteilen, die er treffen muss, um mit der GPU zu sprechen. Ich bin wirklich nicht zu tief in die Quelle eingetaucht, aber es würde mich nicht überraschen, wenn sie nicht mit einem Bus spricht, sondern nur direkt von speicherabgebildeten E/A lädt/speichert.
Daher glaube ich nicht, dass es leider eine allgemeine Antwort für alle ARM-Plattformen gibt.