On Fri, 6 Mar 2020 at 03:01, Feng, Bob C wrote:
>
> Hi Ard,
>
> I found this patch set cause Ovmf platform build failure on windows with
> VS2017.
>
> The error message is as following:
>
> Generating code
> d:\edk2\OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): error
> C2220:
Bob reports that VS2017 chokes on a tentative definition of the const
object 'mEfiFileProtocolTemplate', with the following error:
OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130):
error C2220: warning treated as error - no 'object' file generated
On Fri, 6 Mar 2020 at 00:45, Laszlo Ersek wrote:
>
> On 03/05/20 22:26, Ard Biesheuvel wrote:
> > Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to
> > QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
> > QemuLoadImageLib in the PlatformBootManagerLib
From: Daniel Schaefer
RISC-V doesn't have SMM.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Daniel Schaefer
Cc: Abner Chang
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Dandan Bi
Cc: Liming Gao
Cc: Jian J Wang
Cc: Hao A Wu
---
MdeModulePkg/MdeModulePkg.dsc |
From: Daniel Schaefer
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Daniel Schaefer
Cc: Abner Chang
Cc: Gilbert Chen
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
---
MdePkg/Library/DxeServicesLib/DxeServicesLib.inf | 4 ++--
1 file changed, 2
BZ:2562
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Per to the talk in TianoCore community meeting on 3/6, RISC-V edk2 port is in
the feature list of 2020 May stable tag. We agreed to send RISC-V related
patches against to edk2 master to mail list for review.
Signed-off-by: Abner Chang
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Add RISC-V architecture for EDK2 CI testing.
Signed-off-by: Abner Chang
Cc: Ray Ni
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
FatPkg/FatPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Add RISC-V architecture for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Reviewed-by: Maciej Rabeda
Cc: Jiaxin Wu
Cc: Siyuan Fu
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
NetworkPkg/NetworkPkg.dsc | 4 ++--
1
Add RISC-V architecture to ShellPkg for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Cc: Ray Ni
Cc: Zhichao Gao
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
ShellPkg/ShellPkg.dsc | 3 ++-
1 file changed, 2
Add RISC-V architecture for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Co-authored-by: Daniel Schaefer
Cc: Jian J Wang
Cc: Xiaoyu Lu
Cc: Leif Lindholm
Cc: Gilbert Chen
---
CryptoPkg/CryptoPkg.dsc
Add RISC-V architecture for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Reviewed-by: Maciej Rabeda
Cc: Jiaxin Wu
Cc: Siyuan Fu
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
NetworkPkg/HttpBootDxe/HttpBootDhcp4.h |
Add RISC-V architecture to UnitTestFrameworkPkg for RISC-V EDK2 CI.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Cc: Michael D Kinney
Cc: Sean Brogan
Cc: Bret Barkelew
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
Add RISC-V architecture to SecurityPkg for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Reviewed-by: Jiewen Yao
Cc: Jiewen Yao
Cc: Jian J Wang
Cc: Chao Zhang
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
HTTP/PXE boot RISC-V related definitions for EDK2 CI.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Reviewed-by: Maciej Rabeda
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
Add RISC-V architecture for EDK2 CI testing.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Signed-off-by: Abner Chang
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Schaefer
---
FmpDevicePkg/FmpDevicePkg.dsc | 3 ++-
1 file changed, 2
Hello all:
Need a clarification on the Host Name support added in the HTTP Boot.
When certificates are generated with the Wild Card in the SAN the host name
validation is getting failed with the below error codes.
Ex: DNS Name=*.ami.internal-test.com
TlsDoHandshake SSL_HANDSHAKE_ERROR
This is a required change for the "fix FDT handling for RPi4" patch.
It's the same TF-A, but built with different options:
- PRELOADED_BL33_BASE=0x2 (down from 0x3)
- RPI3_PRELOADED_DTB_BASE=0x1f (up from 0x2)
Signed-off-by: Andrei Warkentin
---
A rev-up of start4.elf VPU firmware meant that
the previous scheme of loading the DTB over top
of RPI_EFI.FD no longer works - the DT is now
loaded way before the armstub, so any overlap
means the DT is overridden.
This change re-arranges a few items in the FD,
allowing the DTB to loaded directly
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.
Miki,
Thanks for the contribution.
I need sometime to look at all the APIs the new library exposes and may get
back to you with more comments next week.
Thanks,
Ray
> -Original Message-
> From: Shindo, Miki
> Sent: Friday, March 6, 2020 6:14 AM
> To: devel@edk2.groups.io
> Cc:
TianoCore Community Meeting Minutes
March 5, 2020
Stable Tag Updates:
1. Edk2 stable tag 202002 has been released:
https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
2. Edk2 stable tag 202005 feature planning has started.
* Features are listed in:
Change looks good. Thanks.
Acked-by: Chasel Chiu
> -Original Message-
> From: Shindo, Miki
> Sent: Friday, March 6, 2020 6:14 AM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Agyeman, Prince
> ; Ni, Ray
> Subject:
Hi Mike, Sean, and Ray,
A BIG thanks to you guys. It was really good to have the EDK2 design meetings
to talk to you guys. I got a lot of valuable feedback from you guys. The
following are what I got from today's meeting and the follow-up I will do. Feel
free to let me know anything I missed
Hi Ard,
I found this patch set cause Ovmf platform build failure on windows with
VS2017.
The error message is as following:
Generating code
d:\edk2\OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): error
C2220: warning treated as error - no 'object' file generated
*Reminder:* TianoCore Design Meeting - APAC/NAMO
*When:* Friday, 6 March 2020, 9:30am to 10:30am, (GMT+08:00) Asia/Chongqing
*Where:* BlueJeans Meeting
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=681239 )
*Organizer:* Ray Ni ray...@intel.com (
*Reminder:* TianoCore Bug Triage - APAC / NAMO
*When:* Thursday, 5 March 2020, 5:00pm to 5:30pm, (GMT-08:00) America/Los
Angeles
*Where:* https://bluejeans.com/889357567?src=calendarLink
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503285 )
*Organizer:* Brian Richardson
From: Andrei Warkentin
The RPi4 TF-A is much smaller than RPi3 TF-A, and doesn't need
an extra 2MB region.
Note: this depends on the edk2 ArmPlatformPkg/PrePi: fix IS_XIP.
Signed-off-by: Andrei Warkentin
---
Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 22
On 03/05/20 22:26, Ard Biesheuvel wrote:
> Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to
> QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
> QemuLoadImageLib in the PlatformBootManagerLib implementation that is
> shared between all OVMF builds, without
On 03/05/20 22:20, Ard Biesheuvel wrote:
> On Thu, 5 Mar 2020 at 22:15, Laszlo Ersek wrote:
>>
>> Hi Ard,
>>
>> On 03/05/20 14:46, Ard Biesheuvel wrote:
>>> Replace the open coded sequence to load Linux on x86 with a short and
>>> generic sequence invoking QemuLoadImageLib, which can be provided
On 03/04/20 20:22, 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 feature
Reviewed-by: Puja Pandya
-Original Message-
From: Desimone, Ashley E
Sent: Wednesday, March 4, 2020 5:49 PM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Pandya, Puja
; Bjorge, Erik C
Subject: [edk2-staging/EdkRepo] [PATCH] EdkRepo: Correct typo in error strings
Fix typo of
On Thu, 5 Mar 2020 at 22:50, Ard Biesheuvel wrote:
>
> As it turns out, ARMv8 (DDI 0487E.a D4.4.5) also permits accesses made
> with the MMU and caches off to hit in the caches, so to ensure that any
> modifications we make before enabling the MMU are visible afterwards as
> well, we should
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2536
This commit adds DxeAslUpdateLib library support in IntelSiliconPkg,
which allows AML to be updated in DXE.
Signed-off-by: Miki Shindo
Cc: Sai Chaganty
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Prince Agyeman
Cc: Ray Ni
Reviewed-by:
As it turns out, ARMv8 (DDI 0487E.a D4.4.5) also permits accesses made
with the MMU and caches off to hit in the caches, so to ensure that any
modifications we make before enabling the MMU are visible afterwards as
well, we should invalidate page tables right after allocation like we do
now on
On Thu, 5 Mar 2020 at 17:29, Leif Lindholm wrote:
>
> On Wed, Mar 04, 2020 at 19:12:37 +0100, Ard Biesheuvel wrote:
> > 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,
Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to
QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
QemuLoadImageLib in the PlatformBootManagerLib implementation that is
shared between all OVMF builds, without taking into account that even
the Xen targeted
On Thu, 5 Mar 2020 at 22:15, Laszlo Ersek wrote:
>
> Hi Ard,
>
> On 03/05/20 14:46, Ard Biesheuvel wrote:
> > 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
Hi Ard,
On 03/05/20 14:46, Ard Biesheuvel wrote:
> 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
On 03/05/20 14:46, Ard Biesheuvel wrote:
> 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.
On Thu, Mar 05, 2020 at 13:59:05 +0100, Ard Biesheuvel wrote:
> A pair of cleanups for issues that I ran into while working on the
> set/way cache maintenance stuff.
For the series:
Reviewed-by: Leif Lindholm
> Ard Biesheuvel (2):
> ArmPkg/ArmMmuLib ARM: simplify assignment of TTBR0 system
On Thu, Mar 05, 2020 at 11:00:28 +0100, Ard Biesheuvel wrote:
> This is a followup to '[PATCH v2 4/9] ArmPkg/ArmMmuLib ARM: cache-invalidate
> initial page table entries', and patch #2 of this series should be folded
> into that.
With the commit message fixup for 2/2 you have already identified
*Reminder:* TianoCore Community Meeting - EMEA/NAMO
*When:* Thursday, 5 March 2020, 9:00am to 10:00am, (GMT-08:00) America/Los
Angeles
*Where:* https://bluejeans.com/889357567?src=join_info
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=621371 )
*Organizer:* Brian Richardson
On Wed, Mar 04, 2020 at 19:12:37 +0100, Ard Biesheuvel wrote:
> 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
On Wed, Mar 04, 2020 at 19:12:38 +0100, 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
On 03/05/20 14:46, Ard Biesheuvel wrote:
> 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 x86 Linux kernels
> in the protocol database.
>
>
On 03/05/20 13:30, Leif Lindholm wrote:
> On Thu, Mar 05, 2020 at 12:23:46 +0100, Ard Biesheuvel wrote:
>> I no longer work for Linaro (and haven't for a while) so in anticipation
>> of losing access to my @linaro.org mailbox, let's switch to the ARM one
>> for my Tiancore contributions and
On 03/05/20 11:40, Ard Biesheuvel wrote:
> On Thu, 5 Mar 2020 at 11:31, Laszlo Ersek wrote:
>>
>> On 03/04/20 10:52, Ard Biesheuvel wrote:
>>> In preparation of moving the legacy x86 loading to an implementation
>>> of the QEMU load image library class, introduce a protocol header
>>> and GUID
On 03/05/20 06:53, Gao, Liming wrote:
> Laszlo:
> Got them. I have added them all in the feature planning. Please help check.
Thank you, it looks good!
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55541):
Ashraf,
I think it might be better to describe my review comments with code
implementation.
Can you please check this branch where I did some modification based on your
code?
https://github.com/niruiyu/edk2/tree/pci/pcie2
Let's firstly align on the feature initialization framework
On Thu, 5 Mar 2020 at 14:52, Ard Biesheuvel wrote:
>
> On Wed, 4 Mar 2020 at 23:31, Andrei Warkentin wrote:
> >
> > 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.
> >
>
>
On Wed, 4 Mar 2020 at 23:31, Andrei Warkentin wrote:
>
> 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.
>
Thanks Andrei,
For future postings, could you please use git send-email or
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 x86 Linux kernels
in the protocol database.
Signed-off-by: Ard Biesheuvel
---
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
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
---
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:
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 ++
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:
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
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:
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
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,
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
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
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 the
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
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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.
The expression passed into ArmSetTTBR0 () in ArmConfigureMmu() is
sub-optimal at several levels:
- TranslationTable is already aligned, and if it wasn't, doing it
here wouldn't help
- TTBRAttributes is guaranteed not to have any bits set outside of
the 0x7f mask, so the mask operation is
We already expect normal memory to be mapped writeback cacheable if
EDK2 itself is to make use of it, so doing an early sanity check on
the memory type of the allocation that the page tables happened to
land in isn't very useful. So let's drop it.
Signed-off-by: Ard Biesheuvel
---
A pair of cleanups for issues that I ran into while working on the
set/way cache maintenance stuff.
Ard Biesheuvel (2):
ArmPkg/ArmMmuLib ARM: simplify assignment of TTBR0 system register
ArmPkg/ArmMmuLib ARM: drop memory type check for page tables
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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.
On Thu, Mar 05, 2020 at 12:23:46 +0100, Ard Biesheuvel wrote:
> I no longer work for Linaro (and haven't for a while) so in anticipation
> of losing access to my @linaro.org mailbox, let's switch to the ARM one
> for my Tiancore contributions and maintainerships. Update the .mailmap
> at the same
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
---
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
---
Reviewed-by: Liran Alon
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
---
Reviewed-by: Liran Alon
-=-=-=-=-=-=-=-=-=-=-=-
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
On 04/03/2020 21:22, Nikita Leshenko wrote:
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 +-
On 04/03/2020 21:22, Nikita Leshenko wrote:
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
---
Reviewed-by: Liran Alon
On 3/5/20 12:38 AM, Pete Batard wrote:
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.
On Thu, 5 Mar 2020 at 12:29, Laszlo Ersek wrote:
>
> On 03/05/20 10:51, Laszlo Ersek wrote:
> > On 03/04/20 10:52, Ard Biesheuvel wrote:
> >> 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
On 03/05/20 10:51, Laszlo Ersek wrote:
> On 03/04/20 10:52, Ard Biesheuvel wrote:
>> 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
I no longer work for Linaro (and haven't for a while) so in anticipation
of losing access to my @linaro.org mailbox, let's switch to the ARM one
for my Tiancore contributions and maintainerships. Update the .mailmap
at the same time so the tooling can rewrite history where needed.
Cc: Andrew Fish
On Thu, 5 Mar 2020 at 11:31, Laszlo Ersek wrote:
>
> On 03/04/20 10:52, Ard Biesheuvel wrote:
> > 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
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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
On Thu, 5 Mar 2020 at 11:00, Ard Biesheuvel wrote:
>
> Instead of performing two cache invalidations for each section entry
> that gets updated, perform the first invalidation, which is intended
> to clean the page tables from caches on systems where cache hits are
> permitted with the MMU and
On Thu, 5 Mar 2020 at 10:39, Laszlo Ersek wrote:
>
> On 03/05/20 10:37, Laszlo Ersek wrote:
> > On 03/04/20 10:52, Ard Biesheuvel wrote:
> >> Introduce the QemuLoadImageLib library class that we will instantiate
> >> to load the kernel image passed via the QEMU command line using the
> >>
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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:
This is a followup to '[PATCH v2 4/9] ArmPkg/ArmMmuLib ARM: cache-invalidate
initial page table entries', and patch #2 of this series should be folded
into that.
Ard Biesheuvel (2):
ArmPkg/ArmMmuLib ARM: use AllocateAlignedPages() for alignment
ArmPkg/ArmMmuLib ARM: invalidate page tables as
Instead of overallocating memory and align the resulting base address
manually, use the AllocateAlignedPages () helper, which achieves the
same, and might even manage that without leaking a chunk of memory of
the same size as the allocation itself.
While at it, fix up a variable declaration in
Instead of performing two cache invalidations for each section entry
that gets updated, perform the first invalidation, which is intended
to clean the page tables from caches on systems where cache hits are
permitted with the MMU and caches off.
Signed-off-by: Ard Biesheuvel
---
On 03/04/20 10:52, Ard Biesheuvel wrote:
> 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
1 - 100 of 106 matches
Mail list logo
