This wasn't correctly testing for FD to be outside RAM,
when RAM base immediately follows the FD.
This is part of some cleanup for RPi4 in edk2-platform.
Signed-off-by: Andrei Warkentin
---
ArmPlatformPkg/PrePi/PrePi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2552
According to CryptoPkg.dsc, the library class only have HashApiLib, so i
think the BaseHashApiLib should be considered as base name rather than
library class.
Cc: Jian J Wang
Cc: Xiaoyu Lu
Signed-off-by: GuoMinJ
---
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2552
DxeCryptLibConstructor have no comments for it, add comments for it.
Cc: Jian J Wang
Cc: Xiaoyu Lu
Signed-off-by: GuoMinJ
---
.../Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c | 9 +
1 file changed, 9 insertions(+)
diff
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2530
The Suite pointer is used before check if it is valid,
correct it to check the validation before use.
Cc: Michael D Kinney
Cc: Sean Brogan
Cc: Bret Barkelew
Signed-off-by: GuoMinJ
---
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2531
AllocatePool may fail and BinData may be invalid, check
it before use.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: GuoMinJ
---
MdePkg/Test/UnitTest/Library/BaseLib/Base64UnitTest.c | 3 +++
1 file changed, 3 insertions(+)
diff
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Wu,
> Hao A
> Sent: Wednesday, February 26, 2020 9:55 AM
> To: Gaurav Jain; devel@edk2.groups.io
> Cc: Wang, Jian J; Ni, Ray; Ard Biesheuvel; Pankaj Bansal
> Subject: Re: [edk2-devel] [PATCH v3
Laszlo:
Got them. I have added them all in the feature planning. Please help check.
Thanks
Liming
> -Original Message-
> From: annou...@edk2.groups.io On Behalf Of Laszlo
> Ersek
> Sent: Thursday, March 5, 2020 2:24 AM
> To: devel@edk2.groups.io; Gao, Liming ;
>
https://bugzilla.tianocore.org/show_bug.cgi?id=2518
ECC need '.' character at the end of line.
Ray Ni
Rangasai V Chaganty
Signed-off-by: GuoMinJ
---
.../Intel/IntelSiliconPkg/Include/Library/ConfigBlockLib.h | 6 +++---
.../Library/BaseConfigBlockLib/BaseConfigBlockLib.c | 6 +++---
This patch is for [edk2-platform]. So, please generate the patch with it. Below
command can be used.
git format-patch -1 --subject-prefix="edk2-platform][patch"
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Zhang, Shenglei
> Sent: Thursday, March 5, 2020 1:05 PM
> To:
Please update the subject " MdePkg/UnitTestBaseLib: Add check for pointer
BinData"
With this updated, Reviewed-by: Shenglei Zhang
We should try to describe the changes in subject rather than a problem it fixes.
It can be described in the body of commit message.
Thanks,
Shenglei
>
Please update the subject. " IntelSiliconPkg: Add periods in comments"
With this updated, Reviewed-by: Shenglei Zhang
Thanks,
Shenglei
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> GuoMinJ
> Sent: Sunday, February 16, 2020 12:43 PM
> To:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2531
AllocatePool may fail and BinData may be invalid, check
it before use.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: GuoMinJ
---
MdePkg/Test/UnitTest/Library/BaseLib/Base64UnitTest.c | 3 +++
1 file changed, 3 insertions(+)
diff
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wu, Hao A
> Sent: Monday, March 02, 2020 3:52 PM
> To: Albecki, Mateusz; devel@edk2.groups.io
> Cc: Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: Re: [edk2-devel] [PATCHv3 0/5]
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wu, Hao A
> Sent: Wednesday, February 26, 2020 8:51 AM
> To: devel@edk2.groups.io; Albecki, Mateusz
> Cc: Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: Re: [edk2-devel] [PATCHv2 1/1]
Fix typo of successfully
Signed-off-by: Ashley E Desimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Erik Bjorge
---
edkrepo/common/common_repo_functions.py | 2 +-
edkrepo/common/humble.py| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2538
For LzmaCompress or BrotliCompress, the platform may use the different
options and add their batch file, such as LzmaCompressPlatform.
Then, specify it in platform.dsc [BuildOptions] to override the default
one in tools_def.txt.
Reviewed-by: Dandan Bi
Thanks,
Dandan
> -Original Message-
> From: Daniel Schaefer [mailto:daniel.schae...@hpe.com]
> Sent: Monday, March 2, 2020 6:33 PM
> To: devel@edk2.groups.io
> Cc: Abner Chang ; Gilbert Chen
> ; Leif Lindholm ; Bi, Dandan
> ; Dong, Eric
> Subject: [PATCH v2 3/3]
On 2020.03.04 22:31, Andrei Warkentin wrote:
The original change*** used positive logic (PcdPi4GBEnabled), while the
upstreamed change uses negative logic (PcdRamLimitTo3GB), which
requires an additional condition, or it blows up on 1GiB and 2GiB boards.
Good catch!
Tested on 2GB and 4GB
On 2020.03.04 22:31, Andrei Warkentin wrote:
Right now there was no way to tell you're booting with RAM limited
to 3GB, since the setup front page still listed 4096 MB.
Fix this by honoring PcdRamLimitTo3GB in PlatformSmbiosDxe.
Tested on 2GB and 4GB boards (with limiting and without)
Right now there was no way to tell you're booting with RAM limited
to 3GB, since the setup front page still listed 4096 MB.
Fix this by honoring PcdRamLimitTo3GB in PlatformSmbiosDxe.
Tested on 2GB and 4GB boards (with limiting and without)
Signed-off-by: Andrei Warkentin
---
The original change*** used positive logic (PcdPi4GBEnabled), while the
upstreamed change uses negative logic (PcdRamLimitTo3GB), which
requires an additional condition, or it blows up on 1GiB and 2GiB boards.
Tested on 2GB and 4GB boards (with limiting and without)
***
Dear all,
Here are two minor fixes to the recently checked-in runtime logic
for enabling/disabling 3GB limit.
It's been tested on 2GB and 4GB boards.
Andrei Warkentin (2):
Platform/RaspberryPi/Drivers/ConfigDxe: fix bug in 3GB RAM logic
Platform/RaspberryPi/Drivers/PlatformSmbiosDxe:
Machines should be able to boot after this commit. Tested with different
Linux distributions (Ubuntu, CentOS) and different Windows
versions (Windows 7, Windows 10, Server 2016).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
The controller supports up to 8 targets (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each
one that responds.
Support for
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.
See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for
Enable the IO Space and Bus Mastering and restore the original values
when the device is stopped. This is a standard procedure in PCI
drivers.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
OvmfPkg/MptScsiDxe/MptScsi.c | 42
The MptScsiControllerSupported function is called on handles passed in
by the ConnectController() boot service and if the handle is the
lsi53c1030 controller the function would return success. A successful
return value will attach our driver to the device.
Ref:
This will give us an exclusive access to the PciIo of this device
after it was started and until is will be stopped.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
OvmfPkg/MptScsiDxe/MptScsi.c | 30 +-
1 file changed, 29
Used to identify the individual disks in the hardware tree
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
OvmfPkg/MptScsiDxe/MptScsi.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git
Install Component Name protocols to have a nice display name for the
driver in places such as UEFI shell.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
Reviewed-by: Laszlo Ersek
Reviewed-by: Jaben Carsey
---
OvmfPkg/MptScsiDxe/MptScsi.c | 61
Support dynamic insertion and removal of the protocol
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
Reviewed-by: Laszlo Ersek
---
OvmfPkg/MptScsiDxe/MptScsi.c | 179 +-
OvmfPkg/MptScsiDxe/MptScsiDxe.inf | 5 +-
2
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 feature parity with SeaBIOS.
We have also developed support for
In order to probe and connect to the MptScsi device we need this
protocol. Currently it does nothing.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
Reviewed-by: Laszlo Ersek
---
OvmfPkg/MptScsiDxe/MptScsi.c | 68 ++-
Currently we accept only Pun=0 and Lun=0, but we will relax this in a
later patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
OvmfPkg/MptScsiDxe/MptScsi.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff
Support for multiple targets will be implemented in a later commit in
this series.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
Reviewed-by: Laszlo Ersek
---
OvmfPkg/MptScsiDxe/MptScsi.c | 38 +--
In preparation for implementing LSI Fusion MPT SCSI devices, create a
basic scaffolding for a driver.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko
---
OvmfPkg/MptScsiDxe/MptScsi.c | 30 +
> On Mar 4, 2020, at 10:18 AM, Laszlo Ersek wrote:
>
> On 03/04/20 18:53, Andrew Fish wrote:
>>
>>
>>> On Mar 4, 2020, at 5:33 AM, Laszlo Ersek wrote:
>>>
>>> On 03/03/20 22:12, Vitaly Cheptsov wrote:
Hello,
I am creating a new thread for this issue, as for some reason half
Hi Liming,
On 03/04/20 10:03, Liming Gao wrote:
> If you have ideas for features in the next stable tag, please enter a
> Bugzilla for evaluation. Please let me know if there are existing
> open Bugzilla entries that should be targeted at this next stable
> tag.
Apologies for responding for the
On 03/04/20 18:53, Andrew Fish wrote:
>
>
>> On Mar 4, 2020, at 5:33 AM, Laszlo Ersek wrote:
>>
>> On 03/03/20 22:12, Vitaly Cheptsov wrote:
>>> Hello,
>>>
>>> I am creating a new thread for this issue, as for some reason half of my
>>> messages do not display in the web-interface and some of
Hi Liming,
On 03/04/20 10:03, Liming Gao wrote:
> If you have ideas for features in the next stable tag, please enter a
> Bugzilla for evaluation. Please let me know if there are existing open
> Bugzilla entries that should be targeted at this next stable tag.
Can you please include (in the
In the AARCH64 version of ArmMmuLib, we are currently relying on
set/way invalidation to ensure that the caches are in a consistent
state with respect to main memory once we turn the MMU on. Even if
set/way operations were the appropriate method to achieve this, doing
an invalidate-all first and
Make the CONSTRUCTOR define in the .INF AARCH64 only, so we can drop
the empty stub that exists for ARM.
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c | 9 -
ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf | 2 ++
2 files changed, 2 insertions(+), 9
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
Suspiciously, ArmLib's INF does not contain a [LibraryClasses]
section at all, but it turns out that all the library includes
it contains (except for ArmLib.h itself) are actually bogus so
let's just drop all of them. While at it, replace with
the more accurate for a BASE type module, and put
The clean/invalidate helper functions that operate on a single cache
line identified by set, way and level in a special, architected format
are only used by the implementations of the clean/invalidate routines
that operate on the entire cache hierarchy, as exposed by ArmLib.
The latter routines
On ARMv7 and up, doing cache maintenance by set/way is only
permitted in the context of on/offlining a core, and any other
uses should be avoided. Add ASSERT()s in the right place to
ensure that any uses with the MMU enabled are caught in DEBUG
builds.
Signed-off-by: Ard Biesheuvel
---
This is a combination of v1 'ArmPkg: eradicate and deprecate by set/way cache
ops' and v1 'ArmPkg/ArmLib: ASSERT() on misuse of set/way ops'
As it turns out, there were still some instances of set/way ops left in
the core code, in ArmMmuLib to be precise.
This series fixes ArmMmuLib to perform
Unlike the AArch64 implementation of ArmMmuLib, which combines the
initial page table population code with the code that runs at later
stages to manage permission attributes in the page tables, ARM uses
two completely separate sets of routines for this.
Since ArmMmuLib is a static library, we can
ArmLib is a BASE type library, which should not depend or
even be aware on DXE type protocols. So drop the reference
to gEfiCpuArchProtocolGuid.
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/ArmLib/ArmBaseLib.inf | 3 ---
1 file changed, 3 deletions(-)
diff --git
In the ARM version of ArmMmuLib, we are currently relying on set/way
invalidation to ensure that the caches are in a consistent state with
respect to main memory once we turn the MMU on. Even if set/way
operations were the appropriate method to achieve this, doing an
invalidate-all first and then
On 03/04/20 16:50, Philippe Mathieu-Daudé wrote:
> On 3/4/20 10:44 AM, Laszlo Ersek wrote:
>> Repo: https://pagure.io/lersek/edk2.git
>> Branch: timeout_var
>>
>> In the PlatformBootManagerLib instances, set the Timeout global variable
>> to the same value as PcdPlatformBootTimeOut. This way the
On 03/04/20 14:29, Philippe Mathieu-Daudé wrote:
> On 3/2/20 8:59 PM, Laszlo Ersek wrote:
>> On 02/26/20 23:11, Laszlo Ersek wrote:
>>> Supersedes: <20200223172537.28464-1-ler...@redhat.com>
>>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
>>> Repo:
> On Mar 4, 2020, at 5:33 AM, Laszlo Ersek wrote:
>
> On 03/03/20 22:12, Vitaly Cheptsov wrote:
>> Hello,
>>
>> I am creating a new thread for this issue, as for some reason half of my
>> messages do not display in the web-interface and some of e-mail clients in
>> the previous one. It
Currently, the 'runaxf' shell command that exists only on ARM's own
development platforms deals with the caches in an unsafe manner, as
it relies on set/way maintenance to ensure that the ELF image it has
put into memory, as well as the running image itself is visible in
memory after the MMU and
On Fri, 21 Feb 2020 at 16:54, Laszlo Ersek wrote:
>
> On 02/21/20 12:07, 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
On Wed, 4 Mar 2020 at 13:11, Leif Lindholm wrote:
>
> On Wed, Mar 04, 2020 at 12:58:41 +0100, Ard Biesheuvel wrote:
> > This driver depends on the gEfiCpuArchProtocolGuid protocol but does
> > not declare it, and so this dependency gets satisfies transitively
> > via ArmLib. However, ArmLib will
On Mon, 2 Mar 2020 at 14:12, Leif Lindholm wrote:
>
> On Mon, Mar 02, 2020 at 14:00:54 +0100, Ard Biesheuvel wrote:
> > On Mon, 2 Mar 2020 at 13:57, Leif Lindholm wrote:
> > >
> > > On Wed, Feb 26, 2020 at 13:41:03 +0100, Ard Biesheuvel wrote:
> > > > Commit 2fe25a74d6fee3c2
On Wed, 4 Mar 2020 at 17:58, Laszlo Ersek wrote:
>
> On 03/04/20 12:49, Ard Biesheuvel wrote:
> > The Linaro CI reports:
> >
> >
> > OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
> > error: variable 'Status' is used uninitialized whenever 'if' condition is
>
On 03/04/20 12:39, GuoMinJ wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2553
>
> The comment haven't indicate the output attribute.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Signed-off-by: GuoMinJ
> ---
> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 2 +-
>
On 03/04/20 12:49, Ard Biesheuvel wrote:
> The Linaro CI reports:
>
>
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
> error: variable 'Status' is used uninitialized whenever 'if' condition is
> false [-Werror,-Wsometimes-uninitialized]
>
On 3/4/20 10:44 AM, Laszlo Ersek wrote:
Repo: https://pagure.io/lersek/edk2.git
Branch: timeout_var
In the PlatformBootManagerLib instances, set the Timeout global variable
to the same value as PcdPlatformBootTimeOut. This way the "setvar"
command in the UEFI shell, and the "efibootmgr"
On Wed, 4 Mar 2020 at 15:51, Laszlo Ersek wrote:
>
> On 03/04/20 10:54, Ard Biesheuvel wrote:
> > On Wed, 4 Mar 2020 at 10:44, Laszlo Ersek wrote:
> >>
> >> Repo: https://pagure.io/lersek/edk2.git
> >> Branch: timeout_var
> >>
> >> In the PlatformBootManagerLib instances, set the Timeout
On 03/04/20 10:54, Ard Biesheuvel wrote:
> On Wed, 4 Mar 2020 at 10:44, Laszlo Ersek wrote:
>>
>> Repo: https://pagure.io/lersek/edk2.git
>> Branch: timeout_var
>>
>> In the PlatformBootManagerLib instances, set the Timeout global variable
>> to the same value as PcdPlatformBootTimeOut. This
On 03/04/20 10:03, Gao, Liming wrote:
> Hi, all
>
> The tag edk2-stable202002 has been created.
> https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
> git clone -b edk2-stable202002 https://github.com/tianocore/edk2.git
>
> The tag edk2-stable202002 has been added into the main
Hi Laszlo,
Got it. Go ahead.
Thanks,
Eric
-Original Message-
From: Laszlo Ersek
Sent: Wednesday, March 4, 2020 8:23 PM
To: devel@edk2.groups.io; Dong, Eric
Cc: Ard Biesheuvel ; Igor Mammedov
; Yao, Jiewen ; Justen, Jordan L
; Kinney, Michael D ;
Philippe Mathieu-Daudé ; Ni, Ray ;
Reviewed-by: Eric Dong
-Original Message-
From: devel@edk2.groups.io On Behalf Of GuoMinJ
Sent: Wednesday, March 4, 2020 7:39 PM
To: devel@edk2.groups.io
Cc: GuoMinJ ; Dong, Eric ; Ni, Ray
; Laszlo Ersek
Subject: [edk2-devel] [PATCH v2] UefiCpuPkg/MpInitLib: ECC issue.
REF:
On 03/03/20 22:12, Vitaly Cheptsov wrote:
> Hello,
>
> I am creating a new thread for this issue, as for some reason half of my
> messages do not display in the web-interface and some of e-mail clients in
> the previous one. It seems that somebody sent broken HTML code to groups.io
>
On 3/2/20 8:59 PM, Laszlo Ersek wrote:
On 02/26/20 23:11, Laszlo Ersek wrote:
Supersedes: <20200223172537.28464-1-ler...@redhat.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Repo: https://github.com/lersek/edk2.git
Branch: vcpu_hotplug_smm_bz_1512_v2
V1 was
On 02/27/20 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 more LF lines.
On 02/26/20 23:11, Laszlo Ersek wrote:
> Supersedes: <20200223172537.28464-1-ler...@redhat.com>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
> Repo: https://github.com/lersek/edk2.git
> Branch: vcpu_hotplug_smm_bz_1512_v2
>
> V1 was posted at:
>
> * [edk2-devel]
On 02/26/20 16:24, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Hi,
>
> The following patches add basic TPM 1.2 support for Ovmf/QEMU.
>
> Tested successfully Win10 with TIS/TPM 1.2 & CRB/TPM 2.0 passthrough,
> and emulated CRB/TPM 2.0.
>
> Git branch:
Hi Eric,
On 02/28/20 04:05, Dong, Eric wrote:
> 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
On Mon, Mar 02, 2020 at 14:15:58 +0100, Ard Biesheuvel wrote:
> > > > > @@ -257,7 +259,11 @@ FillTranslationTable (
> > > > > RemainLength >= TT_DESCRIPTOR_SECTION_SIZE) {
> > > > >// Case: Physical address aligned on the Section Size (1MB) &&
> > > > > the length
> > > > >
On Wed, Mar 04, 2020 at 12:58:41 +0100, Ard Biesheuvel wrote:
> This driver depends on the gEfiCpuArchProtocolGuid protocol but does
> not declare it, and so this dependency gets satisfies transitively
> via ArmLib. However, ArmLib will drop this dependency as it does not
> actually use it, so
On Mon, 2 Mar 2020 at 14:16, Ard Biesheuvel wrote:
>
> On Mon, 2 Mar 2020 at 14:13, Leif Lindholm wrote:
> >
> > On Wed, Feb 26, 2020 at 11:03:53 +0100, Ard Biesheuvel wrote:
> > > Cache maintenance on ARMv7 systems and up should be done by virtual
> > > address if the purpose is to manage the
This driver depends on the gEfiCpuArchProtocolGuid protocol but does
not declare it, and so this dependency gets satisfies transitively
via ArmLib. However, ArmLib will drop this dependency as it does not
actually use it, so declare it for LcdGraphicsOutputDxe instead.
Signed-off-by: Ard
On Wed, 4 Mar 2020 at 12:52, Ard Biesheuvel wrote:
>
> On Wed, 4 Mar 2020 at 12:47, Leif Lindholm wrote:
> >
> > On Wed, Mar 04, 2020 at 12:42:50 +0100, Ard Biesheuvel wrote:
> > > Currently, the 'runaxf' shell command that exists only on ARM's own
> > > development platforms deals with the
On Wed, 4 Mar 2020 at 12:47, Leif Lindholm wrote:
>
> On Wed, Mar 04, 2020 at 12:42:50 +0100, Ard Biesheuvel wrote:
> > Currently, the 'runaxf' shell command that exists only on ARM's own
> > development platforms deals with the caches in an unsafe manner, as
> > it relies on set/way maintenance
The Linaro CI reports:
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
error: variable 'Status' is used uninitialized whenever 'if' condition is
false [-Werror,-Wsometimes-uninitialized]
if (mInitrdLoadFile2Handle != NULL) {
On Wed, Mar 04, 2020 at 12:42:50 +0100, Ard Biesheuvel wrote:
> Currently, the 'runaxf' shell command that exists only on ARM's own
> development platforms deals with the caches in an unsafe manner, as
> it relies on set/way maintenance to ensure that the ELF image it has
> put into memory, as
Currently, the 'runaxf' shell command that exists only on ARM's own
development platforms deals with the caches in an unsafe manner, as
it relies on set/way maintenance to ensure that the ELF image it has
put into memory, as well as the running image itself is visible in
memory after the MMU and
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2553
The comment haven't indicate the output attribute.
Cc: Eric Dong
Cc: Ray Ni
Cc: Laszlo Ersek
Signed-off-by: GuoMinJ
---
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 2 +-
UefiCpuPkg/Library/MpInitLib/MpLib.h| 2 +-
Hi Abner,
For NetworkPkg (3-4/9) & MdePkg/Include (6/9):
Reviewed-by: Maciej Rabeda
Thanks,
Maciej
On 29-Feb-20 15:13, Abner Chang wrote:
BZ:2562
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
EDK2 CI report (RISCV64 only):
https://github.com/tianocore/edk2-staging/pull/196
EDK2 CI
On Wed, 4 Mar 2020 at 10:44, Laszlo Ersek wrote:
>
> Repo: https://pagure.io/lersek/edk2.git
> Branch: timeout_var
>
> In the PlatformBootManagerLib instances, set the Timeout global variable
> to the same value as PcdPlatformBootTimeOut. This way the "setvar"
> command in the UEFI shell, and
In an upcoming patch, we will introduce a separate DXE driver that
exposes the virtual SimpleFileSystem implementation that carries the
kernel and initrd passed via the QEMU command line, and a separate
library that consumes it, to be incorporated into the boot manager.
Since the GUID used for
Introduce the QemuLoadImageLib library class that we will instantiate
to load the kernel image passed via the QEMU command line using the
standard LoadImage boot service.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
Replace the open coded sequence to load Linux on x86 with a short and
generic sequence invoking QemuLoadImageLib, which can be provided by
a generic version that only supports the LoadImage and StartImage boot
services, and one that incorporates the entire legacy loading sequence
as well.
Ref:
Expose the existing implementation of an abstract filesystem exposing
the blobs passed to QEMU via the command line via a standalone DXE
driver.
Notable difference with the original code is the switch to a new vendor
GUIDed media device path, as opposed to a vendor GUID hardware device
path,
Linux v5.7 will introduce a new method to load the initial ramdisk
(initrd) from the loader, using the LoadFile2 protocol installed on a
special vendor GUIDed media device path.
Add support for this to our QEMU command line kernel/initrd loader.
Ref:
Implement QemuLoadImageLib, and make it load the image provided by the
QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented
in a preceding patch in a separate DXE driver, using only the standard
LoadImage and StartImage boot services.
Ref:
Add the components that expose the QEMU abstract loader file system so
that we can switch over our PlatformBmLib over to it in a subsequent
patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
OvmfPkg/OvmfPkgIa32.dsc| 2
On x86, the kernel image consists of a setup block and the actual kernel,
and QEMU presents these as separate blobs, whereas on disk (and in terms
of PE/COFF image signing), they consist of a single image.
So add support to our FS loader driver to expose files via the abstract
file system that
Add the QEMU loader DXE driver and client library to the build for
our QEMU targeted implementations in ArmVirtPkg.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/ArmVirtQemu.dsc | 2 ++
The QemuLoadImageLib implementation we currently use for all OVMF
builds copies the behavior of the QEMU loader code that precedes it,
which is to disregard UEFI secure boot policies entirely when it comes
to loading kernel images that have been specified on the QEMU command
line. This behavior
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard
Implement another version of QemuLoadImageLib that uses LoadImage and
StartImage, but falls back to the legacy Linux loader code if that
fails. The logic in the legacy fallback routines is identical to the
current QEMU linux loader for X64 and IA32.
Note the use of a LoadedImage pseudo-protocol
We have no need for exposing the kernel command line as a file,
so remove support for that. Since the remaining blobs (kernel
and initrd) are typically much larger than a page, switch to
the page based allocator for blobs at the same time.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
On ArmVirtQemu, we require the kernel passed via the QEMU -kernel option
to have a PE/COFF header and an EFI stub, so that it can be loaded and
started using the LoadImage and StartImage boot services, respectively.
This means that, on builds that enable secure boot or measured boot, the
kernel
In preparation of moving the legacy x86 loading to an implementation
of the QEMU load image library class, introduce a protocol header
and GUID that we will use to identify legacy loaded images in the
protocol database.
Signed-off-by: Ard Biesheuvel
---
Repo: https://pagure.io/lersek/edk2.git
Branch: timeout_var
In the PlatformBootManagerLib instances, set the Timeout global variable
to the same value as PcdPlatformBootTimeOut. This way the "setvar"
command in the UEFI shell, and the "efibootmgr" command in a Linux
guest, can report the front
1 - 100 of 111 matches
Mail list logo
