Aquí está mi respuesta oficial después de que respondas mis comentarios. Podría estar bastante equivocado acerca de esto y agradecería las correcciones.
No estoy seguro de cuándo Intel comenzó a incorporar PCIe (que es una extensión de PCI compatible con software) en sus CPU. Sin embargo, no ha sido así durante la mayor parte del tiempo que ha existido x86. PCI es realmente parte de toda la "plataforma de PC" que incluye una serie de otras cosas que son estándar y esperadas, como puertos ISA estándar/dirección de E/S/IRQ para dispositivos y cosas por el estilo.
Retroceda un poco antes de que existiera PCI:básicamente, excepto con el intento fallido de introducir un estándar PnP con ISAPNP, realmente no "probó" algunos dispositivos. Por lo general, deberá asumir que existieron de antemano. Por supuesto, puede probar los registros y ver si las cosas responden como se esperaba, pero luego se mete en problemas si hay un dispositivo diferente, lo que posiblemente provoque bloqueos, etc. Realmente no había una forma de "escanear". el autobús ISA. O realmente cualquier otro bus que no admita conceptos PnP de manera estandarizada.
Una de las cosas que se suponía que ACPI debía resolver era proporcionar algunas tablas de información que indicaban qué dispositivos ISA estaban integrados. Incluso antes de ACPI, se consultaba el BIOS para decidir cuántas unidades de disquete había en el sistema. Esta es la razón por la que en los sistemas más antiguos, incluso si no tiene un disquete conectado, verá una unidad A:en Windows si tiene el BIOS configurado para decir que hay uno.
Entonces, puede preguntar cómo los sistemas operativos modernos determinan o interactúan con un conjunto de chips PCI. La mayoría de las veces, el conjunto de chips aparece como un dispositivo en el propio bus PCI. La interfaz PCI registra "preexistencia" en ubicaciones estándar conocidas en la plataforma de PC. Aquí es posible un escaneo programático a través de todos los dispositivos y ranuras de funciones en el espacio PCI. Nada de eso existe para ISA. Si el dispositivo está en el bus con ISA, sus registros responden cuando se cargan/almacenan, y eso es todo. Realmente no puedes hablar con el autobús en sí.
Por cierto, el conjunto de chips PCI podría incluso tener la capacidad de controlar un puente "PCI-ISA" y llevar parte de la funcionalidad PnP al bus ISA (o ahora, LPC). Sin embargo, ISA dice que estás solo.
No existe tal plataforma estándar para ARM. No todavía, de todos modos. Hay muchas plataformas únicas en las que se ejecutan las CPU ARM. Los buses PCI, I2C y SDIO (y posiblemente más que desconozco) son algo común entre algunos de ellos, pero, de nuevo, hay plataformas ARM que no tienen ninguno de ellos. ACPI no está implementado en ARM AFAIK excepto en Microsoft Surface RT. Sin trabajar con un bus estandarizado que admita alguna noción de PnP, realmente no hay forma de "probar" nada. Debe tener conocimiento previo fuera del sistema del hardware que se supone que debe estar allí. U-Boot es un cargador de arranque ARM de uso común que requiere soporte y debe construirse para la plataforma específica en la que debe ejecutarse. Es algo así como un estándar, pero aun así, por lo general se construye por plataforma desde mi punto de vista.
Algunas breves búsquedas en Google revelan que este dispositivo tiene un chipset de video "Mali 400". La búsqueda adicional trae el sitio del código fuente del controlador de GPU Mali. Estoy un poco oxidado en mi C, pero lo miré. Parece que lo que se supone que debes hacer es, cuando creas el controlador, decirle las direcciones que debe alcanzar para comunicarse con la GPU. Realmente no me sumergí demasiado en la fuente, pero no me sorprendería si no estuviera hablando con un bus, sino simplemente cargando/almacenando directamente desde E/S mapeada en memoria.
Desafortunadamente, no creo que haya una respuesta genérica para todas las plataformas ARM.