Znajdowanie informacji o sprzęcie w systemie Linux bez lspci

Mam urządzenie ARM z ArchLinux. Wygląda na to, że urządzenie nie ma żadnej magistrali PCI, mimo że ma 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 ~]# 

Chcę dowiedzieć się, jakie są inne chipsety. Na przykład wiem, że istnieje karta dźwiękowa i karta wideo obsługująca HDMI. Taki układ nie zostałby umieszczony na linii USB.

Spojrzałem na konfigurację jądra, która obecnie działa na urządzeniu na /proc/config.gz, wyświetla to:

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

Nie wiem co to jest AMBA. Dokładne wyszukiwanie w Google zwraca ten wpis w bazie danych jądra, ale bez faktycznego wyjaśnienia, oprócz tego, że nie należy go używać, jeśli nie wiesz, co robisz.

Korzystanie z lshw nie pokazuje też więcej:

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

Wygląda na to, że w tym jądrze nie ma modułów:

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

Co więcej, hwinfo nie wydaje się być dostępny:

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

Muszę wiedzieć, jakie układy są używane w tym systemie, abym mógł skompilować odpowiednie moduły sterowników wideo. Jak mogę dowiedzieć się, co to jest w systemie bez działającego lspci?

Oto moja oficjalna odpowiedź po udzieleniu odpowiedzi na moje komentarze. Mogę się trochę mylić, jeśli chodzi o niektóre z nich, i z zadowoleniem przyjmuję poprawki.

Nie jestem pewien, kiedy Intel zaczął włączać PCIe (które jest zgodnym z oprogramowaniem rozszerzeniem PCI) do swoich procesorów. Jednak tak się nie stało przez większość czasu, gdy istniało x86. PCI jest naprawdę częścią całej „platformy PC”, która obejmuje szereg innych rzeczy, które są standardowe i oczekiwane, takie jak standardowe porty ISA / adres I / O / IRQ dla urządzeń i tym podobne.

Cofnijmy się nieco wcześniej, zanim pojawiło się PCI - w zasadzie, z wyjątkiem nieudanej próby wprowadzenia standardu PnP z ISAPNP, tak naprawdę nie „sondowałeś” niektórych urządzeń. Zasadniczo należy założyć, że istniały wcześniej. Możesz oczywiście testować rejestry i nie sprawdzać, czy wszystko reaguje zgodnie z oczekiwaniami, ale wtedy masz kłopoty, jeśli jest tam inne urządzenie, co może powodować zawieszanie się itp. Naprawdę nie było sposobu na „skanowanie” autobus ISA. A tak naprawdę każda inna magistrala, która nie obsługuje koncepcji PnP w znormalizowany sposób.

Jedną z rzeczy, które ACPI miało rozwiązać, było udostępnienie tabel z informacjami, które informowały o wbudowanych urządzeniach ISA. Nawet przed ACPI należy skonsultować się z BIOS-em, aby zdecydować, ile stacji dyskietek znajduje się w systemie. Dlatego na starszych systemach, nawet jeśli nie masz podłączonej dyskietki, zobaczysz napęd A: w systemie Windows, jeśli masz ustawiony system BIOS, który mówi, że taki jest.

Możesz więc zapytać, w jaki sposób nowoczesne systemy operacyjne określają interfejs z chipsetem PCI. Przez większość czasu chipset pojawia się jako urządzenie na samej szynie PCI. Interfejs PCI rejestruje „wstępnie” w znanych standardowych lokalizacjach na platformie PC. Możliwe jest tutaj programowe skanowanie wszystkich gniazd urządzeń i funkcji w przestrzeni PCI. Dla ISA nic takiego nie istnieje. Jeśli urządzenie znajduje się w magistrali z ISA, to rejestruje odpowiedź po załadowaniu / zapisaniu i to wszystko. Naprawdę nie możesz rozmawiać z samym autobusem.

Nawiasem mówiąc, chipset PCI może nawet mieć możliwość sterowania mostkiem „PCI-ISA” i wprowadzenia niektórych funkcji PnP do magistrali ISA (lub teraz LPC). ISA twierdzi jednak, że jesteś sam.

Nie ma takiej standardowej platformy dla ARM. W każdym razie jeszcze nie. Istnieje wiele unikalnych platform, na których działają procesory ARM. Magistrale PCI, I2C i SDIO (i być może więcej nie wiem) są wspólne dla niektórych z nich, ale znowu istnieją platformy ARM, które nie mają żadnej z nich. Interfejs ACPI nie jest zaimplementowany w ARM AFAIK, z wyjątkiem Microsoft Surface RT. Bez pracy ze znormalizowaną magistralą, która obsługuje pewne pojęcie PnP, naprawdę nie ma możliwości „sondowania” niczego. Musisz mieć wcześniejszą wiedzę poza systemem sprzętu, który powinien tam być. U-Boot to powszechnie używany moduł ładujący ARM, który wymaga wsparcia i musi być zbudowany na konkretną platformę, na której ma działać. To coś w stylu standardu, ale nawet wtedy

Niektóre krótkie informacje z Google ujawniają, że to urządzenie ma mikroukład wideo „Mali 400”. Dalsze wyszukiwanie przynosi stronę z kodem źródłowym sterownika Mali GPU . Jestem trochę zardzewiały na moim C, ale spojrzałem na to. Wygląda na to, że powinieneś po zbudowaniu sterownika powiedzieć mu, jakie adresy musi trafić, aby porozmawiać z GPU. Naprawdę nie zanurzyłem się zbyt głęboko w źródle, ale nie zaskoczyłoby mnie to, gdyby nie rozmawiał z autobusem, a jedynie ładował / zapisywał bezpośrednio z I / O zamapowanego w pamięci.

Więc nie sądzę, że istnieje ogólna odpowiedź dla wszystkich platform ARM, niestety.

Można spróbować hwinfo. Jest w repozytoriach 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 może dostarczyć kilka informacji

i

cat /proc/devices
find /proc

Warto spróbować odbudować lshw