rpms/edk2
7
0
Fork 0
Code Issues Pull Requests Releases Activity
05b86525bb
edk2/50-edk2-ovmf-ia32-nosb.json

35 lines
726 B
JSON
Raw Normal View History

Ship the JSON firmware "descriptor files" From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and so forth. You can see examples of these files from the QEMU upstream Git: https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors $> tree descriptors/ descriptors/ ├── 50-edk2-i386-secure.json ├── 50-edk2-x86_64-secure.json ├── 60-edk2-aarch64.json ├── 60-edk2-arm.json ├── 60-edk2-i386.json └── 60-edk2-x86_64.json QEMU 4.1 itself will ship the above files. However, Fedora needs to ship these file as part of its EDK2 package. Why? ---- (1) Quoting (with minor formatting edits) Laszlo Ersek: Distributions providing their own EDK2 packages would not include the descriptors from upstream QEMU, even if they otherwise package QEMU. That's beause the descriptor files in QEMU match the firmware bundled with QEMU -- but the firmware images in the distros' own EDK2 packages are different. So, if a distro provides an EDK2 package, then the same EDK2 package should offer matching descriptors. QEMU offers descriptors (soon) because QEMU technically distributes edk2 firmware binaries (soon). [Where "soon" == QEMU 4.1] (2) And as Dan Berrangé reminded on IRC: In Fedora, we need to ship them [the "descriptor files"] as part of the EDK2 package, because Fedora throws away all the firmware files that QEMU bundles, because we're [Fedora] required to rebuild everything from pristine source. - - - In this patch: (*) Use the firmware descriptor files provided by Laszlo (thanks!) in this comment here: https://bugzilla.redhat.com/show_bug.cgi?id=1728652#c2 ("RFE: Ship the JSON firmware "descriptor files" as part of EDK2"). On the double-digit priority prefixes, refer to the rationale here: https://src.fedoraproject.org/rpms/edk2/pull-request/3#comment-27523 (*) Install the JSON files for the relevant architectures in `/usr/share/qemu/firmware`, as required by specification[+]. And make each EDK2 own this directory; multiple RPMs owning the same directory is no problem. [+] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json Resolves: rhbz#1728652 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
2019-07-12 09:20:38 +00:00
{
json: shorten descriptions a bit
2022-11-16 15:19:38 +00:00
"description": "OVMF for i386, without SB+SMM, empty varstore",
Ship the JSON firmware "descriptor files" From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and so forth. You can see examples of these files from the QEMU upstream Git: https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors $> tree descriptors/ descriptors/ ├── 50-edk2-i386-secure.json ├── 50-edk2-x86_64-secure.json ├── 60-edk2-aarch64.json ├── 60-edk2-arm.json ├── 60-edk2-i386.json └── 60-edk2-x86_64.json QEMU 4.1 itself will ship the above files. However, Fedora needs to ship these file as part of its EDK2 package. Why? ---- (1) Quoting (with minor formatting edits) Laszlo Ersek: Distributions providing their own EDK2 packages would not include the descriptors from upstream QEMU, even if they otherwise package QEMU. That's beause the descriptor files in QEMU match the firmware bundled with QEMU -- but the firmware images in the distros' own EDK2 packages are different. So, if a distro provides an EDK2 package, then the same EDK2 package should offer matching descriptors. QEMU offers descriptors (soon) because QEMU technically distributes edk2 firmware binaries (soon). [Where "soon" == QEMU 4.1] (2) And as Dan Berrangé reminded on IRC: In Fedora, we need to ship them [the "descriptor files"] as part of the EDK2 package, because Fedora throws away all the firmware files that QEMU bundles, because we're [Fedora] required to rebuild everything from pristine source. - - - In this patch: (*) Use the firmware descriptor files provided by Laszlo (thanks!) in this comment here: https://bugzilla.redhat.com/show_bug.cgi?id=1728652#c2 ("RFE: Ship the JSON firmware "descriptor files" as part of EDK2"). On the double-digit priority prefixes, refer to the rationale here: https://src.fedoraproject.org/rpms/edk2/pull-request/3#comment-27523 (*) Install the JSON files for the relevant architectures in `/usr/share/qemu/firmware`, as required by specification[+]. And make each EDK2 own this directory; multiple RPMs owning the same directory is no problem. [+] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json Resolves: rhbz#1728652 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
2019-07-12 09:20:38 +00:00
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
json descriptors: explicitly set mode = split
2023-05-16 12:48:40 +00:00
"mode" : "split",
Ship the JSON firmware "descriptor files" From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and so forth. You can see examples of these files from the QEMU upstream Git: https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors $> tree descriptors/ descriptors/ ├── 50-edk2-i386-secure.json ├── 50-edk2-x86_64-secure.json ├── 60-edk2-aarch64.json ├── 60-edk2-arm.json ├── 60-edk2-i386.json └── 60-edk2-x86_64.json QEMU 4.1 itself will ship the above files. However, Fedora needs to ship these file as part of its EDK2 package. Why? ---- (1) Quoting (with minor formatting edits) Laszlo Ersek: Distributions providing their own EDK2 packages would not include the descriptors from upstream QEMU, even if they otherwise package QEMU. That's beause the descriptor files in QEMU match the firmware bundled with QEMU -- but the firmware images in the distros' own EDK2 packages are different. So, if a distro provides an EDK2 package, then the same EDK2 package should offer matching descriptors. QEMU offers descriptors (soon) because QEMU technically distributes edk2 firmware binaries (soon). [Where "soon" == QEMU 4.1] (2) And as Dan Berrangé reminded on IRC: In Fedora, we need to ship them [the "descriptor files"] as part of the EDK2 package, because Fedora throws away all the firmware files that QEMU bundles, because we're [Fedora] required to rebuild everything from pristine source. - - - In this patch: (*) Use the firmware descriptor files provided by Laszlo (thanks!) in this comment here: https://bugzilla.redhat.com/show_bug.cgi?id=1728652#c2 ("RFE: Ship the JSON firmware "descriptor files" as part of EDK2"). On the double-digit priority prefixes, refer to the rationale here: https://src.fedoraproject.org/rpms/edk2/pull-request/3#comment-27523 (*) Install the JSON files for the relevant architectures in `/usr/share/qemu/firmware`, as required by specification[+]. And make each EDK2 own this directory; multiple RPMs owning the same directory is no problem. [+] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json Resolves: rhbz#1728652 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
2019-07-12 09:20:38 +00:00
"executable": {
"filename": "/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd",
"format": "raw"
},
"nvram-template": {
Copy VARS from plain ovmf/ to ovmf-ia32/ Apparently that works fine, but let's use explicit dirs
2019-07-12 18:08:23 +00:00
"filename": "/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd",
Ship the JSON firmware "descriptor files" From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and so forth. You can see examples of these files from the QEMU upstream Git: https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors $> tree descriptors/ descriptors/ ├── 50-edk2-i386-secure.json ├── 50-edk2-x86_64-secure.json ├── 60-edk2-aarch64.json ├── 60-edk2-arm.json ├── 60-edk2-i386.json └── 60-edk2-x86_64.json QEMU 4.1 itself will ship the above files. However, Fedora needs to ship these file as part of its EDK2 package. Why? ---- (1) Quoting (with minor formatting edits) Laszlo Ersek: Distributions providing their own EDK2 packages would not include the descriptors from upstream QEMU, even if they otherwise package QEMU. That's beause the descriptor files in QEMU match the firmware bundled with QEMU -- but the firmware images in the distros' own EDK2 packages are different. So, if a distro provides an EDK2 package, then the same EDK2 package should offer matching descriptors. QEMU offers descriptors (soon) because QEMU technically distributes edk2 firmware binaries (soon). [Where "soon" == QEMU 4.1] (2) And as Dan Berrangé reminded on IRC: In Fedora, we need to ship them [the "descriptor files"] as part of the EDK2 package, because Fedora throws away all the firmware files that QEMU bundles, because we're [Fedora] required to rebuild everything from pristine source. - - - In this patch: (*) Use the firmware descriptor files provided by Laszlo (thanks!) in this comment here: https://bugzilla.redhat.com/show_bug.cgi?id=1728652#c2 ("RFE: Ship the JSON firmware "descriptor files" as part of EDK2"). On the double-digit priority prefixes, refer to the rationale here: https://src.fedoraproject.org/rpms/edk2/pull-request/3#comment-27523 (*) Install the JSON files for the relevant architectures in `/usr/share/qemu/firmware`, as required by specification[+]. And make each EDK2 own this directory; multiple RPMs owning the same directory is no problem. [+] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json Resolves: rhbz#1728652 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
2019-07-12 09:20:38 +00:00
"format": "raw"
}
},
"targets": [
{
"architecture": "i386",
"machines": [
"pc-i440fx-*",
"pc-q35-*"
]
}
],
"features": [
"acpi-s3",
"verbose-dynamic"
],
"tags": [
]
}
Reference in New Issue Copy Permalink