All, I am working on writing the UEFI driver for our LiquidIO line of NICs and have run into an issue with the PCI layer that may or may not be contributing.
I am working with our AARCH64 platform, ThunderX and in the handling of the PCIe detection. The code that handles the PCI configuration on ThunderX requires knowing the resource type of a BAR (IO16, IO32, MEM32/PMEM32, MEM64/PMEM64). There is an automatic demotion of BAR types from 64-bit to 32-bit if an option ROM is detected. I am trying to understand the logic behind this as I do not see anything in the PCIe Firmware specification (Section 5) nor the UEFI Specification (Section 13.4.2). However, after inserting some debugging code into the PCI code under MdeModulePkg/Bus/Pci/PciBusDxe I see that my device's BAR goes from a PMEM64 to a MEM32 after calling DegradeResource(). As a result, the BAR type has changed from MEM64/PMEM64 to MEM32/PMEM32 and this is causing some problems with properly configuring the PCI layer to handle devices using 64-bit PCI BARs. I have put a PCIe Analyzer on it and I can see that the memory requests to the PCI device have the incorrect BAR address resulting in the PCI device unable to read from the host. If I modify the call to DegradeResource() to avoid degrading the 64-bit bar to 32-bit bar when an option ROM is detected, then 64-bit devices work correctly. I can see if the option ROM contained a legacy image, but if it does not, or the option ROM is empty or disabled, then why degrade the BAR resource? Thanks for any help understanding this, Patrick Mahan Cavium, Inc. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
