On Thu, 2 Jun 2022 at 21:08, Dov Murik wrote:
>
> Gerd, thanks for the cleanup.
>
>
> Tested-by: Dov Murik
> Reviewed-by: Dov Murik
>
Merged as #2939. Thanks.
>
> On 02/06/2022 12:11, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann
> > ---
> > OvmfPkg/AmdSev/AmdSevX64.dsc | 47
On Thu, 2 Jun 2022 at 13:01, Yao, Jiewen wrote:
>
> Acked-by: Jiewen Yao
>
Merged as #2939. Thanks.
> > -Original Message-
> > From: Gerd Hoffmann
> > Sent: Thursday, June 2, 2022 5:35 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Oliver Steffen
> > ; Gerd Hoffmann ; Ard Bieshe
Hi,
> This seems to be related to the padding logic, i.e., we are trying to
> preserve some extra I/O space for the root port in case we hotplug
> something that might need it.
> --- a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
> +++ b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
> @@ -733,7 +73
On Fri, 3 Jun 2022 at 10:29, Gerd Hoffmann wrote:
>
> Hi,
>
> > This seems to be related to the padding logic, i.e., we are trying to
> > preserve some extra I/O space for the root port in case we hotplug
> > something that might need it.
>
> > --- a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
>
On Thu, 2 Jun 2022 at 10:42, Gerd Hoffmann wrote:
>
> Needs two little tweaks in PCI code because microvm supports mmio only.
> Other than that just wire up the existing code (the PCIe host adapter
> used by microvm is the same (virtual) hardware used by the arm/aarch64
> virtual machines).
>
> v7
Merged https://github.com/tianocore/edk2/pull/2942
> -Original Message-
> From: Boeuf, Sebastien
> Sent: Thursday, June 2, 2022 5:29 PM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: kra...@redhat.com; Justen, Jordan L
> Subject: Re: [PATCH 0/4] OvmfPkg: CloudHv: Reduce PIO and MMIO acce
Thank you!
From: Yao, Jiewen
Sent: Friday, June 3, 2022 12:52 PM
To: Boeuf, Sebastien ; devel@edk2.groups.io
Cc: kra...@redhat.com ; Justen, Jordan L
Subject: RE: [PATCH 0/4] OvmfPkg: CloudHv: Reduce PIO and MMIO accesses
Merged https://github.com/tianocore/ed
Merged https://github.com/tianocore/edk2/pull/2943
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Min Xu
> Sent: Monday, May 16, 2022 3:42 PM
> To: devel@edk2.groups.io
> Cc: Xu, Min M
> Subject: [edk2-devel] [PATCH V4 0/9] Enable RTMR based measurement and
> measure boot
First step in creating a single, common compiler intrinsics library for
everybody who needs it. Move the ArmPkg library to MdePkg, update all
references. No code changes.
Signed-off-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Acked-by: Ard Biesheuvel
Acked-by: Liming Gao
---
ArmVirtPkg/ArmVirt.d
Update #if conditions so the 64bit version is picked for X64 too.
Signed-off-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Acked-by: Ard Biesheuvel
Acked-by: Liming Gao
---
MdePkg/Library/CompilerIntrinsicsLib/memcmp_ms.c | 2 +-
MdePkg/Library/CompilerIntrinsicsLib/memcpy_ms.c | 2 +-
MdePkg/Libr
This is an attept to start cleaning up the messy compiler intrinsics
situation. Today we don't have a core intrinsics library, resulting
in everybody creating their own. ArmPkg has one, CryptoPkg has one.
I'm sure there are many more.
This doesn't make sense. Given we can't avoid compiler intri
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
.../Library/CompilerIntrinsicsLib/Ia32/Gcc.c | 22 ---
1 file changed, 22 deletions(-)
diff --git a/MdePkg/Library/CompilerIntrinsicsLib/Ia32/Gcc.c
b/MdePkg/Library/CompilerIntrinsicsLib/Ia32/Gcc.c
index d0996d6276bc..3c47b
Does not exist and is not needed.
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
MdePkg/Library/CompilerIntrinsicsLib/Ia32/Gcc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/MdePkg/Library/CompilerIntrinsicsLib/Ia32/Gcc.c
b/MdePkg/Library/CompilerIntrinsicsLib/Ia32/Gcc.c
index bb2
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
.../{memset_ms.c => types_ms.h} | 29 +--
.../Library/CompilerIntrinsicsLib/memcpy_ms.c | 6 +---
.../CompilerIntrinsicsLib/memmove_ms.c| 6 +---
.../Library/CompilerIntrinsicsLib/memset_ms.c | 6 +---
Copy over unmodified (except for running through uncrustify and adding
SPDX licence tags), from
https://github.com/tianocore/edk2-libc/tree/master/StdLib/LibC/CRT
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
.../Library/CompilerIntrinsicsLib/Ia32/Gcc.c | 285 ++
.../Co
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
.../CompilerIntrinsicsLib.inf| 16
1 file changed, 16 insertions(+)
diff --git a/MdePkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
b/MdePkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLi
Move intrinsics for ia32 from CryptoPkg/Library/IntrinsicLib
to MdePkg/Library/CompilerIntrinsicsLib. Also move strcmp.
Remove CryptoPkg/Library/IntrinsicLib.
Use MdePkg/Library/CompilerIntrinsicsLib instead.
Update all references.
Signed-off-by: Gerd Hoffmann
Acked-by: Jiewen Yao
Acked-by: Ar
Implementations for those functions already exist,
so remove them to avoid duplicate symbols.
Signed-off-by: Gerd Hoffmann
Acked-by: Liming Gao
---
.../Library/CompilerIntrinsicsLib/Ia32/Gcc.c | 47 ---
1 file changed, 47 deletions(-)
diff --git a/MdePkg/Library/CompilerIntrin
Hey.
I was asked in https://bugzilla.tianocore.org/show_bug.cgi?id=3919#c1
to forward that issue to this mailing list for further feedback.
All details can be found in the bug report:
https://bugzilla.tianocore.org/show_bug.cgi?id=3919
Thanks,
Chris.
On Wed, 2022-06-01 at 02:03 +, bugzill
Hello everyone, I wanted to ask everyone how most modules and
applications are run/tested in edk2. I will be working on Adding Rust
support for edk2 during GSoC and thus will probably have to do a lot
of primitive testing. I did look at the EmulationPkg but didn't really
understand how to use it. I
Hi Chris,
The attached screen shot from the shell shows block devices.
Is the error that it did not mount a file system on one of those
block devices?
How was the disk image prepared? Are you sure there is a FAT32
file system formatted on one of those block devices. It must be
the UEFI FAT32,
Hey-
On Fri, 2022-06-03 at 16:53 +, Kinney, Michael D wrote:
> The attached screen shot from the shell shows block devices.
>
> Is the error that it did not mount a file system on one of those
> block devices?
I assume it did not mount the EFI System Partition and thus the boot
process stopp
Added X64 ASpeedAst2600Gop UEFI Driver
Cc: Nate DeSimone
Cc: Isaac Oram
Cc: Harikrishna Doppalapudi
Cc: Manickavasakam Karpagavinayagam
Cc: Sureshkumar Ponnusamy
Cc: Zachary Bobroff
Signed-off-by: Sureshkumar Ponnusamy
---
Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2600Gop.efi | Bin 0
Reviewed-by: Isaac Oram
-Original Message-
From: Sureshkumar Ponnusamy
Sent: Friday, June 3, 2022 11:30 AM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Oram, Isaac W
; DOPPALAPUDI, HARIKRISHNA ;
KARPAGAVINAYAGAM, MANICKAVASAKAM ; Bobroff, Zachary
Subject: [edk2-non-osi][PATC
Pushed as 6996a45..3e68772
-Original Message-
From: devel@edk2.groups.io On Behalf Of Oram, Isaac W
Sent: Friday, June 3, 2022 1:07 PM
To: Ponnusamy, Suresh ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; DOPPALAPUDI,
HARIKRISHNA ; KARPAGAVINAYAGAM, MANICKAVASAKAM
; Bobroff, Zachary
Qemu's virtual VFAT (vvfat) disk type is a convenient way to test UEFI
applications. It presents a folder on the host as a VFAT file system to
the guest. It's not the fastest or the most stable disk type (be
careful not to modify files from the host while the guest is running),
but it's reall
In addition to mtools, I wrote a tool to package a set of files into a
fresh VFAT image - kinda like tar, but fat32 as output format. I'm using
it in my hobby OS project. It's a single C file but seems to work great,
albeit only tested in my workflow so far. Called it `fatcreate`, it's
available o
Can you use the dblk shell command on the partition that is expected to contain
a FAT32 file system? Please attach output from dblk of the first block of the
partition to the BZ. It should indicate a FAT32 file system.
Can you also try using efifmt from the EFI Disk Utilities to format the
pa
Hi Jason,
Do you think the code could be more understandable if adding a check for the
size?
if ((gFitTableContext.BiosModule[Index].Address <= Address) &&
(gFitTableContext.BiosModule[Index].Size >= Size) &&
((gFitTableContext.BiosModule[Index].Size - Size) >= (Address -
gFitTableCon
I’m a little confused on why we can’t put an ARM FV at address 0x [1]?
Obviously the zero vector for the FV is getting patch as this ARM code is
jumping to the 1st byte of the FV when it is present at 0x1000. I don’t know of
any generic limitation in our tools. This kind of feels like an
30 matches
Mail list logo
