On 09/28/18 19:07, Philippe Mathieu-Daudé wrote: > On 28/09/2018 12:51, Laszlo Ersek wrote:
>> Figuring out the options is complicated enough (for management tools >> as well) that Daniel made us define a metadata schema for describing >> firmware packages. Please see: >> >> docs/interop/firmware.json >> >> I'm not necessarily suggesting that Avocado be able to parse the >> firmware descriptor metafiles that conform to this schema. I'm just >> pointing out that the QEMU command line will depend on the exact build >> of the firmware image under test. The pathname >> "/usr/share/OVMF/OVMF_CODE.fd" and the URL >> "https://snapshots.linaro.org/.../QEMU_EFI.img.gz"; don't give us >> enough information. >> >> Therefore, if we want to keep the test case simple (= hard-wire the >> command lines), then we'll have to refer to OVMF and ArmVirtQemu >> images with precisely known build configs. > > To focus on QEMU here, I'd like to not have to build a know EDK2 config > but rather use releases (or snapshots). If you mean specific binary releases (released by some well-known specific party), that should work; but they should be available to everyone. If you mean source releases / snapshots, those don't provide enough information. You can still build OVMF with and without -D SMM_REQUIRE, for example, and the QEMU command line options will differ. This is not much different from using a Linux guest kernel image for testing. For example, you can build Linux without virtio drivers, and then you can't use the resultant image for checking QEMU's virtio devices. I.e., the guest build config is part of the equation. > scripts/qemu.py should provide utilities to pack a flash image for > further testing. AIUI, upstream QEMU wouldn't like to bundle more binaries / depend on more external projects. Also, if you build OVMF with a feature that requires OpenSSL, then the resultant binary (covered by the 2-clause BSD license and the OpenSSL license) might not be suitable for bundling with QEMU. Thanks, Laszlo
