Liming, Adding error message/assert when PEI and DXE databases are not compatible is a good idea.
But I also think we should do everything we can to prevent PEI and DXE databases from ever being incompatible. Especially if 100% of the PCDs used are accessed as DynamixEx. Thanks, Mike > -----Original Message----- > From: Gao, Liming > Sent: Wednesday, February 17, 2016 7:07 AM > To: Tim Lewis <[email protected]>; Zeng, Star <[email protected]>; > Kinney, Michael > D <[email protected]>; [email protected] > Subject: RE: PCD Local Token Numbers in PEI/DXE > > Tim: > I think we can enhance PCD driver and Build tool to do this check. If the > mismatch > happens, PcdDxe driver will report error message, and not install PCD > protocol. > > Thanks > Liming > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of Tim > Lewis > Sent: Monday, February 15, 2016 1:59 PM > To: Zeng, Star <[email protected]>; Kinney, Michael D > <[email protected]>; > [email protected] > Subject: Re: [edk2] PCD Local Token Numbers in PEI/DXE > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
