82c66f1853
edk2 passes no -march for the X64 toolchains, so the ISA baseline of the
shipped firmware is whatever the builder's GCC defaults to, and AlmaLinux 10
builds GCC with --with-arch_64=x86-64-v3. edk2-ovmf is noarch and one build
is shared by the x86_64 and the x86_64_v2 repositories, so OVMF ends up
carrying BMI1/BMI2 code and no UEFI guest boots on a v2-only CPU: it resets
in a loop right after the SEC phase.
%{optflags} cannot fix this. edk2.spec exports it as EXTRA_OPTFLAGS, which
only reaches the host BaseTools binaries, and edk2-build.py has no way to
pass compiler flags to the firmware build, so tools_def is the only place
where the baseline can be set.
The same patch applies to both edk2 snapshots (a10: 20251114/46548b1adac8,
a10s: 20260221/b7a715f7c03c) - the context around the define is identical.
rpms/edk2#1
21 lines
714 B
YAML
21 lines
714 B
YAML
actions:
|
|
- modify_release:
|
|
- suffix: ".alma.1"
|
|
enabled: true
|
|
|
|
- changelog_entry:
|
|
- name: "Eduard Abdullin"
|
|
email: "eabdullin@almalinux.org"
|
|
line:
|
|
- "Pin the X64 firmware ISA baseline to x86-64-v2"
|
|
|
|
# edk2 passes no -march for the X64 toolchains, so the shipped firmware
|
|
# inherits the builder's GCC default (x86-64-v3 on AlmaLinux 10). The
|
|
# edk2-ovmf subpackage is noarch and shared by the x86_64 and x86_64_v2
|
|
# repositories, so it has to be built for the lower baseline.
|
|
# https://git.almalinux.org/rpms/edk2/issues/1
|
|
- add_files:
|
|
- type: "patch"
|
|
name: "0001-BaseTools-pin-the-X64-ISA-baseline-to-x86-64-v2.patch"
|
|
number: "Latest"
|