On 2017-07-01 13:42:06, Laszlo Ersek wrote:
> On 06/29/17 21:14, Jordan Justen wrote:
> > On 2017-06-26 16:04:41, Laszlo Ersek wrote:
> >> On 06/27/17 00:36, Jordan Justen wrote:
> >>>
> >>> Why can't SmramInternal.c read the size from the PCD directly?
> >>
> >> If I remember correctly, I wanted t
On 06/29/17 21:14, Jordan Justen wrote:
> On 2017-06-26 16:04:41, Laszlo Ersek wrote:
>> On 06/27/17 00:36, Jordan Justen wrote:
>>>
>>> Why can't SmramInternal.c read the size from the PCD directly?
>>
>> If I remember correctly, I wanted to base SmramAccessGetCapabilities()
>> directly on hardwar
On 2017-06-26 16:04:41, Laszlo Ersek wrote:
> On 06/27/17 00:36, Jordan Justen wrote:
> >
> > Why can't SmramInternal.c read the size from the PCD directly?
>
> If I remember correctly, I wanted to base SmramAccessGetCapabilities()
> directly on hardware configuration. At that point (regardless o
On 06/27/17 00:36, Jordan Justen wrote:
> On 2017-06-26 12:12:45, Laszlo Ersek wrote:
>> On 06/26/17 19:59, Jordan Justen wrote:
>>> I looked at this series a number of times. My thought is that:
>>>
>>> * PcdQ35TsegMbytes should become dynamic
>>>
>>> * No PCD for tseg mask
>>>
>>> * PlatformPei a
On 2017-06-26 12:12:45, Laszlo Ersek wrote:
> On 06/26/17 19:59, Jordan Justen wrote:
> > I looked at this series a number of times. My thought is that:
> >
> > * PcdQ35TsegMbytes should become dynamic
> >
> > * No PCD for tseg mask
> >
> > * PlatformPei adds knowledge of qemu ext tseg to set Pc
On 06/26/17 19:59, Jordan Justen wrote:
> On 2017-06-19 12:39:51, Laszlo Ersek wrote:
>>
>> Even if the PCDs were technically doable, I think I'd slightly prefer
>> the current approach. The PCI config space accesses at module startup
>> are minimal, and they affect only three modules. OTOH, introd
On 2017-06-19 12:39:51, Laszlo Ersek wrote:
>
> Even if the PCDs were technically doable, I think I'd slightly prefer
> the current approach. The PCI config space accesses at module startup
> are minimal, and they affect only three modules. OTOH, introducing two
> PCDs feels, in this particular ca
On 06/21/17 02:52, Yao, Jiewen wrote:
> As far as I know, the real platform SmmAccessPeim may depend on
> gEfiPeiMemoryDiscoveredPpiGuid, because the SmramHob is produced in
> MRC wrapper.
Thanks for the info, Jiewen!
- I don't know what "MRC wrapper" is.
I found "QuarkPlatformPkg/Platform/Pei
As far as I know, the real platform SmmAccessPeim may depend on
gEfiPeiMemoryDiscoveredPpiGuid, because the SmramHob is produced in MRC wrapper.
At same time, I also saw a solution to use library to produce SmmAccessPpi. In
such case, there is no dependency expression, because one module does 2
On 06/19/17 19:30, Jordan Justen wrote:
> On 2017-06-08 10:13:29, Laszlo Ersek wrote:
>> OvmfPkg contains three modules that work with the TSEG (SMRAM) size:
>> PlatformPei (PEIM), SmmAccessPei (PEIM), and SmmAccess2Dxe (DXE_DRIVER).
>> These modules open-code the interpretation of the ESMRAMC regi
On 2017-06-08 10:13:29, Laszlo Ersek wrote:
> OvmfPkg contains three modules that work with the TSEG (SMRAM) size:
> PlatformPei (PEIM), SmmAccessPei (PEIM), and SmmAccess2Dxe (DXE_DRIVER).
> These modules open-code the interpretation of the ESMRAMC register's
> TSEG_SZ bit-field. That is OK as lon
OvmfPkg contains three modules that work with the TSEG (SMRAM) size:
PlatformPei (PEIM), SmmAccessPei (PEIM), and SmmAccess2Dxe (DXE_DRIVER).
These modules open-code the interpretation of the ESMRAMC register's
TSEG_SZ bit-field. That is OK as long as we stick with the Q35 hardware
spec and nothing
12 matches
Mail list logo
