Hi all,
With these two patches checked in, you may meet build failure with
MdeModulePkg and BaseTools. Because the components in brotli can't be found.
Please try command " git submodule update --init" to check out the source code
before you build the packages.
Thanks,
Shenglei
>
Reviewed-by: Ray Ni
> -Original Message-
> From: Laszlo Ersek
> Sent: Thursday, April 16, 2020 1:41 AM
> To: Wu, Hao A ; Wang, Jian J ; Ni,
> Ray
> Cc: edk2-devel-groups-io ; Ard Biesheuvel
> ; Philippe Mathieu-Daudé
>
> Subject: Re: [edk2-devel] [PATCH]
bhyve uses the older VESA BIOS Extensions 2.0, so add the mode info
structure to IndustryStandard/LegacyVgaBios.h
Signed-off-by: Rebecca Cran
---
.../Include/IndustryStandard/LegacyVgaBios.h | 39 +++
1 file changed, 39 insertions(+)
diff --git
Update ResetSystemLib to support powering off bhyve guests instead of
having them enter the CpuDeadLoop.
On bhyve, the Power Management 1 Control Register is located at 0x404;
a write with SLP_TYP set to 5 will power off the guest.
Signed-off-by: Rebecca Cran
---
Add bhyve support to AcpiPlatformDxe. bhyve doesn't use QemuFwCfg
and installs its own ACPI tables, so introduce a new
AcpiPlatformDxeBhyve.inf that's customized for it.
Signed-off-by: Rebecca Cran
---
OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c| 8 +-
The VS2019 toolchain warns about casts from UINT32 to UINT16.
Work around this by adding casts in the call to BhyveSetGraphicsMode, as
a temporary measure.
Signed-off-by: Rebecca Cran
---
BhyvePkg/BhyveRfbDxe/GopScreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Add a null implementation library fof QemuFwCfgS3Lib, to support bhyve.
Signed-off-by: Rebecca Cran
---
.../DxeQemuFwCfgS3LibFwCfgNull.inf| 32 ++
.../QemuFwCfgS3LibNull/QemuFwCfgS3DxeNull.c | 307 ++
.../QemuFwCfgS3PeiDxeNull.c | 31 ++
3 files
This is the bhyve patch series for initial review.
I know there are a few formatting issues, but thought
it might be good to get some feedback to make sure I'm
on the right track with adding this new package/platform.
Signed-off-by: Rebecca Cran
Rebecca Cran (13):
OvmfPkg: Add bhyve support
Add a null PEI implementation of QemuFwCfgLib for bhyve.
Signed-off-by: Rebecca Cran
---
.../QemuFwCfgLibNull/QemuFwCfgPeiLibNull.inf | 36 ++
.../QemuFwCfgLibNull/QemuFwCfgPeiNull.c | 107 ++
2 files changed, 143 insertions(+)
create mode 100644
On bhyve, the ACPI timer is located at a fixed IO address; it need
not be programmed into, nor fetched from, the PMBA -- power
management base address -- register of the PCI host bridge.
Signed-off-by: Rebecca Cran
---
OvmfPkg/Include/IndustryStandard/Bhyve.h | 21
Signed-off-by: Rebecca Cran
---
OvmfPkg/PlatformPei/MemDetectBhyve.c | 631 +++
OvmfPkg/PlatformPei/PlatformBhyve.c | 612 ++
OvmfPkg/PlatformPei/PlatformPeiBhyve.inf | 119 +
3 files changed, 1362 insertions(+)
create mode 100644
Add a null implementation of QemuFwCfgS3Lib, for bhyve.
Signed-off-by: Rebecca Cran
---
.../PeiQemuFwCfgS3LibFwCfgNull.inf| 39
.../QemuFwCfgS3BasePeiNull.c | 221 ++
.../QemuFwCfgS3LibNull/QemuFwCfgS3PeiNull.c | 80 +++
3 files changed,
Add a null implementation of BhyveFwCtlLib, to support building
AcpiPlatformDxe for Qemu/Xen.
Signed-off-by: Rebecca Cran
---
.../BhyveFwCtlLibNull/BhyveFwCtlLibNull.c | 53 +++
.../BhyveFwCtlLibNull/BhyveFwCtlLibNull.inf | 39 ++
2 files changed, 92
On Windows, building BhyveFwCtlLib using VS2019 causes a call to
memcpy to be generated. Work around this by adding IntrinsicsLib to
resolve the reference.
Signed-off-by: Rebecca Cran
---
BhyvePkg/Library/BhyveFwCtlLib/BhyveFwCtlLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
Only use __attribute__ ((unused)) when building using a compiler which
claims to support GNU C.
Signed-off-by: Rebecca Cran
---
BhyvePkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/BhyvePkg/Library/PlatformBootManagerLib/BdsPlatform.c
When installing packages pip may attempt to download dependencies. The
installer should contain all dependencies so tell pip where to look
for any dependencies.
Signed-off-by: Erik Bjorge
Cc: Ashley DeSimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Bret Barkelew
Cc: Prince Agyeman
---
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:
On 4/15/2020 2:44 PM, sean.brogan via [] wrote:
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
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
From: Sean Brogan
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2513
Remove Windows only scopes in the CISettngs file
Cc: Sean Brogan
Cc: Bret Barkelew
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Sean Brogan
Signed-off-by: Michael Kubacki
---
.pytool/CISettings.py | 3 ---
1
From: Sean Brogan
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2513
Update HostBasedUnitTestRunner plugin to support the Linux environment
and remove any Windows only logic.
Cc: Bob Feng
Cc: Liming Gao
Cc: Bret Barkelew
Cc: Michael D Kinney
Signed-off-by: Sean Brogan
Signed-off-by:
From: Michael Kubacki
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2513
The following 2 patches remove the Core CI limitation of running and
reporting results of host based unit tests only for Core CI on Windows.
Branch can be reviewed here:
On 4/15/2020 10:15 AM, Sean via groups.io wrote:
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
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
Fix: 'Error: local variable 'repo_sources_to_sync'
referenced before assignment' by adding the case where
it is populated based on the current combo when not
using the -u flag.
Signed-off-by: Ashley E Desimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Erik Bjorge
Cc: Bret Barkelew
Cc: Prince
Hao, Jian, Ray:
can one of you please approve this patch?
Thanks
Laszlo
On 04/09/20 13:30, Laszlo Ersek wrote:
> NonDiscoverablePciDeviceDxe currently #defines the module-internal
> PCI_MAX_BARS macro, with value 6 (and type "int").
>
> Remove this private macro definition, and adopt
On 4/15/20 7:18 PM, Laszlo Ersek wrote:
On 04/09/20 21:57, Sean via groups.io wrote:
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
ACPI memory mapped configuration space access (MCFG) table requires
defination of EFI_ACPI_DESCRIPTION_HEADER.
Signed-off-by: Wasim Khan
---
.../IndustryStandard/MemoryMappedConfigurationSpaceAccessTable.h| 2 ++
1 file changed, 2 insertions(+)
diff --git
On 04/09/20 21:57, Sean via groups.io wrote:
> 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.
OK. This makes sense to
I saw Bret gave an R-b to the v2 series since it was sent. In addition
to the R-bs already captured from v1, is there anything else needed for
the series to be pushed?
Thanks,
Michael
On 4/10/2020 1:02 PM, michael.kuba...@outlook.com wrote:
From: Michael Kubacki
Hi Sean,
On 04/15/20 08:55, Sean via groups.io wrote:
> Any thoughts?
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.
While I do follow
On 04/15/20 18:25, Laszlo Ersek wrote:
> In other words, I personally believe that bug#1974 should have been
> closed as INVALID (without patching the edk2 source). The EBS handler in
> SnpDxe is necessary (as long as it does not alter the UEFI memory map
> itself), because sending the Shutdown
On 04/15/20 11:45, Rabeda, Maciej wrote:
> Siyuan, Jiaxin, Laszlo,
>
> It would be great to hear especially your opinion on the matter before
> decisions take place :)
My understanding is that UNDI is yet another (historica?l) NIC interface
specification. I've failed to find a download location
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
Hello Bob, Liming and Michael,
This is just a re-post of my last message on the Bugzilla ticket available at
https://bugzilla.tianocore.org/show_bug.cgi?id=2646
I wanted to be sure we agreed before trying to make an implementation. It seems
that in edk2 build system, the steps described below
(CC Gerd, Qiming, Marcel, qemu-devel for ramfb:)
On 04/14/20 23:20, valerij zaporogeci wrote:
[snip]
> There is a Boot Manager UI display problem, I don't know if this is
> qemu problem, but with the ARM (both 32 and 64 bits, the qemu version
> is 4.2.0, the OVMF is fresh), and using "ramfb"
On 4/15/2020 8:04 AM, Laszlo Ersek wrote:
I figure you attempted the DEBUG_ON_SERIAL_PORT build because without it
you get no debug output at all (due to the default
PlatformDebugLibIoPort resolution, which produces no logs on Xen).
I just attempted the DEBUG_ON_SERIAL_PORT build because
On 04/14/20 20:01, Rebecca Cran wrote:
> I was trying to build OvmfPkg/XenPkg -a X64 -t GCC5 -b DEBUG
> -DDEBUG_ON_SERIAL_PORT=TRUE, but the build fails. Both plain DEBUG and
> RELEASE builds without trying to put the debug output on the serial
> port work.
>
>
> [bcran@smic ~/src/tmp/edk2]$ build
Zhiju:
Thanks for your update. The change is good to me. For the report error
message, I suggest as below
xx FV free space is not enough to meet with the required spare space
set by -D FV_SPARE_SPACE_THRESHOLD option.
Thanks
Liming
> -Original Message-
> From: Fan, ZhijuX
Acked-by: Zhichao Gao
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Chang,
> Abner (HPS SW/FW Technologist)
> Sent: Friday, April 10, 2020 3:26 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner (HPS SW/FW Technologist) ; Chen,
> Gilbert ; Leif Lindholm ; Gao,
> Zhichao ;
On 04/14/20 19:38, Nikita Leshenko wrote:
> Used to identify the individual disks in the hardware tree.
>
> Currently we accept only Pun=0 and Lun=0, but we will relax this in a
> later patch.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Signed-off-by: Nikita Leshenko
>
On 4/9/20 1:30 PM, Laszlo Ersek wrote:
NonDiscoverablePciDeviceDxe currently #defines the module-internal
PCI_MAX_BARS macro, with value 6 (and type "int").
Remove this private macro definition, and adopt PCI_MAX_BAR from
"MdePkg/Include/IndustryStandard/Pci22.h". Both the value and the type
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2654
If FV is placed in FD region, its FV image size is fixed.
When FV image size exceeds it, it will trig the build break.
To alert the developer to adjust FV image size earlier,
I request to add new checker for the the spare FV space.
When the
Siyuan, Jiaxin, Laszlo,
It would be great to hear especially your opinion on the matter before
decisions take place :)
On 14-Apr-20 19:08, Michael Kubacki wrote:
Hi Maciej,
Thank you for summarizing the background.
I would like to get others feedback as well. If the EBS notification
is
Reviewed-by: Chasel Chiu
> -Original Message-
> From: Kumar, Chandana C
> Sent: Wednesday, April 15, 2020 4:31 PM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Chiu, Chasel
> ; Desimone, Nathaniel L
>
> Subject: [edk2-platforms: PATCH] MinPlatformPkg/PlatformInitPei: Create
Create an Library instance of ReportCpuHobLib from PlatformInitPei driver.
PA bits reported can be overriden using Library instance in Platform.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2674
Signed-off-by: Chandana Kumar
Cc: Sai Chaganty
Cc: Chasel Chiu
Cc: Nate DeSimone
---
Create an Library instance of ReportCpuHobLib from PlatformInitPei driver,
so that from platform side reporting Physical address bits can be overriden.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2674
Signed-off-by: Chandana Kumar
Cc: Sai Chaganty
Cc: Chasel Chiu
Cc: Nate DeSimone
Create an Library instance of ReportCpuHobLib from PlatformInitPei driver,
so that from platform side reporting Physical address bits can be overriden.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2674
Signed-off-by: Chandana Kumar
Cc: Sai Chaganty
Cc: Chasel Chiu
Cc: Nate DeSimone
Create an Library instance of ReportCpuHobLib from PlatformInitPei driver,
so that from platform side reporting Physical address bits can be overriden.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2674
Signed-off-by: Chandana Kumar
Cc: Sai Chaganty
Cc: Chasel Chiu
Cc: Nate DeSimone
Sorry for that. I didn’t make the query clear.
· what do you mean "test for the adding pipelines"? I mean when you
add a new pipline how do you know it can work well on github and all steps work
correctly. Do you have test on a local server or something?
Thanks,
Shenglei
From:
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
On 04/14/20 19:38, Nikita Leshenko wrote:
> Support dynamic insertion and removal of the protocol
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Signed-off-by: Nikita Leshenko
> Reviewed-by: Laszlo Ersek
> ---
> OvmfPkg/MptScsiDxe/MptScsi.c | 181
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
-=-=-=-=-=-=-=-=-=-=-=-
On 04/14/20 19:38, Nikita Leshenko wrote:
> In preparation for implementing LSI Fusion MPT SCSI devices, create a
> basic scaffolding for a driver.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Signed-off-by: Nikita Leshenko
> Reviewed-by: Liran Alon
> ---
> Maintainers.txt
Hi Chandana,
Your commit message format a little weird, please help to correct it.
Please also update MinPlatformPkg.dec/[LibraryClasses] section for new library
class this patch introduced.
Thanks,
Chasel
> -Original Message-
> From: Kumar, Chandana C
> Sent: Tuesday, April 14,
57 matches
Mail list logo
