From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.apple.com [17.179.253.48]) by mx.groups.io with SMTP id smtpd.web12.3271.1652143044125688705 for ; Mon, 09 May 2022 17:37:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=qhy7J6Ro; spf=pass (domain: apple.com, ip: 17.179.253.48, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 24A0EqvQ010011; Mon, 9 May 2022 17:37:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=VDxwSRPh9rSjDh1Qe28kqau0tt2n3z6UF8K8WXsXQy4=; b=qhy7J6RoxVvtoFjQT0834o0cWZ8zOWj6R3Jy4UffWfHNjg5QcOVenwuRbUBNwWNRDmoK KmKgpy+vKGJI2ObQG1kbhZx6FTNVDgjjaEcrNJDZTBiLR3bYhkb8NAjrDR7iIUASSzZL 7GhqHv9i7lO7T9p9WT4jMfP7u2vCIunJyQMswfiPNHxpBSprRrVLsEAfB36Ge/JpbZo8 MNgPUjITbi5XVx8ILQr+7fK+Hb8kgwissAZK0eDqmr3e8XzFG/2THpYPnyuhekF0mtps 9tQdpBbzLNuJRYCqz3RUqcbnUzXdd/hjhcnqD/HrhclLTD/lnINVQJryMX9Y1xDDAeWf nw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3fwm98jjxs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 09 May 2022 17:37:23 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RBN00FHP5QBD920@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 09 May 2022 17:37:23 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RBN00G005M8GN00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 09 May 2022 17:37:23 -0700 (PDT) X-Va-A: X-Va-T-CD: 159e65cf5d47202b04bd3f023f2dd26b X-Va-E-CD: 9dbf719d48827ed8011e5bb7a18e8b15 X-Va-R-CD: 6aa164f6f9b4b8d67f20c4c202671e9a X-Va-CD: 0 X-Va-ID: 0ad83b5f-4484-4a1b-90e1-ea849a80d447 X-V-A: X-V-T-CD: 159e65cf5d47202b04bd3f023f2dd26b X-V-E-CD: 9dbf719d48827ed8011e5bb7a18e8b15 X-V-R-CD: 6aa164f6f9b4b8d67f20c4c202671e9a X-V-CD: 0 X-V-ID: 34e28e40-24f1-400b-ba36-45e12787ecf1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858 definitions=2022-05-09_06:2022-05-09,2022-05-09 signatures=0 Received: from smtpclient.apple (unknown [17.235.7.9]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RBN00YIA5QAK600@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 09 May 2022 17:37:22 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [edk2-devel] Question about PCD and FW_BASE_ADDRESS Date: Mon, 09 May 2022 17:37:21 -0700 In-reply-to: <7144915ac16db9a40d16d1054c6a5366eb9f439f.camel@intel.com> Cc: "kraxel@redhat.com" , "Yao, Jiewen" To: edk2-devel-groups-io , sebastien.boeuf@intel.com References: <7144915ac16db9a40d16d1054c6a5366eb9f439f.camel@intel.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858 definitions=2022-05-09_06:2022-05-09,2022-05-09 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_9C7E0101-3DD6-4099-9E2E-E567689A3506" --Apple-Mail=_9C7E0101-3DD6-4099-9E2E-E567689A3506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 9, 2022, at 2:42 AM, Boeuf, Sebastien = wrote: >=20 > Hi, >=20 > 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? >=20 Sebastien, The PCD=E2=80=99s end up being build configurable. They can get compiled in= to 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 DS= C maps for this platform what form the PCD takes. There are also PCDs in t= he FDF file that get setup base on the Flash Layout. There is a write up he= re: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/PC= D/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.=20 https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Universal/PCD/Pe= i 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 repor= t to figure out NVRAM addresses. The early code is XIP and it gets relocate= d 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? >=20 One =E2=80=9CPro Tip=E2=80=9D is to pass --report-file=3DREPORTFILE to the = build command. That build report is very useful debugging things. For examp= le it will show you how the PCD values got set.=20 So you modified the FW_BASE_ADDRESS under the !if $(FD_SIZE_IN_KB) =3D=3D 4= 096? I think a some of those values are chained together? Also notice the N= VRAM starts at the beginning of the ROM [1]. See FW_BASE_ADDRESS and CODE_B= ASE_ADDRESS.=20 !if $(FD_SIZE_IN_KB) =3D=3D 4096 DEFINE VARS_SIZE =3D 0x84000 DEFINE VARS_BLOCKS =3D 0x84 DEFINE VARS_LIVE_SIZE =3D 0x40000 DEFINE VARS_SPARE_SIZE =3D 0x42000 DEFINE FW_BASE_ADDRESS =3D 0xFFC00000 DEFINE FW_SIZE =3D 0x00400000 DEFINE FW_BLOCKS =3D 0x400 DEFINE CODE_BASE_ADDRESS =3D 0xFFC84000 DEFINE CODE_SIZE =3D 0x0037C000 DEFINE CODE_BLOCKS =3D 0x37C DEFINE FVMAIN_SIZE =3D 0x00348000 DEFINE SECFV_OFFSET =3D 0x003CC000 DEFINE SECFV_SIZE =3D 0x34000 !endif [1] https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgDefines.fd= f.inc Thanks, Andrew Fish PS Note sometimes I configure my builds to place this in the Build generate= d directories so it is ignored by git and always available per platform bui= ld.=20 vmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG --report-= file=3Dbuild.log > Thanks, > Sebastien > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris,=20 > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 5 208 026.16 Euros >=20 > 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. >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_9C7E0101-3DD6-4099-9E2E-E567689A3506 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 9, 2022, at 2:42 AM, = Boeuf, Sebastien <sebastien.boeuf@intel.com> wrote:

Hi,

I have a question related to the MMIO accesses performed by OVMF that I<= br class=3D"">can see are happening whenever PcdGet() is invoked. Could you= tell me
how PCD works that can explain why I can see some MM= IO read accesses on
address 0xFFFD5A24?


Sebastien,<= div class=3D"">
The PCD=E2=80=99s end u= p being build configurable. They can get compiled into constants, call a da= tabase. The database entries can get set by code, or mapped to NVRAM variab= les etc. Some of the PCD values are set as constants from the DSC file [Pcd= s*] sections. Also the name of the [Pcds*] in the DSC  maps for this p= latform what form the PCD takes. There are also PCDs in the FDF file that g= et setup base on the Flash Layout. There is a write up here: https://github.com/tianocore/edk2/blob/master/Mde= ModulePkg/Universal/PCD/Pei/Pcd.inf

There is a PCD PEIM and it has a database that is bu= ild in and it provides a service. It pass info up in a HOB to the DXE versi= on 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 RO= M. 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 t= he FV. You can figure these addresses out from the build map files. Example= s for OVMF:
Bu= ild/OvmfX64/DEBUG_XCODE5/FV/SECFV.Fv.map
Build/OvmfX64/DEBUG_XCODE5/FV/PEIFV.Fv.map

Also, I'm using the CloudHv target, mean= ing it's loaded as a PVH ELF
binary, and therefore it's not l= oaded at address 0xFFC00000. Instead
it's loaded at address 0= x4FFFD0. I did modify the FW_BASE_ADDRESS in
OvmfPkgDefines.f= df.inc but I'm not sure that's the correct approach.
What do = you think about it?

<= div>
One =E2=80=9CPro Tip=E2=80=9D is to pass = ;--report-f= ile=3DREPORTFILE to the build command. That build report is ver= y useful debugging things. For example it will show you how the PCD values = got set. 

So you modified the = ;FW_BASE_ADDRESS under the&nbs= p;!if $(FD_SIZE_IN_KB) =3D=3D 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 an= d CODE_BASE_ADDRESS. 
<= /tr>
!= if $(FD_SIZE_IN_KB) =3D=3D 4096
DEFINE VARS_SIZE =3D 0x84000
DEFINE VAR= S_BLOCKS =3D 0x84
DEFINE VARS_LIVE_SIZE =3D 0x40000
DEFINE VARS_SPARE= _SIZE =3D 0x42000
D= EFINE FW_BASE_ADDRESS =3D 0xFFC00000
DEFINE FW_SIZE =3D 0x0040000= 0
= DEFINE FW_BLOCKS =3D 0x400
<= /td>DEFINE CODE_BASE_ADDRESS =3D 0xFFC84000
DEF= INE CODE_SIZE =3D 0x0037C000
DEFINE CODE_BLOCKS =3D 0x37C
DEFIN= E FVMAIN_SIZE =3D 0x00348000
<= /td>DEFINE SECFV_OFFSET =3D 0x003CC000
DEF= INE SECFV_SIZE =3D 0x34000
!endif



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/Cl= oudHv/CloudHvX64.dsc -a X64 -b DEBUG --report-file=3Dbuild.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:  3= 02 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confiden= tial 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 sen= der and delete all copies.





--Apple-Mail=_9C7E0101-3DD6-4099-9E2E-E567689A3506--