On 03/07/20 08:39, Laszlo Ersek wrote:
> Hi Jiewen,
>
> On 03/07/20 02:43, Yao, Jiewen wrote:
>> Just saw Laszlo's email. Similar feedback. Especially, I like the regression
>> test part.
>
> Thanks.
>
>> I am not sure how many virtual platforms we will have eventually.
>> If there are more and
On Sat, 7 Mar 2020 at 08:39, Laszlo Ersek wrote:
>
> Hi Jiewen,
>
> On 03/07/20 02:43, Yao, Jiewen wrote:
> > Just saw Laszlo's email. Similar feedback. Especially, I like the
> > regression test part.
>
> Thanks.
>
> > I am not sure how many virtual platforms we will have eventually.
> > If ther
On 03/07/20 08:28, Laszlo Ersek wrote:
> On 03/07/20 07:10, Ard Biesheuvel wrote:
>> I queued it here as well:
>> https://github.com/tianocore/edk2/pull/427
>
>
> Nope, still stuck, both #427 and #428.
>
> "We are currently investigating a delay in notification delivery."
>
> "We are monitorin
Hi Jiewen,
On 03/07/20 02:43, Yao, Jiewen wrote:
> Just saw Laszlo's email. Similar feedback. Especially, I like the regression
> test part.
Thanks.
> I am not sure how many virtual platforms we will have eventually.
> If there are more and more, maybe we can create a new edk2-virt-platform
>
On 03/07/20 07:10, Ard Biesheuvel wrote:
> On Sat, 7 Mar 2020 at 02:00, Laszlo Ersek wrote:
>>
>> On 03/07/20 01:01, Philippe Mathieu-Daudé wrote:
>>> On 3/7/20 12:04 AM, Laszlo Ersek wrote:
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local v
On Fri, 6 Mar 2020 at 19:50, Leif Lindholm wrote:
>
> On Fri, Mar 06, 2020 at 17:12:45 +0100, Ard Biesheuvel wrote:
> > Replace the slightly overcomplicated page table management code with
> > a simplified, recursive implementation that should be far easier to
> > reason about.
> >
> > Signed-off-
On Sat, 7 Mar 2020 at 02:00, Laszlo Ersek wrote:
>
> On 03/07/20 01:01, Philippe Mathieu-Daudé wrote:
> > On 3/7/20 12:04 AM, Laszlo Ersek wrote:
> >> When the MDE_CPU_IA32 macro is not defined, there is no access to the
> >> "KernelImageHandle" local variable in QemuStartKernelImage(). This break
Just saw Laszlo's email. Similar feedback. Especially, I like the regression
test part.
I am not sure how many virtual platforms we will have eventually.
If there are more and more, maybe we can create a new edk2-virt-platform repo,
and put them together there. (Similar to edk2-platform repo for
I can share some of my experience, for your information only.
0) If the patch is generic, not specific to Bhyve, but benefit to current EDKII
pkg, you can submit them directly. No need to wait for Bhyve.
1) If the patch is very simple, you can merge into current PKG with current DSC.
If there is
On 03/07/20 01:01, Philippe Mathieu-Daudé wrote:
> On 3/7/20 12:04 AM, Laszlo Ersek wrote:
>> When the MDE_CPU_IA32 macro is not defined, there is no access to the
>> "KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
>> the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at l
Hi,
The draft specification for EDK II Python development process for presentation
made earlier now available .
Presentation thread :
https://edk2.groups.io/g/announce/message/92
Wiki Page link for specification document:
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Draft-Spec
On 3/7/20 12:04 AM, Laszlo Ersek wrote:
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.
Move the local variable to the inner sco
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.
Move the local variable to the inner scope, where declaration and usage
are insepa
@Gao, Liming - here is my AR to list things desired for 2020 02 stable tag.
At minimum
2516TianocorCodesean.bro...@microsoft.com CONF---
Add new package for XML support in Edk2 2020-02-20
2517TianocorCodesean.bro...@microsoft.com CONF---
Hi Lazlo,
On 06/03/2020 22:14, Laszlo Ersek wrote:
Hi Nikita,
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
On 03/06/20 22:52, Liran Alon wrote:
>
> Hi Lazlo,
("Laszlo")
> On 06/03/2020 22:14, Laszlo Ersek wrote:
>> Hi Nikita,
>>
>> On 03/04/20 20:22, Nikita Leshenko wrote:
>>> This series adds driver support for:
>>> - LSI53C1030
>>> - SAS1068
>>> - SAS1068E
>>>
>>> These controllers are widely suppo
Hi Nikita,
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
On 03/06/20 20:54, Laszlo Ersek wrote:
> On 03/06/20 17:09, Rebecca Cran wrote:
>> I'm currently working on updating EDK2 support for Bhyve
>> (https://bhyve.org/) from the edk2-stable201903 tag to
>> edk2-stable202002. It's currently kept in a separate repo
>> (https://github.com/freebsd/uefi-edk2
On 03/06/20 17:09, Rebecca Cran wrote:
> I'm currently working on updating EDK2 support for Bhyve
> (https://bhyve.org/) from the edk2-stable201903 tag to
> edk2-stable202002. It's currently kept in a separate repo
> (https://github.com/freebsd/uefi-edk2), but I'd like to discuss pushing
> support
On 03/06/20 17:40, Ard Biesheuvel wrote:
> On Fri, 6 Mar 2020 at 17:14, Laszlo Ersek wrote:
>>
>> On 03/06/20 08:38, Ard Biesheuvel wrote:
>>> Bob reports that VS2017 chokes on a tentative definition of the const
>>> object 'mEfiFileProtocolTemplate', with the following error:
>>>
>>> OvmfPkg\Qe
I tried again to get CI running on FreeBSD, and succeeded with one
change. FreeBSD can't run .NET executables directly, so NuGet.exe needed
to be a shell script that calls "mono NuGet.ex" where the original
NuGet.exe has been renamed NuGet.ex .
--
Rebecca Cran
-=-=-=-=-=-=-=-=-=-=-=-
Group
On Fri, Mar 06, 2020 at 17:12:46 +0100, Ard Biesheuvel wrote:
> As it turns out, ARMv8 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 tab
On Fri, Mar 06, 2020 at 17:12:45 +0100, Ard Biesheuvel wrote:
> Replace the slightly overcomplicated page table management code with
> a simplified, recursive implementation that should be far easier to
> reason about.
>
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPkg/Library/ArmMmuLib/AArch64/Ar
On Fri, 6 Mar 2020 at 11:50, Leif Lindholm wrote:
>
> On Wed, Mar 04, 2020 at 18:50:56 +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 t
On Fri, 6 Mar 2020 at 13:46, Pete Batard wrote:
>
> On 2020.03.06 05:53, Andrei Warkentin wrote:
> > 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_P
On Fri, 6 Mar 2020 at 13:46, Pete Batard wrote:
>
> Please see one note at the end:
>
> On 2020.03.06 05:53, Andrei Warkentin wrote:
> > 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 w
On Fri, 6 Mar 2020 at 12:51, Pete Batard wrote:
>
> On 2020.03.06 11:42, Pete Batard via Groups.Io wrote:
> > This currently produces an ASSERT for me:
> >
> > ASSERT [ArmPlatformPrePiUniCore]
> > /usr/src/edk2/ArmPlatformPkg/PrePi/PrePi.c(75): (((UINT64)0xULL
> > > mSystemMemoryEnd) || (
On Fri, 6 Mar 2020 at 13:58, Leif Lindholm wrote:
>
> On Fri, Feb 21, 2020 at 17:29:04 +0100, Ard Biesheuvel wrote:
> > The dma-ranges DT property describes the DMA translation between a
> > parent bus and its children, and so having a dma-ranges property in
> > the root node makes little sense, b
On Fri, 6 Mar 2020 at 17:14, Laszlo Ersek wrote:
>
> On 03/06/20 08:38, Ard Biesheuvel wrote:
> > Bob reports that VS2017 chokes on a tentative definition of the const
> > object 'mEfiFileProtocolTemplate', with the following error:
> >
> > OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(1
On 03/06/20 08:38, Ard Biesheuvel wrote:
> 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 'obje
I finally got fed up with the state of the AArch64 MMU handling code, and
decided to rewrite it before rebasing the cache invalidation fix onto
it.
Ard Biesheuvel (2):
ArmPkg/ArmMmuLib AARCH64: rewrite page table code
ArmPkg/ArmMmuLib AARCH64: invalidate page tables before populating
them
Replace the slightly overcomplicated page table management code with
a simplified, recursive implementation that should be far easier to
reason about.
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 332 +++-
1 file changed, 108 insertions(+),
As it turns out, ARMv8 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
ARM, if the MMU is still
I'm currently working on updating EDK2 support for Bhyve
(https://bhyve.org/) from the edk2-stable201903 tag to
edk2-stable202002. It's currently kept in a separate repo
(https://github.com/freebsd/uefi-edk2), but I'd like to discuss pushing
support upstream into the main edk2 repo (I guess int
On Fri, Mar 06, 2020 at 11:40:32 +0100, Ard Biesheuvel wrote:
> As it turns out, ARMv8 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
Urgh. I thought v8 had chan
On Fri, Feb 21, 2020 at 17:29:04 +0100, Ard Biesheuvel wrote:
> The dma-ranges DT property describes the DMA translation between a
> parent bus and its children, and so having a dma-ranges property in
> the root node makes little sense, but it doesn't harm either.
>
> However, recent kernels (v5.5
On 2020.03.06 05:53, Andrei Warkentin wrote:
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 Wa
Please see one note at the end:
On 2020.03.06 05:53, Andrei Warkentin wrote:
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.
Thi
On 2020.03.06 11:42, Pete Batard via Groups.Io wrote:
This currently produces an ASSERT for me:
ASSERT [ArmPlatformPrePiUniCore]
/usr/src/edk2/ArmPlatformPkg/PrePi/PrePi.c(75): (((UINT64)0xULL
> mSystemMemoryEnd) || ((0xULL + 0x0020U) < 0x0020ULL))
|| ((0xULL
This currently produces an ASSERT for me:
ASSERT [ArmPlatformPrePiUniCore]
/usr/src/edk2/ArmPlatformPkg/PrePi/PrePi.c(75): (((UINT64)0xULL
> mSystemMemoryEnd) || ((0xULL + 0x0020U) < 0x0020ULL))
|| ((0xULL >= 0x0020ULL) && ((UINT64)(0xULL +
0x002000
On Wed, Mar 04, 2020 at 18:50:56 +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 well
As it turns out, ARMv8 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
ARM, if the MMU is still
On Fri, 21 Feb 2020 at 17:29, Ard Biesheuvel wrote:
>
> The dma-ranges DT property describes the DMA translation between a
> parent bus and its children, and so having a dma-ranges property in
> the root node makes little sense, but it doesn't harm either.
>
> However, recent kernels (v5.5+) have
(adding PIWG and some other folks to cc)
On Mon, 6 Jan 2020 at 02:16, Gao, Liming wrote:
>
> Ard:
> The changes are good to me. But, I think this change will not be added into
> MdePkg until PI1.7 errata A is published.
>
Hello all,
Due to the Huawei situation, and now the fact that there is
On 3/5/20 11:46 PM, Andrei Warkentin wrote:
From: Andrei Warkentin
The RPi4 TF-A is much smaller than RPi3 TF-A, and doesn't need
an extra 2MB region.
The note ...:
---vvv---
Note: this depends on the edk2 ArmPlatformPkg/PrePi: fix IS_XIP.
---^^^---
Signed-off-by: Andrei Warkentin
-
45 matches
Mail list logo
