sysutils/edk2: fix network boot on bhyve
NetworkPkg's DxeNetLib needs EFI_RNG_PROTOCOL, and the Bhyve build's
only producer is VirtioRngDxe, which never binds since bhyve has no
virtio-rng device. RngDxe uses RDRAND instead and needs no device.
TcpDxe depexes gEfiHash2ServiceBindingProtocolGuid, so add
Hash2DxeCrypto too; without TcpDxe there is no HttpServiceBinding.
Also enable HTTP boot.
This recommits 3fcead9dc69a ("sysutils/edk2: fix network boot on bhyve"),
which also contained three unrelated patch files.
PR: 298499
Approved by: manu
Sponsored by: Netflix
sysutils/edk2: fix network boot on bhyve
NetworkPkg's DxeNetLib needs EFI_RNG_PROTOCOL, and the Bhyve build's
only producer is VirtioRngDxe, which never binds since bhyve has no
virtio-rng device. RngDxe uses RDRAND instead and needs no device.
TcpDxe depexes gEfiHash2ServiceBindingProtocolGuid, so add
Hash2DxeCrypto too; without TcpDxe there is no HttpServiceBinding.
Also enable HTTP boot.
PR: 298499
Approved by: manu
Sponsored by: Netflix
sysutils/edk2: Reinstantiate binary aliases for ar and dtc
ar and dtc in base differ in function and capability form the ports
counterparts. Use from ports to make to build run again.
PR: 292544
MFH: 2026Q2
Differential Revision: https://reviews.freebsd.org/D57279
sysutils/edk2: Depend on GCC at build time only
EDK2 produces self-contained binary runtime data which do not require GCC at
runtime, but only at build time.
Reviewed by: fuz
MFH: 2026Q2
Differential Revision: https://reviews.freebsd.org/D57187
sysutils/edk2: update to 2025008
Patch to update EDK2 OVMF firmware package used in bhyve and some ARM
platforms from 2023 to 2025 stable release. New submodules added in
GH_TUPLE, some script for build has been moved to a bash subshell.
BHYVE notices: tiny boot speedup, a bug with crashing on CPU sensor
wmsr from HWiNFO has stopped occurring, a bug with glibc apps crashing
in Linux VMs has stopped occurring, a crash on memtest86+ with more
than 1 vCPU has stopped occurring.
No new bugs seem to have surfaced.
PR: 285554
Tested by: novel
MFH: 2025Q4
Mk/bsd.commands.mk: Use absolute path to define GMAKE
Same as BSDMAKE variable. It is needed by some ports.
Some ports needed fixes:
- devel/rcs57: Regenerate configure with newer autoconf so it can deal
with MAKE set to an absolute path. While here fix issues with
(un)escaping double quotes. The warnings about this were in
WRKSRC/src/conf.err.
- lang/gnu-cobol: Patch configure.ac so the MAKE environment variable
can contain an absolute path, and define MAKE before it is used in
AM_INIT_AUTOMAKE. Remove post-patch patching of configure. It appears
to have been fixed upstream.
- math/unuran: Remove post-patch, fixed upstream.
- net-mgmt/kismet: Fix post-patch.
PR: 283534
Exp-run by: antoine
sysutils/edk2: make bhyve's bootorder feature work
Bhyve supports a bootindex property for bootable devices. When adding it
to at least one device, bhyve creates a bootorder and passes it over the
Qemu FwCfg interface to the guest. The guest firmware has to pick up the
FwCfg file and has to apply the bootorder. Otherwise, the bootindex
property won't have any effect. Recently, a commit was merged by EDKII
to support that feature and we can simply cherry-pick it.
PR: 279720
Reviewed by: manu
Approved by: manu
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D45768
sysutils/edk2: enable TPM on bhyve
bhyve gained support for TPM emulation in the upcoming FreeBSD 14.0. The
firmware has to setup the TPM to make it useable for the OS.
Reviewed by: manu
Approved by: manu
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41868
sysutils/edk2: enable secure boot on bhyve
Everything is ready in edk2 for secure boot. To make use of secure boot
you have to boot into an EFI shell and install your keys. Booting an EFI
shell can be done by starting bhyve without any image attached to it.
More information on how to generate and install keys can be found in the
ACRN documentation [1].
Note that that secure boot capable UEFI implementation is required to
meet the Windows 11 requirements.
[1] https://projectacrn.github.io/3.2/tutorials/waag-secure-boot.html
Reviewed by: manu
Approved by: manu
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41869
OvmfPkg/Bhyve: don't exit early if RSDP is not found in memory
If OVMF fails to find the RSDP in memory, it should fall back installing
the statically provided ACPI tables.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
PR: 273560
Reviewed by: madpilot, manu
Approved by: manu
Fixes: 8097dda40a03b8a27a1edf1f31a8af0455a52baf ("sysutils/edk2: update to
202308")
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D41769
all: remove explicit versions in USES=python for "3.x+"
The logic in USES=python will automatically convert this to 3.8+ by
itself.
Adjust two ports that only had Python 3.7 mentioned but build fine
on Python 3.8 too.
finance/quickfix: mark BROKEN with PYTHON
libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../.. -I -I. -I.. -I../.. -I../C++
-DLIBICONV_PLUG -DPYTHON_MAJOR_VERSION=3 -Wno-unused-variable
-Wno-maybe-uninitialized -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-fno-strict-aliasing -DLIBICONV_PLUG -Wall -ansi
-Wno-unused-command-line-argument -Wpointer-arith -Wwrite-strings
-Wno-overloaded-virtual -Wno-deprecated-declarations -Wno-deprecated -std=c++0x
-MT _quickfix_la-QuickfixPython.lo -MD -MP -MF
.deps/_quickfix_la-QuickfixPython.Tpo -c QuickfixPython.cpp -fPIC -DPIC -o
.libs/_quickfix_la-QuickfixPython.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
'-Wno-uninitialized'? [-Wunknown-warning-option]
QuickfixPython.cpp:175:11: fatal error: 'Python.h' file not found
^~~~~~~~~~
1 warning and 1 error generated.
Reviewed by: portmgr, vishwin, yuri
Differential Revision: <https://reviews.freebsd.org/D40568>
sysutils/edk2: Fix build on aarch64
Build on aarch64 was failing with the following error:
ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by
/usr/local/lib/gcc11/libstdc++.so.6 not found
Fix by using /usr/local/lib/gcc*/libgcc_s.so.1 instead.
While here, also define WWW variable.
PR: 266404
Approved by: imp (uboot)
sysutils/edk2: Fix build with GCC 12
- Backport two upstreamed patches.
- Fix ar path.
While here, pet portlint.
PR: 263543
Reported by: exp-run (antoine)
Approved by: manu
sysutils/edk2@qemu_i386: Fix build depends
nasm is also needed for qemu_i386
Fixes: 177204e319 ("sysutils/edk2: Add qemu_x64 and qemu_i386 as new FLAVORs of
edk2")
Reported by: pkg-fallout
Sponsored by: Beckhoff Automation GmbH & Co. KG
sysutils/edk2: Add qemu_x64 and qemu_i386 as new FLAVORs of edk2
Instead of having a separate sysutils/uefi-edk2-qemu port, add qemu_x64
and qemu_i386 as FLAVORs of sysutils/edk2 and delete sysutils/uefi-edk2-qemu.
Differential Revision: https://reviews.freebsd.org/D35408
Approved by: manu
sysutils/edk2@bhyve: Fix main firmware
EDK2 produce multiple files for the bhyve flavor, _CODE and _DATA
The PLAT_RESULT is just a concat of both.
But bhyve doesn't support having only one file.
When it was its own port we just install the _CODE file as the main file
instead of using the concat one generated during edk2 build.
For this port we need to use the main PLAT_RESULT files for all flavors
except bhyve so add a quirks in the install phase that just replace the main
file with the _CODE one.
Thanks to Corvin Köhne <CorvinK@beckhoff.com> for helping me understanding
the issue.
Fixes: 2e6a6ccd15 ("sysutils/edk2: Add bhyve as a new FLAVOR of edk2")
Sponsored by: Beckhoff Automation GmbH & Co. KG
PR: 264338
sysutils/edk2: Add bhyve as a new FLAVOR of edk2
Instead of having a separate sysutils/uefi-edk2-bhyve port, add bhyve
as a FLAVOR of sysutils/edk2 and delete sysutils/uefi-edk2-bhyve.
To support existing users who depend on firmware in
/usr/local/share/uefi-firmware create compatibility symlinks.
Update sysutils/bhyve-firmware to depend on edk2@bhyve.
Differential Revision: https://reviews.freebsd.org/D35148
Reviewed by: manu
Approved by: manu
sysutils/edk2: Mark the xen flavor as amd64 only
Xen flavors needs a gcc that can compile amd64 code (obviously) which
we don't really have in ports. Also there isn't much sense to build something
amd64 only on other arches. The inverse isn't true as bootstraping arm64 boards
from amd64 is common.
Reported by: diizzy
Style: improve ONLY_FOR_ARCHS_REASON (grammar, markup, etc.)
ONLY_FOR_ARCHS_REASON is used as part of the sentence and thus should
start with lower-case letter and not end with a period which is added
by the framework, similar to other knobs like BROKEN, IGNORE, et al.
While here, remove needless quoting, add missing Oxford comma, expand
contractions and jargonisms, use correct spelling for proper names.
sysutils/edk2: Reorder FLAVORS
Put the default one (macchiatobin) at the first place otherwise poudriere
keeps rebuilding the package :
Deleting edk2-macchiatobin-g202102.pkg: stale package: unwanted origin
sysutils/edk2@macchiatobin
sysutils/edk2: Add fvp support
This is used on the Arm Models (simulators)
Reviewed by: manu
Approved by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31277
sysutils/xen-tools: fix build on FreeBSD 12
QEMU Inter-VM shared memory device (ivshmem) depends on eventfd and
will only be built on FreeBSD versions > 12.
The fix is picked up from the QEMU port.
Approved by: bapt (implicit)
sysutils/edk2: update to 202102
This also requires bumping the versions of some submodules and the
platform repositories.
Reviewed by: manu
Approved by: manu
Differential revision: https://reviews.freebsd.org/D30329
sysutils/edk2: use default gcc
Builds fine with the default gcc version.
Reviewed by: manu
Approved by: manu
Differential revision: https://reviews.freebsd.org/D30328
sysutils/edk2: Rename xen flavor to xen_x64
We might want to have other flavor of this for other xen
arches at one point.
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D30278
sysutils/edk2: Restrict building on aarch64 and amd64
The port only provides firmwares for those arch so it doesn't make sense to
build them for other arch.
If one day people wants to bootstrap an aarch64 image from a risc-v board
we will reconsider this change.
sysutils/edk2: add Xen platform
As part of this make the gcc aarch64 dependency conditional to
building a firmware for that architecture, and make the nasm package a
build dependency for the X64 (amd64) targets.
Sponsored by: Citrix Systems R&D
Reviewed by: manu
Approved by: manu
Differential revision: https://reviews.freebsd.org/D30225
sysutils/edk2: Set maintainer to uboot@
Nobody should ever own this port so set the uboot list as the maintainer.
Even if it's not uboot this port is a flavored port for edk2 targeting
arm64 boards (for now) so uboot@ is the closest things that we have.
Restrict only to architectures that the code claims to support:
Python/TargetTool/TargetTool.py: help="ARCHS is one of list: IA32, X64, ARM,
AARCH64 or EBC, which replaces target.txt's TARGET_ARCH definition. To specify
more archs, please repeat this option."
Python/build/buildoptions.py: help="ARCHS is one of list: IA32, X64, ARM,
AARCH64, RISCV64 or EBC, which overrides target.txt's TARGET_ARCH definition. To
specify more archs, please repeat this option."
See also: BaseTools/Source/C/GNUmakefile.
Result from attempt on powerpc64:
Attempting to detect HOST_ARCH from 'uname -m': powerpc
Could not detected HOST_ARCH from uname results
Approved by: portmgr (tier-2 blanket)
sysutils/edk2: Add new port
EDK2 is a modern, feature-rich, cross-platform firmware development
environment for the UEFI and PI specifications from www.uefi.org.
The port currently support 3 flavors: macchiatobin, rpi3 and rpi4.
