From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-170.mimecast.com (us-smtp-delivery-170.mimecast.com [216.205.24.170]) by mx.groups.io with SMTP id smtpd.web10.1076.1579743445440730848 for ; Wed, 22 Jan 2020 17:37:25 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@phoenix.com header.s=mimecast20170203 header.b=unFLzFT0; spf=pass (domain: phoenix.com, ip: 216.205.24.170, mailfrom: ken_taylor@phoenix.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=phoenix.com; s=mimecast20170203; t=1579743444; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=tgAMnsNo4q3XQZq1aEDmeArQXESs1GMzbr+9pHXIDd4=; b=unFLzFT0bt08LXLH6Qv24JqLWymRg2J58mzQ8hX2z0+gsPBp/tAsmzJt4f8qzgoArbIf/9 pWdiqoN1qXSxG4Xuv2ozn3c67iU+QfccRiJDIJu63tOA5rovhWSwO3kUlDTkmZ3YMYNLUF ZhCpw5ayFDtY+bdtmisAxTqu6+IBrV4= X-CrossPremisesHeadersFilteredBySendConnector: SCL-EXCHMB-13.phoenix.com Received: from SCL-EXCHMB-13.phoenix.com (67.51.239.50 [67.51.239.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-5-xQGhB1KGOuaMiS82CJBERQ-1; Wed, 22 Jan 2020 20:37:21 -0500 Received: from SCL-EXCHMB-13.phoenix.com (10.122.68.16) by SCL-EXCHMB-13.phoenix.com (10.122.68.16) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 22 Jan 2020 17:37:08 -0800 Received: from SCL-EXCHMB-13.phoenix.com ([fe80::fd2e:a8f8:f740:cb3b]) by SCL-EXCHMB-13.phoenix.com ([fe80::fd2e:a8f8:f740:cb3b%12]) with mapi id 15.00.1156.000; Wed, 22 Jan 2020 17:37:08 -0800 From: "Ken Taylor" To: "devel@edk2.groups.io" Subject: PCD EX interface. Thread-Topic: PCD EX interface. Thread-Index: AdXRh2b+NA48Goz8SvSV/wyvNoq9Jw== Date: Thu, 23 Jan 2020 01:37:08 +0000 Message-ID: <2fb8e97b19214251bf25f44c7b4149a3@SCL-EXCHMB-13.phoenix.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.40.63] MIME-Version: 1.0 X-OrganizationHeadersPreserved: SCL-EXCHMB-13.phoenix.com X-MC-Unique: xQGhB1KGOuaMiS82CJBERQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: phoenix.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2fb8e97b19214251bf25f44c7b4149a3SCLEXCHMB13phoenixcom_" --_000_2fb8e97b19214251bf25f44c7b4149a3SCLEXCHMB13phoenixcom_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi all, I'm trying to access a PCD in a build independent manner. Specifically, mo= ving forward, I want to write a PCD value in my BIOS code during PEI phase,= and then read back the value of that PCD in a build independent shell util= ity (or identify and report situations in which the PCD is not found). I f= igure this is a good time to use [PcdsDynamicEx] in the build, because stan= dard PCDs are assigned a build specific token, which kind of defeats my pur= pose. At first, everything seemed to be working okay. A call to PcdGetEx8 return= ed 0 on a build in which the PCD was undefined. Then I tried a build in wh= ich I wrote the PCD, and I got back a random number other than 0 or what I'= d written to the PCD in the BIOS. Then, I decided to try PcdGetExSize to s= ee if the PCD was even defined properly defined... at which point my shell = utility locked up. So a little debugging later, and I discover that I'm hitting an ASSERT beca= use the GUID my utility is passing to the DXE PCD service isn't being found= in the list of GUIDs. Probably an error in my build or build tool configu= ration, so I'll have to sort that out. That's on me. But now I've got a problem: If I try to get the size of a DynamicEx PCD in the context of a BIOS build = for which that PCD is undefined, the call locks up. I expected to just get= a size of 0, since the PCD is not defined in the build context of the PCD = DXE service. Is this a problem that's been fixed since my BIOS source code= was cut? What can I do for older builds that haven't been fixed (and prob= ably never will)? Do I have to just accept that I'm going to get garbage o= r lockup if I run my shell utility on some builds? Do I have to write a DX= E driver and expose a protocol, just so I can know if that PCD exists and i= s properly defined? Is the idea that I might want to do this unreasonable? Should I just give = up and use a HOB or a variable? Regards, -Ken. --_000_2fb8e97b19214251bf25f44c7b4149a3SCLEXCHMB13phoenixcom_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’m trying to access a PCD in a build independ= ent manner.  Specifically, moving forward, I want to write a PCD value= in my BIOS code during PEI phase, and then read back the value of that PCD= in a build independent shell utility (or identify and report situations in which the PCD is not found).  I figure this = is a good time to use [PcdsDynamicEx] in the build, because standard PCDs a= re assigned a build specific token, which kind of defeats my purpose.<= /o:p>

 

At first, everything seemed to be working okay. = ; A call to PcdGetEx8 returned 0 on a build in which the PCD was undefined.=   Then I tried a build in which I wrote the PCD, and I got back a rand= om number other than 0 or what I’d written to the PCD in the BIOS.  Then, I decided to try PcdGetExSize to see if t= he PCD was even defined properly defined… at which point my shell uti= lity locked up.

 

So a little debugging later, and I discover that I&#= 8217;m hitting an ASSERT because the GUID my utility is passing to the DXE = PCD service isn’t being found in the list of GUIDs.  Probably an= error in my build or build tool configuration, so I’ll have to sort that out.  That’s on me.

 

But now I’ve got a problem:

 

If I try to get the size of a DynamicEx PCD in the c= ontext of a BIOS build for which that PCD is undefined, the call locks up.&= nbsp; I expected to just get a size of 0, since the PCD is not defined in t= he build context of the PCD DXE service.  Is this a problem that’s been fixed since my BIOS source code was cu= t?  What can I do for older builds that haven’t been fixed (and = probably never will)?  Do I have to just accept that I’m going t= o get garbage or lockup if I run my shell utility on some builds?  Do I have to write a = DXE driver and expose a protocol, just so I can know if that PCD exists and= is properly defined?

 

Is the idea that I might want to do this unreasonabl= e?  Should I just give up and use a HOB or a variable?

 

Regards,

-Ken.

--_000_2fb8e97b19214251bf25f44c7b4149a3SCLEXCHMB13phoenixcom_--