On Jul 23, 2014, at 5:36 AM, Laszlo Ersek lersek@redhat.com wrote:
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).
What form do get for _PCD_GET_MODE_*_PcdFvBaseAddress in the AutoGen.h? That is the real issue.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/PcdLib... #define PcdGet8(TokenName) _PCD_GET_MODE_8_##TokenName The behavior of libraries (try to inherit things from drivers) and drivers is different. Where is the PCD in question?
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.
Yes it is good to debug with DEBUG builds.
Thanks,
Andrew Fish
(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