Star -- There are many cases where the PEI FV is not updated because it resides in a portion of the flash that is specially protected, often by a pin on the motherboard. In many platforms, this recovery firmware in PEI is never updated throughout the life of the platform. But DXE might be updated many times.
We handle the mismatch case often, for HOBs, etc. We design the HOBs, UEFI variables, etc. in such a way that the detection can be detected or worked-around. But with PCDs, we cannot detect the mismatch without special knowledge, because the PCD driver will return the wrong PCD value. Tim -----Original Message----- From: Zeng, Star [mailto:[email protected]] Sent: Sunday, February 14, 2016 9:54 PM To: Tim Lewis <[email protected]>; Kinney, Michael D <[email protected]>; [email protected] Cc: Zeng, Star <[email protected]> Subject: RE: PCD Local Token Numbers in PEI/DXE Tim, Basically, I aware PEI as the high-reliability, high-security portion of the BIOS. I mean for this case, should PEI FV be also updated? And the mismatch seems not a special case for PCD. Consider one situation that new DXE wants to consume a HOB produced by new PEI, the new DXE could also not work with old PEI. Thanks, Star -----Original Message----- From: Tim Lewis [mailto:[email protected]] Sent: Monday, February 15, 2016 1:45 PM To: Zeng, Star; Kinney, Michael D; [email protected] Subject: RE: PCD Local Token Numbers in PEI/DXE Star -- Consider the case where PEI FV is inside the flash boot block, but DXE FV is outside of the flash boot block. This case is very common, using PEI as the high-reliability, high-security portion of the BIOS. You are correct, there is another case which is: Build #1: PEI database A does not have PCD X, DXE database A has PCD X Build #2: PEI database A has PCD X, DXE database A does not have PCD X If the PEI from #2 is combined with the DXE from #1, there will be two copies of the PCD (one in PEI, one in DXE). In our work-around, we searched PEI before DXE. The better method might be to timestamp (rather than assume PEI before DXE). Tim -----Original Message----- From: Zeng, Star [mailto:[email protected]] Sent: Sunday, February 14, 2016 9:33 PM To: Kinney, Michael D <[email protected]>; Tim Lewis <[email protected]>; [email protected] 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:[email protected]] On Behalf Of Kinney, Michael D Sent: Thursday, February 11, 2016 2:21 AM To: Tim Lewis; [email protected]; 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:[email protected]] > Sent: Wednesday, February 10, 2016 9:50 AM > To: Kinney, Michael D <[email protected]>; > [email protected] > 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:[email protected]] On Behalf Of > Kinney, Michael D > Sent: Wednesday, February 10, 2016 9:41 AM > To: Tim Lewis <[email protected]>; [email protected]; Kinney, > Michael D <[email protected]> > 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:[email protected]] On Behalf > > Of Tim Lewis > > Sent: Tuesday, February 9, 2016 10:24 AM > > To: [email protected] > > 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 > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel

