Localizando informações de hardware no linux sem lspci

Eu tenho um dispositivo ARM executando o ArchLinux. O dispositivo não parece ter nenhum barramento PCI, apesar de possuir 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 ~]# 

Eu quero encontrar o que há outros chipsets. Por exemplo, eu sei que há uma placa de som e uma placa de vídeo capazes de HDMI. Esse chip não seria colocado em uma linha USB.

Eu olhei para a configuração do kernel que está atualmente trabalhando no dispositivo em /proc/config.gz, ela lista isto:

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

Não sei o que é o AMBA. Uma pesquisa minuciosa do google retorna essa entrada no banco de dados do kernel, mas sem nenhuma explicação real, exceto para não usá-lo se você não souber o que está fazendo.

O uso do lshw também não mostra muito mais:

[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 não haver módulos neste kernel carregados:

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

Além disso, o hwinfo não parece estar disponível:

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

Preciso saber quais chips são usados ​​neste sistema para que eu possa compilar nos módulos corretos de driver de vídeo. Como descobrir o que há em um sistema sem lspci funcionando?

Aqui está a minha resposta oficial depois de você responder aos meus comentários. Eu poderia estar completamente errado sobre isso e receber as correções.

Não sei ao certo quando a Intel começou a incorporar o PCIe (que é uma extensão compatível com o software do PCI) em suas CPUs. No entanto, não tem sido assim na maioria das vezes que o x86 existe. O PCI é realmente parte de toda a "plataforma de PC", que inclui várias outras coisas que são padrão e esperadas, como portas ISA padrão / endereço de E / S / IRQs para dispositivos e coisas assim.

Retroceda um pouco antes do PCI estar disponível - basicamente, exceto com a tentativa abortada de introduzir um padrão PnP com o ISAPNP, você realmente não "sondou" alguns dispositivos. Você geralmente precisaria assumir que elas existiam antes. Você poderia, é claro, testar os registros e o que não ver se as coisas respondem como o esperado, mas você terá problemas se houver um dispositivo diferente, possivelmente resultando em travamentos, etc. Não havia realmente uma maneira de "digitalizar" o barramento ISA. Ou realmente qualquer outro barramento que não suporte conceitos de PnP de maneira padronizada.

Uma das coisas que a ACPI deveria resolver era fornecer algumas tabelas de informações que informavam quais dispositivos ISA estavam embutidos. Mesmo antes da ACPI, o BIOS seria consultado para decidir quantas unidades de disquete havia no sistema. É por isso que em sistemas mais antigos, mesmo se não houver um disquete conectado, você verá uma unidade A: no Windows se o BIOS estiver configurado para dizer que existe um.

Então você pode perguntar como os sistemas operacionais modernos determinam ou fazem interface com um chipset PCI. Na maioria das vezes, o chipset aparece como um dispositivo no próprio barramento PCI. A interface PCI registra "pré-existe" em locais padrão conhecidos na plataforma do PC. Uma varredura programática através de todos os slots de dispositivos e funções no espaço PCI é possível aqui. Nada disso existe para o ISA. Se o dispositivo estiver no barramento com o ISA, os registradores responderão quando carregados / armazenados, e é isso. Você realmente não pode falar com o próprio ônibus.

Aliás, o chipset PCI pode até ter a capacidade de controlar uma ponte "PCI-ISA" e trazer parte da funcionalidade PnP para o barramento ISA (ou agora, LPC). Por si só, o ISA diz que você está por sua conta.

Não existe uma plataforma padrão para o ARM. Ainda não, pelo menos. Existem muitas plataformas exclusivas nas quais as CPUs ARM são executadas. Os barramentos PCI, I2C e SDIO (e possivelmente mais que eu não conheço) são comuns entre alguns deles, mas, novamente, existem plataformas ARM que não possuem nenhum deles. O ACPI não é implementado no ARM AFAIK, exceto no Microsoft Surface RT. Sem trabalhar com um barramento padronizado que suporte alguma noção de PnP, realmente não há como "sondar" nada. Você precisa ter conhecimento prévio fora do sistema do hardware que deveria estar lá. O U-Boot é um carregador de inicialização ARM comumente usado que requer suporte e é construído para a plataforma específica na qual ele deve ser executado. É algo como um padrão, mas mesmo assim, é '

Alguns estudos no Google revelam que este dispositivo possui um chipset de vídeo "Mali 400". Outras pesquisas trazem o site de código-fonte do driver GPU do Mali . Estou um pouco enferrujado no meu C, mas olhei para ele. Parece que você deve fazer, quando criar o driver, informar os endereços que ele precisa atingir para conversar com a GPU. Eu realmente não mergulhei profundamente na fonte, mas não me surpreenderia se não estivesse falando com um barramento, mas apenas carregando / armazenando diretamente da E / S mapeada na memória.

Infelizmente, acho que não há uma resposta genérica para todas as plataformas ARM.

Você pode tentar hwinfo. Está nos repositórios do 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

O dmesg pode fornecer algumas informações

e

cat /proc/devices
find /proc

lshw deve valer uma tentativa de ser reconstruído