On 09/10/19 17:58, Igor Mammedov wrote:
> On Mon, 9 Sep 2019 21:15:44 +0200
> Laszlo Ersek wrote:
[...]
> It looks like fwcfg smi feature negotiation isn't reusable in this case.
> I'd prefer not to add another device just for another SMI feature
> negotiation/activation.
I thought it could be
On Mon, 9 Sep 2019 21:15:44 +0200
Laszlo Ersek wrote:
> Hi Igor,
>
> On 09/05/19 17:49, Igor Mammedov wrote:
> > lpc already has SMI negotiation feature, extend it by adding
> > optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.
> >
> > Writing this bit into
On 09/09/19 21:15, Laszlo Ersek wrote:
> ... I've done some testing too. Applying the QEMU patch on top of
> 89ea03a7dc83, my plan was:
>
> - do not change OVMF, just see if it continues booting with the QEMU
> patch
>
> - then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
>
Hi Igor,
On 09/05/19 17:49, Igor Mammedov wrote:
> lpc already has SMI negotiation feature, extend it by adding
> optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.
>
> Writing this bit into "etc/smi/requested-features" fw_cfg file,
> tells QEMU to alias 0x3,128K RAM range into
lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.
Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x3,128K RAM range into SMRAM address
space and mask this region from normal RAM
