Leo,
> > BTW, reading the PlatformId MSR was already being done by MicrocodeDetect(),
> > but it never affected AMD-based platforms as the flow never gets that far,
> > since
> > the Detect routine bails out early when it finds the size of the patch is
> > zero.
You are saying that PlatformId M
Acked-by: Siyuan Fu
> -Original Message-
> From: Ni, Ray
> Sent: 2020年2月26日 15:46
> To: Leo Duran ; devel@edk2.groups.io; Wu, Hao A
> ; Fu, Siyuan
> Cc: Dong, Eric ; Laszlo Ersek
> Subject: RE: [PATCH 2/2] UefiCpuPkg: MpInitLib: Exclude code no pertinent
> to AMD processors.
>
> + Hao
+ Hao Wu and Siyuan Fu for review.
> -Original Message-
> From: Leo Duran
> Sent: Wednesday, February 26, 2020 3:39 AM
> To: devel@edk2.groups.io
> Cc: Leo Duran ; Dong, Eric ; Ni, Ray
> ; Laszlo Ersek
>
> Subject: [PATCH 2/2] UefiCpuPkg: MpInitLib: Exclude code no pertinent to AMD
> p
On Wed, 26 Feb 2020 at 02:34, Pete Batard wrote:
>
> Hi Ard,
>
> On 2020.02.25 22:27, Ard Biesheuvel wrote:
> > On Tue, 25 Feb 2020 at 19:31, Ard Biesheuvel
> > wrote:
> >>
> >> On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel
> >> wrote:
> >>>
> >>> Cache maintenance operations by set/way are onl
Hi Leo,
Yes, I means you also change the cod position in the c file, so in the patch
file, it seems like it has other changes.
My recommendation is to refine the patch to not change the code postion.
-Original Message-
From: Duran, Leo
Sent: Wednesday, February 26, 2020 10:41 AM
To: D
Reviewed-by: Ray Ni
> -Original Message-
> From: Chaganty, Rangasai V
> Sent: Wednesday, February 26, 2020 9:39 AM
> To: Fu, Siyuan ; devel@edk2.groups.io
> Cc: Ni, Ray
> Subject: RE: [Patch] IntelSiliconPkg: Declare zero array explicitly to avoid
> compiler error.
>
> Reviewed-by: Sa
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2539
Microsoft signtool supports creation of attached P7's with any OID payload
via the "/p7co" parameter. It is necessary to check the data before get
the string.
Signed-off-by: GuoMinJ
---
.../BaseCryptLib/Pk/CryptPkcs7VerifyBase.c| 51 +
> -Original Message-
> From: Gaurav Jain [mailto:gaurav.j...@nxp.com]
> Sent: Tuesday, February 25, 2020 8:01 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Ard Biesheuvel; Pankaj Bansal; Gaurav
> Jain
> Subject: [PATCH v3 1/1] MdeModulePkg/Pci: Fixed Asserts in SCT P
Reviewed-by: Sai Chaganty
-Original Message-
From: Fu, Siyuan
Sent: Tuesday, February 25, 2020 5:08 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Chaganty, Rangasai V
Subject: [Patch] IntelSiliconPkg: Declare zero array explicitly to avoid
compiler error.
This patch fixes a potential co
Hi Ard,
On 2020.02.25 22:27, Ard Biesheuvel wrote:
On Tue, 25 Feb 2020 at 19:31, Ard Biesheuvel wrote:
On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel wrote:
Cache maintenance operations by set/way are only intended to be used
in the context of on/offlining a core, while it has been taken out
On 02/26/20 00:43, Laszlo Ersek wrote:
> On 02/25/20 10:39, Ard Biesheuvel wrote:
>> +" 2. The initrd is not unloaded when the shell exits, and will remain
>> active\r\n"
>> +" until it is unloaded again by a different invocation of the
>> shell.\r\n"
>> +" Consumers of the LoadFile2 pr
Hi Leo,
I check the code and find the real change for the C files are add "EFIAPI" in
the code. Can you help to refine the change and only keep the real changes?
Thanks,
Eric
-Original Message-
From: Leo Duran
Sent: Wednesday, February 26, 2020 3:39 AM
To: devel@edk2.groups.io
Cc: Le
Reviewed-by: Liming Gao
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Siyuan, Fu
> Sent: Wednesday, February 26, 2020 9:08 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
>
> Subject: [edk2-devel] [Patch] IntelSiliconPkg: Declare zero array explicitl
This patch fixes a potential compiler error introduced by commit
b0099a39bd since not all compiler can support empty array member.
BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449
Cc: Ray Ni
Cc: Rangasai V Chaganty
Signed-off-by: Siyuan Fu
---
.../Intel/IntelSiliconPkg/Include/Guid
Added missing GUID gEfiMemoryTypeInformationGuid to
PeiPolicyUpdateLib.inf to fix VS2017 build issue
Cc: Chasel Chiu
Cc: Nate DeSimone
Signed-off-by: Prince Agyeman
---
.../Policy/Library/PeiPolicyUpdateLib/PeiPolicyUpdateLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Platfo
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2408
The patch series add VS2017 build support to the
edk2-plaforms/Intel boards
Cc: Chasel Chiu
Cc: Nate DeSimone
Prince Agyeman (2):
CoffeelakeSiliconPkg: Add Missing GUID
CoffeelakeSiliconPkg: Add missing library
.../PeiPolicyUpdateL
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2408
Added GbeMdiLib implementation and added additional registers
definitions needed by GbeMdilib. This fixes the linker errors seen
during VS2017 builds
Cc: Chasel Chiu
Cc: Nate DeSimone
Signed-off-by: Prince Agyeman
---
.../Pch/Include/L
Hi Leo,
On 02/25/20 20:39, Leo Duran wrote:
> This patch set fixes an issue introduced recently in MpInitLib, where we read
> a PlatformId MSR that is not implemented on AMD processors.
>
> The proposed solution is to export the StandardSignatureIsAuthenticAMD
> function
> from LocalApicLib, so
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Albecki, Mateusz
> Sent: Tuesday, February 25, 2020 11:06 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [edk2-devel] [PATCHv2
On 02/25/20 19:28, Ard Biesheuvel wrote:
> Cache maintenance operations by set/way are only intended to be used
> in the context of on/offlining a core, while it has been taken out of
> the coherency domain. Any use intended to ensure that the contents of
> the cache have made it to main memory is
On 02/25/20 11:44, Ard Biesheuvel wrote:
> Duplicate the TPM2_ENABLE and TPM2_CONFIG_ENABLE build time flags that
> already exist in OvmfPkg, and wire them up in the .DSC and .FDF so
> that setting those flags produces a ArmVirtQemu build that implements
> measured boot using a TPM provided by QEMU
On 02/26/20 01:24, Laszlo Ersek wrote:
> On 02/25/20 11:44, Ard Biesheuvel wrote:
>> Introduce a boolean PCD that tells us whether TPM support is enabled
>> in the build, and if it is, record the TPM base address in the existing
>> routine that traverses the device tree in the platform PEIM.
>>
>>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2191
This patch series add the initial Up Xtreme board support to the
WhiskeylakeOpenBoardPkg
V4 Changes:
- Removed MTRR configuration function
- Rearranged FVs to improve boot time
V3 Changes:
- Updated copyright year
- Added function
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2191
Co-authored-by: Michael Kubacki
Cc: Chasel Chiu
Cc: Nate DeSimone
Signed-off-by: Prince Agyeman
---
.../Intel/WhiskeylakeOpenBoardPkg/Include/PlatformBoardId.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Pla
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2191
Adds the DSC and build files necessary to build the
UpXtreme board instance.
Key files
=
* build_config.cfg - Board-specific build configuration file.
* OpenBoardPkg.dsc - The UpXtreme board description file.
* OpenBoardPkgPcd.dsc -
Removes BoardFuncInit related functionality in WhiskeylakeURvp.
Co-authored-by: Michael Kubacki
Cc: Chasel Chiu
Cc: Nate DeSimone
Signed-off-by: Prince Agyeman
---
.../Library/BoardInitLib/BoardFunc.c | 19
.../Library/BoardInitLib/BoardFunc.h | 20 -
On 02/25/20 11:44, Ard Biesheuvel wrote:
> Implement a ArmVirtPkg specific version of the PSCI ResetSystemLib that
> is usable in the PEI phase, as the existing one relies on the FDT client
> protocol, making it unsuitable.
>
> Note that accessing the device tree passed by QEMU via its initial bas
On 02/25/20 11:44, Ard Biesheuvel wrote:
> Introduce a boolean PCD that tells us whether TPM support is enabled
> in the build, and if it is, record the TPM base address in the existing
> routine that traverses the device tree in the platform PEIM.
>
> If a TPM is found, install the gOvmfTpmDiscov
On 02/25/20 11:44, Ard Biesheuvel wrote:
> Wire up the various existing pieces so that we can implement measured
> boot on ArmVirtQemu based on the TPM support in QEMU, just like it has
> been implemented for x86 in OvmfPkg.
>
> The main difference is that on ARM, we first need to discover the TPM
On 02/25/20 11:44, Ard Biesheuvel wrote:
> We currently include PcdLib.h in PlatformPeiLib, without declaring
> this dependency in its .INF description. Since all the PCDs we use
> resolve to fixed type in practice, this does not really matter at
> the moment, but since we will be adding dynamic PC
On 02/26/20 00:43, Laszlo Ersek wrote:
> On 02/25/20 10:39, Ard Biesheuvel wrote:
>> +Status = ShellOpenFileByName (Filename, &FileHandle,
>> + EFI_FILE_MODE_READ, 0);
>> +if (!EFI_ERROR (Status)) {
>> + Status = CacheInitrdFile (FileHandle);
>> +
On 02/25/20 10:39, Ard Biesheuvel wrote:
> This is the UEFI counterpart to my Linux series which generalizes
> mixed mode support into a feature that requires very little internal
> knowledge about the architecture specifics of booting Linux on the
> part of the bootloader or firmware.
>
> Instead
On 02/25/20 10:39, Ard Biesheuvel wrote:
> Add the 'initrd' dynamic shell command to the build so we can load
> Linux initrds straight from the shell using the new generic protocol,
> which does not rely on initrd= being passed on the command line.
>
> Signed-off-by: Ard Biesheuvel
> ---
> OvmfP
On 02/25/20 10:39, Ard Biesheuvel wrote:
> Add the 'initrd' dynamic shell command to the build so we can load
> Linux initrds straight from the shell using the new generic protocol,
> which does not rely on initrd= being passed on the command line.
>
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVi
On 02/25/20 10:39, Ard Biesheuvel wrote:
> Add a new 'initrd' command to the UEFI Shell that allows any file that is
> accessible to the shell to be registered as the initrd that is returned
> when Linux's EFI stub loader invokes the LoadFile2 protocol on its special
> vendor media device path.
>
On Tue, 25 Feb 2020 at 19:31, Ard Biesheuvel wrote:
>
> On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel
> wrote:
> >
> > Cache maintenance operations by set/way are only intended to be used
> > in the context of on/offlining a core, while it has been taken out of
> > the coherency domain. Any use i
On 02/25/20 10:39, Ard Biesheuvel wrote:
> Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
> it can be used in a media device path to specify a Linux style initrd
> that can be loaded by the OS using the LoadFile2 protocol.
>
> Signed-off-by: Ard Biesheuvel
> ---
> OvmfPkg
On 02/25/20 14:20, Liming Gao wrote:
> Laszlo:
> Seemly, this is a regression issue. I am ok to catch it into stable tag
> edk2-stable202002.
Thank you. If Phil is satisfied with my explanation, I'll push the patch
tomorrow.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all me
On 02/25/20 21:51, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> On 2/24/20 6:17 PM, Laszlo Ersek wrote:
>> In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's
>> "secondary-vga" device model (originally introduced in QEMU commit
>> 63e3e24db2e9).
>>
>> In QEMU commit 765c94290863
> On Feb 25, 2020, at 12:40 PM, Laszlo Ersek wrote:
>
> Hi Andrew,
>
> On 02/25/20 19:56, Andrew Fish wrote:
>> Laszlo,
>>
>> If I understand this correctly is it not more complicated than just size. It
>> also assumes the memory layout is the same?
>
> Yes.
>
>> The legacy BIOS used fixe
Hi Laszlo,
On 2/24/20 6:17 PM, Laszlo Ersek wrote:
In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's
"secondary-vga" device model (originally introduced in QEMU commit
63e3e24db2e9).
In QEMU commit 765c94290863, the "bochs-display" device was introduced,
which would work with
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556
The StandardSignatureIsAuthenticAMD function was introduced locally
to help divert code paths pertinent (or not) to AMD processors.
This patch exports that function so that it may serve the same purpose
in other modules that consume LocalApi
This patch set fixes an issue introduced recently in MpInitLib, where we read
a PlatformId MSR that is not implemented on AMD processors.
The proposed solution is to export the StandardSignatureIsAuthenticAMD function
from LocalApicLib, so that it may be used by MpInitLib or any other module that
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556
This patch uses the newly exported StandardSignatureIsAuthenticAMD function
from LocalApicLib, to divert code paths not pertinent to AMD processors.
Specifically, the PlatformId MSR and embedded Microcode patches are not
relevant on AMD-base
Hi Andrew,
On 02/25/20 19:56, Andrew Fish wrote:
> Laszlo,
>
> If I understand this correctly is it not more complicated than just size. It
> also assumes the memory layout is the same?
Yes.
> The legacy BIOS used fixed magic address ranges, but UEFI uses dynamically
> allocated memory so add
Laszlo,
If I understand this correctly is it not more complicated than just size. It
also assumes the memory layout is the same? The legacy BIOS used fixed magic
address ranges, but UEFI uses dynamically allocated memory so addresses are not
fixed. While the UEFI firmware does try to keep S3 an
On Tue, 25 Feb 2020 at 19:28, Ard Biesheuvel wrote:
>
> Cache maintenance operations by set/way are only intended to be used
> in the context of on/offlining a core, while it has been taken out of
> the coherency domain. Any use intended to ensure that the contents of
> the cache have made it to m
Cache maintenance operations by set/way are only intended to be used
in the context of on/offlining a core, while it has been taken out of
the coherency domain. Any use intended to ensure that the contents of
the cache have made it to main memory is unreliable, since cacheline
migration and non-arc
On 02/24/20 16:28, Daniel P. Berrangé wrote:
> On Tue, Feb 11, 2020 at 05:39:59PM +, Alex Bennée wrote:
>>
>> wuchenye1995 writes:
>>
>>> Hi all,
>>>We found a problem with live migration of UEFI virtual machines
>>>due to size of OVMF.fd changes.
>>>Specifically, the size of OVMF.
On Tue, Feb 25, 2020 at 05:01:36PM +0800, Heyi Guo wrote:
> The function iort_node_map_id() does the sanity check against the
> first mapping in the node, but not the one which we really use.
>
> Logically we need check the mapping we use, or check every mapping in
> the node. Choose the first fix
On Mon, Feb 24, 2020 at 06:17:41PM +0100, Laszlo Ersek wrote:
> In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's
> "secondary-vga" device model (originally introduced in QEMU commit
> 63e3e24db2e9).
>
> In QEMU commit 765c94290863, the "bochs-display" device was introduced,
> wh
This patch series aims to increase the reliability of the eMMC detection by
exectuing the SEND_STATUS after SWITCH command on the lower frequency.
Currently the driver will first switch the frequency to the new target and then
execute SEND_STATUS to see if SWITCH was a success. While this behavi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
To avoid stability issues on some designs the driver
will now send SEND_STATUS at previous, lower, frequency
when upgrading the bus timing.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
-
Laszlo:
Seemly, this is a regression issue. I am ok to catch it into stable tag
edk2-stable202002.
Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Ard Biesheuvel
> Sent: Tuesday, February 25, 2020 1:21 AM
> To: Laszlo Ersek
> Cc: edk2-devel-groups-io ; Ge
> -Original Message-
> From: Daniel Schaefer [mailto:daniel.schae...@hpe.com]
> Sent: Sunday, February 23, 2020 12:59 AM
> To: devel@edk2.groups.io
> Cc: Abner Chang ; Gilbert Chen
> ; Leif Lindholm ; Bi, Dandan
> ; Dong, Eric
> Subject: [PATCH 3/3] MdeModulePkg: Use CopyGuid instead of GU
On Tue, 25 Feb 2020 at 11:45, Ard Biesheuvel wrote:
>
> Wire up the various existing pieces so that we can implement measured
> boot on ArmVirtQemu based on the TPM support in QEMU, just like it has
> been implemented for x86 in OvmfPkg.
>
> The main difference is that on ARM, we first need to dis
Wire up the various existing pieces so that we can implement measured
boot on ArmVirtQemu based on the TPM support in QEMU, just like it has
been implemented for x86 in OvmfPkg.
The main difference is that on ARM, we first need to discover the TPM base
address from the device tree provided by QEMU
Introduce a boolean PCD that tells us whether TPM support is enabled
in the build, and if it is, record the TPM base address in the existing
routine that traverses the device tree in the platform PEIM.
If a TPM is found, install the gOvmfTpmDiscoveredPpiGuid signalling PPI
that will unlock the dis
Implement a ArmVirtPkg specific version of the PSCI ResetSystemLib that
is usable in the PEI phase, as the existing one relies on the FDT client
protocol, making it unsuitable.
Note that accessing the device tree passed by QEMU via its initial base
address is guaranteed to be safe at any time duri
We currently include PcdLib.h in PlatformPeiLib, without declaring
this dependency in its .INF description. Since all the PCDs we use
resolve to fixed type in practice, this does not really matter at
the moment, but since we will be adding dynamic PCD references in
a subsequent patch, let's make th
On ARM systems, the TPM does not live at a fixed address, and so we
need the platform to discover it first. So introduce a PPI that signals
that the TPM address has been discovered and recorded in the appropriate
PCD, and make Tcg2ConfigPei depex on it when built for ARM or AARCH64.
Reviewed-by: L
Duplicate the TPM2_ENABLE and TPM2_CONFIG_ENABLE build time flags that
already exist in OvmfPkg, and wire them up in the .DSC and .FDF so
that setting those flags produces a ArmVirtQemu build that implements
measured boot using a TPM provided by QEMU and described in the device
tree.
Note that the
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2319
__debugbreak() in any application will terminate the application on
windows 10. add /debug option for debugging windows 10.
Signed-off-by: GuoMinJ
---
EmulatorPkg/Win/Host/WinHost.c | 30 ++
1 file changed, 30
On Tue, 25 Feb 2020 at 11:27, Pete Batard wrote:
>
> "rgmii-rxid" is what the Linux folks use in their Device Tree so we follow
> suit. This fixes packet losses and unreliable network connections which we
> experienced when testing the Linux Genet driver.
>
> Signed-off-by: Pete Batard
Reviewed-
"rgmii-rxid" is what the Linux folks use in their Device Tree so we follow
suit. This fixes packet losses and unreliable network connections which we
experienced when testing the Linux Genet driver.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl | 2 +-
1 file chang
EDK2's implementation of the LoadImage() boot service permits non-native
binaries to be loaded (i.e., X64 images on IA32 firmware), but any
attempts to start such an image using StartImage() will return
EFI_UNSUPPORTED.
The integration of the PE/COFF emulator protocol into the DXE core
deviates sl
This is the UEFI counterpart to my Linux series which generalizes
mixed mode support into a feature that requires very little internal
knowledge about the architecture specifics of booting Linux on the
part of the bootloader or firmware.
Instead, we add a .compat PE/COFF header containing an array
Add a new 'initrd' command to the UEFI Shell that allows any file that is
accessible to the shell to be registered as the initrd that is returned
when Linux's EFI stub loader invokes the LoadFile2 protocol on its special
vendor media device path.
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/LinuxIn
This is tagged as a v2 since it is a followup to a couple of patches [0][1]
that have already been sent to the list.
This series is part of my effort to define a generic EFI boot protocol for
Linux, i.e,. one that is the same across all different architectures that
are able to boot Linux from EFI,
Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/ArmVirt.dsc.inc | 4
ArmVirtPkg/Ar
Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/OvmfPkgIa32.dsc| 4
OvmfPkg/OvmfPkgIa32.fdf
Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions,
it can be used in a media device path to specify a Linux style initrd
that can be loaded by the OS using the LoadFile2 protocol.
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h | 17 ++
Hi all,
Please ignore it. I made a mistake of sending to the wrong mailing list...
Sorry for the noise.
And have a good day :)
Heyi
On 2020/2/25 17:01, Guoheyi wrote:
The function iort_node_map_id() does the sanity check against the
first mapping in the node, but not the one which we really
The function iort_node_map_id() does the sanity check against the
first mapping in the node, but not the one which we really use.
Logically we need check the mapping we use, or check every mapping in
the node. Choose the first fix for we are not firmware tester.
Signed-off-by: Heyi Guo
---
Cc:
74 matches
Mail list logo
