Trovare informazioni hardware su linux senza lspci

Ho un dispositivo ARM con ArchLinux. Il dispositivo non sembra avere alcun bus PCI, anche se ha USB.

[root@alarm ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
[root@alarm ~]# lspci
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.
[root@alarm ~]# 

Voglio trovare quali altri chipset ci sono. Ad esempio, so che esiste una scheda audio e una scheda video in grado di HDMI. Un tale chip non verrebbe messo su una linea USB.

Ho guardato la configurazione del kernel che sta attualmente lavorando sul dispositivo in /proc/config.gz, che elenca questo:

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set

Non so cosa sia AMBA. Una ricerca approfondita di google restituisce questa voce nel database del kernel ma senza una vera spiegazione, se non quella di non usarla se non sai cosa stai facendo.

L'uso di lshw non mostra molto di più:

[root@alarm ~]# lshw
alarm                     
    description: Computer
    width: 32 bits
  *-core
       description: Motherboard
       physical id: 0
     *-memory
          description: System memory
          physical id: 0
          size: 307MiB
     *-cpu
          physical id: 1
          bus info: cpu@0
          size: 1008MHz
          capacity: 1008MHz
          capabilities: cpufreq
  *-network
       description: Ethernet interface
       physical id: 1
       logical name: eth0
       serial: 00:01:02:03:04:05
       size: 10Mbit/s
       capacity: 100Mbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=off broadcast=yes driver=wemac driverversion=1.01 duplex=half ip=192.168.1.1 link=yes multicast=yes port=MII speed=10Mbit/s
[root@alarm ~]# 

Sembra che non ci siano moduli caricati in questo kernel:

[root@alarm ~]# lsmod
Module                  Size  Used by
[root@alarm ~]# 

Inoltre, hwinfo non sembra essere disponibile:

[root@alarm ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 alarm is up to date
 aur is up to date
:: Starting full system upgrade...
 there is nothing to do
[root@alarm ~]# pacman -S hwinfo
error: target not found: hwinfo
[root@alarm ~]# hwinfo
-bash: hwinfo: command not found
[root@alarm ~]# 

Devo sapere quali chip vengono utilizzati su questo sistema in modo da poter compilare i moduli driver video corretti, come faccio a sapere cosa c'è su un sistema senza lspci funzionante?

Ecco la mia risposta ufficiale dopo aver risposto ai miei commenti. Potrei sbagliarmi su alcune di queste e accogliere correzioni.

Non sono sicuro quando Intel abbia iniziato a incorporare PCIe (che è un'estensione PCI compatibile con il software) nelle loro CPU. Tuttavia, non è stato così per la maggior parte delle volte che x86 è stato in circolazione. PCI fa davvero parte dell'intera "piattaforma PC" che include una serie di altre cose che sono standard e previste, come le porte ISA / indirizzo I / O / IRQ standard per dispositivi e cose del genere.

Esegui il rollback un po 'prima che PCI fosse in circolazione - fondamentalmente, tranne con il tentativo fallito di introdurre uno standard PnP con ISAPNP, non hai davvero "sondato" per alcuni dispositivi. Generalmente dovresti presumere che esistessero prima. Potresti, ovviamente, testare i registri e cosa non vedere se le cose rispondono come previsto, ma allora potresti avere problemi se c'è un dispositivo diverso, che potrebbe causare blocchi, ecc. Non c'è davvero un modo per "scansionare" il bus ISA. O qualsiasi altro bus che non supporti i concetti PnP in modo standardizzato.

Una delle cose che ACPI doveva risolvere era quella di fornire alcune tabelle di informazioni che dicessero quali dispositivi ISA erano integrati. Anche prima di ACPI, il BIOS sarebbe stato consultato per decidere quante unità floppy c'erano nel sistema. Questo è il motivo per cui sui sistemi più vecchi, anche se non hai un floppy collegato, vedrai un'unità A: in Windows se hai il BIOS impostato per dire che ce n'è uno.

Quindi potresti chiedere come determinano o si interfacciano i moderni sistemi operativi con un chipset PCI. Il più delle volte il chipset appare come un dispositivo sul bus PCI stesso. L'interfaccia PCI registra "preesistente" in posizioni standard note nella piattaforma PC. Qui è possibile eseguire una scansione programmatica attraverso tutti gli slot dei dispositivi e delle funzioni nello spazio PCI. Niente del genere esiste per ISA. Se il dispositivo si trova 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 sul 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 funzionano le CPU ARM. I bus PCI, I2C e SDIO (e forse altro che non conosco) sono elementi comuni tra alcuni di essi, ma ancora una volta ci sono piattaforme ARM che non ne hanno. ACPI non è implementato su ARM AFAIK ad eccezione di Microsoft Surface RT. Senza lavorare con un bus standardizzato che supporti alcune nozioni di PnP non c'è davvero modo di "sondare" nulla. È necessario avere conoscenza preliminare al di fuori del sistema dell'hardware che dovrebbe essere lì. U-Boot è un bootloader ARM comunemente usato che richiede supporto e deve essere costruito per la piattaforma specifica su cui dovrebbe funzionare. È qualcosa di simile a uno standard, ma anche allora

Alcuni brevi googling rivelano che questo dispositivo ha un chipset video "Mali 400". Ulteriore ricerca porta il sito del codice sorgente del driver GPU Mali . Sono un po 'arrugginito sulla mia C, ma l'ho guardato. Sembra che quello che dovresti fare è, quando costruisci il driver, dirgli gli indirizzi che deve colpire per parlare con la GPU. In realtà non mi sono immerso troppo nella sorgente ma non mi sorprenderebbe se non stesse parlando con un bus, 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.

Si può provare hwinfo. È nei repository Arch.

$ hwinfo --gfxcard
08: PCI 02.0: 0300 VGA compatible controller (VGA)              
[Created at pci.318]
Unique ID: _Znp.jjHn_gm8Jz5
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Model: "Intel VGA compatible controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x0162 
SubVendor: pci 0x1849 "ASRock Incorporation"
SubDevice: pci 0x0162 
Revision: 0x09
Driver: "i915"
Driver Modules: "drm"
Memory Range: 0xf7800000-0xf7bfffff (rw,non-prefetchable)
Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable)
I/O Ports: 0xf000-0xf03f (rw)
IRQ: 57 (6 events)
Module Alias: "pci:v00008086d00000162sv00001849sd00000162bc03sc00i00"
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: "modprobe i915"
Config Status: cfg=new, avail=yes, need=no, active=unknown

Primary display adapter: #8

dmesg può fornire alcune informazioni

e

cat /proc/devices
find /proc

Vale la pena provare a ricostruire lshw