Mike, The issue is that even with Legacy OptionROM, most adapters that advertise 64bit MMIO capability actually support it. We have seen instances of specific adapters/classes of adapters that don't work unless they get degeaded, but that is not usually following the generic pattern of the presence of a Legacy option ROM.
In fact, I am working on a seperate patch to allow a platform library of implementing special degradation rules for specific cards (could be a black list implementation for instance). That would be completely up to the platform to decide, with EDK2 providing a NULL library call. We could also move the optionROM check to the platform library if you prefer. What do you think? Thanks Samer -----Original Message----- From: Kinney, Michael D [michael.d.kin...@intel.com] Received: Tuesday, 15 Dec 2015, 6:54PM To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]; Mahan, Patrick [patrick.ma...@caviumnetworks.com]; edk2-devel@lists.01.org [edk2-devel@lists.01.org]; Kinney, Michael D [michael.d.kin...@intel.com] Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected Samer, Do you think it makes sense to add code to check to see if legacy option ROM image is present in the option ROM BAR and only degrade if that type of image is found. That could avoid the introduction of a new PCD. Thanks, Mike > -----Original Message----- > From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj- > mahm...@hpe.com] > Sent: Tuesday, December 15, 2015 10:31 AM > To: Mahan, Patrick <patrick.ma...@caviumnetworks.com>; edk2- > de...@lists.01.org; Kinney, Michael D > <michael.d.kin...@intel.com> > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com> > Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when > an option ROM is detected > > Patrick, > The Patch was submitted to EDK2 list yesterday. Look for subject > line: > > [PATCH] MdePkg: Add PcdPciDegradeIfOptionRomPresent PCD for PCI > resource degradation policy > > Please review. > > I also CC'd Mike Kinney on the review. > > Thanks, > --Samer > > > -----Original Message----- > From: Mahan, Patrick [mailto:patrick.ma...@caviumnetworks.com] > Sent: Tuesday, December 15, 2015 12:27 PM > To: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; edk2- > de...@lists.01.org > Subject: Re: [edk2] Regarding the demotion of 64-bit BARs when > an option ROM is detected > > 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
