On 07/23/14 13:34, Varad Gautam wrote:

Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
issue with
PcdGet(): it always returns `0` no matter what the PCD is set to. However,
FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet
calls with
FixedPcdGet to get PrePi working which is a bad idea).

#define PcdGet8(TokenName)                  _PCD_GET_MODE_8_##TokenName

The build report too shows the PCDs being set to their proper values,
and so do the
AutoGen.i file macros like `const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress
= 0x80008000U;`

I've come up with two reasons to this,
* Is there a build flag I'm missing to enable PcdGet support?
* `_gPcd_FixedAtBuild_PcdFvBaseAddress` is declared with
`GLOBAL_REMOVE_IF_UNREFERENCED` in AutoGen.c and gets removed before
I can use it. This also explains why FixedPcdGet would work, since
`_PCD_VALUE_PcdFvBaseAddress` is correctly #defined to be  0x80008000U.

This happens for all fixed-at-build type PCDs. Also, I'm linked to
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf for the buid. What could
I try to fix it?

You're getting this result because you're combining incorrect library
class resolution with RELEASE builds.

(I cannot condemn RELEASE builds
enough.) Namely, you call

   UINT32
   EFIAPI
   LibPcdGet32 (
     IN UINTN             TokenNumber
     )
   {
     ASSERT (FALSE);

     return 0;
   }

from "MdePkg/Library/BasePcdLibNull/PcdLib.c", and since you build for
RELEASE, the ASSERT() is a no-op. In a DEBUG build you'd have caught
this immediately with a failed assertion: the Null implementation of
PcdLib doesn't allow you to actually access PCDs.

Library instances that usably resolve the PcdLib library class are:

$ git grep -l 'LIBRARY_CLASS *= *PcdLib' -- '*.inf'

EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
MdePkg/Library/DxePcdLib/DxePcdLib.inf
MdePkg/Library/PeiPcdLib/PeiPcdLib.inf

In PEIMs, you need the fourth; in DXE & UEFI drivers, you need the third.

However, this is not the entire picture yet, because these libraries
delegate the work to a PPI (in PEI) and to a protocol (in DXE) that are
provided by dedicated drivers, respectively:
- MdeModulePkg/Universal/PCD/Pei/Pcd.inf
- MdeModulePkg/Universal/PCD/Dxe/Pcd.inf

You should add these drivers to the corresponding (ie. PEI vs. DXE)
APRIORI files of the firmware volumes that your FDF file defines, so
that any driver loaded / dispatched later can use their PCD services
(through the above-mentioned library instances). Refer to
OvmfPkg/OvmfPkgX64.fdf for examples.

Thanks
Laszlo

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel