On Thu, 12 Dec 2019 at 01:26, Gao, Liming wrote:
>
> Reviewed-by: Liming Gao
>
Thanks
Pushed as bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798
> > -Original Message-
> > From: Ard Biesheuvel
> > Sent: Wednesday, December 11, 2019 6:01 PM
> > To: Pete Batard ; Kinney, Michael D
> > ; Gao,
Reviewed-by: Ray Ni
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, December 2, 2019 8:54 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Augustine, Linson
> Subject: [PATCH] ShellPkg/ShellProtocol: Return error code while fail parsing
> cmd-line
>
> REF:
OK I see now the Enable PCD is defined in MdeModulePkg, produced in platform
and consumed in MpInitLib.
Is there a way to easily detect whether SEV-ES is enabled? (without triggering
CPUID as what SEC does)
If no, can you define the PCD in UefiCpuPkg?
> -Original Message-
> From: Tom
Is the 16bit code segment descriptor needed in early DXE before CpuDxe (DXE MP)?
> -Original Message-
> From: Tom Lendacky
> Sent: Thursday, November 21, 2019 4:07 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek
> ; Ard Biesheuvel
> ; Kinney, Michael D ;
> Gao,
> + // Allocate GHCB and per-CPU variable pages.
> + //
> + GhcbPageCount = mMaxCpuCount * 2;
> + GhcbBase = AllocatePages (GhcbPageCount);
> + ASSERT (GhcbBase != NULL);
> +
> + GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
> +
> + DecryptStatus = MemEncryptSevClearPageEncMask (
> +
Tom,
When are GHCP pages are allocated? Can DxeIpl gets the address by reading the
GHCB MSR?
Can the GHCB PCD be eliminated by updating all GHCB address consumer to read
the GHCB MSR?
Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Lendacky,
> Thomas
>
Tom,
Why all DR registers are not pushed to stack in VC handler?
I thought only DR7 pushing is skipped.
Thanks,
Ray
> -Original Message-
> From: Tom Lendacky
> Sent: Thursday, November 21, 2019 4:07 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek
> ; Ard Biesheuvel
Do you really need to define the PCD in MdePkg?
General guide lines are:
1. Avoid UefiCpuPkg depend on MdeModulePkg.
2. Do not define platform level PCD in core pkgs (MdePkg, MdeModulePkg,
UefiCpuPkg, etc)
PcdSevEsIsEnabled seems to be used in OVMF pkg only so how about define that in
>
> ;; UINT64 Dr0, Dr1, Dr2, Dr3, Dr6, Dr7;
> +cmp qword [rbp + 8], 29
Can you define a macro instead of using 29?
> +je VcDebugRegs ; For SEV-ES (#VC) Debug registers ignored
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
Hi Ray,
Can you help to review the patch?
Thanks,
Zhichao
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Philippe Mathieu-Daudé
> Sent: Monday, December 2, 2019 7:10 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Ni, Ray ; Augustine,
Actually I didn't do the functionality test of Mandatory one, only do the build
test and logic check. It is part of the Optional one. I assume the optional one
is working fine. Then there would be no problem with Mandatory one.
I would write a test for both of them to make sure they are both
Zhichao:
The change is good. What functionality test is done?
Thanks
Liming
>-Original Message-
>From: Gao, Zhichao
>Sent: Thursday, December 12, 2019 10:09 AM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D ; Gao, Liming
>; Vitaly Cheptsov
>Subject: [PATCH V2 0/2]
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
The UefiDevicePathLibOptionalDevicePathProtocolConstructor's implementation
isn't match with its instance name.
Remove the ASSERT and depex of the gEfiDevicePathUtilitiesProtocolGuid
because of "Optional".
Add a mandatory instance to force
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
UefiDevicePathLibOptionalDevicePathProtocol's implementation isn't
fit its description. It should be implement as blow:
Try to find the DevicePathProtocol, if found then use it to implement
the interface. Else, use the local interface. It
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
Add the new instance lib for build.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Vitaly Cheptsov
Signed-off-by: Zhichao Gao
---
MdePkg/MdePkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MdePkg/MdePkg.dsc
Reviewed-by: Nate DeSimone
-Original Message-
From: Agyeman, Prince
Sent: Friday, December 6, 2019 9:32 AM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kubacki, Michael A
Subject: [PATCH] SimicsOpenBoardPkg: Replace CMOS Hardcoded Addresses
REF:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2409
Updated WhiskeylakeURvp PCDs to enable FSP/BL stack sharing.
This fixes the boot failure seen with the latest Coffee Lake (CFL)
FSP binary (v 7.0.68.41)
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Michael Kubacki
Signed-off-by: Prince
Please include [edk2-platforms] in the subject in the future.
Reviewed-by: Michael Kubacki
> -Original Message-
> From: Agyeman, Prince
> Sent: Friday, December 6, 2019 9:32 AM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Kubacki,
> Michael A
> Subject: [PATCH]
Reviewed-by: Liming Gao
> -Original Message-
> From: Ard Biesheuvel
> Sent: Wednesday, December 11, 2019 6:01 PM
> To: Pete Batard ; Kinney, Michael D
> ; Gao, Liming
> Cc: edk2-devel-groups-io ; Leif Lindholm
> ; Philippe Mathieu-Daudé
>
> Subject: Re: [edk2][PATCH 1/1]
Reviewed-by: Ashley DeSimone
-Original Message-
From: Desimone, Nathaniel L
Sent: Tuesday, December 10, 2019 1:56 AM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Pandya, Puja
; Bret Barkelew
Subject: [edk2-staging/EdkRepo] [PATCH] EdkRepo: Support uninstalling packages
with '_'
Reviewed-by: Ashley DeSimone
-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Nate
DeSimone
Sent: Tuesday, December 10, 2019 1:55 AM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Pandya, Puja
; Bret Barkelew
Subject: [edk2-devel]
This issue happens under two conditions.
1. Unicode language environment in Windows
2. Call 'edksetup.bat forcerebuild' with python subprocess.call()
Steps to reproduce
C:\edk2>python
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40)
Type help, copyright, credits or license
Hi everyone,
I'm working on a HTTPS server on EFI using EDK II, but I found the following
code on *\edk2\CryptoPkg\Library\TlsLib\TlsConfig.c:
* if ( ! IsServer) {
//
// Set TLS to work in Client mode.
//
SSL_set_connect_state (TlsConn->Ssl) ;
} else {
//
// Set TLS to work in Server mode.
//
From: Ard Biesheuvel
This is an improvement of e9db04631b63574b090aeab769cc47dcb75a29f7
where we inhibit serial output of MMIO mapped UARTs to all runtime
drivers rather than just RTC, as other drivers may crash the OS
just the same.
Also add it to the Pi 4 platform where it was missing
On Wed, 11 Dec 2019 at 12:26, Pete Batard wrote:
>
> This series adds basic support to build the Raspberry Pi 4 platform.
>
> It requires the earlier series, that add binary files for the platform,
> to have been applied to edk2-non-osi.
>
> For the introduction of the platform, USB support is
Hi Leif,
On 2019.12.11 14:14, Leif Lindholm wrote:
On Wed, Dec 11, 2019 at 11:24:00 +, Pete Batard wrote:
Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
4 UEFI firmware requires the provision of a Trusted Firmware binary
(TF-A).
The binary is built for a dtb base
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2371
This patch is to fix a regression issue that build fails
if multiple build targets given.
Two changes cause this regression issue.
One is AutoGen object __hash__ function only
hash file path and arch, missing ToolChain and build target.
On 12/10/19 9:04 PM, Ni, Ray wrote:
> Can you please have your slides ready in
>
On Tue, 10 Dec 2019 at 18:25, Vladimir Olovyannikov
wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel
> > Sent: Tuesday, December 10, 2019 9:13 AM
> > To: Vladimir Olovyannikov ; Sami
> > Mujawar
> > Cc: edk2-devel-groups-io
> > Subject: Re: Debugging aarch64 edk2 built with
On Wed, Dec 11, 2019 at 11:24:00 +, Pete Batard wrote:
> Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
> 4 UEFI firmware requires the provision of a Trusted Firmware binary
> (TF-A).
>
> The binary is built for a dtb base address of 0x0002 and a UEFI
> payload base
On Wed, 11 Dec 2019 at 12:24, Pete Batard wrote:
>
> This series of patches adds the binaries we need available to introduce
> Raspberry Pi 4 support.
>
> Similar to the Pi 3, we must have TF-A and Device Tree binaries we can embed.
>
> Pete Batard (2):
> Platforms/RPi4: Add Device Tree
>
Jeff,
Tom from AMD booked the meeting for SEV discussion months ago. I am afraid
there is no time for this discussion.
Let's try to resolve it in mails.
Firstly, let me rephase the problem and your proposed solutions here
(subjective + verb + objective). Sunny's input is also included. Hope
This change is pushed in to the following EDK Repo for review:-
https://github.com/ashrafj/edk2-staging/commit/560b6c1dd5b7eae8c49bd43e83335c7d13fef4a3
Please review and provide your feedback.
Thanks
Ashraf
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Javeed,
> Ashraf
On 12/11/19 12:25 PM, Pete Batard wrote:
From: Ard Biesheuvel
When using ACPI OpRegions to poke device registers, Linux will use
the UEFI memory map to decide which memory attributes to use, and
so they should not be described as cacheable memory.
Since MMIO regions that don't require an OS
On 12/11/19 12:25 PM, Pete Batard wrote:
From: Ard Biesheuvel
Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.
Signed-off-by: Pete Batard
---
From: Ard Biesheuvel
When using ACPI OpRegions to poke device registers, Linux will use
the UEFI memory map to decide which memory attributes to use, and
so they should not be described as cacheable memory.
Since MMIO regions that don't require an OS virtual mapping at runtime
don't really
This series adds basic support to build the Raspberry Pi 4 platform.
It requires the earlier series, that add binary files for the platform,
to have been applied to edk2-non-osi.
For the introduction of the platform, USB support is not yet enabled
which means that user I/O has to be carried out
From: Andrei Warkentin
This enables building the initial RPi4 platform firmware.
Note that PCIe and xHCI are missing at this stage and that this
version of the firmware uses miniUART for serial I/O. PCIe and
xHCI support will be added in a later patch series as well as
the ability to switch
From: Samer El-Haj-Mahmoud
For this initial commit, we duplicate the RPi3 ones.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h | 76 +++
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf | 40 ++
Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc | 326
From: Andrei Warkentin
Update CSRT, DSDT, GTDT, MADT, SDHC and serial tables for the new
base addresses and switch ACPI to GIC.
We use ACPI 5.1 for MADT because older versions of the Linux kernel
can be finicky when it comes to checking the size of the GICC entries
the table: depending on the
From: Ard Biesheuvel
Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 36
+---
1
Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
4 UEFI firmware requires the provision of a Trusted Firmware binary
(TF-A).
The binary is built for a dtb base address of 0x0002 and a UEFI
payload base address of 0x0003.
Binaries are built using a custom version of
This series of patches adds the binaries we need available to introduce
Raspberry Pi 4 support.
Similar to the Pi 3, we must have TF-A and Device Tree binaries we can embed.
Pete Batard (2):
Platforms/RPi4: Add Device Tree
Platforms/RPi4: Add Trusted Firmware binaries
Hello Bob and Liming,
I am coming back to you after re-reading Bob's answer:
> I meet another problem related to .asl file. In one of platforms build
> process, there is a step which need to compile a .asl file a .h file firstly
> and that .h file will be included by a module’s source code.
>
Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi 4
UEFI firmware requires a binary Device Tree for the Broadcom 2711 SoC.
This patch adds the most up to date Device Tree binary, as published
with commit 601d36df3aa541560e4cf9b571105d20db2b4b7c from
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
Two interfaces added to PCI Express Platform Protocol:-
(1) GetDevicePolicy() -> to retrieve device-specific platform policies
(2) NotifyDeviceState -> to notify platform about device PCI Express
configuration state
PCI Express Override
On Mon, 9 Dec 2019 at 09:42, Ard Biesheuvel wrote:
>
> On Mon, 9 Dec 2019 at 03:12, Ni, Ray wrote:
> >
> > > Exactly. This flow is identical to how option ROMs are processed if
> > > they are discovered before EndOfDxe signalling completes (which is why
> > > the Juno platform was broken without
(add MdePkg maintainers)
On Tue, 10 Dec 2019 at 19:23, Pete Batard wrote:
>
> As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
> can be found online, we are missing 2 serial interface types for
> Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).
>
> These same
Created new email account that will not append legal disclaimers to
my responses/patches.
Switching to NetworkPkg maintainer.
Cc: Jiaxin Wu
Cc: Siyuan Fu
Signed-off-by: Maciej Rabeda
---
Maintainers.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Maintainers.txt
Hi all,
Since I can't attend the design meeting (EMEA), I would like to add some use
cases and a suggestion for your guys' reference before this topic being
discussed:
We had similar needs (use cases) as Ashish like the following, so making this
code change would be definitely good for
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: Philippe Mathieu-Daude [mailto:phi...@redhat.com]
Sent: Friday, December 6, 2019 7:27 PM
To: devel@edk2.groups.io
Cc: Philippe Mathieu-Daude ; Zhu, Yonghong
Subject: [PATCH v2 103/105] .mailmap: Add an
51 matches
Mail list logo
