Please run a a test PR with this patchset? I would like to see how it impacts
the build times.
Patche series look fine to me.
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58126):
Thanks for providing feedback.
My V10 branch is up which will be sent to the mailing list tomorrow as the V3
patch set unless there are any changes requested.
This now includes a 7th patch which converts the edk2 ReadMe.md to ReadMe.rst
and shows the Platform CI status. The other package
Navdeep,
Yes since the 202002 stable tag there have been submodules introduced to the
basetools. If you look closely you will see in the CI process this required a
change where stuart_setup is run before calling edk2toolsbuild.py.
I was hoping that because it wasn't "HTML tag soup" that build status could be
front and center in the package readme as I find that more in line with
expectations on github based projects. Nesting it deeper in the package just
means less people find it when looking at your package. But I
Laszlo,
PIP vs Submodules:
The issue with submodule and not using python packages (pip is really just a
super convenient helper to install that consistently) is that it requires the
paradigm of file system python path management. Think of this as edk1 vs edk2
public includes (if you remember
I support somewhere other than edk2 core.
I would offer a third option to think about; create a new tianocore repo. For
optional features or features that don't have broad community adoption it would
allow for those downstream consumers to easily pick and chose their
consumption. It also
Laszlo,
Regarding your comments about disliking the verbosity of the markdown
table/html table for build status both in Core Ci and now these Platform CI
readme files.
As a learning experience I updated the OvmfPkg readme to use reStructuredText
instead of markdown. Not sure if I like RST
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57545): https://edk2.groups.io/g/devel/message/57545
Mute This Topic: https://groups.io/mt/72907803/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
If it is a pytool general failure please open an issue here:
https://github.com/tianocore/edk2-pytool-extensions/issues with details.
If the PlatformBuild.py in this patchset has an issue please reply here with
logs or reproducible steps.
Thanks
Sean
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
Rebecca,
Each CI framework has different syntax, capabilities, and requirements. The
PyTools environment attempts to generalize the edk2/uefi aspects of the setup,
build, and test but regardless there are things that should be done as "steps"
in the CI framework being targeted. This is why
On Wed, Apr 15, 2020 at 10:18 AM, Laszlo Ersek wrote:
>
> ArmVirtPkg/ArmVirtPkg.ci.yaml
> ArmVirtPkg/PlatformCI/Ubuntu-GCC5.yml
> ArmVirtPkg/PlatformCI/PlatformBuild.py
> ArmVirtPkg/PlatformCI/README-pytools.md
> ArmVirtPkg/PlatformCI/iasl_ext_dep.yaml
I am ok with the above except one thought
Andrew/Jordan,
Any thoughts?
On the Ovmf and ArmVirt package they have requested the files move into a
PlatformCI folder. This is a "new" pattern so I want to understand what you
would like for EmulatorPkg?
See thread https://edk2.groups.io/g/devel/message/57423
-=-=-=-=-=-=-=-=-=-=-=-
On Wed, Apr 15, 2020 at 09:58 AM, Laszlo Ersek wrote:
>
> I have not ignored your email. Instead, I have not seen it.
>
> The reason is that you messaged the list only -- you didn't put me in
> the To: or Cc: headers, despite addressing me by name in the message body.
I use the groups.io web
No local server. I use a free devops account. When i was standing up the
original Core CI project for tianocore I created a Azure devops project here
https://dev.azure.com/tianocore/edk2-ci-play
In this project I can connect to my fork on github and run builds. Anyone else
could also setup
Any thoughts? I would like to get this in before any more failures get checked
in causing more dependencies.
I have a branch here:
https://github.com/spbrogan/edk2/tree/PlatformAndCoreCIForOvmfArmVirtEmulatorPackages_v7
but am waiting for more feedback to make V2 patchset.
Thanks
Sean
what do you mean "test for the adding pipelines"?
The pipeline currently builds the platforms and then runs them to the shell
where it has a startup.nsh which does reset -h.
If the boot fails or hangs the task will timeout in 1 minute and then fail.
Thanks
Sean
-=-=-=-=-=-=-=-=-=-=-=-
Ard/Laszlo,
On the topic of Package files.
1. The *.ci.yaml is designed to be at the root of the package and this follows
all other Core ci usage. The Core CI will only look for this file at the root
as of now.
2. The PlatformBuild.py file is exactly like a build.bat or build.sh file
found
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#57054): https://edk2.groups.io/g/devel/message/57054
Mute This Topic: https://groups.io/mt/72670002/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
Guomin,
Can you speak to why you implemented differently than the suggested and
validated patch? Seems you created a local whereas ours just used the internal
data member.
Thanks
sean
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online
Bob and Ray,
My point isn't that there is anything wrong with script. This script is
designed to work with edk2-platforms repo or other repos of similar layout.
This is a "platform" thing that is needed on some platforms (not edk2 core
platforms). To me this means it does't belong in edk2
Platform and Core CI patches are ready for review. I have 14 commits here.
https://github.com/spbrogan/edk2/tree/PlatformAndCoreCIForOvmfArmVirtEmulatorPackages
This adds support for "Platform CI" for ArmVirtPkg, OvmfPkg, and EmulatorPkg.
Each readme has live status and links to the builds as
Not sure I follow. The changes are in BaseTools/Source/Python/GenFds/GenFds.py
I am suggesting this functionality to be written outside the GenFds.py files so
that we don't add complexity to the critical tools used for building and
packaging FW binaries.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io
I would have much rather seen this implemented independent of the GenFds tool
as this is a nice feature but shouldn't be tightly coupled into the tool that
does building and packaging firmware.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply
I am not a fan of this. The community and design meetings have had a few
discussions about tools (PyTools has been presented twice) and a few brief
discussions about common patterns to build platforms but I don't think there is
real alignment. Each "platform" has its own way of doing things.
On Tue, Mar 31, 2020 at 08:52 AM, Zhang, Shenglei wrote:
>
>
>
> "CharEncodingCheck": {
>
>
>
> "IgnoreFiles":
> [[(MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/test/testc.c),(MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/windows/testc.c)]
>
>
>
>
> }
>
>
This syntax
Does anyone know off hand if defining this and enabling floating point has any
negative side effects if you don't need it? Size? Optimization? Other? That
is my only concern for enabling in all modules which is why the initial
proposal was for a new library.
-=-=-=-=-=-=-=-=-=-=-=-
I agree that safeintlib is not doing anything too interesting in this case but
that's not really the point. The argument for it is that it becomes the
central point of code to check for safe conversions and an indicator that the
developer was thoughtful about this conversion and didn't just
On Mon, Mar 30, 2020 at 11:41 PM, Ard Biesheuvel wrote:
>
> Not sure I follow. Which command line are we talking about?
@Ard - In this Platform CI, ArmVirt is building and running AARCH64 but not ARM
32bit. Would it be valuable to build for ARM too?
I prototyped it but want to make sure I am
A couple of thoughts.
1. I would suggest that ASSERT should not be the only protection for an invalid
operation as ASSERT is usually disabled on release builds.
2. We do have a library to make this more explicit and common.
@Ard -
pflash change: https://github.com/spbrogan/edk2/pull/12
Logging change - I actually switched OVMF to use stdio since the log is
captured either way and now it shows up in the web log output.
https://github.com/spbrogan/edk2/pull/13
Do you have instructions for the cmdline for Qemu for
@Rebecca - Agree. I need to package up a newer version. I have treated this
as lower priority. Is there a feature you need or just best practices on
keeping current?
@Ard - Padding in python is easy. I just need to understand the requirements.
@Mike - I would like to get to read/write
Laszlo/Ard -
I have cleaned up git history and pushed to https://github.com/spbrogan/edk2
master.
If you want you can create a PR against that branch and it should kick OVMF,
Emulator, and ArmVirt to build and run.
Looking for feedback.
@Laszlo - I followed Ard's parameters but feel free to
On Mon, Mar 30, 2020 at 10:44 AM, Ard Biesheuvel wrote:
>
> Thanks. But can I get these actions to trigger from my branch as well?
> Or do I need special powers for that?
Right now it requires manually running so it requires "special powers". :)
I am happy to get this into a branch that you can
On Mon, Mar 30, 2020 at 10:04 AM, Ard Biesheuvel wrote:
>
> Is there any way I could contribute ArmVirtQemu to this? Or would it
> be easier if I provided comments/instructions?
Either way.
Any instructions you provide would be great. I was going to hack something up
for feedback but happy
On Mon, Mar 30, 2020 at 02:36 AM, Ard Biesheuvel wrote:
>
> It should be trivial to extend this to ARM, using TCG emulation.
>
> One question though: what happens if the boot does not make it to the
> shell, and crashes for some reason? The QEMU process will hang, so I'd
> assume some kind of
Thanks. I was missing the "-s" and Andrew you solution worked for the
filesystem.
OVMF: Windows builds and Linux builds and boot to shell. IA32, X64 and IA32x64
-
https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4950=results
Emulator: Windows and linux builds and boots to
Ard/Laszlo or anyone familiar with QEMU.
I read up on the ovmf readme and the qemu wiki but still have a few issues i am
hoping for quick/easy answers.
1. How do i programmatically exit the emulator. Seems like uefi shell > reset
just reboots. Other ideas?
2. Is there an easy way to map a
Ard,
I agree. How would we do this with AARCH64? I don't believe azure devops
pipelines has a native AARCH64 platform available. I briefly looked over
ArmVirtPkg but not sure where to start. OVMF readme only talks about ia32/x64.
I could also see a scenario for a self hosted agent that is
Thanks
I opened a bug to get this tracked.
https://bugzilla.tianocore.org/show_bug.cgi?id=2640
In that bug i link to a commit which does the above using python. It saves
about 20 seconds for each build on linux in Azure pipelines.
Thanks
Sean
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You
Added support for EmulatorPkg running to UEFI shell.
Segmentation fault on GCC / Ubuntu x64. Works on Windows.
Could very easily be user error.
https://bugzilla.tianocore.org/show_bug.cgi?id=2639
Laszlo - can you point me to any docs, scripts, examples of how i would do the
same thing with
"Stuart" gives the system a lot of structure and flexibility. It lets us
maintain the build process consistently in a cross platform way and allows
platforms to use python instead of shell scripting. This takes advantage of
our investments in dependency management, optimized submodule
There are two parts of this I think should be discussed.
1. Core-Ci for emulator, ovmf, armvirt packages.
a. I think there is some value here for those package maintainers. The core ci
does spell checks, char encoding checks, lib class declaration, etc. Those
seem valuable to help keep the
So even though the scope for right now is to build the package only, since
these are platforms I think they would better align with a platform build
pipeline rather than the stuart_ci_build pipeline. Basically we would setup a
new pipeline that builds each platform. To start they can just
Rebecca - I think for any platform testing it would make more sense to use self
hosted agents. They could even be your own VM. QEMU and emulator might be the
two where we could explore using the DevOps VMs but I worry we will spend too
much time downloading and install dependencies since the
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
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
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.,
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
Sorry let me clarify a little more. I don't doubt that you spending the time
to validate a patch using OVMF catches issues and regressions. I am very
appreciative of that effort, my point is you could do that without being in the
edk2 tree and in fact we need to enable and request that more
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 platform not being part of the edk2
git repo and the fact that changes to edk2 may not
Laszlo - Added comment to your PR.
@Mike Kinney (michael.d.kin...@intel.com) who has mergify permission?
I tried to add comment "@Mergifyio refresh" to the PR but since I don't have
"command" permission it was rejected. I am happy to look at mergify a little
closer if you give me access.
The name of this flag is terrible but if you read the 2.8 spec.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf
page 1436.
Says:
EFI_TLS_VERIFY_FLAG_NONE means no additional flags set for hostname validation.
Wildcards are supported and they match only in the left-most
The options in the spellcheck object seem to be copied from a different
package. I would start with an empty set and then add in "ExtendWords" for
unique and valid words in the package. I would also suggest that for any new
package we should start with the spellcheck on (not in auditonly
Given that i think MdeModulePkg depending on ArmPkg is a bug that should get
fixed, I don't agree with this change. If there is an api needed for these
different architectures then the definition of the API should move to Mde or
MdeModulePkg.
Thanks
Sean
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io
On Tue, Mar 3, 2020 at 10:02 PM, Abner Chang wrote:
>
> BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
Web extdeps can have a hash so we are sure we get the expected file. My
opinion is for edk2 extdeps we should use this feature.
I never saw a patch in the series that actually added the submodule to the
.gitmodules file but maybe i missed that. If that is approved then the changes
to this file look ok. I have no idea why all the line endings are shown but
the substantial changes here look fine to me.
Rebecca,
If I understand you correctly we already do something like this on linux.
You can see the code here:
https://github.com/tianocore/edk2-pytool-extensions/blob/master/edk2toolext/environment/extdeptypes/nuget_dependency.py#L31
For better support can we move this conversation over to the
This looks fine but it seems focused on writing a new module/project. Most
python work going into edk2 is part of existing code.
I would like to see additional documentation about how this applies to edk2
basetools.
* A flake8 config file could be added to basetools python.
* Documentation of
@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---
On Fri, Feb 14, 2020 at 02:14 PM, Laszlo Ersek wrote:
>
> I think Bugzilla tickets are the best place to capture the focused
> analysis of a bug. I write a *lot* of text in Red Hat bugzillas (most of
> them are public, luckily!) -- I want to document my own "adventure" with
> the issue, even if
Soumya,
I would like to add three things to community discussions especially around
governance and process.
1. RFC: The RFC process seems to get only minimal comments and a lot gets lost
in the noise of the lists. There isn't a good "final" state where all approved
RFCs can be seen. The
Reviewed by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#54158): https://edk2.groups.io/g/devel/message/54158
Mute This Topic: https://groups.io/mt/71145488/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
Looks great.
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#54062): https://edk2.groups.io/g/devel/message/54062
Mute This Topic: https://groups.io/mt/71060085/21656
Group Owner: devel+ow...@edk2.groups.io
Mike,
The hardcoded vs paths are not a safe assumption.
I would rather see agreement of how the environment should be configured prior
to calling edk2 build and if being capable of building host os specific
binaries is the requirement then that should be clarified and the scripts can
be
Thomas,
Are you able to share the Clang-format file? I would like to get a format file
as close to edk2 style as possible and then see if we can move the community to
auto formatted code. This could then be easily enforced by a PR gate that
requires all modified/new files to conform to auto
On Mon, Jan 6, 2020 at 10:43 AM, Vitaly Cheptsov wrote:
>
> My original suggestion was to remove the assertions entirely, but several
> people here said that they use them to verify usage errors when handling
> trusted data. This makes good sense to me, so we suggest to support both
> cases by
Sorry Rebecca for the slow reply.
We have identified the issue and will be adding some minor documentation to
pytool docs to help.
In short, nuget relies on new versions of mono. Mono is not getting updated in
linux distro maintained packages as fast as needed.
This resolved the issue for our
Mike/Steven/Ray,
We have had a tool for a couple of years with similar functionality. It is a
python tool you run on your code base and it creates a single (local) webpage
that you can then use to build charts.
Please give it a try and see if you think it is useful.
Here is the tool.
Bob,
Glad to hear it is working for you. A few questions just to make sure
something wasn't missed.
Did you build edk2 base tools using the process here.
https://github.com/out0xb2/edk2/blob/feature/pytoolsForOvmf/OvmfPkg/README-pytools.md#differences-from-edk-classic-build-setup
If you
Sorry let me clarify.
The plugin is not designed to work for the VS2015 toolchain. The plugin is not
part of pytools but part of edk2 repo.
If you would like to build with VS2017 or VS2019 the plugin will handle your
path management.
If you are not setting the tool chain on the command line
Rebecca,
I'll take a look and see if I can build up my own Ubuntu vm. We use the Ubuntu
instance provided by Azure DevOps without any issues. Here is the documentation
provided for that.
Overview
https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops
and more
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#50417): https://edk2.groups.io/g/devel/message/50417
Mute This Topic: https://groups.io/mt/53599349/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
Src of image for GCC build status looks like it is pointing at old
edk2-staging. The rest look good.
If that gets updated.
Reviewed-by: Sean Brogan
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#50385):
Laszlo,
Our legal team has requested that we don't include the copyright year.
Thanks
Sean
-Original Message-
From: Kinney, Michael D
Sent: Thursday, November 7, 2019 11:23 AM
To: devel@edk2.groups.io; ler...@redhat.com; Sean Brogan
Cc: Dong, Eric ; Ni, Ray
Subject: RE:
I tested using "#" character to indicate the line was a comment. I did this
for a copyright, license identifier, and some text. On Windows pip -r had no
issues installing, upgrading, or uninstalling and didn't show any output
related to those lines.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:
It is a convention for projects using python. It definitely isn't required but
there are some features that come for free when using that filename.
https://github.blog/2018-07-12-security-vulnerability-alerts-for-python/
and
Since the LSV can be managed from within the FmpDeviceLib i don't understand
why this change is required. This adds yet again more complexity to all users
of FmpDxe for a very niche use case. I believe the hooks already exist that
would allow you to achieve the same functionality from within
devel@edk2.groups.io On Behalf Of Sean
> via Groups.Io
> Sent: Thursday, August 29, 2019 7:22 PM
> To: r...@edk2.groups.io; Kinney, Michael D
> ; devel@edk2.groups.io
> Cc: Bret Barkelew
> Subject: Re: [edk2-devel] [RFC] EDK II Continuous Integration Phase 1
>
> Mike,
These tests require using the "edk2-pytool" stuff but are easy to integrate
with the github PR or CI flow. Example of it running the code compliance tests
is here:
https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=13&_a=summary
A test run takes about 3 minutes.
The past week
Laszlo/Mike,
The idea that the maintainer must create the PR is fighting the optimized
github PR flow. Github and PRs process is optimized for letting everyone
contribute from "their" fork while still protecting and putting process in
place for the "upstream".
Why not use github to assign
Mike, as you mentioned we have been working towards enabling a practical and
extensible CI for Edk2 using Azure dev ops and the recently added edk2-pytool
infrastructure. We have been using similar CI for Project Mu for the last few
years.
Our approach is a little different in that we focus
Final update on the RFC.
The repo is up and populated and ready for contributions. Please read the
repository readme for details.
https://github.com/tianocore/edk2-pytool-library
An initial Pypi release has been made
https://pypi.org/project/edk2-pytool-library/
And CI & pull request builds
Both of these RFCs listed flake8 because that is what we have today and it
should be relatively easy to get parity. I am super happy to have you
add/propose/provide pr with additional test capability like Pylint. Thats one
of the goals of adding this to tianocore.
You can see what we are
One final update as requested. Changing the repo name and pip module to
*edk2-pytool-library*
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#41755): https://edk2.groups.io/g/devel/message/41755
Mute This Topic:
RFC edk2-tools-library creation
Create a new tianocore owned repository to host a python library package in
support of UEFI development. This package will allow easy sharing of python
library code to facilitate reuse. Inclusion of this package and dependency
management should be managed
Yes the plan would be to support both CI and local builds. There is actually
more features related to support platform builds so I think it would be better
to keep ci out of the name. The reason why Tool-Env was suggested is the
modules can be used to run anything within the python
Take a look at the proposed content and how it is used. We even have examples
of calling from DevOps and i don't think Jenkins would be any different. I
don't think we are trying to duplicate CI functionality. We are providing the
"last mile" so that those CI engines can run EDK specific
Rebecca,
If you know of anything I am interested as I don't like building and supporting
something unnecessary.
This tooling isn't trying to reinvent anything but is really focused on
providing reusable/sharable functionality that can then be pieced together by a
platform to produce the
RFC Edk2-ToolEnv creation
Create a new tianocore owned repository to host python code to support an
extensible, pluggable, rich environment. This environment has command line
interfaces to support building a product, building CI, running tests, and
downloading dependencies. This environment
1. Agree on the name but not sure whats better. i don't think it should be
edk2-tools because the idea of this is to be a library of support code but not
the tools themselves. This limits dependencies and keeps the library free of
business specific logic. The second RFC will be for a new
RFC Edk2-Library creation
Create a new tianocore owned repository to host a python library package in
support of UEFI development. This package will allow easy sharing of python
library code to facilitate reuse. Inclusion of this package and dependency
management should be managed using
Laszlo,
Except for a very few platforms that are in the current edk2 repo today,
everyone building products has to deal with this "split repo" reality. It gets
even harder when you account for different business units, different silicon
partners, IBVs, ODMs, open source, closed source, secret
gt;
If I have any mistakes, please correct them.
Thanks,
Zhichao
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
[mailto:devel@edk2.groups.io] On Behalf Of Sean via Groups.Io
Sent: Friday, April 26, 2019 9:12 AM
To: Gao; Gao, Zhichao mailto:zhichao@intel.com>>;
devel@ed
Is there a branch where this code change can be reviewed?
The intent of bug 1412 was not to break spec alignment on the uefi defined
protocol and SetMode() function. We had a proposed change that can be seen
here. https://github.com/Microsoft/mu_basecore/pull/13/files
The idea was for new
94 matches
Mail list logo
