From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 4299421954068 for ; Thu, 27 Apr 2017 19:10:20 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 19:10:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,386,1488873600"; d="scan'208";a="1141119438" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 27 Apr 2017 19:10:19 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Apr 2017 19:10:19 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Apr 2017 19:10:18 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.246]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.117]) with mapi id 14.03.0319.002; Fri, 28 Apr 2017 10:10:09 +0800 From: "Zeng, Star" To: Andrew Fish CC: "Kinney, Michael D" , "edk2-devel@lists.01.org" , Tim Lewis , "Gao, Liming" , "Zeng, Star" Thread-Topic: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance Thread-Index: AdK8pzAQEOD5vN6pRr2+K5rEi6Vq8wCAToJwAANxi6AAAIvDEAAAk1/AAACDQ2AAADMmcAACCgMgAAZmNbAAAJJkYAACyJsgACGHa0AAEcFR8AABsp4QAAAe8zD//36qgP//eLRw Date: Fri, 28 Apr 2017 02:10:08 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B87FEB3@shsmsx102.ccr.corp.intel.com> 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> <29F15248-7AFB-406B-A2A0-4C220521C7F6@apple.com> In-Reply-To: <29F15248-7AFB-406B-A2A0-4C220521C7F6@apple.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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 02:10:20 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, It is definitely supported with or without this RFC. No impact to this by t= his RFC. The code path could use GetSku() to be different after an early platform PE= IM called SetSku(). Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andr= ew Fish Sent: Friday, April 28, 2017 10:03 AM To: Zeng, Star Cc: Kinney, Michael D ; edk2-devel@lists.01.org= ; Tim Lewis ; Gao, Liming Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > On Apr 27, 2017, at 6:53 PM, Zeng, Star wrote: >=20 > Tim, >=20 > So, you mean SKU in other scope? >=20 > The title of this RFC is about PCD. Should they be discussed together?=20 > :) >=20 > That relationship between PCD SKUs proposed by this RFC is just used to *= simplify the PCDs configuring for multiple SKUs in DSC*. > How the relationship between PCD SKUs impact other things? >=20 Star, It seems to me the SKU implies what data you get from a PCD, but there may = be code paths that need to be different per SKU. Does the current proposal = support this, or does there need to a manual feature flag/PCD value for cod= e that needs to kept in sync with the SKU value? I guess you could use the SKU support to manually make a PCD that tracks th= e SKU for code paths, but that seems a little redundant? Why would the buil= d system not just automate this?=20 Thanks, Andrew Fish >=20 > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Friday, April 28, 2017 9:43 AM > To: Zeng, Star ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Star -- >=20 > Simply to say: We use SKUs for many more things than PCDs. While EDK2's b= uild system may only use SKU IDs in relation with PCDs, our BIOS uses it fo= r many other things. >=20 > So understanding the relationship between SKUs has an impact (for us) bey= ond what can be decided by the PCD database. >=20 > Tim >=20 > -----Original Message----- > From: Zeng, Star [mailto:star.zeng@intel.com] > Sent: Thursday, April 27, 2017 6:00 PM > To: Tim Lewis ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming ; Zeng, Star=20 > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Could you share more information about the case Hii string packages? >=20 > Like Mike replied with below explanation, the purpose of this RFC is simp= le to extend SKU inheritance in DSC. >=20 > "With this proposal, a relationship between SKUs can be declared in the D= SC 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." >=20 > 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=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Mike -- >=20 > For the one-logo case, yes, that would work. But this is the simplest cas= e. Consider HII string packages. >=20 > Tim >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 5:28 PM > To: Tim Lewis ; Zeng, Star=20 > ; edk2-devel@lists.01.org; Kinney, Michael D=20 > > Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Could you use a PCD (for example a GUID value of an FFS file) for the Log= o, and you could use PcdGet() after SetSku() and the GUID value of the FFS = file with the logo would be returned for the lookup. >=20 > That way, the need for the relationship information at runtime is removed= and you would get the behavior you describe below. >=20 > Mike >=20 >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 >> Of Tim Lewis >> Sent: Wednesday, April 26, 2017 4:06 PM >> To: Kinney, Michael D ; Zeng, Star=20 >> ; edk2-devel@lists.01.org >> Cc: Gao, Liming >> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >>=20 >> Mike -- >>=20 >> 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=20 >> SKU from SKU A is used. And if not from SKU A, then from DEFAULT. >>=20 >> Tim >>=20 >> -----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=20 >> ; edk2- devel@lists.01.org; Kinney, Michael D=20 >> >> Cc: Gao, Liming >> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >>=20 >> Hi Tim, >>=20 >> How would this relationship information be used in a module? >> Do you have an example use case where this relationship information=20 >> could be used from the selected SKU? Maybe there is a different=20 >> method to solve the same problem? >>=20 >> Please also review the 2nd SKU related RFC titled: >>=20 >> [RFC 0/2] PCD: Extended SKU support 2 - sub SKU >>=20 >> This 2nd RFC builds on the first SKU RFC. The SKU inheritance=20 >> relationships are not as straight forward when you add the concept of=20 >> generating all possible combinations of SKUs from multiple subsystems. >>=20 >> Thanks, >>=20 >> Mike >>=20 >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 >>> Of Tim Lewis >>> Sent: Wednesday, April 26, 2017 12:59 PM >>> To: Kinney, Michael D ; Zeng, Star=20 >>> ; edk2-devel@lists.01.org >>> Cc: Gao, Liming >>> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >>>=20 >>> Mike -- >>>=20 >>> So your use case for SetSku() is also what we've used. >>>=20 >>> Generating a simple table that describes the default relationships=20 >>> between SKUs is helpful: >>>=20 >>> DEFAULT >>> A DEFAULT >>> B A DEFAULT >>>=20 >>> This could be a #define in the form of a C UINT32 structure initializer= : >>>=20 >>> #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0 >>>=20 >>> I think that this should be a part of this RFC. >>>=20 >>> ------------- >>> Having said that, we've used multi-SKU for a long time and there are=20 >>> common error cases that could be aided by some tool support. >>>=20 >>> 1) When an image is designed to support SKUs A, B, C (out of a=20 >>> possible set of SKU A-H), but the SKU detected is: G. This is an=20 >>> error condition that is difficult to detect. SetSku() can't do it,=20 >>> because there is no guarantee (today) that the PCD driver knows all=20 >>> possible SKUs, only those that have PCDs associated with them. >>>=20 >>> 2) When C code is designed to run for SKUs A, B, D, H, the image was=20 >>> built for A,B,C and the SKU detected during POST was D. By having a=20 >>> macro that returns whether board X is supported, code which is not=20 >>> used for the current build can be eliminated from the build. For=20 >>> example. #define SKU_NAME_SUPPORTED(sku- >>> identifier) can return FALSE if the SKU associated with=20 >>> sku-identifier is not in the build. Also useful for ASL and VFR. >>>=20 >>> 3) We have also found it useful to extend the build.exe command-line=20 >>> to allow multiple instances of -x to correctly populate the SKUID_IDENT= IFIER. >>>=20 >>> These might be the subject for additional RFCs. >>>=20 >>> Tim >>>=20 >>> -----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=20 >>> ; edk2- devel@lists.01.org; Kinney, Michael D=20 >>> >>> Cc: Gao, Liming >>> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >>>=20 >>> Hi Tim, >>>=20 >>> If multiple SKUs are present in a FW image, in most cases A platform=20 >>> specific PEIM detects what SKU is present and calls SetSku() for the=20 >>> detected SKU. The detection mechanism is typically very HW specific=20 >>> and may involve checking straps, GPIOs, or reading ID values from regis= ters. >>>=20 >>> Before the SKU is set, PCD services access values from the DEFAULT=20 >>> SKU (SKU ID 0). After SetSku() is called, the PCD services access=20 >>> values for that specific SKU. >>>=20 >>> What would be the runtime use case for being able to lookup the=20 >>> relationships between SKUs if in a single boot only the DEFAULT SKU=20 >>> and the one SKU passed to >>> SetSku() are involved? >>>=20 >>> What additions do you suggest to this RFC or to another RFC that=20 >>> builds on top of this RFC? >>>=20 >>> Thanks, >>>=20 >>> Mike >>>=20 >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 >>>> Of Tim Lewis >>>> Sent: Wednesday, April 26, 2017 11:46 AM >>>> To: Kinney, Michael D ; Zeng, Star=20 >>>> ; edk2-devel@lists.01.org >>>> Cc: Gao, Liming >>>> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >>>>=20 >>>> Mike -- >>>>=20 >>>> I am saying that creating a relationship between SKUs that cannot=20 >>>> be determined at runtime is a confusing thing to add to the DSC. >>>>=20 >>>> Tim >>>>=20 >>>> -----Original Message----- >>>> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] >>>> Sent: Wednesday, April 26, 2017 11:40 AM >>>> To: Tim Lewis ; Zeng, Star=20 >>>> ; edk2- devel@lists.01.org; Kinney, Michael D=20 >>>> >>>> Cc: Gao, Liming >>>> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >>>>=20 >>>> Tim, >>>>=20 >>>> This RFC does not change the DEFAULT behavior. If a PCD value=20 >>>> 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=20 >>>> clarifications for the next revision of this RFC. >>>>=20 >>>> This RFC is about reducing the number of PCD statements in a DSC=20 >>>> file if there are multiple SKUs and if there is a relationship=20 >>>> between SKUs that can be used to support that reduction. It is an=20 >>>> optional new feature. You do not have to use it. >>>>=20 >>>> I consider the optimization of the PCD database from a size and=20 >>>> performance perspective a separate topic. The implementation of=20 >>>> this RFC does not require any changes to the PCD database format or=20 >>>> the way PCD value lookup algorithm in the PCD drivers. >>>>=20 >>>> We do recognize that if a large number of SKUs with close=20 >>>> relationships are present in a single FW build, there may be more=20 >>>> optimal ways to store the data and more efficient ways to access=20 >>>> the data. But we would like to consider any work in this area as a=20 >>>> separate work item. Please feel free to add a Bugzilla feature=20 >>>> request if you have specific ideas on how to reduce size and/or=20 >>>> improve >>> performance. >>>>=20 >>>> Given that this RFC is only about a more efficient DSC file implementa= tion. >>>> Can you please describe your concerns with SKUs as they are=20 >>>> currently documented in the EDK II specifications? If you have=20 >>>> additional feature requests for the EDK II SKU behavior, then I=20 >>>> look forward to seeing >>> your detailed proposals. >>>>=20 >>>> Thanks, >>>>=20 >>>> Mike >>>>=20 >>>>> -----Original Message----- >>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 >>>>> Behalf Of Tim Lewis >>>>> Sent: Wednesday, April 26, 2017 11:24 AM >>>>> To: Kinney, Michael D ; Zeng, Star=20 >>>>> ; edk2-devel@lists.01.org >>>>> Cc: Gao, Liming >>>>> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 -=20 >>>>> inheritance >>>>>=20 >>>>> I understand the purpose. Today there is an assumption that IF not=20 >>>>> SKU x, then use SKU DEFAULT. This assumption is used (by us) for=20 >>>>> many purposes other than the PCD database. >>>>>=20 >>>>> I'm confused by your statement that "This RFC has no impact to the=20 >>>>> PCD database or behavior of PCD services." Currently, as I recall,=20 >>>>> there is an optimization that says: only the differences between=20 >>>>> SKU A/SKU B and SKU DEFAULT must exist in the PCD database (SKU A=20 >>>>> and SKU B are sparsely encoded). Are you saying that this proposed=20 >>>>> change will not, in fact, optimize the PCD database for SKU B=20 >>>>> (that it will have the full set of values that differ from SKU >>>>> DEFAULT?) If so, it >>> is a pity. >>>>>=20 >>>>> My other concern is that, we use the defaulting assumption for=20 >>>>> many other >>>> items. >>>>> For example: logos. Leaving it as a build-time construct only=20 >>>>> prevents other components from taking advantage of this knowledge. >>>>>=20 >>>>> Tim >>>>>=20 >>>>> On a separate, but related topic, the term "SKU" has a broad=20 >>>>> connotation, and we use it for many other items board-specific=20 >>>>> at build-time >>>> and run-time (ie. >>>>> Logos). Leaving the defaulting relationship as a build-time=20 >>>>> construct prevents usage at runtime. This is similar run-time=20 >>>>> problem to the case when (a) there are >>>>> 10 SKUs listed in [SkuIds] but (b) 3 are listed in=20 >>>>> SKUID_IDENTIFIERS for this particular build. How, at runtime,=20 >>>>> does C code pick up that SkuA is supported in the current build? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----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=20 >>>>> ; edk2- devel@lists.01.org; Kinney, Michael=20 >>>>> D >>>>> Cc: Gao, Liming >>>>> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >>>>>=20 >>>>> Tim, >>>>>=20 >>>>> Can you please provide more details on your specific concerns=20 >>>>> along with some use cases? >>>>>=20 >>>>> This RFC does not change the SKU feature in EDK II. This RFC=20 >>>>> simply provides a more efficient way for a developer to provide=20 >>>>> PCD values for different SKUs with fewer PCD statements in a DSC file= . >>>>>=20 >>>>> Today, every SKU is a based on the DEFAULT SKU and if a PCD=20 >>>>> requires a different value than the DEFAULT SKU value, then a=20 >>>>> SKU specific PCD statement >>>> is required. >>>>>=20 >>>>> With this proposal, a relationship between SKUs can be declared=20 >>>>> 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=20 >>>>> RFC has no impact to the PCD database or behavior of PCD services. >>>>>=20 >>>>> The example Star provides at the end shows the equivalent set of=20 >>>>> PCD settings using the current EDK II syntax and with this RFC's=20 >>>>> backwards compatible syntax extensions. >>>>>=20 >>>>> One way to think about this RFC is that a DSC file using the=20 >>>>> syntax in this RFC can be converted to a DSC file without the RFC syn= tax. >>>>> In fact, that is what the implementation of this RFC would do to=20 >>>>> build the set of >>>> PCD values for each SKU. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Mike >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 >>>>>> 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,=20 >>>>>> Liming >>>>>> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 -=20 >>>>>> inheritance >>>>>>=20 >>>>>> Star -- >>>>>>=20 >>>>>> This assumes that the SKU ID is only used for PCDs, which is=20 >>>>>> not the case. The SKU ID may be used by other components, and=20 >>>>>> other components may use the >>>>>> 0|DEFAULT rule as well. >>>>>>=20 >>>>>> 1) There is no way to read this defaulting rule at runtime.=20 >>>>>> The information is buried in the PCD database, but not available ext= ernally. >>>>>> 2) There is no way to read the contents of SKUID_IDENTIFIER=20 >>>>>> when multiple SKUs are specified. While more than one SKU can=20 >>>>>> be specified (separated by spaces), there is no way to pass=20 >>>>>> multiple values into build.exe today, nor is there any way to=20 >>>>>> identify which SKUs (out of the total list of SKUs) is=20 >>>>>> supported on one build at >>> runtime. >>>>>>=20 >>>>>> Tim >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 >>>>>> Behalf Of Zeng, Star >>>>>> Sent: Tuesday, April 25, 2017 5:40 AM >>>>>> To: edk2-devel@lists.01.org >>>>>> Cc: Kinney, Michael D ; Zeng, Star=20 >>>>>> ; Gao, Liming >>>>>> Subject: [edk2] [RFC] PCD: Extended SKU support 1 -=20 >>>>>> inheritance >>>>>>=20 >>>>>> - Requirement >>>>>> Simplify the PCDs configuring for multiple SKUs in DSC. >>>>>>=20 >>>>>>=20 >>>>>> - Current limitation >>>>>> Non-DEFAULT SKU could only derive from DEFAULT SKU, but could=20 >>>>>> not derive from another non-DEFAULT SKU. >>>>>> For example below, SkuA and SkuB could only derive from=20 >>>>>> DEFAULT, but SkuB could not derive from SkuA. >>>>>>=20 >>>>>> [SkuIds] >>>>>> 0 | DEFAULT >>>>>> 1 | SkuA >>>>>> 2 | SkuB >>>>>>=20 >>>>>>=20 >>>>>> - Proposal: One non-DEFAULT SKU could be a derivative of=20 >>>>>> another non-DEFAULT >>>>> SKU. >>>>>> This proposal only extends DSC [SkuIds] section syntax and the=20 >>>>>> extension is optional. >>>>>> This proposal keeps the backward compatibility with current SKU usag= e. >>>>>> BaseTools update is needed to support the syntax extension,=20 >>>>>> and no any change in PCD database and driver is required. >>>>>>=20 >>>>>> DSC syntax: >>>>>> [SkuIds] >>>>>> SkuValue|SkuName[|ParentSkuName] >>>>>> SkuValue: integer, 0 is reserved for DEFAULT SKU. >>>>>> SkuName: string >>>>>> ParentSkuName: string, optional, it is new introduced in=20 >>>>>> this proposal and defines which SKU the PCD value will derive=20 >>>>>> from for this SKU. The PCD value will derive from DEFAULT SKU=20 >>>>>> for this SKU if the >>>>> ParentSkuName is absent. >>>>>>=20 >>>>>>=20 >>>>>> - Example: SkuB is a derivative of SkuA, but not a derivative of DEF= AULT. >>>>>>=20 >>>>>> [SkuIds] >>>>>> 0 | DEFAULT >>>>>> 1 | SkuA >>>>>> 2 | SkuB | SkuA >>>>>>=20 >>>>>> [PcdsDynamicDefault.Common.DEFAULT] >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXSignature|"DEFAULT" >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXConfig1|FALSE >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXConfig2|FALSE >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXConfig3|FALSE >>>>>>=20 >>>>>> [PcdsDynamicDefault.Common.SkuA] >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXSignature|"SkuA" >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXConfig1|TRUE >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXConfig2|TRUE >>>>>> # No need statement for PcdXXXConfig3 whose value will=20 >>>>>> derive from DEFAULT SKU and be FLASE. >>>>>>=20 >>>>>> [PcdsDynamicDefault.Common.SkuB] >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" >>>>>> # No need statement for PcdXXXConfig1 and PcdXXXConfig2=20 >>>>>> 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 > _______________________________________________ > 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