Trouver des informations sur le matériel sous Linux sans lspci

J'ai un périphérique ARM exécutant ArchLinux. L'appareil ne semble pas avoir de bus PCI, même s'il est 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 ~]# 

Je veux trouver d'autres chipsets. Par exemple, je sais qu'il existe une carte son et une carte vidéo compatibles HDMI. Une telle puce ne serait pas placée sur une ligne USB.

J'ai regardé la configuration du noyau qui fonctionne actuellement sur le périphérique à /proc/config.gz, il répertorie ceci:

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

Je ne sais pas ce qu'est l'AMBA. Une recherche approfondie de google renvoie cette entrée dans la base de données du noyau mais sans aucune explication réelle, à part de ne pas l'utiliser si vous ne savez pas ce que vous faites.

L'utilisation de lshw ne montre pas grand-chose non plus:

[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 ~]# 

Il ne semble y avoir aucun module dans ce noyau chargé:

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

De plus, hwinfo ne semble pas être disponible:

[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 ~]# 

J'ai besoin de savoir quelles puces sont utilisées sur ce système pour pouvoir compiler dans les bons modules de pilote vidéo, comment savoir ce que c'est sur un système sans lspci fonctionnel?

Voici ma réponse officielle après avoir répondu à mes commentaires. Je peux me tromper sur certains de ces points et souhaiter la bienvenue aux corrections.

Je ne sais pas quand Intel a commencé à incorporer PCIe (qui est une extension PCI compatible avec les logiciels) dans ses CPU. Cependant, il n'en a pas été ainsi pendant la majorité du temps où x86 existe. PCI fait vraiment partie de l'ensemble de la «plate-forme PC» qui comprend un certain nombre d'autres choses standard et attendues, comme les ports ISA standard / l'adresse d'E / S / IRQ pour les périphériques et des choses comme ça.

Revenez un peu en arrière avant que PCI n'existait - en gros, sauf avec la tentative avortée d'introduire une norme PnP avec ISAPNP, vous n'avez pas vraiment "sondé" certains appareils. Vous devrez généralement supposer qu'ils existaient au préalable. Vous pouvez, bien sûr, tester les registres et ne pas voir si les choses répondent comme prévu, mais vous rencontrez des problèmes si un autre appareil est là, ce qui peut entraîner des blocages, etc. Il n'y avait vraiment pas de moyen de "scanner" le bus ISA. Ou tout autre bus qui ne prend pas en charge les concepts PnP de manière standardisée.

Une des choses que l'ACPI était censé résoudre était de fournir des tableaux d'informations qui vous indiquaient quels périphériques ISA étaient intégrés. Avant ACPI, le BIOS était consulté pour décider du nombre de lecteurs de disquette 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 vous avez le BIOS pour en dire un.

Vous pouvez donc vous demander comment les systèmes d'exploitation modernes déterminent ou 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. L'interface PCI enregistre «préexiste» à des emplacements standard connus de la plate-forme PC. Une analyse programmatique de tous les emplacements de périphériques et de fonctions dans l'espace PCI est possible ici. Rien de tel n'existe pour ISA. Si l'appareil 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.

Soit dit en passant, 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). Seul, ISA dit que vous êtes seul, cependant.

Il n'y a pas une telle plate-forme standard pour ARM. Pas encore en tout cas. Il existe de nombreuses plates-formes uniques sur lesquelles les processeurs ARM s'exécutent. Les bus PCI, I2C et SDIO (et peut-être d'autres que je ne connais pas) sont communs à certains d'entre eux, mais encore une fois, il existe des plates-formes ARM qui n'en ont pas. 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é être là. U-Boot est un chargeur de démarrage ARM couramment utilisé qui nécessite la prise en charge et la construction de la plate-forme spécifique sur laquelle il est censé fonctionner. C'est quelque chose comme une norme, mais même alors, c'est '

Une brève recherche sur Google révèle que cet appareil possède un chipset vidéo "Mali 400". Une recherche plus approfondie amène le site du code source du pilote GPU Mali . Je suis un peu rouillé sur mon C, mais je l'ai regardé. Il semble que ce que vous êtes censé faire, c'est lorsque vous construisez le pilote, dites-lui les adresses qu'il doit atteindre pour parler au GPU. Je ne me suis vraiment pas plongé trop profondément dans la source, mais cela ne me surprendrait pas s'il ne parle pas à un bus, mais simplement en chargeant / stockant 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 plateformes ARM, malheureusement.

Tu peux essayer hwinfo. C'est dans les dépôts 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 peut fournir quelques informations

et

cat /proc/devices
find /proc

lshw devrait valoir la peine d'être reconstruit