From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5DA122195406C for ; Thu, 27 Apr 2017 20:25:59 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 20:25:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,386,1488873600"; d="scan'208,217";a="850667956" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by FMSMGA003.fm.intel.com with ESMTP; 27 Apr 2017 20:25:58 -0700 Received: from orsmsx160.amr.corp.intel.com (10.22.226.43) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Apr 2017 20:25:58 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.59]) by ORSMSX160.amr.corp.intel.com ([169.254.13.69]) with mapi id 14.03.0319.002; Thu, 27 Apr 2017 20:25:58 -0700 From: "Kinney, Michael D" To: Tim Lewis , "Zeng, Star" , "edk2-devel@lists.01.org" , "Kinney, Michael D" CC: "Gao, Liming" , "Zeng, Star" Thread-Topic: [RFC] PCD: Extended SKU support 1 - inheritance Thread-Index: AdK8pzAQEOD5vN6pRr2+K5rEi6Vq8wCAToJwAANxi6AAAIvDEAAAk1/AAACDQ2AAADMmcAACCgMgAAZmNbAAAJJkYAACyJsgACGHa0AAEcFR8AABsp4QAAAe8zAAANN9IAACmGFg Date: Fri, 28 Apr 2017 03:25:57 +0000 Message-ID: References: <0C09AFA07DD0434D9E2A0C6AEB0483103B87E776@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5763C0@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576515@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576579@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F57664A@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F57681D@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576D79@msmail.insydesw.com.tw> <0C09AFA07DD0434D9E2A0C6AEB0483103B87FD84@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F57707E@msmail.insydesw.com.tw>, <0C09AFA07DD0434D9E2A0C6AEB0483103B87FE7A@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5770FA@msmail.insydesw.com.tw> In-Reply-To: <7236196A5DF6C040855A6D96F556A53F5770FA@msmail.insydesw.com.tw> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjE4YmZkYjUtZGQxZC00NjNjLThiNGUtMTE2ZjA1OGM5YjU2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InhEQXJZcUs3NUhuQktaUjdRRjZ4c3h3NThlMkFXeUUzWFpYWkJjSUp4WWs9In0= dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [RFC] PCD: Extended SKU support 1 - inheritance X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 03:25:59 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Star, The 2nd RFC for SKUs add some autogen to support setting the SKU from a pla= tform PEIM. We should consider additional autogen that allows a module to determine the= relationships between SKUs. This additional autogen is not required for t= he PCD part of the proposal, but could be used by other components. Mike From: Tim Lewis [mailto:tim.lewis@insyde.com] Sent: Thursday, April 27, 2017 7:09 PM To: Zeng, Star ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Gao, Liming ; Zeng, Star Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Start, The RFC adds a new mechanism for expressing a relationship between SKUs. Th= e [SkuIds] section is not tied to PCDs. The RFC wants to use this relationship to simplify PCD definitions in the D= SC file. Fine. But SkuId relationships are not exclusive to PCDs. There are= other places where such information can be used. Therefore, publishing thi= s information so that it can be used by other runtime agents besides the. P= CD driver makes sense. Many of these have nothing to do with EDK, but have = to do with OEM designs. Thanks, Tim Sent from my Windows 10 phone From: Zeng, Star Sent: Thursday, April 27, 2017 6:53 PM To: Tim Lewis; Kinney, Michael D; edk2-devel@lists.01.org Cc: Gao, Liming; Zeng, Star Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, So, you mean SKU in other scope? The title of this RFC is about PCD. Should they be discussed together? :) That relationship between PCD SKUs proposed by this RFC is just used to *si= mplify the PCDs configuring for multiple SKUs in DSC*. How the relationship between PCD SKUs impact other things? Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tim = Lewis Sent: Friday, April 28, 2017 9:43 AM To: Zeng, Star >; Kinney, M= ichael D >; e= dk2-devel@lists.01.org Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance Star -- Simply to say: We use SKUs for many more things than PCDs. While EDK2's bui= ld system may only use SKU IDs in relation with PCDs, our BIOS uses it for = many other things. So understanding the relationship between SKUs has an impact (for us) beyon= d what can be decided by the PCD database. Tim -----Original Message----- From: Zeng, Star [mailto:star.zeng@intel.com] Sent: Thursday, April 27, 2017 6:00 PM To: Tim Lewis >; Kinney, = Michael D >; = edk2-devel@lists.01.org Cc: Gao, Liming >; Zeng, = Star > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, Could you share more information about the case Hii string packages? Like Mike replied with below explanation, the purpose of this RFC is simple= to extend SKU inheritance in DSC. "With this proposal, a relationship between SKUs can be declared in the DSC= file, so SKUs can inherit PCD values from other SKUs. This inheritance is= limited to the scope of the DSC file. This RFC has no impact to the PCD d= atabase or behavior of PCD services." Thanks, Star -----Original Message----- From: Tim Lewis [mailto:tim.lewis@insyde.com] Sent: Friday, April 28, 2017 12:28 AM To: Kinney, Michael D >; Zeng, Star >; e= dk2-devel@lists.01.org Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Mike -- For the one-logo case, yes, that would work. But this is the simplest case.= Consider HII string packages. Tim -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] Sent: Wednesday, April 26, 2017 5:28 PM To: Tim Lewis >; Zeng, St= ar >; edk2-devel@lists.01.o= rg; Kinney, Michael D > Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, Could you use a PCD (for example a GUID value of an FFS file) for the Logo,= and you could use PcdGet() after SetSku() and the GUID value of the FFS fi= le with the logo would be returned for the lookup. That way, the need for the relationship information at runtime is removed a= nd you would get the behavior you describe below. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Tim Lewis > Sent: Wednesday, April 26, 2017 4:06 PM > To: Kinney, Michael D >; Zeng, Star > >; edk2-devel@lists.01.or= g > Cc: Gao, Liming > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > Mike -- > > We select logos for SKU C (which is listed as having SKU A and > DEFAULT) as its antecedents. If SKU C does not have a logo, then the > SKU from SKU A is used. And if not from SKU A, then from DEFAULT. > > Tim > > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 3:57 PM > To: Tim Lewis >; Zeng, = Star > >; edk2- devel@lists.01.o= rg; Kinney, Michael D > > > Cc: Gao, Liming > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > Hi Tim, > > How would this relationship information be used in a module? > Do you have an example use case where this relationship information > could be used from the selected SKU? Maybe there is a different > method to solve the same problem? > > Please also review the 2nd SKU related RFC titled: > > [RFC 0/2] PCD: Extended SKU support 2 - sub SKU > > This 2nd RFC builds on the first SKU RFC. The SKU inheritance > relationships are not as straight forward when you add the concept of > generating all possible combinations of SKUs from multiple subsystems. > > Thanks, > > Mike > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf > > Of Tim Lewis > > Sent: Wednesday, April 26, 2017 12:59 PM > > To: Kinney, Michael D >; Zeng, Star > > >; edk2-devel@lists.01.= org > > Cc: Gao, Liming > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > > > Mike -- > > > > So your use case for SetSku() is also what we've used. > > > > Generating a simple table that describes the default relationships > > between SKUs is helpful: > > > > DEFAULT > > A DEFAULT > > B A DEFAULT > > > > This could be a #define in the form of a C UINT32 structure initializer= : > > > > #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0 > > > > I think that this should be a part of this RFC. > > > > ------------- > > Having said that, we've used multi-SKU for a long time and there are > > common error cases that could be aided by some tool support. > > > > 1) When an image is designed to support SKUs A, B, C (out of a > > possible set of SKU A-H), but the SKU detected is: G. This is an > > error condition that is difficult to detect. SetSku() can't do it, > > because there is no guarantee (today) that the PCD driver knows all > > possible SKUs, only those that have PCDs associated with them. > > > > 2) When C code is designed to run for SKUs A, B, D, H, the image was > > built for A,B,C and the SKU detected during POST was D. By having a > > macro that returns whether board X is supported, code which is not > > used for the current build can be eliminated from the build. For > > example. #define SKU_NAME_SUPPORTED(sku- > > identifier) can return FALSE if the SKU associated with > > sku-identifier is not in the build. Also useful for ASL and VFR. > > > > 3) We have also found it useful to extend the build.exe command-line > > to allow multiple instances of -x to correctly populate the SKUID_IDENT= IFIER. > > > > These might be the subject for additional RFCs. > > > > Tim > > > > -----Original Message----- > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > Sent: Wednesday, April 26, 2017 12:04 PM > > To: Tim Lewis >; Zeng= , Star > > >; edk2- devel@lists.01= .org; Kinney, Michael D > > > > > Cc: Gao, Liming > > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > Hi Tim, > > > > If multiple SKUs are present in a FW image, in most cases A platform > > specific PEIM detects what SKU is present and calls SetSku() for the > > detected SKU. The detection mechanism is typically very HW specific > > and may involve checking straps, GPIOs, or reading ID values from regis= ters. > > > > Before the SKU is set, PCD services access values from the DEFAULT > > SKU (SKU ID 0). After SetSku() is called, the PCD services access > > values for that specific SKU. > > > > What would be the runtime use case for being able to lookup the > > relationships between SKUs if in a single boot only the DEFAULT SKU > > and the one SKU passed to > > SetSku() are involved? > > > > What additions do you suggest to this RFC or to another RFC that > > builds on top of this RFC? > > > > Thanks, > > > > Mike > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On > > > Behalf Of Tim Lewis > > > Sent: Wednesday, April 26, 2017 11:46 AM > > > To: Kinney, Michael D >; Zeng, Star > > > >; edk2-devel@lists.0= 1.org > > > Cc: Gao, Liming > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - > > > inheritance > > > > > > Mike -- > > > > > > I am saying that creating a relationship between SKUs that cannot > > > be determined at runtime is a confusing thing to add to the DSC. > > > > > > Tim > > > > > > -----Original Message----- > > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > > Sent: Wednesday, April 26, 2017 11:40 AM > > > To: Tim Lewis >; Ze= ng, Star > > > >; edk2- devel@lists.= 01.org; Kinney, Michael D > > > > > > > Cc: Gao, Liming > > > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > Tim, > > > > > > This RFC does not change the DEFAULT behavior. If a PCD value > > > override is not provided in a SKU, then the DEFAULT value is used. > > > If this is not how you interpret the RFC, then please provide some > > > clarifications for the next revision of this RFC. > > > > > > This RFC is about reducing the number of PCD statements in a DSC > > > file if there are multiple SKUs and if there is a relationship > > > between SKUs that can be used to support that reduction. It is an > > > optional new feature. You do not have to use it. > > > > > > I consider the optimization of the PCD database from a size and > > > performance perspective a separate topic. The implementation of > > > this RFC does not require any changes to the PCD database format > > > or the way PCD value lookup algorithm in the PCD drivers. > > > > > > We do recognize that if a large number of SKUs with close > > > relationships are present in a single FW build, there may be more > > > optimal ways to store the data and more efficient ways to access > > > the data. But we would like to consider any work in this area as > > > a separate work item. Please feel free to add a Bugzilla feature > > > request if you have specific ideas on how to reduce size and/or > > > improve > > performance. > > > > > > Given that this RFC is only about a more efficient DSC file implement= ation. > > > Can you please describe your concerns with SKUs as they are > > > currently documented in the EDK II specifications? If you have > > > additional feature requests for the EDK II SKU behavior, then I > > > look forward to seeing > > your detailed proposals. > > > > > > Thanks, > > > > > > Mike > > > > > > > -----Original Message----- > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On > > > > Behalf Of Tim Lewis > > > > Sent: Wednesday, April 26, 2017 11:24 AM > > > > To: Kinney, Michael D >; Zeng, Star > > > > >; edk2-devel@lists= .01.org > > > > Cc: Gao, Liming > > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - > > > > inheritance > > > > > > > > I understand the purpose. Today there is an assumption that IF > > > > not SKU x, then use SKU DEFAULT. This assumption is used (by us) > > > > for many purposes other than the PCD database. > > > > > > > > I'm confused by your statement that "This RFC has no impact to > > > > the PCD database or behavior of PCD services." Currently, as I > > > > recall, there is an optimization that says: only the differences > > > > between SKU A/SKU B and SKU DEFAULT must exist in the PCD > > > > database (SKU A and SKU B are sparsely encoded). Are you saying > > > > that this proposed change will not, in fact, optimize the PCD > > > > database for SKU B (that it will have the full set of values > > > > that differ from SKU > > > > DEFAULT?) If so, it > > is a pity. > > > > > > > > My other concern is that, we use the defaulting assumption for > > > > many other > > > items. > > > > For example: logos. Leaving it as a build-time construct only > > > > prevents other components from taking advantage of this knowledge. > > > > > > > > Tim > > > > > > > > On a separate, but related topic, the term "SKU" has a broad > > > > connotation, and we use it for many other items board-specific > > > > at build-time > > > and run-time (ie. > > > > Logos). Leaving the defaulting relationship as a build-time > > > > construct prevents usage at runtime. This is similar run-time > > > > problem to the case when (a) there are > > > > 10 SKUs listed in [SkuIds] but (b) 3 are listed in > > > > SKUID_IDENTIFIERS for this particular build. How, at runtime, > > > > does C code pick up that SkuA is supported in the current build? > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > > > Sent: Wednesday, April 26, 2017 11:05 AM > > > > To: Tim Lewis >; = Zeng, Star > > > > >; edk2- devel@list= s.01.org; Kinney, Michael > > > > D > > > > > Cc: Gao, Liming > > > > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > > > Tim, > > > > > > > > Can you please provide more details on your specific concerns > > > > along with some use cases? > > > > > > > > This RFC does not change the SKU feature in EDK II. This RFC > > > > simply provides a more efficient way for a developer to provide > > > > PCD values for different SKUs with fewer PCD statements in a DSC fi= le. > > > > > > > > Today, every SKU is a based on the DEFAULT SKU and if a PCD > > > > requires a different value than the DEFAULT SKU value, then a > > > > SKU specific PCD statement > > > is required. > > > > > > > > With this proposal, a relationship between SKUs can be declared > > > > in the DSC file, so SKUs can inherit PCD values from other SKUs. > > > > This inheritance is limited to the scope of the DSC file. This > > > > RFC has no impact to the PCD database or behavior of PCD services. > > > > > > > > The example Star provides at the end shows the equivalent set of > > > > PCD settings using the current EDK II syntax and with this RFC's > > > > backwards compatible syntax extensions. > > > > > > > > One way to think about this RFC is that a DSC file using the > > > > syntax in this RFC can be converted to a DSC file without the RFC s= yntax. > > > > In fact, that is what the implementation of this RFC would do to > > > > build the set of > > > PCD values for each SKU. > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On > > > > > Behalf Of Tim Lewis > > > > > Sent: Wednesday, April 26, 2017 9:21 AM > > > > > To: Zeng, Star >;= edk2-devel@lists.01.org > > > > > Cc: Kinney, Michael D >; Gao, > > > > > Liming > > > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - > > > > > inheritance > > > > > > > > > > Star -- > > > > > > > > > > This assumes that the SKU ID is only used for PCDs, which is > > > > > not the case. The SKU ID may be used by other components, and > > > > > other components may use the > > > > > 0|DEFAULT rule as well. > > > > > > > > > > 1) There is no way to read this defaulting rule at runtime. > > > > > The information is buried in the PCD database, but not available = externally. > > > > > 2) There is no way to read the contents of SKUID_IDENTIFIER > > > > > when multiple SKUs are specified. While more than one SKU can > > > > > be specified (separated by spaces), there is no way to pass > > > > > multiple values into build.exe today, nor is there any way to > > > > > identify which SKUs (out of the total list of SKUs) is > > > > > supported on one build at > > runtime. > > > > > > > > > > Tim > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On > > > > > Behalf Of Zeng, Star > > > > > Sent: Tuesday, April 25, 2017 5:40 AM > > > > > To: edk2-devel@lists.01.org > > > > > Cc: Kinney, Michael D >; Zeng, Star > > > > > >; Gao, Liming > > > > > > Subject: [edk2] [RFC] PCD: Extended SKU support 1 - > > > > > inheritance > > > > > > > > > > - Requirement > > > > > Simplify the PCDs configuring for multiple SKUs in DSC. > > > > > > > > > > > > > > > - Current limitation > > > > > Non-DEFAULT SKU could only derive from DEFAULT SKU, but could > > > > > not derive from another non-DEFAULT SKU. > > > > > For example below, SkuA and SkuB could only derive from > > > > > DEFAULT, but SkuB could not derive from SkuA. > > > > > > > > > > [SkuIds] > > > > > 0 | DEFAULT > > > > > 1 | SkuA > > > > > 2 | SkuB > > > > > > > > > > > > > > > - Proposal: One non-DEFAULT SKU could be a derivative of > > > > > another non-DEFAULT > > > > SKU. > > > > > This proposal only extends DSC [SkuIds] section syntax and the > > > > > extension is optional. > > > > > This proposal keeps the backward compatibility with current SKU u= sage. > > > > > BaseTools update is needed to support the syntax extension, > > > > > and no any change in PCD database and driver is required. > > > > > > > > > > DSC syntax: > > > > > [SkuIds] > > > > > SkuValue|SkuName[|ParentSkuName] > > > > > SkuValue: integer, 0 is reserved for DEFAULT SKU. > > > > > SkuName: string > > > > > ParentSkuName: string, optional, it is new introduced in > > > > > this proposal and defines which SKU the PCD value will derive > > > > > from for this SKU. The PCD value will derive from DEFAULT SKU > > > > > for this SKU if the > > > > ParentSkuName is absent. > > > > > > > > > > > > > > > - Example: SkuB is a derivative of SkuA, but not a derivative of = DEFAULT. > > > > > > > > > > [SkuIds] > > > > > 0 | DEFAULT > > > > > 1 | SkuA > > > > > 2 | SkuB | SkuA > > > > > > > > > > [PcdsDynamicDefault.Common.DEFAULT] > > > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"DEFAULT" > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|FALSE > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|FALSE > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig3|FALSE > > > > > > > > > > [PcdsDynamicDefault.Common.SkuA] > > > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"SkuA" > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|TRUE > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|TRUE > > > > > # No need statement for PcdXXXConfig3 whose value will > > > > > derive from DEFAULT SKU and be FLASE. > > > > > > > > > > [PcdsDynamicDefault.Common.SkuB] > > > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" > > > > > # No need statement for PcdXXXConfig1 and PcdXXXConfig2 > > > > > whose values will derive from SkuA SKU and be TRUE. > > > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig3|TRUE > > > > > _______________________________________________ > > > > > 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 > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel