Encontrar información de hardware en Linux sin lspci

Tengo un dispositivo ARM que ejecuta ArchLinux. El dispositivo no parece tener ningún bus PCI, aunque tenga 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 ~]# 

Quiero encontrar qué otros conjuntos de chips hay. Por ejemplo, sé que hay una tarjeta de sonido y una tarjeta de video con capacidad para HDMI. Tal chip no se pondría en una línea USB.

Miré la configuración del kernel que actualmente funciona en el dispositivo en /proc/config.gz, enumera esto:

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

No sé qué es AMBA. Una búsqueda exhaustiva de google devuelve esta entrada en la base de datos del kernel pero sin una explicación real, aparte de no usarla si no sabe lo que está haciendo.

Usar lshw tampoco muestra mucho más:

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

Parece que no hay módulos en este kernel cargado:

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

Además, hwinfo no parece estar 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 ~]# 

Necesito saber qué chips se usan en este sistema para poder compilar en los módulos de controlador de video correctos, ¿cómo puedo saber qué hay en un sistema sin lspci que funcione?

Aquí está mi respuesta oficial después de que respondiste mis comentarios. Podría estar bastante equivocado sobre esto y agradecer las correcciones.

No estoy seguro de cuándo Intel comenzó a incorporar PCIe (que es una extensión de PCI compatible con el software) en sus CPU. Sin embargo, no ha sido así la mayoría de las veces x86 ha existido. PCI es realmente parte de toda la "plataforma de PC" que incluye una serie de otras cosas que son estándar y esperadas, como puertos ISA estándar / dirección de E / S / IRQ para dispositivos y cosas por el estilo.

Retroceda un poco antes de que existiera PCI, básicamente, excepto con el intento fallido de introducir un estándar PnP con ISAPNP, realmente no "investigó" algunos dispositivos. Por lo general, debe suponer que existieron de antemano. Podría, por supuesto, probar registros y qué no ver si las cosas responden como se esperaba, pero luego se mete en problemas si hay un dispositivo diferente, lo que puede provocar bloqueos, etc. Realmente no había una manera de "escanear" El bus ISA. O realmente cualquier otro bus que no admita conceptos PnP de manera estandarizada.

Una de las cosas que se suponía que ACPI debía resolver era proporcionar algunas tablas de información que indicaran qué dispositivos ISA estaban integrados. Incluso antes de ACPI, se consultaría al BIOS para decidir cuántas unidades de disquete había en el sistema. Es por eso que en los sistemas más antiguos, incluso si no tiene un disquete conectado, verá una unidad A: en Windows si tiene el BIOS configurado para decir que hay uno.

Por lo tanto, puede preguntar cómo los sistemas operativos modernos determinan o interactúan con un conjunto de chips PCI. La mayoría de las veces el conjunto de chips aparece como un dispositivo en el bus PCI. La interfaz PCI registra "preexistencia" en ubicaciones estándar conocidas en la plataforma de la PC. Aquí es posible un escaneo programático a través de todas las ranuras de dispositivos y funciones en el espacio PCI. Nada de eso existe para ISA. Si el dispositivo está en el bus con ISA, sus registros responden cuando se cargan / almacenan, y eso es todo. Realmente no puedes hablar con el autobús en sí.

Por cierto, el chipset PCI podría incluso tener la capacidad de controlar un puente "PCI-ISA" y llevar parte de la funcionalidad PnP al bus ISA (o ahora, LPC). Sin embargo, ISA dice que está solo.

No existe una plataforma estándar para ARM. No todavía, de todos modos. Hay muchas plataformas únicas en las que se ejecutan CPU ARM. Los buses PCI, I2C y SDIO (y posiblemente más que no conozco) son una característica común entre algunos de ellos, pero de nuevo, hay plataformas ARM que no tienen ninguno de esos. ACPI no se implementa en ARM AFAIK, excepto en Microsoft Surface RT. Sin trabajar con un bus estandarizado que admita alguna noción de PnP, realmente no hay forma de "probar" nada. Debe tener conocimiento previo fuera del sistema del hardware que se supone que debe estar allí. U-Boot es un gestor de arranque ARM de uso común que requiere soporte y debe construirse para la plataforma específica en la que debe ejecutarse. Es algo así como un estándar, pero incluso entonces, '

Algunas breves búsquedas en Google revelan que este dispositivo tiene un conjunto de chips de video "Mali 400". La búsqueda adicional trae el sitio del código fuente del controlador GPU Mali . Estoy un poco oxidado en mi C, pero lo miré. Parece que lo que se supone que debes hacer es, cuando construyas el controlador, dile las direcciones que necesita para poder hablar con la GPU. Realmente no me sumergí demasiado en la fuente, pero no me sorprendería si no está hablando con un autobús, sino solo cargando / almacenando directamente desde E / S mapeadas en memoria.

Por lo tanto, no creo que haya una respuesta genérica para todas las plataformas ARM, desafortunadamente.

Puedes intentarlo hwinfo. Está en los repositorios de 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 puede proporcionar algunas informaciones

y

cat /proc/devices
find /proc

Merece la pena intentar reconstruir lshw