On 11/22/13 21:51, Jordan Justen wrote:
> Many of these scenarios were discussed in the past on qemu-devel, but
> a single -pflash was the only thing that stuck. This has made me just
> focus on making the single file pflash work.
I almost forgot to reflect on this -- I'm extremely grateful to yo
On 11/22/13 21:51, Jordan Justen wrote:
> On Fri, Nov 22, 2013 at 10:43 AM, Laszlo Ersek wrote:
>> OTOH building all three FDs per default might be confusing for
>> end-users. We know for a fact that they usually don't read the README
>> (or not thoroughly enough). If we only give them one output
On Fri, Nov 22, 2013 at 12:54 PM, Eric Blake wrote:
> On 11/22/2013 01:51 PM, Jordan Justen wrote:
>
>> Tangentially related idea: if the user specifies -pflash to a
>> non-existent file, then QEMU could copy 'pflash-$(arch).bin' from the
>> roms folder into that file, and then the use it for the
On 11/22/2013 01:51 PM, Jordan Justen wrote:
> Tangentially related idea: if the user specifies -pflash to a
> non-existent file, then QEMU could copy 'pflash-$(arch).bin' from the
> roms folder into that file, and then the use it for the flash. It
> could make using a flash almost as easy as usin
On Fri, Nov 22, 2013 at 10:43 AM, Laszlo Ersek wrote:
> OTOH building all three FDs per default might be confusing for
> end-users. We know for a fact that they usually don't read the README
> (or not thoroughly enough). If we only give them one output file per
> default, that's less potential for
On 11/22/13 18:37, Jordan Justen wrote:
> On Thu, Nov 21, 2013 at 2:21 PM, Laszlo Ersek wrote:
>> Split the variable store off to a separate file when SPLIT_VARSTORE is
>> defined.
>
> Is the goal to allow the central OVMF to be updated so the VM will
> automatically be running the newest firmwar
On Thu, Nov 21, 2013 at 2:21 PM, Laszlo Ersek wrote:
> Split the variable store off to a separate file when SPLIT_VARSTORE is
> defined.
Is the goal to allow the central OVMF to be updated so the VM will
automatically be running the newest firmware? (While preserving
variables)
I think in your s
Split the variable store off to a separate file when SPLIT_VARSTORE is
defined.
Even in this case, the preexistent PCDs' values don't change. Qemu must
take care of contiguously mapping NVVARSTORE.fd + OVMF.fd so that when
concatenated they end exactly at 4GB.
Contributed-under: TianoCore Contrib