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?
lsmod
et jetez un œil à vos modules existants. De plus, si vous avez un noyau de travail connu avec unconfig
fichier, vous pouvez l'utiliser pour commencer - et rechercher, car il aura déjà les bons modules sélectionnés. M'a été utile pour créer des noyaux personnalisés pour le Guruplug.cat /proc/cpuinfo
Réponses:
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.
la source
Tu peux essayer
hwinfo
. C'est dans les dépôts Arch.la source
dmesg peut fournir quelques informations
et
lshw devrait valoir la peine d'être reconstruit
la source