As you can see the command returns, amongst other information, the Vendor ID (VID) and the Device ID (DID) together with a simple generic description of the device.

On Linux distributions, the utility lspci is typically used to view PCI information. This utility uses the pci.ids text-based database to provide descriptions of vendors, devices, and subvendors. It is not a perfect list but it is relatively complete.

Here is an excerpt from pci.ids which details where to get the file and the layout of the file, together with a number of entries:

I decided to try and produce a “better” PCI utility for the UEFI shell – a utility that would use pci.ids to retrieve and display a description for both the VID and the DID of each device found. This blog post details my experiment.

Before you read any further, if you are unfamiliar with the PCI configuration space, you might wish to read this Wikipedia article. A good reference source for Vendor IDs and Device IDs is pcidatabase.com. It is more complete than the data in pci.ids.

The 16-bit VID and DID registers together identify the device (such as a networking chip), and are commonly called the PCI IDs. The VID is allocated by the PCI-SIG. The DID is assigned by the vendor.

The Subsystem Vendor ID (SVID) and the Subsystem ID (SSID) are used to differentiate between the original equipment manufacturer and the implementation manufacturer. If implemented correctly, the VID/DID/SVID/SSID combination provides a 4 tuple that is unique.

A example is useful here. Suppose Kane Security Devices Limited manufactures a PCI-based security board which uses a Intel LAN on Motherboard (LOM). The company is a member of PCI-SIG and has an assigned DID of 0xEEAA (SVIDs come from the DID namespace). Their DID would go into the SVID register in our example. What goes into the Subvendor Device ID field? Well, it can be anything you like. Some people just start at 1 (0 evidently causes problems) and increment the number for each new design.

As usual, it is assumed that you are familiar with the various UEFI specifications and UDK2015 if you are reading this blog post. The above source code is not production quality code and still needs some work to make it more robust. Currently it has no support for displaying SubVendor ID descriptions but the required code to do so can easily be added.

Note that 0xFFFF is the value that is returned on read accesses to PCI configuration space registers of non-existent devices. Hence the test for this value in the above code.

I could also have listed the PCI class code and description for each device but I do not think it adds much value to the output. There are standard classes for every sort of PCI device; for example the class code for a SCSI device is 0x0100.

1 comment to Using PCI.IDS Database to Show PCI Vendor and Device Information in UEFI Shell

I hope I can ask a question regarding your article on converting MBR to GPT. I have followed your steps and everything completes without error. When I reboot Fedora 16 I only get GRUB_ with a flashing underscore but no GRUB boot menu. I have hammered on this for a week and this is where I am. SDA1 is flagged bios boot, SDA2 has the Linux OS and SDA3 is storage.

The original install uses MBR and works fine with a 2TB limit. I am trying to move to GPT to expand the drive to 4TB.