qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 11/14] tests: acpi: add AVMF firmware blobs


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 11/14] tests: acpi: add AVMF firmware blobs
Date: Wed, 16 Jan 2019 11:01:58 -0500

On Wed, Jan 16, 2019 at 01:29:53PM +0100, Igor Mammedov wrote:
> On Tue, 15 Jan 2019 21:47:49 +0100
> Laszlo Ersek <address@hidden> wrote:
> 
> > On 01/15/19 16:41, Igor Mammedov wrote:
> > > Add firmware blobs built with PcdAcpiTestSupport=TRUE,
> > > that puts RSDP address in RAM after 1Mb aligned GUID
> > >   AB87A6B1-2034-BDA0-71BD-375007757785
> > > so that tests could scan and find it in RAM once firmware's
> > > initialized ACPI tables.
> > > 
> > > Signed-off-by: Igor Mammedov <address@hidden>
> > > ---
> > >  Makefile              |   3 ++-
> > >  pc-bios/avmf.img      | Bin 0 -> 2097152 bytes
> > >  pc-bios/avmf_vars.img | Bin 0 -> 786432 bytes
> > >  3 files changed, 2 insertions(+), 1 deletion(-)
> > >  create mode 100644 pc-bios/avmf.img
> > >  create mode 100644 pc-bios/avmf_vars.img  
> > 
> > "AVMF" is not a great name. "AAVMF" is a downstream name alright, but
> > many dislike it in upstream use. "edk2-aarch64" or "edk2-ArmVirtQemu"
> > would be more precise, but those are verbose. Sigh, why are names so
> > hard. What does everyone think?
> I'm fine with either version.
>  
> > Also, do you have to care about the license of firmware images built
> > from edk2 when bundling such images? Since edk2 commit 9a67ba261fe9
> > ("ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.",
> > 2018-12-14), you cannot build the ArmVirtQemu (aka AAVMF) firmware
> > without OpenSSL. Thus, the resultant license is 2-BSDL + OpenSSL -- for
> > now anyway.
> > 
> > Because, in the near future, that might change again. edk2 is in the
> > process of moving to Apache-2.0, and OpenSSL will also move (AFAICT) to
> > Apache-2.0 starting with release 3.0.0. (See commit 151333164ece,
> > "Change license to the Apache License v2.0", 2018-12-06.)
> That's another reason to look into EFI app approach (a simple one without
> dependencies) ans let distro to provide firmware image.

That will mean supporting very old firmware with the app.
I'm all for the EFI app approach for modularity
but I think we should include the batteries with this toy.


> > Thanks
> > Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]