On Jul 23, 2014, at 9:56 AM, Varad Gautam <varadgau...@gmail.com> wrote:
>
> On Wed, Jul 23, 2014 at 9:43 PM, Andrew Fish <af...@apple.com> wrote:
> > 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.h
> >
> > #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?
>
> I see that `PeiUniCore/DEBUG/AutoGen.h` contains
> `#define _PCD_GET_MODE_32_PcdFvBaseAddress
> _gPcd_FixedAtBuild_PcdFvBaseAddress`
>
> and `PeiUniCore/DEBUG/AutoGen.c`:
> `GLOBAL_REMOVE_IF_UNREFERENCED const UINT32
> _gPcd_FixedAtBuild_PcdFvBaseAddress = _PCD_VALUE_PcdFvBaseAddress;`
>
> also, in PeiUniCore/DEBUG/AutoGen.h
> `#define _PCD_VALUE_PcdFvBaseAddress 0x80008000U`
>
> So _PCD_GET_MODE_32_PcdFvBaseAddress should get set to the right value.
>
>
> On Jul 23, 2014, at 5:36 AM, Laszlo Ersek <ler...@redhat.com> wrote:
> > (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.
>
> Oddly, the call to PcdGet32() from PrePi doesn't get here. It takes the
> MdePkg/Include/Library/PcdLib.h:
> #define PcdGet32(TokenName) _PCD_GET_MODE_32_##TokenName
> route instead.
>
What is the AutoGen.* for the library?
Thanks,
Andrew Fish
> > 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, I was unaware of that.
>
>
> Varad
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
