On Tue, 15 Jan 2019 21:47:49 +0100
Laszlo Ersek <ler...@redhat.com> 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 <imamm...@redhat.com>
> > ---
> > 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.
> Thanks
> Laszlo
