Trouver des informations sur le matériel sur Linux sans lspci
J'ai un périphérique ARM exécutant ArchLinux. Le périphérique 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 quels autres chipsets il y a. Par exemple, je sais qu’il existe une carte son et une carte vidéo compatibles HDMI. Une telle puce ne serait pas mise sur une ligne USB.
J'ai examiné la configuration du noyau qui fonctionne actuellement sur le périphérique dans /proc/config.gz. Elle 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 AMBA. Une recherche approfondie de google renvoie cette entrée dans la base de données du noyau, mais sans aucune explication, à part ne pas l'utiliser si vous ne savez pas ce que vous faites.
Utiliser lshw ne montre pas beaucoup plus 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 semble n'y avoir aucun module chargé dans ce noyau:
[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 les modules de pilote vidéo appropriés. Comment savoir ce qu'il en est sur un système sans lspci en fonctionnement?
Voici ma réponse officielle après que vous ayez répondu à mes commentaires. Je peux me tromper à propos de certaines de ces choses et me réjouir des corrections.
Je ne sais pas quand Intel a commencé à incorporer PCIe (une extension de PCI compatible avec les logiciels) dans ses processeurs. Cependant, il n'en a pas été ainsi depuis la majorité du temps x86 a été autour. Le PCI fait vraiment partie de la "plate-forme PC" dans son ensemble, qui comprend un certain nombre d'éléments standard et prévus, tels que l'adresse standard [ISA] _ ports/l'adresse d'E/S/IRQ pour les périphériques, etc.
Revenez un peu en arrière avant que le PCI ne soit utilisé - en gros, sauf avec la tentative avortée d'introduire un standard PnP avec ISAPNP, vous n'avez pas vraiment "sondé" certains périphériques. Vous devez généralement supposer qu’ils existaient auparavant. Vous pouvez, bien sûr, tester les registres et tout ce qui ne va pas voir si les choses réagissent comme prévu, mais vous aurez alors des problèmes si un autre appareil est présent, ce qui peut entraîner des blocages, etc. Il n'y avait vraiment pas de moyen de "scanner" le bus ISA. Ou bien 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 ISA périphériques étaient intégrés. Même avant ACPI, le BIOS serait consulté pour décider du nombre de lecteurs de disquettes présents dans le système. C'est pourquoi, sur les systèmes plus anciens, même si vous n'avez pas de disquette connectée, un lecteur A: apparaît dans Windows si le BIOS est configuré pour indiquer qu'il en existe un.
Vous pouvez donc vous demander comment les OS modernes déterminent ou interfacent avec un chipset PCI. La plupart du temps, le chipset apparaît en tant que périphérique sur le bus PCI lui-même. L’interface PCI enregistre "préexistante" aux emplacements standard connus de la plate-forme PC. Une analyse programmatique de tous les logements et de tous les logements de l’espace PCI est possible ici. Rien de tel n'existe pour ISA. Si le périphérique est sur le bus avec ISA, ses registres répondent quand ils sont chargés/stockés, et c'est tout. Vous ne pouvez pas vraiment parler au bus lui-même.
Incidemment, le jeu de puces 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.
Il n'existe pas de plate-forme standard de ce type pour ARM. Pas encore, en tout cas. Il existe de nombreuses plates-formes uniques sur lesquelles ARM CPU s'exécute. Les bus PCI, I2C et SDIO (et peut-être davantage 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 aucune. ACPI n'est pas implémenté sur ARM AFAIK, sauf sur Microsoft Surface RT. Sans travailler avec un bus normalisé 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 supposé s'y trouver. U-Boot est un chargeur de démarrage communément utilisé par ARM et nécessitant une prise en charge. conçu pour la plate-forme spécifique sur laquelle il est conçu. C'est quelque chose qui ressemble à une norme, mais même dans ce cas, il est généralement construit pour chaque plate-forme d'après ce que j'ai compris.
Une brève recherche sur Google révèle que cet appareil possède un chipset vidéo "Mali 400". Une recherche plus poussée amène le site 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 est, lorsque vous construisez le pilote, de lui indiquer les adresses qu’il doit taper pour pouvoir parler au GPU. Je ne me suis pas vraiment immergé trop profondément dans la source, mais cela ne me surprendrait pas si ce n'est pas de parler à un bus, mais juste de charger/stocker des entrées/sorties mappées en mémoire directement.
Donc, je ne pense pas qu'il existe une réponse générique pour toutes les plateformes ARM, malheureusement.
Vous pouvez essayer hwinfo. C'est dans les dépôts d'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 infos
et
cat /proc/devices
find /proc
lshw devrait valoir la peine d'être reconstruit