Finding hardware information on linux without lspci

Solution 1:

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.

Solution 2:

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