Several comments:
1. All the functions in AslUpdateLib.h don't have "EFIAPI" prefix. "EFIAPI" is
required for any public APIs according
to EDKII coding standards specification:
Sean:
We mostly use Emulator to verify and debug the code change in the common
module, such as BDS, HII, DxeCore, PeiCore. Compared to the real platform,
Emulator and OVMF are more easier to be built and verified. So, I request to
add Open CI build test for Ovmf and Emulator (BZ 2570). Later,
Thanks Laszlo. I am glad that you like the whitepaper.
Right. The platform should assert the WSMT bit, because the platform need make
sure that all SMI handlers do right thing for SMM communication buffer.
Using PcdCpuSmmRestrictedMemoryAccess is a good way to ensure any violation can
be
Zhiju:
I expect the output tool name is same to the one specified in tools_def.txt
or [BuildOptions] in platform.dsc file.
Thanks
Liming
> -Original Message-
> From: Feng, Bob C
> Sent: Monday, March 9, 2020 1:54 PM
> To: Fan, ZhijuX ; devel@edk2.groups.io
> Cc: Gao, Liming
>
Hi Sean,
On Sun, Mar 08, 2020 at 23:08:54 -0700, Sean via Groups.Io wrote:
> Ard/Lazlo,
>
> I find your position on OvmfPkg, ArmVirtPkg,and edk2-platforms in
> edk2 to be detrimental to the overall success of the edk2 project.
>
> The majority of edk2 consumers already have to deal with their
>
Well time to let this one simmer a while. I appreciate the viewpoints.
For what it is worth, I am unconvinced that leaving OVMF, ArmVirt, or Emulator
packages in the edk2 tree is the right choice. I would be opposed to adding
more as that would just continue the growth and noise of platforms
(This message seems to have broken the threading, so I'll make an
attempt below, to quote the context in a way that I think is logical.)
On 03/10/20 20:23, Michael D Kinney wrote:
> Sean,
>
> This is the reason that OvmfPkg was kept in the edk2 repo so only a
> single repo is required for local
On 03/10/20 18:25, sean.brogan via [] wrote:
> I don't see the difference besides the mechanics of the operation (which
> you have described clearly). To guarantee a repo or repos is
> "git-bisectable" you need to build and test every commit on your
> platform. For example in the recent
Note: This patch is being superseded by:
https://edk2.groups.io/g/devel/message/55734
On 2020.03.09 12:35, Pete Batard wrote:
On 2020.03.08 05:31, Andrei Warkentin wrote:
For Pi 4, the custom CPU frequency range goes all the way up to 2.2GHz.
The acrobatics with
This patch supersedes https://edk2.groups.io/g/devel/topic/71809869#55659.
It's more or less a complete rewrite of the previous proposal, as it
introduces new "Default" and "Low" CPU frequency settings and does away
with the need for platform specific strings altogether.
More importantly, it
Improve the CPU frequency settings of the platforms by:
- Adding a "Default" option that sets the frequency to the
official default for each model/submodel.
- Adding a "Low" option, that sets the frequency to a fixed
PCD, custom to each platform.
- Using fixed PCDs to set the maximum and
Please update copyright year on common_repo_functions.py
With that change... Reviewed-by: Nate DeSimone
-Original Message-
From: Desimone, Ashley E
Sent: Monday, March 9, 2020 5:36 PM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Pandya, Puja
; Bjorge, Erik C
Subject:
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Secure SMM Communication
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
--^--
bullet#3 in
Extract the dynamic setting of the
- PcdFlashNvStorageVariableBase64
- PcdFlashNvStorageFtwWorkingBase
- PcdFlashNvStorageFtwSpareBase
addresses to a helper function.
For now, the helper function is identical (duplicated) between the SMM
flash driver and the runtime DXE flash driver. In
The only two OvmfPkg references to "PcdFlashNvStorageVariableBase" are the
spurious ones in the runtime DXE driver and the SMM driver INF files of
the QEMU flash driver. Remove these references.
The flash driver does not access "PcdOvmfFlashNvStorageEventLogBase"
either, so remove that from the
FaultTolerantWritePei consumes:
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase.
VariablePei consumes:
- PcdFlashNvStorageVariableBase64.
Due to the previous patches in this series, the above PCDs are available
in the PEI phase, in the SMM_REQUIRE build.
FaultTolerantWritePei
The following flash-related base addresses:
- PcdFlashNvStorageVariableBase64,
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase,
are always set to constant (invariable) values in the "-D SMM_REQUIRE"
build of OVMF. (That's because in the SMM build, actual pflash is a hard
Repo: https://pagure.io/lersek/edk2.git
Branch: mem_type_info
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=386
The following "A Tour Beyond BIOS" whitepapers, available at
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
discuss the WSMT ACPI table:
-
Hi Miki,
Please see my feedback inline.
Thanks,
Nate
On Thu, Mar 05, 2020 at 10:14:23PM +, Shindo, Miki wrote:
> 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.
>
>
I think the expectation is that any OVMF testing requirements would be added to
the CI system, so contributors would simply have to wait a few extra minutes
when submitting a change?
Rebecca Cran
> On Mar 10, 2020, at 1:44 PM, Sean via Groups.Io
> wrote:
>
> If I look around i don't see
I just noticed a typo on the page about python tools: the heading says Falke8
instead of Flake8.
—
Rebecca Cran
>> On Mar 6, 2020, at 5:27 PM, Purma, Kondal R wrote:
>
> Hi,
>
> The draft specification for EDK II Python development process for
> presentation made earlier now available .
If I look around i don't see that documented.
https://github.com/tianocore/edk2#code-contributions
https://github.com/tianocore/tianocore.github.io/wiki/Code-Contributions
https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
Sean,
This is the reason that OvmfPkg was kept in the edk2 repo so only a single repo
is required for local dev testing and CI testing. Same reason for the
EmulatorPkg.
The current rule for the edk2 repo is common firmware packages and
virtual/emulated platforms.
The fact that there has not
On Tue, Mar 10, 2020 at 10:54 AM, Ard Biesheuvel wrote:
>
> This means we can reasonably require any contributor not to regress on
> those platforms, given how they have full access to it, and this is
> actually where i would like us to take the next step when it comes to
> ci automation, i.e.,
On Tue, Mar 10, 2020, 13:52 Laszlo Ersek wrote:
>
> Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg:
> raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've
> outgrown DXEFV again. Increase the DXEFV size to 12MB now.
>
> Cc: Ard Biesheuvel
> Cc: Gary
For me, the issue is more fundamental than what Laszlo describes.
The platforms that target qemu, which is available to anyone, can run
on any host, and can boot various OSes beyond Linux (including
windows), which is their primary target. It even supports
virtualization, which is highly
Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've
outgrown DXEFV again. Increase the DXEFV size to 12MB now.
Cc: Ard Biesheuvel
Cc: Gary Lin
Cc: Jordan Justen
Cc: Leif Lindholm
Cc: Philippe
I don't see the difference besides the mechanics of the operation (which you
have described clearly). To guarantee a repo or repos is "git-bisectable" you
need to build and test every commit on your platform. For example in the
recent ArmMmuLib patchset, you were able to build every commit in
Hi again Jiewen,
On 03/10/20 10:36, Laszlo Ersek wrote:
> Hi Jiewen,
>
> reading the following chapter:
>
>
> https://edk2-docs.gitbooks.io/a-tour-beyond-bios-memory-protection-in-uefi-bios/content/memory-protection-in-SMM.html
>
> I'm having trouble associating the protection features
Jian,
On 02/14/20 01:40, Zurcher, Christopher J wrote:
> In order to implement the EVP interface, the EVP_get_digestbyname function
> requires the desired digest to be already initialized. Removing the
> "no-autoalginit" build option will allow algorithms to be retrieved by name.
> I plan to
On 03/10/20 09:44, Bob Feng wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2580
>
> Ovmf build failed on Windows with VS2017 tool chain.
> The error message like:
>
> OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr
> dDynamicShellCommand.c(199): error C2220: warning treated as
Hi Jiewen,
reading the following chapter:
https://edk2-docs.gitbooks.io/a-tour-beyond-bios-memory-protection-in-uefi-bios/content/memory-protection-in-SMM.html
I'm having trouble associating the protection features implemented in
edk2 with the various bits in the WSMT (per
On 03/10/20 02:50, sean.brogan via [] wrote:
> [...] There are numerous ways to keep multiple repos in sync that
> allow a user to root cause regressions. Using submodules is one way
> to easily track the version of edk2 that was/is used in the platform
> repo and when issues are identified the
Hello Jiaxin:
Would you please provide your comments on the below Query.
-Siva
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Sivaraman
Nainar
Sent: Friday, March 6, 2020 11:37 AM
To: To:; Wu, Jiaxin; Fu, Siyuan
Cc: Madhan B. Santharam; Arun Subramanian B; Bhuvaneshwari M
Laszlo,
I found this is the last one issue. I created a patch
https://edk2.groups.io/g/devel/message/55708. Please review.
Thanks,
Bob
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Sunday, March 8, 2020 5:00 PM
To: Feng, Bob C ; devel@edk2.groups.io;
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2580
Ovmf build failed on Windows with VS2017 tool chain.
The error message like:
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr
dDynamicShellCommand.c(199): error C2220: warning treated as error -
no 'object' file generated
On 03/09/20 22:44, Kinney, Michael D wrote:
> Laszlo,
>
> If the dev branch that is being submitted as a PR
> contains the merge commit, or that developer use the
> one of the github features to rebase, the merge
> commit can be introduced.
>
> When a PR is in this state, the developer need to
>
Reviewed-by: Nate DeSimone
-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
38 matches
Mail list logo
