drivers - Finding hardware information on linux without lspci

I have an ARM device running ArchLinux. The device doesn't appear to have any PCI bus, even though it has 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 ~]# 

I want to find what other chipsets there are. For example, I know there is a soundcard and video card capable of HDMI. Such a chip wouldn't be put on a USB line.

I looked at the kernel config that is currently working on the device at /proc/config.gz, it lists this:

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

I don't know what AMBA is. A thorough search of google returns this entry in the kernel database but with no actual explanation, other than not to use it if you don't know what you're doing.

Using lshw doesn't show much more either:

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

There appear to be no modules in this kernel loaded:

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

Furthermore, hwinfo doesn't seem to be available:

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

I need to know what chips are used on this system so that I can compile in the right video driver modules, how do I find out what that is on a system with no working lspci?

Here is my official answer after your answering my comments. I could be quite wrong about some of this and welcome corrections.

I'm not sure when Intel began incorporating PCIe (which is a software-compatible extension of PCI) into their CPUs. However, it hasn't been this way for the majority of the time x86 has been around. PCI is really part of the whole "PC platform" which includes a number of other things that are standard and expected, like standard ISA ports/I/O address/IRQs for devices and things like that.

Rollback a bit to before PCI was around - basically, except with the abortive attempt to introduce a PnP standard with ISAPNP, you didn't really "probe" for some devices. You generally would need to assume they existed beforehand. You could, of course, test registers and what not to see if things respond as expected, but you then get in trouble if a different device is there, possibly resulting in hangs, etc. There really wasn't a way to "scan" the ISA bus. Or really any other bus that doesn't support PnP concepts in a standardized way.

One of the things ACPI was supposed to solve was to provide some tables of information that told you what ISA devices were built-in. Even before ACPI the BIOS would be consulted to decide how many floppy drives were in the system. This is why on older systems, even if you have no floppy connected, you'll see an A: drive in Windows if you have the BIOS set to say there is one.

So you may ask how modern OS's determine or interface with a PCI chipset. Most of the time the chipset appears as a device on the PCI bus itself. The PCI interface registers "pre-exist" at known standard locations in the PC platform. A programmatic scan through all device and function slots in the PCI space is possible here. Nothing like that exists for ISA. If the device is on the bus with ISA, it's registers respond when loaded/stored to, and that's it. You can't really talk to the bus itself.

Incidentally, the PCI chipset might even have the capability to control a "PCI-ISA" bridge and bring some of the PnP functionality to the ISA (or now, LPC) bus. On it's own, ISA says you're on your own, though.

There is no such standard platform for ARM. Not yet, anyway. There are many unique platforms that ARM CPUs run on. PCI, I2C and SDIO buses (and possibly more I don't know of) are a commonality between some of them, but again, there are ARM platforms that have none of those. ACPI is not implemented on ARM AFAIK except on the Microsoft Surface RT. Without working with a standardized bus that supports some notion of PnP there really is no way to "probe" for anything. You need to have foreknowledge outside of the system of the hardware that is supposed to be there. U-Boot is a commonly used ARM bootloader that requires support for and to be built for the specific platform it is meant to run on. It's something like a standard, but even then, it's usually built per-platform from my understanding.

Some brief Googling reveals that this device has a "Mali 400" video chipset. Further searching brings the Mali GPU driver source code site. I'm a little rusty on my C, but I looked at it. It seems what you are supposed to do is, when you build the driver, tell it the addresses it needs to hit in order to talk to the GPU. I really didn't immerse myself into the source too deeply but it wouldn't surprise me if it's not talking to a bus, but just loading/storing from memory-mapped I/O directly.

So I don't think there is a generic answer for all ARM platforms, unfortunately.

You can try hwinfo. It's in the 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 can provide some infos

and

cat /proc/devices
find /proc

lshw should worth a try to be rebuilt