Voici ma réponse officielle après avoir répondu à mes commentaires. Je peux me tromper sur certains points et j'apprécie les corrections.
Je ne sais pas quand Intel a commencé à incorporer PCIe (qui est une extension compatible avec le logiciel PCI) dans ses processeurs. Cependant, il n'en a pas été ainsi pendant la majeure partie du temps où x86 a existé. PCI fait vraiment partie de l'ensemble de la "plate-forme PC" qui comprend un certain nombre d'autres choses qui sont standard et attendues, comme les ports ISA standard/l'adresse d'E/S/les IRQ pour les périphériques et des choses comme ça.
Revenez un peu en arrière avant que PCI ne soit là - en gros, sauf avec la tentative avortée d'introduire une norme PnP avec ISAPNP, vous n'avez pas vraiment "sondé" pour certains périphériques. Vous auriez généralement besoin de supposer qu'ils existaient auparavant. Vous pouvez, bien sûr, tester les registres et quoi ne pas voir si les choses répondent comme prévu, mais vous rencontrez alors des problèmes si un périphérique différent est là, ce qui peut entraîner des blocages, etc. Il n'y avait vraiment aucun moyen de "scanner" le bus ISA. Ou vraiment tout autre bus qui ne prend pas en charge les concepts PnP de manière standardisée.
L'une des choses que l'ACPI était censé résoudre était de fournir des tableaux d'informations indiquant quels périphériques ISA étaient intégrés. Même avant l'ACPI, le BIOS était consulté pour décider du nombre de lecteurs de disquettes dans le système. C'est pourquoi sur les systèmes plus anciens, même si vous n'avez pas de disquette connectée, vous verrez un lecteur A:dans Windows si le BIOS est configuré pour dire qu'il y en a un.
Vous pouvez donc vous demander comment les systèmes d'exploitation modernes déterminent ou s'interfacent avec un chipset PCI. La plupart du temps, le chipset apparaît comme un périphérique sur le bus PCI lui-même. Les registres d'interface PCI "préexistent" à des emplacements standard connus dans la plate-forme PC. Une analyse par programmation de tous les emplacements de périphérique et de fonction dans l'espace PCI est possible ici. Rien de tel n'existe pour ISA. Si le périphérique est sur le bus avec ISA, ses registres répondent lorsqu'ils sont chargés/stockés, et c'est tout. Vous ne pouvez pas vraiment parler au bus lui-même.
Incidemment, le chipset PCI pourrait même avoir la capacité de contrôler un pont "PCI-ISA" et d'apporter une partie de la fonctionnalité PnP au bus ISA (ou maintenant, LPC). En soi, ISA dit que vous êtes seul, cependant.
Il n'existe pas de plate-forme standard de ce type pour ARM. Pas encore en tout cas. Il existe de nombreuses plates-formes uniques sur lesquelles les processeurs ARM fonctionnent. Les bus PCI, I2C et SDIO (et peut-être plus que je ne connais pas) sont des points communs entre certains d'entre eux, mais encore une fois, il existe des plates-formes ARM qui n'en ont aucune. ACPI n'est pas implémenté sur ARM AFAIK sauf sur Microsoft Surface RT. Sans travailler avec un bus standardisé qui prend en charge une certaine notion de PnP, il n'y a vraiment aucun moyen de "sonder" quoi que ce soit. Vous devez avoir une connaissance préalable en dehors du système du matériel qui est censé s'y trouver. U-Boot est un chargeur de démarrage ARM couramment utilisé qui nécessite une prise en charge et doit être conçu pour la plate-forme spécifique sur laquelle il est censé fonctionner. C'est quelque chose comme un standard, mais même dans ce cas, il est généralement construit par plate-forme d'après ma compréhension.
Quelques brèves recherches sur Google révèlent que cet appareil dispose d'un chipset vidéo "Mali 400". Une recherche plus poussée amène le site du code source du pilote Mali GPU. Je suis un peu rouillé sur mon C, mais je l'ai regardé. Il semble que ce que vous êtes censé faire est, lorsque vous construisez le pilote, de lui indiquer les adresses qu'il doit atteindre pour parler au GPU. Je ne me suis vraiment pas immergé trop profondément dans la source, mais cela ne me surprendrait pas s'il ne parlait pas à un bus, mais se contentait de charger/stocker directement à partir d'E/S mappées en mémoire.
Je ne pense donc pas qu'il existe une réponse générique pour toutes les plates-formes ARM, malheureusement.