On 02/26/20 17:41, Nikita Leshenko wrote:
> This series adds driver support for:
> - LSI53C1030
> - SAS1068
> - SAS1068E
>
> These controllers are widely supported by QEMU, VirtualBox and VMWare. This
> work
> is part of the more general agenda of enhancing OVMF boot device support to
> have
>
Leo,
Thanks for your quick reply.
My most concern part to your patch is to expose a new API in LocalApicLib
checking whether the processor is AMD type. LocalApicLib is a library that
operates on Local APIC registers while checking CPU type deals with CPUID
signature. It's not proper to mix the
Lefi and Laszlo:
I add my comments.
> -Original Message-
> From: Laszlo Ersek
> Sent: Friday, February 28, 2020 1:25 AM
> To: Leif Lindholm ; devel@edk2.groups.io; Gao, Liming
>
> Cc: Kinney, Michael D ; af...@apple.com; Guptha,
> Soumya K ; Marvin
> Häuser ; Gao, Zhichao ;
>
> On Feb 26, 2020, at 1:42 AM, Laszlo Ersek wrote:
>
> Hi Andrew,
>
> On 02/25/20 22:35, Andrew Fish wrote:
>
>> Laszlo,
>>
>> The FLASH offsets changing breaking things makes sense.
>>
>> I now realize this is like updating the EFI ROM without rebooting the
>> system. Thus changes in how
Hi Laszlo,
Thanks for your patch. The change make sense base on the comments in the data
structure header file.
I also checked all the code related to this data structure. The inputs for this
data structure are CpuS3DataDxe and RegisterCpuFeaturesLib. Both these two
drivers not support CPU
Also include NetworkPkg reviewer to collect the feedback for this change.
Thanks
Liming
> -Original Message-
> From: Laszlo Ersek
> Sent: Friday, February 28, 2020 1:40 AM
> To: devel@edk2.groups.io; maciej.rab...@linux.intel.com; Gao, Liming
> ; Kinney, Michael D
> ; Andrew Fish ;
Laszlo, I agree BZ status should be update in time. You do a very good
practices about that. I need to learn from you. And thank you that you have
done a lot on BZ maintenance for me and other assignees.
I think we need have a document to record these good practices on BZ
maintenance so that
On Thu, 27 Feb 2020 at 22:39, Laszlo Ersek wrote:
>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1659
> Repo: https://github.com/lersek/edk2.git
> Branch: crlf_bz_1659
>
> Future patches for some Arm*Pkg source files would either introduce CRLF
> lines into LF files, or add
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1659
Repo: https://github.com/lersek/edk2.git
Branch: crlf_bz_1659
Future patches for some Arm*Pkg source files would either introduce CRLF
lines into LF files, or add more LF lines. The first would increase
inconsistency, the second
On Wed, 26 Feb 2020 at 20:43, Ard Biesheuvel wrote:
>
> 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
On Thu, 27 Feb 2020 at 19:14, Laszlo Ersek wrote:
>
> On 02/27/20 15:40, 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
On 02/27/20 15:40, 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
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and
This patch series aims to refactor command processing to achieve following
- Trace the failing TRB packets to see what commands are failing and for what
reasons
- Get the response data even if data transfer timed out to allow easier
debugging
- Fix the PIO mode which is currently completely
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed
Current driver does not support PIO transfer mode for
commands other then tuning. This change adds the code
to transfer PIO data.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 3 +
This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
Driver code used to map memory for DMA transfer even if host doesn't
support DMA. This is causing memory corruption when driver transfers
data using PIO. This change refactors the code to skip call to
PciIo->Map for non DMA transfers.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming
On 02/27/20 17:23, Leif Lindholm wrote:
> Hi Liming,
>
> On Thu, Feb 27, 2020 at 16:06:22 +, Liming Gao wrote:
>> Stewards:
>> I update the patch lists and status. Based on current information,
>> only one patch (item 5) needs catch this stable tag. Its fix is
>> clear, and risk is low.
On 02/27/20 16:53, Feng, Bob C wrote:
> [Bob] I agree the BZ status should be update in time. I don't think BZ status
> update is the reviewer's/maintainer's responsibility, the BZ owner should be
> responsible for it.
Agreed.
>
> NOTE: GitHub.com Pull Requests would not help *at all* in the
Hi Liming,
On Thu, Feb 27, 2020 at 16:06:22 +, Liming Gao wrote:
> Stewards:
> I update the patch lists and status. Based on current information,
> only one patch (item 5) needs catch this stable tag. Its fix is
> clear, and risk is low. So, I think we can still keep current
>
Stewards:
I update the patch lists and status. Based on current information, only one
patch (item 5) needs catch this stable tag. Its fix is clear, and risk is low.
So, I think we can still keep current planning to create stable tag
edk2-stable202002 on 2020 Feb 28th (UTC – 8). If you think
Hi Laszlo,
Thanks for your comments. I add comments inline.
Thanks,
Bob
-Original Message-
From: devel@edk2.groups.io On Behalf Of Laszlo Ersek
Sent: Thursday, February 27, 2020 8:39 PM
To: Feng, Bob C ; Andrew Fish ; Leif
Lindholm ; Kinney, Michael D ;
Gao, Liming
Cc:
Mike,
Flexible array members must be the last element of a struct but they can not
be the only element.
This is non standard behavior from the compilers that are not throwing the
error.
Why not just use a pointer?
> On Feb 26, 2020, at 10:03 PM, Michael D Kinney
> wrote:
>
> Liming,
>
>
On 02/27/20 15:40, Ard Biesheuvel wrote:
> Enable the TPM2 support module in the DXE phase, and the associated
> libraries and PCDs that it requires. This will be wired into the
> measured boot support code in a subsequent patch.
>
> Note that Tcg2Dxe.inf is added to ArmVirtQemuFvMain.fdf.inc,
On 2/27/20 3:40 PM, 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 PCD
On 02/27/20 15:40, Ard Biesheuvel wrote:
> In preparation of conditializing the choice of resolution based on
> TPM2_ENABLE for ArmVirtQemu, move the TpmMeasurementLib out of the
> shared .DSC include and into the individual DSCs.
>
> Signed-off-by: Ard Biesheuvel
> ---
>
On 02/27/20 15:40, Ard Biesheuvel wrote:
> DxeTpmMeasurementLib should only be used on platforms that implement
> measured boot, which we will do in a future patch, but only for
> ArmVirtQemu, as the remaining ones are fundamentally incompatible,
> given that they do not implement a PEI phase.
>
Reviewed-by: Liming Gao
Tested-by: Liming Gao -Original Message-
> From: devel@edk2.groups.io On Behalf Of Bob Feng
> Sent: Thursday, February 27, 2020 10:25 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Laszlo Ersek ; Leif
> Lindholm ; Kinney, Michael D
> ; Pierre Gondois
>
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
Enable the DXE phase component that publishes the HII pages and
associated logic to enable TPM2 parameters to be configured by
the user via the setup menu.
This patch ports (parts of) the following commits to ArmVirtQemu:
- 3103389043bd ("OvmfPkg: Add TCG2 Configuration menu to the Device
Enable the TPM2 support module in the DXE phase, and the associated
libraries and PCDs that it requires. This will be wired into the
measured boot support code in a subsequent patch.
Note that Tcg2Dxe.inf is added to ArmVirtQemuFvMain.fdf.inc, which
is shared with other platforms in ArmVirtPkg,
Now that all the TPM2 related plumbing is in place, we can add the
final piece that performs the measurements of loaded images into
the appropriate PCRs.
This patch ports commit d5a002aba0aa ("OvmfPkg: plug
DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09) to ArmVirtQemu.
Signed-off-by:
In preparation of conditializing the choice of resolution based on
TPM2_ENABLE for ArmVirtQemu, move the TpmMeasurementLib out of the
shared .DSC include and into the individual DSCs.
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/ArmVirt.dsc.inc | 1 -
ArmVirtPkg/ArmVirtQemu.dsc | 1
Incorporate the PEI components and the associated library class
resolutions and PCD declarations to enable TPM2 support in the
PEI phase.
This patch ports (parts of) the following OvmfPkg commits to
ArmVirtQemu:
- 6cf1880fb5b6 ("OvmfPkg: add customized Tcg2ConfigPei clone",
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
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
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.
DxeTpmMeasurementLib should only be used on platforms that implement
measured boot, which we will do in a future patch, but only for
ArmVirtQemu, as the remaining ones are fundamentally incompatible,
given that they do not implement a PEI phase.
So use TpmMeasurementLibNull as the default
As a first step in gradually adding TPM2 support to ArmVirtQemu, add
the TPM2_ENABLE configurable to the [Defines] section, and if it is
set, add the ResetSystem PEIM to the build, along with the library
class references that we will need to support it:
- wire ArmVirtPsciResetSystemPeiLib into the
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
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563
This patch is to fix a incremental build regression bug
which happen when using nmake. That's introduced by 818283de3f6d.
If there is white space before !INCLUDE instruction, nmake will not
process it. Source code's dependent header files
Laszlo:
Thanks for your quick response. I add my comments.
Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek
> Sent: Thursday, February 27, 2020 8:39 PM
> To: Feng, Bob C ; Andrew Fish ; Leif
> Lindholm ; Kinney, Michael D
> ; Gao, Liming
>
(+Liming and stewards; CC Nick)
On 02/27/20 12:02, Maciej Rabeda wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2032
>
> 'ping' command's receive flow utilizes a single Rx token which it
> attempts to reuse before recycling the previously received packet.
> This causes a situation
On 02/27/20 13:39, Laszlo Ersek wrote:
> On 02/27/20 10:47, Bob Feng wrote:
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563
>>
>> This patch is to fix a increametal build regression bug
>> which happen when using nmake. That's introduced by 818283de3f6d.
>>
>> If there is white space
On 02/27/20 10:47, Bob Feng wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563
>
> This patch is to fix a increametal build regression bug
> which happen when using nmake. That's introduced by 818283de3f6d.
>
> If there is white space before !INCLUDE instruction, nmake will not
>
On 02/26/20 22:40, Ard Biesheuvel wrote:
> On Wed, 26 Feb 2020 at 21:32, Brian J. Johnson wrote:
>>
>> I'm not an official reviewer, but I'd feel better about this patch if
>> you added a condition to exit the "while (PeCompat->Type != 0)" loop if
>> PeCompat ever gets pointed outside of the
On Thu, 27 Feb 2020 at 12:07, Laszlo Ersek wrote:
>
> On 02/26/20 20:43, 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
On 02/26/20 20:43, 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
>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2032
'ping' command's receive flow utilizes a single Rx token which it
attempts to reuse before recycling the previously received packet.
This causes a situation where under ICMP traffic,
Ping6OnEchoReplyReceived() function will receive an
On 02/26/20 20:43, 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.
>
Hi Nikita,
On 02/26/20 17:41, Nikita Leshenko wrote:
> This series adds driver support for:
> - LSI53C1030
> - SAS1068
> - SAS1068E
>
> These controllers are widely supported by QEMU, VirtualBox and VMWare. This
> work
> is part of the more general agenda of enhancing OVMF boot device support
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563
This patch is to fix a increametal build regression bug
which happen when using nmake. That's introduced by 818283de3f6d.
If there is white space before !INCLUDE instruction, nmake will not
process it. Source code's dependent header files
On 02/26/20 20:05, Ard Biesheuvel wrote:
> Now that all the TPM2 related plumbing is in place, we can add the
> final piece that performs the measurements of loaded images into
> the appropriate PCRs.
>
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
> 1 file
On 02/26/20 20:05, Ard Biesheuvel wrote:
> Enable the DXE phase component that publishes the HII pages and
> associated logic to enable TPM2 parameters to be configured by
> the user via the setup menu.
>
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/ArmVirtQemu.dsc | 9 +
On 02/26/20 20:05, Ard Biesheuvel wrote:
> Enable the TPM2 support module in the DXE phase, and the associated
> libraries and PCDs that it requires. This will be wired into the
> measured boot support code in a subsequent patch.
>
> Note that Tcg2Dxe.inf is added to ArmVirtQemuFvMain.fdf.inc,
Agree Nate.
Reviewed-by: Chasel Chiu
Thanks,
Chasel
> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Thursday, February 27, 2020 6:17 AM
> To: Chiu, Chasel ; devel@edk2.groups.io; Agyeman,
> Prince
> Subject: RE: [edk2-devel] [edk2-platforms] [PATCH 2/2]
On Thu, 27 Feb 2020 at 09:24, Laszlo Ersek wrote:
>
> On 02/26/20 20:05, Ard Biesheuvel wrote:
> > Incorporate the PEI components and the associated library class
> > resolutions and PCD declarations to enable TPM2 support in the
> > PEI phase.
> >
> > Signed-off-by: Ard Biesheuvel
> > ---
> >
On 02/26/20 20:05, Ard Biesheuvel wrote:
> Incorporate the PEI components and the associated library class
> resolutions and PCD declarations to enable TPM2 support in the
> PEI phase.
>
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/ArmVirtQemu.dsc | 20
>
On 02/26/20 20:05, Ard Biesheuvel wrote:
> As a first step in gradually adding TPM2 support to ArmVirtQemu, add
> the TPM2_ENABLE configurable to the [Defines] section, and if it is
> set, add the ResetSystem PEIM to the build, along with the library
> class references that we will need to support
63 matches
Mail list logo
