Star -- I think that would work. The copy would have to be by GUID/token number/SKU (for DynamicEx) and token number/SKU (for Dynamic)
The downside would be that the PEI copy would have priority, even if the DXE copy were newer. Tim -----Original Message----- From: Zeng, Star [mailto:star.z...@intel.com] Sent: Wednesday, February 17, 2016 6:48 PM To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org Subject: RE: PCD Local Token Numbers in PEI/DXE Could we let PEI PCD database includes all PCDs' information used in PEI phase and DXE PCD database includes all PCDs' information (include PCDs used by both PEI and DXE) used in DXE phase. DXE PCD driver is to sync the value of PCDs used by both PEI and DXE. Thanks, Star -----Original Message----- From: Kinney, Michael D Sent: Thursday, February 18, 2016 1:21 AM To: Zeng, Star; Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D Subject: RE: PCD Local Token Numbers in PEI/DXE Star, I agree if PCDs are added to PEI Database that are also present in DXE Database, there could be a conflict. There are several cases we need to consider to support separate update of PEI and DXE databases: 1) Add one or more PCDs to PEI Database that are not used in DXE Phase 2) Add one or more PCDs to PEI Database that are used in DXE Phase 3) Remove one or more PCDs from PEI Database that are not used in DXE Phase 4) Remove one or more PCDs from PEI Database that are used in DXE Phase 5) Add one or more PCDs to DXE Database that are not used in PEI Phase 6) Add one or more PCDs to DXE Database that are used in PEI Phase 7) Remove one or more PCDs from DXE Database that are not used in PEI Phase 8) Remove one or more PCDs from DXE Database that are used in PEI Phase Case (1), (3), (5), (6), (7), and (8) should be relatively easy to support Case (2) is the one you raised, where there could a conflict in the Default Value, Storage Type, and size. Case (4) is even harder, because DXE Phase depends on PCDs passed up from PEI that are no longer there. This should be an ASSERT()/failure. I also want to emphasis that the PCD database needs to support 3 types of platform builds for PCD types: A) 100% Dynamic PCDs (Usually used for source builds) B) A mix of Dynamic and DynamicEx PCDs (Usually used for source builds with a few pre-built binary modules mixed in) C) 100% DynamicEx PCDs (Used for 100% pre-built binary modules) If we detect case (C), I think we can build the PEI and DXE databases so they do not use local tokens at all and avoid the local token number issue raised by Tim. For (A) and (C), we might consider using 2 different ranges of local token numbers, so the number of local token numbers allocated to PEI and DXE database can change without token number overlaps. Thanks, Mike > -----Original Message----- > From: Zeng, Star > Sent: Sunday, February 14, 2016 9:33 PM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Tim Lewis > <tim.le...@insyde.com>; edk2-devel@lists.01.org > Subject: RE: PCD Local Token Numbers in PEI/DXE > > Mike, > > Could one PCD be accessed using both methods Dynamic and DynamicEx in one > build? > As I know, it could not. > > Another problem is about where the default PCD value stores. > Currently, PEI and PEI+DXE phase consumed PCDs are stored in PEI PCD > database, and only DXE phase consumed PCDs are stored in DXE PCD database. > If the new PEI consumes 4+ PCDs, the 4+ PCDs will be stored in PEI > database, and if DXE also consumes them, the new DXE would not work > with old PEI. And is it a valid case to only update DXE FV? > > > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Kinney, Michael D > Sent: Thursday, February 11, 2016 2:21 AM > To: Tim Lewis; edk2-devel@lists.01.org; Kinney, Michael D > Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE > > Tim, > > All good ideas to evaluate. > > We did design in the Dynamic PCDs with generated local tokens to > minimize the size overhead of the PCD database for source builds. We > can do some size impact analysis of these ideas to see which one makes the > most sense. > > The database is currently optimized for Dynamic PCDs. When a > DynamicEx PCD is used it is internally translated to a Dynamic > request. I think all of the ideas here require this concept to be > reversed. We need to optimized the database for DynamicEx and never > reference Dynamic part of database to process a DynamicEx request. If > Dynamic is used, it can either be internally translated to a DynamicEx > request with a fixed token space guid or be processed as a local > token. In mixed Dynamic/DynamicEx environments, the same PCD may be accessed > using both methods. Current design supports this mixed env, so we need to > make sure that aspect is not broken if we change internal code/database. > > Best regards, > > Mike > > > -----Original Message----- > > From: Tim Lewis [mailto:tim.le...@insyde.com] > > Sent: Wednesday, February 10, 2016 9:50 AM > > To: Kinney, Michael D <michael.d.kin...@intel.com>; > > edk2-devel@lists.01.org > > Subject: RE: PCD Local Token Numbers in PEI/DXE > > > > Mike -- > > > > Yes, we use all DynamicEx PCDs because we use a large number of > > binary deliverables in certain segments. > > > > It would be a much simpler database design if the look up was purely > > a GUID/token number/SkuId look-up (no local token numbers at all). > > The existing Dynamic PCDs could be supported by assigning them a > > single GUID. That is, Dynamic PCDs would be translated up to > > DynamicEx by using gEfiDynamicPcdGuid. Or we could deprecate > > Dynamic. Or make it auto-translate > to DynamicEx. > > > > Tim > > > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Kinney, Michael D > > Sent: Wednesday, February 10, 2016 9:41 AM > > To: Tim Lewis <tim.le...@insyde.com>; edk2-devel@lists.01.org; > > Kinney, Michael D <michael.d.kin...@intel.com> > > Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE > > > > Hi Tim, > > > > Your description looks correct to me. The current design does have > > an assumption that the PCD database used in PEI is aligned with the > > PCD database used in > DXE. > > > > If the number of Dynamic/DynamicEx PCDs used in a platform changes, > > then the PCD database associated with the PCD PEIM and PCD DXE > > Driver both need to be > updated. > > > > I think it would be good to work on a method that allows the PEI > > Database and DXE Database to be updated independently. > > > > In general, if binary modules are used, then Dynamic PCDs can not be > > used. Instead all Dynamic PCDs must be updated to by DynamicEx PCDs. > > That is for binary modules that performs PCD Get/Set operations > > through the PCD > PPI/Protocol. > > > > I think the gap here is that the PCD database does not have a build > > mode that forces use of only DynamicEx (TokenSpaceGuid, TokenNumber) > > for the entire > database contents. > > If we added that build mode (so there are no "local token numbers") > > then the PEI database and DXE database could be updated independently. > > > > This build mode could only be enabled if there are no Dynamic PCDs. > > In fact, this build mode could be automatic if there are no Dynamic PCDs in > > DSC file. > > > > Mike > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On > > > Behalf Of Tim Lewis > > > Sent: Tuesday, February 9, 2016 10:24 AM > > > To: edk2-devel@lists.01.org > > > Subject: [edk2] PCD Local Token Numbers in PEI/DXE > > > > > > We have run into an interesting problem with the PCD database when > > > the PEI and DXE databases were not built at the same time. This > > > happens with boot-block type arrangements. This is not a Dynamic > > > vs. DynamicEx > issue. > > > > > > Short form: > > > > > > > > > 1) The standard PCD database for Dynamic/DynamicEx PCDs is broken > > > into two > > pieces, > > > based on whether the PCD is access by a PEIM, a DXE driver, or both. > > > The pieces are embedded directly into the PCD PEIM and PCD DXE > > > driver that produces > > the PCD services. > > > > > > 2) Each Dynamic/DynamicEx PCD is assigned a unique "local token > > > number" This > > > number is different than the token number which is in the PCD > > > declaration in the .dec file. This number is assigned at build time. > > > > > > 3) If a later version of the DXE PCD driver is a) built in a later > > > codebase > > where > > > there are more or less PEI-access PCDs, but later b) executed with > > > a version of the PEI PCD database from the earlier codebase where > > > there were fewer, it causes a problem. For example, if the new PEI > > > PCD database has 4 more, the new DXE PCD database will start its > > > numbering at +4. But when it is executed with the old PEI PCD > > > database, it will end up looking up the wrong PCD > > > > > > We're not sure what the best course is to solve this. Frankly, the > > > PCD database format is a muddle. We have a temporary work-around, > > > but we're wondering if anyone has thoughts on a good solution. > > > > > > Thanks, > > > > > > Tim > > > _______________________________________________ > > > 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
