Aqui está minha resposta oficial depois de responder meus comentários. Eu poderia estar muito errado sobre algumas dessas coisas e receber correções.
Não sei quando a Intel começou a incorporar o PCIe (que é uma extensão de PCI compatível com software) em suas CPUs. No entanto, não tem sido assim na maior parte do tempo x86 tem sido em torno. PCI é realmente parte de toda a "plataforma de PC", que inclui uma série de outras coisas que são padrão e esperado, como portas ISA padrão / endereço de E / S / IRQs para dispositivos e coisas assim.
Retroceda um pouco antes do PCI - basicamente, exceto com a tentativa frustrada de introduzir um padrão PnP com o ISAPNP, você realmente não "testou" alguns dispositivos. Você geralmente precisaria assumir que eles existiam de antemão. Você poderia, é claro, testar registros e o que não fazer se as coisas responderem como esperado, mas você terá problemas se houver um dispositivo diferente, possivelmente resultando em interrupções, etc. Não existe uma maneira de "varrer" o barramento ISA. Ou realmente qualquer outro barramento que não suporte os conceitos de PnP de forma padronizada.
Uma das coisas que a ACPI deveria resolver era fornecer algumas tabelas de informações que informavam quais dispositivos ISA eram internos. Mesmo antes da ACPI, o BIOS seria consultado para decidir quantas unidades de disquete estavam no sistema. É por isso que em sistemas mais antigos, mesmo que você não tenha um disquete conectado, você verá uma unidade A: no Windows se tiver o BIOS configurado para dizer que existe um.
Assim, você pode perguntar como os sistemas operacionais modernos determinam ou interagem com um chipset PCI. Na maioria das vezes, o chipset aparece como um dispositivo no próprio barramento PCI. A interface PCI registra "pré-existente" em locais padrão conhecidos na plataforma do PC. Uma varredura programática através de todos os slots de dispositivos e funções no espaço PCI é possível aqui. Nada disso existe para o ISA. Se o dispositivo estiver no barramento com o ISA, os registros respondem quando carregados / armazenados, e é isso. Você não pode falar com o próprio ônibus.
Por acaso, o chipset PCI pode até ter a capacidade de controlar uma ponte "PCI-ISA" e trazer algumas das funcionalidades PnP para o barramento ISA (ou agora, LPC). Por conta própria, o ISA diz que você está sozinho, no entanto.
Não existe essa plataforma padrão para o ARM. Ainda não, de qualquer forma. Existem muitas plataformas exclusivas nas quais os processadores ARM são executados. Barramentos PCI, I2C e SDIO (e possivelmente mais que eu não conheço) são comuns entre alguns deles, mas, novamente, existem plataformas ARM que não possuem nenhuma delas. A ACPI não está implementada no ARM AFAIK, exceto no Microsoft Surface RT. Sem trabalhar com um barramento padronizado que suporte alguma noção de PnP, não há como "sondar" nada. Você precisa ter presciência fora do sistema do hardware que deveria estar lá. O U-Boot é um carregador de boot ARM comumente usado que requer suporte para ser construído para a plataforma específica na qual ele deve rodar. . É algo como um padrão, mas mesmo assim, geralmente é construído por plataforma do meu entendimento.
Alguns breves googling revelam que este dispositivo tem um chipset de vídeo "Mali 400". Outras buscas traz o código-fonte do driver GPU Mali site. Eu estou um pouco enferrujado no meu C, mas eu olhei para ele. Parece que o que você deve fazer é, ao criar o driver, informar os endereços que ele precisa atingir para falar com a GPU. Eu realmente não mergulhei na fonte muito profundamente, mas não me surpreenderia se não estivesse falando com um ônibus, mas apenas carregando / armazenando diretamente de E / S mapeada na memória.
Portanto, não acho que haja uma resposta genérica para todas as plataformas ARM, infelizmente.