Reviewed-by: Ray Ni
-Original Message-
From: Lin, JackX
Sent: Friday, August 27, 2021 2:04 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Dong, Eric ;
Yao, Jiewen ; Ni, Ray ; Chaganty,
Rangasai V ; Kuo, Donald ;
Kumar, Chandana C
Subject: [edk2-platforms: PATCH V10 2/2] Platform/Int
Reviewed-by: Ray Ni
-Original Message-
From: Lin, JackX
Sent: Friday, August 27, 2021 2:04 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Dong, Eric ;
Yao, Jiewen ; Ni, Ray ; Chaganty,
Rangasai V ; Kuo, Donald ;
Kumar, Chandana C
Subject: [edk2-platforms: PATCH V10 1/2] Platform/Int
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3365
Correct coding style
Signed-off-by: JackX Lin
Cc: Chasel Chiu
Cc: Dong Eric
Cc: Jiewen Yao
Cc: Ray Ni
Cc: Rangasai V Chaganty
Cc: Donald Kuo
Cc: Chandana C Kumar
Cc: JackX Lin
---
Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/Acpi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3365
BIOS cannot find correct AcpiProcId in mApicIdMap because of
there is no suitable map, that causes ACPI_BIOS_ERROR.
Remove mApicIdMap for determing AcpiProcId, uses normal
countings instead.
Signed-off-by: JackX Lin
Cc: Chasel Chiu
Cc: Do
@@ -747,6 +747,9 @@ PiCpuSmmEntry (
AsmCpuidEx(CPUID_EXTENDED_STATE, 12, &RegEax, NULL, &RegEcx, NULL);
DEBUG ((DEBUG_INFO, "CPUID[D/12] EAX - 0x%08x, ECX - 0x%08x\n",
RegEax, RegEcx));
}
+} else {
+ mCetSupported = FALSE;
+ PatchInstructionX86(mPatchCetSuppo
Reviewed-by: Dandan Bi
Thanks,
Dandan
> -Original Message-
> From: Wenyi Xie
> Sent: Thursday, August 26, 2021 9:16 AM
> To: devel@edk2.groups.io; Wang, Jian J ; Wu, Hao A
> ; Bi, Dandan ; Dong, Eric
>
> Cc: songdongku...@huawei.com; xiewen...@huawei.com
> Subject: [PATCH EDK2 v1 1/1]
> > + //
> > + // 5. Re-assigen AcpiProcessorId for AcpiProcessorUId uses purpose.
> > + //
> > + for (Socket = 0; Socket < MAX_SOCKET; Socket++) {
1. Or if you add a "Index = 0" to reset Index for each Socket, that also work.
> > +for (CurrProcessor = 0, Index = 0; CurrProcessor < mNumbe
Yes agreed, making this more consistent would be a good improvement and one
that I would support. There is always the perennial issue of finding the time
to make those improvements and balancing that with everything else that needs
to get done 😊.
From: Benjamin Doron
Sent: Thursday, August 26,
Pushed: https://github.com/tianocore/edk2-platforms/commit/b401dfd
-Original Message-
From: Benjamin Doron
Sent: Friday, August 13, 2021 5:43 PM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Liming Gao ;
Desimone, Nathaniel L
Subject: [edk2-platforms][PATCH v2 1/2] BoardModulePkg/BoardBdsH
Hi Nate,
That makes sense. I had been concerned that UiApp might be used in some
places, but I didn't expect significant disparity between the boards (and I
didn't check all of them, my mistake).
Maybe trying to align them on some differences, someday, might be a
good idea? But not for now, in any
Reviewed-by: Nate DeSimone
-Original Message-
From: Benjamin Doron
Sent: Friday, August 13, 2021 5:43 PM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Liming Gao ;
Desimone, Nathaniel L
Subject: [edk2-platforms][PATCH v2 1/2] BoardModulePkg/BoardBdsHookLib:
Register UiApp as boot option
Hi Benjamin,
In principle this is a good idea, unfortunately some platforms have been coded
to do stuff like this:
https://github.com/tianocore/edk2-platforms/blob/784f7739f5afd268042d4d9e8ef570131620c82c/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc#L323
And this:
https://github.com/tianoc
HI Caden,
You accidentally added a bunch of trailing white space on line 371, but that
should be fixable during the check-in process.
Reviewed-by: Nate DeSimone
-Original Message-
From: Caden Kline
Sent: Sunday, August 22, 2021 7:44 PM
To: devel@edk2.groups.io
Cc: Wang, Jian J ; Wu,
Hi Benjamin,
Sounds good. I have pushed your patch.
Thanks,
Nate
From: Benjamin Doron
Sent: Wednesday, August 25, 2021 9:09 PM
To: Desimone, Nathaniel L
Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] [edk2-platforms][PATCH v3 0/7] KabylakeOpenBoardPkg:
Add AspireVn7Dash572G
Hi Nate,
Than
Pushed: https://github.com/tianocore/edk2-platforms/commit/fe47032
-Original Message-
From: Benjamin Doron
Sent: Thursday, August 26, 2021 9:49 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L
Subject: [edk2-platforms][PATCH v1] KabylakeOpenBoardPkg/AspireVn7Dash572
Reviewed-by: Nate DeSimone
-Original Message-
From: Benjamin Doron
Sent: Thursday, August 26, 2021 9:49 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L
Subject: [edk2-platforms][PATCH v1] KabylakeOpenBoardPkg/AspireVn7Dash572G:
Correct my name on copyrights
Use
I've created a ticket in Bugzilla:
https://bugzilla.tianocore.org/show_bug.cgi?id=3594.
--
Rebecca Cran
On 8/22/21 11:35 PM, Rebecca Cran wrote:
Linaro no longer do gcc releases - Arm creates them now.
Update the gcc_[arm,aarch64]_linux_ext_dep.yaml files in BaseTools/Bin to
switch from Lin
Mike,
That reminds me that my patch to fix this for Xcode is still in limbo.
Thanks,
Andrew Fish
> On Aug 26, 2021, at 9:44 AM, Kinney, Michael D
> wrote:
>
> Marvin,
>
> The main reason most components in the EDK II repos continue to use the
> variables is
> because there are incomplete
On 26/08/2021 20:38, Ni, Ray wrote:
Marvin,
If we can keep the secure parsing code inside the PeCoff library, all the
backward combability issues because of removing the HII section support don't
exist.
Hey Ray,
As I said, the updated proposal no longer has any impact on
backwards-compatibi
Marvin,
If we can keep the secure parsing code inside the PeCoff library, all the
backward combability issues because of removing the HII section support don't
exist.
The PeCoff library might be very complex but the complexity[1] is hidden inside
and abstracted by the PeCoff library API.
The com
On 26/08/2021 20:19, Ni, Ray wrote:
3. Saves error-prone parsing work
This might be the key reason? Is it theoretically possible to write a secure
parsing code?
Hey Ray,
Yes it is, but the most secure parsing code is that which doesn't exist.
I'm confident in the one I wrote for the new PE/
> 3. Saves error-prone parsing work
This might be the key reason? Is it theoretically possible to write a secure
parsing code?
Thanks,
Ray
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79860): https://edk2.groups.io/g/devel/message/79
Though CopyMem() copies nothing when Length equals to 0, I agree this patch to
totally skip the CopyMem() call.
Reviewed-by: Ray Ni
> -Original Message-
> From: Mark Wilson
> Sent: Friday, November 13, 2020 8:05 AM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray
> Subject: [PATC
> + //
> + // 5. Re-assigen AcpiProcessorId for AcpiProcessorUId uses purpose.
> + //
> + for (Socket = 0; Socket < MAX_SOCKET; Socket++) {
> +for (CurrProcessor = 0, Index = 0; CurrProcessor < mNumberOfCpus;
> CurrProcessor++) {
> + if (mCpuApicIdOrderTable[CurrProcessor].Flags &&
>
Hey Mike,
On 26/08/2021 18:44, Michael D Kinney wrote:
Marvin,
The main reason most components in the EDK II repos continue to use the
variables is
because there are incomplete tools to generate PE/COFF resource sections for all
the OS/compiler combinations that EDK II supports.
The preferenc
Hi Marvin --
Sorry, nothing I can share. Thanks,
Tim
-Original Message-
From: Marvin Häuser
Sent: Thursday, August 26, 2021 9:07 AM
To: tim.le...@insyde.com; devel@edk2.groups.io; michael.d.kin...@intel.com
Cc: 'Andrew Fish' ; l...@nuviainc.com; 'Ni, Ray'
; 'Gao, Zhichao' ; 'Wang, Jia
Good day Samer,
Thanks a lot for your reply!
On 26/08/2021 18:49, Samer El-Haj-Mahmoud wrote:
I am aware of some proprietary tools (not open source) that depend on this
functionality.
The feature has been used, especially on some server designs, to allow
exporting HII packages and consuming
Comment below:
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Gerd
> Hoffmann
> Sent: Thursday, August 26, 2021 4:32 PM
> To: Yao, Jiewen
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Xu, Min M
> ; Ard Biesheuvel ; Justen,
> Jordan L ; Brijesh Singh ;
> Erdem Aktas ; James
Marvin,
The main reason most components in the EDK II repos continue to use the
variables is
because there are incomplete tools to generate PE/COFF resource sections for all
the OS/compiler combinations that EDK II supports.
The preference would be to use PE/COFF resource sections and we would
I am aware of some proprietary tools (not open source) that depend on this
functionality.
The feature has been used, especially on some server designs, to allow
exporting HII packages and consuming them offline by out-of-band or OS-based
management applications for instance. The need for this s
Use my correct, legal name for copyright purposes.
Cc: Chasel Chiu
Cc: Nate DeSimone
Signed-off-by: Benjamin Doron
---
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Acpi/BoardAcpiTables.inf
| 2 +-
Platform/Intel/KabylakeOpenBoardPkg/Aspir
Good idea, Ard.
> ASSERT_EFI_ERROR (Status);
> ASSERT (LowerMemorySize > 0);
I like this suggestion.
Thank you
Yao Jiewen
> -Original Message-
> From: Ard Biesheuvel
> Sent: Thursday, August 26, 2021 7:15 PM
> To: Gerd Hoffmann
> Cc: edk2-devel-groups-io ; Ard Biesheuvel
> ; Yao, Ji
Hey Tim,
Interesting, do you happen to have some tool or code that performs such
edits at hand to take a look at? Seems like most modules already use
variables and thus cannot be modified in such a way even right now?
That's the kind of information I am looking for, thanks a lot!
Best regard
Hi Marvin --
I would like to add some historical perspective on this. One of the design
requirements back when HII was first introduced into the UEFI specification
after Intel's initial contribution was that of binary editability. In order to
be able to reliably find, extract and then re-insert
Reviewed-by: Michael Kubacki
On 8/25/2021 11:55 PM, Nate DeSimone wrote:
Added EFI_INVALID_PARAMETER to the EcRead()
function's list of return values.
Cc: Chasel Chiu
Cc: Michael Kubacki
Cc: Benjamin Doron
Signed-off-by: Nate DeSimone
---
.../Intel/KabylakeOpenBoardPkg/Include/Library/Ec
Hey Mike,
Yes, I am aware. My goal for that would be to declare support as
optional to support drivers up until UEFI vX (whatever would be the spec
to endorse drivers to move away from the PE/COFF section model), much
like EFI 1.10 backwards-compatibility worked with UEFI 2.x, and have
some e
Marvin,
One constraint in this discussion is that the HII content in
a PE/COFF resource section is defined in the UEFI Specification,
Which means UEFI Apps and UEFI Drivers from media and option ROMs
that are not part of the system FW image are allowed to use this
feature, This means the system
Add myself as a maintainter for Features/Ext4Pkg.
Cc: Leif Lindholm
Cc: Michael D Kinney
Signed-off-by: Pedro Falcato
---
Maintainers.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Maintainers.txt b/Maintainers.txt
index 9b8d6aead923..e5ddaa8d2284 100644
--- a/Maintainers.txt
+++
On Thu, Aug 26, 2021 at 00:08:50 +0100, Pedro Falcato wrote:
> Add myself as a maintainter for Features/Ext4Pkg.
>
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Signed-off-by: Pedro Falcato
> ---
> Maintainers.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Maintainers.txt b/M
On Thu, 26 Aug 2021 at 11:55, Gerd Hoffmann wrote:
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
>
> Not needed for qemu 1.7 (released in 2013) and newer.
>
> Signed-off-by: Gerd Hoffmann
> ---
> OvmfPkg/PlatformPei/MemDetect.c | 58 ++---
> 1 file chan
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
Not needed for qemu 1.7 (released in 2013) and newer.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/PlatformPei/MemDetect.c | 58 ++---
1 file changed, 3 insertions(+), 55 deletions(-)
diff --git a/OvmfPkg/Platform
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
Prefer the e820 map provided via qemu firmware config interface
for memory detection. Use rtc cmos only as fallback, which should
be rarely needed these days as qemu supports etc/e820 since 2013.
Signed-off-by: Gerd Hoffmann
Reviewed-by:
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593
Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify
whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above
4G) or scan only.
Also add a lowmem parameter so ScanOrAdd64BitE820Ram
can report the memory size belo
Don't use cmos for memory detection if possible.
qemu provides the etc/e820 firmware config file
as alternative since 2013.
v2:
- fix lowmem detection
- pick up review tags
- add rfc patch to completely drop cmos support.
Gerd Hoffmann (3):
OvmfPkg/PlatformPei: ScanOrAdd64BitE820Ram improvem
Hey Mike,
Thanks for your reply!
Well, this switch is not well-documented. Looking now at both the
generation code and the emitted code, it does not generate a package
list like my code does, but separate data variables (strings and images)
that cannot easily be passed to HiiDatabase as-is. H
Hi,
> Some reference for QEMU:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg01682.html
Ah, good. /me adds an entry to the todo list.
> > > The fw_cfg is still allowed in the TDVF design guide, just because we
> > > feel it is a burden to convert everything suddenly.
> >
> >
On Wed, Aug 25, 2021 at 03:15:04PM +, Yao, Jiewen wrote:
> Thanks for the detail info.
> We do have process for handle compatibility.
>
> My recommendation is:
> 1) Please send out RFC email about removing CMOS support in QEMU.
> To see if someone still need support old version before qemu ver
47 matches
Mail list logo
