On Wed, 16 Jan 2019 17:22:31 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 01/16/19 13:31, Igor Mammedov wrote: > > On Wed, 16 Jan 2019 12:52:17 +0100 > > Gerd Hoffmann <kra...@redhat.com> wrote: > > > >> Hi, > >> > >>> This approach allows the UEFI app source to live in the QEMU tree, and > >>> the affected maintainer(s) would be personally responsible for setting > >>> up their edk2 clones, and compilers. (The edk2 clone could even be a > >>> submodule of QEMU, for example at roms/edk2.) For example, > >>> "roms/Makefile" already calls an external EFIROM utility (also from > >>> edk2) in order to build the combined iPXE option ROMs. > >>> > >>> And yes, we could turn the UEFI binaries into bootable ISO images at once. > >>> > >>> I'll try to post some patches soon (or not so soon). I think the app's > >>> source code, and the edk2 submodule, should live under roms/, and the > >>> bootable images should live under pc-bios/. > >>> > >>> (In fact we could use this opportunity to build & bundle OVMF itself... > >>> not sure if that's in scope for now. Gerd, what's your take?) > >> > >> Well, there is still the idea to move over firmware submodules and > >> prebuilt firmware blobs to a separate repo. Expermimental repo: > >> https://git.kraxel.org/cgit/qemu-firmware/. Not touched for more than a > >> year due to being busy with other stuff. Oh well ... > >> > >> (if someone feels like picking this up feel free to do so). > >> > >> I think adding edk2 as submodule below roms/ makes sense. Adding rules > >> to roms/Makefile to build the blobs makes sense too. Not sure we want > >> the binaries actually copied over to pc-bios/ and commited as the uefi > >> firmware is pretty big ... > >> > >> Not sure what a good place for the uefi app would be. I'd tend to not > >> use roms/, that is the place for firmware submodules. > > I figured the source code for the UEFI app would fit due to the script > "configure-seabios.sh" and some actual config files being there already. > But, I'm happy to follow directions. :) > > >> contrib/ or test/ maybe? > > > Could be tests/data/acpi in this case > > If "tests/data/acpi" is appropriate for source code, that works for me. > We already have "rebuild-expected-aml.sh" there, so I guess another > build script and the UEFI app source code would fit there too. I suggested tests/data/acpi for binary EFI app blobs For EFI app source maybe just 'tests' or sub-directory there and make 'make check-efi-app' build EFI app (doing all needed magic and asking for things that missing) if source is newer than blobs. > > It would be nice if I could get around submitting some patches this > week. Sigh. :/ > > Thanks, > Laszlo >
