I would point out that in systems where PEI FVs are updated independently of DXE FVs, we use 100% DynamicEx, because we try to make no assumptions. Basically, the PEIMs in the PEI FV are considered "binary builds" per Mike's classification.
Tim -----Original Message----- From: Kinney, Michael D [mailto:[email protected]] Sent: Wednesday, February 17, 2016 9:00 AM To: Gao, Liming <[email protected]>; Tim Lewis <[email protected]>; Zeng, Star <[email protected]>; [email protected]; Kinney, Michael D <[email protected]> Subject: RE: PCD Local Token Numbers in PEI/DXE 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
