On 2015/10/19 10:48, Zeng, Star wrote:
On 2015/10/18 14:48, Jordan Justen wrote:
This patch appears to have caused OVMF to stop booting. I hit an
assert now in BDS after attempting to set the BootOrder variable
fails. An ideas of how to fix this?
There is bug in this patch, it was thoughtless
On 2015/10/16 16:04, Dimitri wrote:
Hi,
Fist of all: I am DimitRi.
UDK2014/UEFI 2.4 does not have EFI_PROPERTIES_TABLE feature. Anyway we have
a bug by default.
Collegue from Apple confirmed that os x boot loader move EfiRuntime memory
to different physical address. I did not find in UEFI spec
Looks good. Reviewed by: jiewen@intel.com
Would you please add some comments in the code to indicate why we need skip
check in Set() and add check in Get()?
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, October 19,
On 2015/10/18 14:48, Jordan Justen wrote:
This patch appears to have caused OVMF to stop booting. I hit an
assert now in BDS after attempting to set the BootOrder variable
fails. An ideas of how to fix this?
There is bug in this patch, it was thoughtless for property set.
I have resent patch to
R18611 only updated the logic to return correct property
when no property set to variable with wildcard name.
But VariablePropertySet needs the pointer to property data for set.
So roll back the change in VariablePropertyGetWithWildcardName at R18611,
and check the property revision first in Variab
R18611 only updated the logic to return correct property
when no property set to variable with wildcard name.
But VariablePropertySet needs the pointer to property data for set.
So roll back the change in VariablePropertyGetWithWildcardName at R18611,
and check the property revision first in Variab
> On Oct 18, 2015, at 12:29 AM, Jordan Justen wrote:
>
> I can't find a fault with your argument, but something tells me it
> might be good to get some input from Mike or Andrew (or others on the
> list) in the form of a history lesson to know why the two modes might
> have been supported.
>
T
On 2015-10-14 15:26:22, Laszlo Ersek wrote:
> From: Paolo Bonzini
>
> This adjusts the previously introduced state save map access functions, to
> account for QEMU and KVM's 64-bit state save map following the AMD spec
> rather than the Intel one.
Shouldn't this layout match the processor being
I can't find a fault with your argument, but something tells me it
might be good to get some input from Mike or Andrew (or others on the
list) in the form of a history lesson to know why the two modes might
have been supported.
I've always seen it done this way, but likely this has been due to a
l
9 matches
Mail list logo