[edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

Fri Feb 18 02:49:50 UTC 2022

> On Feb 17, 2022, at 5:36 PM, Michael D Kinney <michael.d.kinney at intel.com> wrote:
> 
> Hi Andrew,
>  
> I forgot about the library constraints.
>  
> Unless we want to first add a feature to build a library instance for each module type into
> a different build output directory, we cannot support setting a FixedAtBuild PCD for each
> module type.
>  

Mike,

Yea I’m thinking this is a good reason to maybe not add more knobs. 

I was trying to get tricky and have code conditionally use a global so I could use the lib XIP when I shot myself in the foot. 

Thanks,

Andrew Fish

> If you use PatchableInModule, you can post process all the modules to set individual
> module PCD values.  You have to do two steps.  One DSC to build all the modules and
> generate AsBuiltInf.  2nd DSC/FDF that references the AsBuildInfs and sets the 
> PatchableInModule PCD values in the scope of the modules needed.
>  
> The only reason the different ARCHs for PEI and DXE works is because the libs
> for each ARCH are build separately and already have different build output locations.
>  
> Mike
>  
>  
>  
> From: Andrew Fish <afish at apple.com <mailto:afish at apple.com>> 
> Sent: Thursday, February 17, 2022 4:42 PM
> To: devel at edk2.groups.io <mailto:devel at edk2.groups.io>; Oram, Isaac W <isaac.w.oram at intel.com <mailto:isaac.w.oram at intel.com>>
> Cc: Kinney, Michael D <michael.d.kinney at intel.com <mailto:michael.d.kinney at intel.com>>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?
>  
>  
> 
> 
> On Feb 17, 2022, at 4:26 PM, Oram, Isaac W <isaac.w.oram at intel.com <mailto:isaac.w.oram at intel.com>> wrote:
>  
> Andrew,
> 
> It is a reasonable ask, but I lean towards voting no.  We can more or less do the equivalent by breaking a monolithic build into a set of phase specific build/DSC/FDF or something similar.  That seems more flexible anyway.  Maybe we want binaries with settings based on maturity more than phase.  And so on.
> 
> 
> My primary concern that the complexity added to an already complex feature.  PCD have a lot of binary compatibility challenges anyway.  And this doesn't add any that don't already exist, but it does make it a lot easier to introduce a mismatch issue.
> 
>  
> I shot my self in the foot with the Fixed* macro in a library so I did not get the drivers override. So I feel that pain. You need to used the non Fixed form from a lib to get the value from the global produced by the driver. 
> 
> 
> 
> My more recreational question is if this makes sense in most cases, or if there are a limited set of PCD that it makes sense for.  A lot of similar PCD are much more like shared constants and thus it doesn't make a lot of sense for them to vary across executables.  E.G. drivers are asking for problems if they change max string lengths inconsistently. There are definitely more than one PCD where it seems reasonable.  Maybe they are the "wrong" type though.  Maybe they should be a dynamic type if a flexible usage is desired.
> 
>  
> I was trying to have different settings for gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask is regards to the action taken on an ASSERT. 
>  
> To be honest it was not my 1st choice and I was working around some early boot exception handling code not saving the EFI_SYSTEM_CONTEXT and blocking the scheme I was trying to use. 
> 
> 
> 
> Tangentially related, there was some previous work to make macros for phase architectures.
> 
> [Defines]
>  PEI_ARCH                            = IA32
>  DXE_ARCH                            = X64
> 
> Enabling [Components.$(PEI_ARCH)] and [Components.$(DXE_ARCH)]
> 
>  
> In my case PEI_ARCH == DXE_ARCH so this kind of trick is not helpful. The reality is this trick only works for non virtualized X64 platforms and the edk2 supports a lot more flavors of platforms than X64. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2308 <https://bugzilla.tianocore.org/show_bug.cgi?id=2308>
> 
> If we do something with PCD, we should probably try to be consistent with this and maybe extend it or integrate it into DSC syntax.  With standalone MM, it probably makes more sense to have PEI, DXE, and SMM.  RT would also make sense to have different settings.  I have mixed feelings about BDS.  I think it makes sense to see it as a potentially independent phase that isn't currently.  But also probably won't ever be independent from DXE.
> 
> Regards,
> Isaac
> 
> 
> -----Original Message-----
> From: devel at edk2.groups.io <mailto:devel at edk2.groups.io> <devel at edk2.groups.io <mailto:devel at edk2.groups.io>> On Behalf Of Andrew Fish via groups.io <http://groups.io/>
> Sent: Thursday, February 17, 2022 12:22 PM
> To: Kinney, Michael D <michael.d.kinney at intel.com <mailto:michael.d.kinney at intel.com>>
> Cc: devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?
> 
> 
> 
> 
> On Feb 17, 2022, at 10:52 AM, Kinney, Michael D <michael.d.kinney at intel.com <mailto:michael.d.kinney at intel.com>> wrote:
> 
> I agree that your approach is the only way right now.
> 
> Do you have a feature request???
> 
> Well it does seem like a reasonable thing to be able to do? What do other people think?
> 
> I was able to refactor my code and I did not actually end up needing to override every PEIM and the PEI Core.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
> Mike
> 
> 
> -----Original Message-----
> From: Andrew Fish <afish at apple.com <mailto:afish at apple.com>>
> Sent: Wednesday, February 16, 2022 7:26 PM
> To: Kinney, Michael D <michael.d.kinney at intel.com <mailto:michael.d.kinney at intel.com>>
> Cc: devel at edk2.groups.io <mailto:devel at edk2.groups.io>
> Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?
> 
> 
> 
> 
> On Feb 16, 2022, at 2:10 PM, Kinney, Michael D <michael.d.kinney at intel.com <mailto:michael.d.kinney at intel.com>> wrote:
> 
> Hi Andrew,
> 
> Current DSC syntax for platform scoped [PcdsXXX] sections only 
> supports CPU Arch and SKUID.
> 
> So there is no mechanism today to specify different PCD values based 
> on module type.
> 
> You can manage this in the DSC file, but it does require the module 
> scoped <PcdXXX> section for each module INF that requires a 
> different value that the platform scoped [PcdXXX] section.
> 
> 
> Mike,
> 
> That is what I ended up doing, but it required overriding every PEIM and PEI Core. Seemed kind of excessive.
> 
> I think people cheat and use IA32 vs X64 to mean PEI vs. DXE on X64 platforms.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> Mike
> 
> 
> -----Original Message-----
> From: devel at edk2.groups.io <mailto:devel at edk2.groups.io> <devel at edk2.groups.io <mailto:devel at edk2.groups.io>> On Behalf Of 
> Andrew Fish via groups.io <http://groups.io/>
> Sent: Wednesday, February 16, 2022 1:02 PM
> To: edk2-devel-groups-io <devel at edk2.groups.io <mailto:devel at edk2.groups.io>>
> Subject: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?
> 
> I’m trying to have a different platform policy for 
> PcdDebugPropertyMask in PEI and DXE. I can’t figure out how to do without overriding every PEIM that I build?
> 
> My PEI and DXE has the same arch so I can’t use the CPU Arch to tell them apart.
> 
> Is there something I’m missing?
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
>  
>  
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86749): https://edk2.groups.io/g/devel/message/86749
Mute This Topic: https://groups.io/mt/89195478/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20220217/bbf551e4/attachment.htm>