Ecco la mia risposta ufficiale dopo aver risposto ai miei commenti. Potrei sbagliarmi di grosso su alcune di queste cose e gradirei correzioni.
Non sono sicuro di quando Intel abbia iniziato a incorporare PCIe (che è un'estensione compatibile con il software di PCI) nelle proprie CPU. Tuttavia, non è stato così per la maggior parte del tempo in cui x86 è stato utilizzato. PCI è davvero parte dell'intera "piattaforma PC" che include una serie di altre cose che sono standard e previste, come porte ISA standard/indirizzo I/O/IRQ per dispositivi e cose del genere.
Un po' di rollback a prima che esistesse il PCI - fondamentalmente, a parte il tentativo fallito di introdurre uno standard PnP con ISAPNP, non hai davvero "sondato" per alcuni dispositivi. In genere dovresti presumere che esistessero in anticipo. Potresti, ovviamente, testare i registri e cosa non vedere se le cose rispondono come previsto, ma poi ti metti nei guai se è presente un dispositivo diverso, con possibili blocchi, ecc. Non c'era davvero un modo per "scansionare" l'autobus ISA. O davvero qualsiasi altro bus che non supporta i concetti PnP in modo standardizzato.
Una delle cose che ACPI avrebbe dovuto risolvere era fornire alcune tabelle di informazioni che ti dicessero quali dispositivi ISA erano incorporati. Anche prima dell'ACPI, il BIOS veniva consultato per decidere quante unità floppy erano presenti nel sistema. Questo è il motivo per cui sui sistemi più vecchi, anche se non hai un floppy connesso, vedrai un'unità A:in Windows se hai il BIOS impostato per dire che ce n'è uno.
Quindi potresti chiedere in che modo i sistemi operativi moderni determinano o si interfacciano con un chipset PCI. Il più delle volte il chipset appare come un dispositivo sul bus PCI stesso. L'interfaccia PCI si registra "preesistente" in posizioni standard note nella piattaforma PC. Qui è possibile una scansione programmatica di tutti gli slot di dispositivi e funzioni nello spazio PCI. Niente di simile esiste per ISA. Se il dispositivo è sul bus con ISA, i suoi registri rispondono quando vengono caricati/memorizzati, e il gioco è fatto. Non puoi davvero parlare con l'autobus stesso.
Per inciso, il chipset PCI potrebbe anche avere la capacità di controllare un bridge "PCI-ISA" e portare alcune delle funzionalità PnP al bus ISA (o ora LPC). Da solo, ISA dice che sei da solo, però.
Non esiste una piattaforma standard per ARM. Non ancora, comunque. Esistono molte piattaforme uniche su cui vengono eseguite le CPU ARM. I bus PCI, I2C e SDIO (e forse altri che non conosco) sono una comunanza tra alcuni di loro, ma ancora una volta, ci sono piattaforme ARM che non ne hanno. ACPI non è implementato su ARM AFAIK tranne che su Microsoft Surface RT. Senza lavorare con un bus standardizzato che supporti qualche nozione di PnP non c'è davvero modo di "sondare" per qualcosa. Devi avere una conoscenza preliminare al di fuori del sistema dell'hardware che dovrebbe essere lì. U-Boot è un bootloader ARM di uso comune che richiede il supporto e la creazione per la piattaforma specifica su cui è destinato a funzionare. È qualcosa di simile a uno standard, ma anche in questo caso, di solito è costruito per piattaforma per quanto ne so.
Alcune brevi ricerche su Google rivelano che questo dispositivo ha un chipset video "Mali 400". Ulteriori ricerche portano al sito del codice sorgente del driver GPU Mali. Sono un po' arrugginito sulla mia C, ma l'ho guardata. Sembra che quello che dovresti fare sia, quando crei il driver, dirgli gli indirizzi che deve colpire per parlare con la GPU. In realtà non mi sono immerso troppo a fondo nella fonte, ma non mi sorprenderebbe se non stesse parlando con un autobus, ma semplicemente caricando/archiviando direttamente dall'I/O mappato in memoria.
Quindi non penso che ci sia una risposta generica per tutte le piattaforme ARM, sfortunatamente.