Greetings Samer, I would like to see this patch implemented. Part of the issue I am wrestling with on our AARCH64 platform is how our PCIe's are supported. In our current architecture, we can have up to 6 PCIe's connected through two Switch Logic Interfaces (SLI) that must be programmed correctly. Part of this is the BAR address that is in use which depends heavily on the BAR type. What we are seeing is that the BAR type is being demoted to 32-bit which causes us to program the SLI for 32-bit access. But the PCIe device is 64-bit and attempts to use 64-bit addressing which fails.
A PCD that can be configured to disable the demotion based on the presence of an option ROM would be greatly appreciated. Then the code in DegradeResource() could simply check to see if it needed to enforce this demotion or not. I can understand if this were a legacy BIOS image as this currently seems (to me) to limit option ROM drivers to be 32-bit only. As I stated below, I currently have it commented out and this is allowing our SLI's to be programmed correctly. I'll be glad to review the patch when you have it ready. Thanks, Patrick ________________________________________ From: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com> Sent: Monday, December 14, 2015 3:35 PM To: Mahan, Patrick; edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected Hello Patrick, We ran into the same issue of automatic demoation simply because of the presence of an OptionROM. We believe this is an overly aggressive policy. In fact, I have a patch that I am about to submit that adds a platform PCD to enable/disable this policy. Would like feedback on the idea as well as the patch. Thanks, --Samer -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mahan, Patrick Sent: Monday, December 14, 2015 4:13 PM To: edk2-devel@lists.01.org Subject: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
