Is there any substitute for `lspci`?

Question

lspci is not implemented in petalinux. So is there any alternative for this? Any file where I can read lspci output?

Answer 1

File /proc/bus/pci/devices might help:

$ cut -f1,2,18 /proc/bus/pci/devices 
0000    808627a0
0008    808627a1        pcieport
00d8    808627d8        snd_hda_intel
00e0    808627d0        pcieport
00e1    808627d2        pcieport
00e2    808627d4        pcieport
00e3    808627d6        pcieport
00e8    808627c8        uhci_hcd
00e9    808627c9        uhci_hcd
00ea    808627ca        uhci_hcd
00eb    808627cb        uhci_hcd
00ef    808627cc        ehci_hcd
00f0    80862448
00f8    808627b9
00f9    808627df        ata_piix
00fa    808627c5        ahci
00fb    808627da        i801_smbus
0100    10027149        radeon
0200    8086109a        e1000e
0300    80864227        iwl3945
1500    104cac56        yenta_cardbus

Folder /sys/bus/pci/devices has even more details but spread wider...

Answer 2

You can get similar information from the sysfs filesystem under (e.g.) /sys/device/pci0000:00; there is also a symlink under /sys/class/pci_bus. I'll discuss that first, since it provides some clues about correspondences to lspci output that you can examine on a system that has lspci in order to familiarize yourself.

Here's some edited lscpi output:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4)
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03)
06:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller

Notice 00:1c. has a .3,.4,.6, and .7, and there is also a 03:00.0, 04:00.0, 06:00.0, and 07:00.0. These correspond -- the later are the devices attached to the former. The symlinks in /sys/class/pci_bus point to nodes in /sys/devices/pci0000:00 like this:

0000:03 -> 0000:00:1c.3
0000:04 -> 0000:00:1c.4
0000:06 -> 0000:00:1c.6
0000:07 -> 0000:00:1c.7

You don't have to think about this too much if you just want information about what's there, but I mention this because these correspondences can get confusing in relation to lspci output.

Inside these nodes (they're directories), you'll find a file called subsystem_device, which contains a 16-bit (4 digit) hex code in text form, e.g. 0x84ca. There are similar hex codes in subsystem_vendor and device, but the later is of no use to us (n.b. it is not a device ID provided by the device, it a label internal to the system) and the former is not specific enough (but it still may be useful, see below).

Since the list of these codes presumably grows all the time, a good place to look them up is an online database. To get a list of all the ones from the example:

> find /sys/devices/pci0000:00 -name subsystem_device -exec cat '{}' \;
0x84ca
0x84ca
0x84ca
0x84ca
0x84ca
0x849c
0x84ca
0x84fb
0x84ca
0x84b7
0x84ca
0x1080
0x84ca
0x850d
0x84ca
0x8488
0x84ca
0x84ca
0x84ca
0x84ca
0x84ca

I've avoided the symlinked directories here in order to use find. Notice 0x084ca is repeated a lot. Looking that up via "Device Search" in the database reveals this is a "450NX PCIset Memory & I/O Controller" from Intel. The reason it is repeated so much is because the other stuff is plugged into it.

Rather than going though all of these, let's take a short cut to figure out what my wifi controller is. /sys/class/net lists 3 symlinks:

em1
lo
wlp6so

Corresponding to the names of the labels used in, e.g., ifconfig output. wlp6so links to pci0000:00/0000:00:1c.6/0000:06:00.0/net/wlp6s0 but this won't help us identify the device. There are two subsystem_device nodes in the tree rooted at pci0000:00/0000:00:1c.6, the first one is 0x84ca (the controller again) and one in the 0000:06:00.0, 0x850d.

This is where we run into the reality of missing entries in the database. There's a form there you can submit information to add to it, but of course that does not help us now.

An online search for "pci 0x850d" turns up a reference to the linux kernel source,¹ since the kernel uses theses codes to load appropriate drivers. This tells us something (it's a wifi chip, ostensibly from ASUSTEK) we could have deduced another way, namely by looking at the subsystem_vendor node in the same directory (Asustek turns out to be in the online database when you do a "Vendor search:" for 0x1043) and considering that this refers to the wifi interface.² There's also a clue about the OEM (original equipment manufacturer) being Atheros, since this is the source code for the ath9k driver -- and indeed, lscpi listed 06:00 as a "Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)".

Without looking at the source for lspci, I would presume it queries the devices directly for a string. The kernel probably does not do this since it uses the unique device ID's to load drivers and the information is not of use to it.

---

^{1. A better place to look, based on that discovery, would be using grep -R in the drivers/ directory of the kernel source tree. If you can't find it, there's no driver for it anyway.}

^{2. Of course that wouldn't be as obvious if no driver were loaded and the interface were down, but the ID will still be in /sys/devices/...}