@Doron_Holan said:
Unknown PCI device Showing up in device manager means it is a pnp device. It has a hardware id and can have a driver installed against it. Devcon update and all the other pnp driver install tools listed most definitely work in this scenario.
Hmm … so I tried an experiment; I use a Galatea Tagus [ https://numato.com/product/tagus-artix-7-pci-express-development-board/ ] board for FPGA development, and connect it to the PC using a Thunderbolt3 expansion chassis [ https://www.startech.com/en-us/cards-adapters/tb31pciex16 ] using an Asus Alaska class motherboard [ https://www.asus.com/us/Motherboards-Components/Motherboards/Workstation/Pro-WS-W480-ACE/ ] which supports Thunderbolt3. OS is Win10 21H2, Thunderbolt full access was granted in the BIOS
To test the Thunderbolt connection I used a standard PCIe serial card [ https://www.amazon.com/StarTech-com-PCI-Express-Serial-Card/dp/B01N25W4P9 ] which worked as expected; plug the PCIe card into the TB3 chassis, plug in the TB3 connector into the motherboard, Win10 detected the serial card and loaded the stock driver and poof I have two serial ports
I then loaded some PCIe 2.0 IP into the Artix on the Tagus, unplugged the TB3 chassis and replaced the serial card with the Tagus, repowered and replugged the TB3 connection; the PnP stack renumerated upon the TB3 insertion, removed the serial card and detected the Tagus; however, as it has no idea how to interact with the card it placed it in the “Unknown PCI device” section. When I look at the properties of the card I can see a bus and function number but that’s it … again, as expected
I then disconnected the TB3 chassis, powered it down and loaded up a very simple PCIe Firmware image into the Tagus which supports one 4MB BAR, two MSI-X interrupts and one DMA engine with my own VID/ PID and again repowered and replugged … the PnP bus renumerated on TB3 insertion, still placed the card in the “Unknown PCI device” section but now shows the VID/ PID of the card (so I know it’s able to read the ECAM space)
I then took a KMDF PCIe driver which interacts with the Firmware, and attempted the following experiments. To ensure that I wasn’t polluting the universe before the experiment I made an RDriveImage copy of the OS and restored from that copy before each of these experiments, and examined the results of the setup.dev log file in \inf, SecureBoot was off and TestSigning enabled, code Authentication disabled …
pnputil /enable-device /device-id … installs in driver store, sits there quietly, Numato still shows as “Unknown PCI device”, driver failed to start
pnputil /add-device … same as /enable-device, driver failed to load
devcon update … same as pnp-util, driver failed to load
I then ran my Wix custom action DLL for this type of driver which uses the DiXX functions but had the forced renumeration portion commented out and again, in the driver store but still the driver stubbornly failed to load
Finally I uncommented the forced renumeration portion of the custom action DLL, the driver went into the driver store and still failed to load BUT when the forced renumeration occurred the driver was successfully started and PrepareHardware happily showed me a BAR and two MSI-X interrupts, and my scatter/ gather DMA started chugging along …
Thoughts? I would be so totally glad to be able to avoid this dance step, but I can’t afford to reboot the machine on driver installation when a new card is installed …