| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The source package now supports other platforms so follow suit.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The filenames used here differ from Fedora, which ships far more
variants. I felt it unnecessary to include the raw and unpadded images
when the padded QCOW2 images should be all you need.
QEMU_EFI.secboot_INSECURE.qcow2 does have Secure Boot enabled, but it
must not be used in production. The lack of an SMM implementation for
arm64 in this firmware means that the EFI variable store is unprotected,
making the firmware unsafe.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ebuild has been largely rewritten. It now:
* Respects CC, CXX, and flags when building the base tools.
* Doesn't use gcc/cc when building the firmware, enabling cross.
* Prepares the ground for supporting platforms other than OVMF for x64.
* Installs OVMF_VARS.secboot.fd prepared with virt-fw-vars.
* Includes the latest UEFI DBX update in OVMF_VARS.secboot.fd.
* Adds 4MB variants of the .fd images (in QCOW2 format).
* Fixes network support broken by a recent bump.
* Drops EnrollDefaultKeys.efi and UefiShell.img
The enrollment tool hasn't actually worked for a while and is no longer needed
now that we provide OVMF_VARS.secboot.fd. UefiShell.img is therefore of little
use, and other distros now provide UefiShell.iso instead anyway. We can do the
same if there is sufficient interest.
This moves us closer to Fedora, but they ship far more variants. They
have a large Python wrapper around upstream's build system, which is
unusual in itself. Building all these would make the ebuild much more
complex, take a long time, and use up more disk space. Perhaps USE flags
could help here, but I'm not sure what all these variants are for.
I also decided to install to paths based on upstream's names, e.g.
edk2/ArmVirtQemu-AARCH64 as opposed to Fedora's edk2/aarch64 because
mixing QEMU with Xen and others would be confusing when there are many
similarly named files, even within a single architecture.
Closes: https://bugs.gentoo.org/891191
Closes: https://bugs.gentoo.org/921819
Closes: https://bugs.gentoo.org/929838
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
| |
The new version bump won't use this.
Closes: https://bugs.gentoo.org/853271
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/937610
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
|
| |
I don't think using UefiShell.img actually works any more, but the new version
bump will automatically create OVMF_VARS.secboot.fd for you.
Closes: https://bugs.gentoo.org/926630
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
There is a lot of overlap in building firmware for other platforms from
source, so it makes sense to have one source package.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|