Suchen von Hardwareinformationen unter Linux ohne lspci

Ich habe ein ARM-Gerät, auf dem ArchLinux ausgeführt wird. Das Gerät scheint keinen PCI-Bus zu haben, obwohl es über USB verfügt.

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

Ich möchte herausfinden, welche anderen Chipsätze es gibt. Ich weiß zum Beispiel, dass es eine Soundkarte und eine Grafikkarte gibt, die HDMI unterstützen. Ein solcher Chip würde nicht auf eine USB-Leitung gesteckt werden.

Ich habe mir die Kernel-Konfiguration angesehen, die derzeit auf dem Gerät unter /proc/config.gz ausgeführt wird.

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

Ich weiß nicht, was AMBA ist. Eine gründliche Suche in Google gibt diesen Eintrag in der Kernel-Datenbank zurück, jedoch ohne tatsächliche Erklärung, außer ihn nicht zu verwenden, wenn Sie nicht wissen, was Sie tun.

Die Verwendung von lshw zeigt auch nicht viel mehr:

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

In diesem Kernel sind anscheinend keine Module geladen:

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

Außerdem scheint hwinfo nicht verfügbar zu sein:

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

Ich muss wissen, welche Chips auf diesem System verwendet werden, damit ich die richtigen Grafiktreibermodule kompilieren kann. Wie kann ich herausfinden, was auf einem System ohne funktionierende lspci-Funktion geschieht?

Hier ist meine offizielle Antwort, nachdem Sie meine Kommentare beantwortet haben. Ich könnte mich in einigen Punkten irren und Korrekturen begrüßen.

Ich bin mir nicht sicher, wann Intel begann, PCIe (eine Software-kompatible Erweiterung von PCI) in seine CPUs zu integrieren. Dies war jedoch in den meisten Fällen nicht der Fall. PCI ist wirklich Teil der gesamten "PC-Plattform", die eine Reihe anderer Dinge enthält, die Standard sind und erwartet werden, wie z. B. Standard-ISA-Ports / E / A-Adresse / IRQs für Geräte und dergleichen.

Rollback etwas früher als PCI - im Grunde genommen haben Sie mit Ausnahme des fehlgeschlagenen Versuchs, einen PnP-Standard mit ISAPNP einzuführen, einige Geräte nicht wirklich "getestet". In der Regel müssen Sie davon ausgehen, dass sie bereits vorhanden sind. Sie könnten natürlich Register testen und nicht sehen, ob die Dinge wie erwartet reagieren, aber Sie bekommen dann Probleme, wenn ein anderes Gerät vorhanden ist, was möglicherweise zu Hangs usw. führt. Es gab wirklich keine Möglichkeit zum "Scannen". der ISA Bus. Oder wirklich jeder andere Bus, der PnP-Konzepte nicht standardisiert unterstützt.

Als Lösung sollte ACPI einige Informationstabellen bereitstellen, aus denen hervorgeht, welche ISA-Geräte integriert sind. Noch vor ACPI wurde das BIOS konsultiert, um zu entscheiden, wie viele Diskettenlaufwerke sich im System befinden. Aus diesem Grund wird auf älteren Systemen, auch wenn keine Diskette angeschlossen ist, unter Windows ein Laufwerk A: angezeigt, wenn das BIOS so eingestellt ist, dass es eines gibt.

Sie können sich also fragen, wie moderne Betriebssysteme einen PCI-Chipsatz bestimmen oder mit diesem kommunizieren. Meistens erscheint der Chipsatz als Gerät auf dem PCI-Bus. Die PCI-Schnittstellenregister sind an bekannten Standardpositionen auf der PC-Plattform bereits vorhanden. Hier ist ein programmatisches Durchsuchen aller Geräte- und Funktionssteckplätze im PCI-Raum möglich. Für ISA gibt es so etwas nicht. Wenn sich das Gerät mit ISA auf dem Bus befindet, reagieren seine Register auf das Laden / Speichern, und das war's. Sie können nicht wirklich mit dem Bus selbst sprechen.

Im Übrigen kann der PCI-Chipsatz sogar eine "PCI-ISA" -Brücke steuern und einen Teil der PnP-Funktionalität auf den ISA-Bus (oder jetzt LPC) übertragen. ISA sagt jedoch, dass Sie alleine sind.

Es gibt keine solche Standardplattform für ARM. Jedenfalls noch nicht. Es gibt viele einzigartige Plattformen, auf denen ARM-CPUs ausgeführt werden. PCI-, I2C- und SDIO-Busse (und möglicherweise weitere, die ich nicht kenne) sind eine Gemeinsamkeit zwischen einigen von ihnen, aber es gibt auch ARM-Plattformen, die keine von diesen haben. ACPI ist auf ARM AFAIK nur auf Microsoft Surface RT implementiert. Ohne die Arbeit mit einem standardisierten Bus, der eine Vorstellung von PnP unterstützt, gibt es wirklich keine Möglichkeit, nach irgendetwas zu "suchen". Sie müssen Vorkenntnisse außerhalb des Systems der Hardware haben, die vorhanden sein soll. U-Boot ist ein häufig verwendeter ARM-Bootloader, der Unterstützung für die spezifische Plattform benötigt und für diese erstellt werden muss, auf der er ausgeführt werden soll. Es ist so etwas wie ein Standard, aber selbst dann ist es

Ein kurzes Googeln zeigt, dass dieses Gerät einen "Mali 400" -Videochipsatz hat. Weitere Suche bringt die Mali GPU-Treiber-Quellcode- Site. Ich bin ein bisschen rostig auf meinem C, aber ich habe es angeschaut. Wenn Sie den Treiber erstellen, sollten Sie ihm anscheinend die Adressen mitteilen, die er benötigt, um mit der GPU zu kommunizieren. Ich habe mich wirklich nicht zu tief in die Quelle eingetaucht, aber es würde mich nicht wundern, wenn es nicht um ein Gespräch mit einem Bus geht, sondern nur um direktes Laden / Speichern von speicherabgebildeten E / A.

Leider gibt es keine generische Antwort für alle ARM-Plattformen.

Sie können es versuchen hwinfo. Es ist in den Arch Repos.

$ 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 kann einige Infos liefern

und

cat /proc/devices
find /proc

lshw sollte einen Versuch wert sein, wieder aufgebaut zu werden