> On May 9, 2022, at 2:42 AM, Boeuf, Sebastien <sebastien.bo...@intel.com> > wrote: > > Hi, > > I have a question related to the MMIO accesses performed by OVMF that I > can see are happening whenever PcdGet() is invoked. Could you tell me > how PCD works that can explain why I can see some MMIO read accesses on > address 0xFFFD5A24? >
Sebastien, The PCD’s end up being build configurable. They can get compiled into constants, call a database. The database entries can get set by code, or mapped to NVRAM variables etc. Some of the PCD values are set as constants from the DSC file [Pcds*] sections. Also the name of the [Pcds*] in the DSC maps for this platform what form the PCD takes. There are also PCDs in the FDF file that get setup base on the Flash Layout. There is a write up here: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/PCD/Pei/Pcd.inf There is a PCD PEIM and it has a database that is build in and it provides a service. It pass info up in a HOB to the DXE version of the driver. https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/PCD/Pei How far did you get in the boot? What do you have on serial? That address looks like it could be NVRAM or ROM. You can use a build report to figure out NVRAM addresses. The early code is XIP and it gets relocated to the FLASH address when it gets placed in the FV. You can figure these addresses out from the build map files. Examples for OVMF: Build/OvmfX64/DEBUG_XCODE5/FV/SECFV.Fv.map Build/OvmfX64/DEBUG_XCODE5/FV/PEIFV.Fv.map > Also, I'm using the CloudHv target, meaning it's loaded as a PVH ELF > binary, and therefore it's not loaded at address 0xFFC00000. Instead > it's loaded at address 0x4FFFD0. I did modify the FW_BASE_ADDRESS in > OvmfPkgDefines.fdf.inc but I'm not sure that's the correct approach. > What do you think about it? > One “Pro Tip” is to pass --report-file=REPORTFILE to the build command. That build report is very useful debugging things. For example it will show you how the PCD values got set. So you modified the FW_BASE_ADDRESS under the !if $(FD_SIZE_IN_KB) == 4096? I think a some of those values are chained together? Also notice the NVRAM starts at the beginning of the ROM [1]. See FW_BASE_ADDRESS and CODE_BASE_ADDRESS. !if $(FD_SIZE_IN_KB) == 4096 DEFINE VARS_SIZE = 0x84000 DEFINE VARS_BLOCKS = 0x84 DEFINE VARS_LIVE_SIZE = 0x40000 DEFINE VARS_SPARE_SIZE = 0x42000 DEFINE FW_BASE_ADDRESS = 0xFFC00000 DEFINE FW_SIZE = 0x00400000 DEFINE FW_BLOCKS = 0x400 DEFINE CODE_BASE_ADDRESS = 0xFFC84000 DEFINE CODE_SIZE = 0x0037C000 DEFINE CODE_BLOCKS = 0x37C DEFINE FVMAIN_SIZE = 0x00348000 DEFINE SECFV_OFFSET = 0x003CC000 DEFINE SECFV_SIZE = 0x34000 !endif [1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgDefines.fdf.inc Thanks, Andrew Fish PS Note sometimes I configure my builds to place this in the Build generated directories so it is ignored by git and always available per platform build. vmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG --report-file=build.log > Thanks, > Sebastien > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 5 208 026.16 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#89626): https://edk2.groups.io/g/devel/message/89626 Mute This Topic: https://groups.io/mt/90985557/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
