[PATCH V3 0/3] Add UEFI firmware for qemux86*

[PATCH V3 0/3] Add UEFI firmware for qemux86*

[leonardo.sandoval.gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>

These patches include:

    1. iasl recipe taken from luv-yocto repository into OE-Core (the only 
       change done was the LICENSE, from Intel-ACPI to BSD | GPLv2)
    2. OVMF recipe (taken from luv-yocto repository) into OE-Core
    3. Boot script: Instrumenting runqemu to include OECORE_MACHINE_SYSROOT, 
    so the OVMF BIOS can be found.

[YOCTO #5654]

  bitbake: cooker: Improve DATE/TIME handling (2015-07-08 00:06:08 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lsandov1/efi-qemux86
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/efi-qemux86

Leonardo Sandoval (3):
  iasl: Recipe taken from the luv-yocto repository
  ovmf: Recipe taken from luv-yocto repository
  runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

 ...s-Force-tools-variables-to-host-toolchain.patch | 48 +++++++++++++++++
 meta/recipes-core/ovmf/ovmf_git.bb                 | 61 ++++++++++++++++++++++
 meta/recipes-extended/iasl/iasl_20150515.bb        | 27 ++++++++++
 scripts/runqemu                                    | 13 ++++-
 4 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
 create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb
 create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb

-- 
1.8.4.5

[PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository

[leonardo.sandoval.gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>

Taken from [1]. ACPICA is licensed under two main licenses:
1) An Intel license (Intel-ACPI) and 2) a dual GPL/BSP license. This
recipe uses the latter.

[1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-extended/iasl

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
---
 meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb

diff --git a/meta/recipes-extended/iasl/iasl_20150515.bb b/meta/recipes-extended/iasl/iasl_20150515.bb
new file mode 100644
index 0000000..b6b9050
--- /dev/null
+++ b/meta/recipes-extended/iasl/iasl_20150515.bb
@@ -0,0 +1,27 @@
+DESCRIPTION = "This is a cross development C compiler, assembler and linker environment for the production of 8086 executables (Optionally MSDOS COM)"
+HOMEPAGE = "http://www.acpica.org/"
+LICENSE = "GPLv2 | BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://source/include/acapps.h;beginline=7;endline=114;md5=9204ca6fc24d2e54f659ec512ea51f01"
+SECTION = "console/tools"
+PR="r1"
+
+DEPENDS="flex-native bison-native"
+
+SRC_URI="https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz"
+
+SRC_URI[md5sum] = "c8c128b2d4859b52bc9c802faba2e908"
+SRC_URI[sha256sum] = "bfa1f296a3cc13421331dbaad3b62e0184678cc312104c3e8ac799ead0742c45"
+
+S="${WORKDIR}/acpica-unix-${PV}"
+
+NATIVE_INSTALL_WORKS = "1"
+BBCLASSEXTEND = "native"
+
+do_compile() {
+	make iasl
+}
+
+do_install() {
+	mkdir -p ${D}${prefix}/bin
+	cp ${S}/generate/unix/bin/iasl ${D}${prefix}/bin
+}
-- 
1.8.4.5

Re: [PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository

[Richard Purdie]

On Tue, 2015-07-14 at 20:07 +0000,
leonardo.sandoval.gonzalez@linux.intel.com wrote:
> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> 
> Taken from [1]. ACPICA is licensed under two main licenses:
> 1) An Intel license (Intel-ACPI) and 2) a dual GPL/BSP license. This
> recipe uses the latter.
> 
> [1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-extended/iasl
> 
> Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> ---
>  meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb

Sadly this and the ovmf patch trigger failures in world and world-lsb
builds:

https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/495
https://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/213

Cheers,

Richard

Re: [PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository

[Fathi Boudra]

On 13 September 2015 at 01:00, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2015-07-14 at 20:07 +0000,
> leonardo.sandoval.gonzalez@linux.intel.com wrote:
>> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>>
>> Taken from [1]. ACPICA is licensed under two main licenses:
>> 1) An Intel license (Intel-ACPI) and 2) a dual GPL/BSP license. This
>> recipe uses the latter.
>>
>> [1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-extended/iasl

fwiw, acpica is already part of meta-oe and generate iasl:
http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-extended/acpica/acpica_20140828.bb?h=master

>> Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>> ---
>>  meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++
>>  1 file changed, 27 insertions(+)
>>  create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
>
> Sadly this and the ovmf patch trigger failures in world and world-lsb
> builds:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/495
> https://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/213
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository

[Leonardo Sandoval]

On 09/12/2015 05:00 PM, Richard Purdie wrote:
> On Tue, 2015-07-14 at 20:07 +0000,
> leonardo.sandoval.gonzalez@linux.intel.com wrote:
>> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>>
>> Taken from [1]. ACPICA is licensed under two main licenses:
>> 1) An Intel license (Intel-ACPI) and 2) a dual GPL/BSP license. This
>> recipe uses the latter.
>>
>> [1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-extended/iasl
>>
>> Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>> ---
>>   meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++
>>   1 file changed, 27 insertions(+)
>>   create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
>
> Sadly this and the ovmf patch trigger failures in world and world-lsb
> builds:

RP, Working on it. I will send an update ASAP.

>
> https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/495
> https://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/213
>
> Cheers,
>
> Richard
>

[PATCH V3 2/3] ovmf: Recipe taken from luv-yocto repository

[leonardo.sandoval.gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>

OVMF metadata taken from the luv-yocto[1] repository and copied into
OE-Core meta/recipes-core folder.

[1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-core/ovmf

[YOCTO #5654]

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
---
 ...s-Force-tools-variables-to-host-toolchain.patch | 48 +++++++++++++++++
 meta/recipes-core/ovmf/ovmf_git.bb                 | 61 ++++++++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
 create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb

diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
new file mode 100644
index 0000000..c0cc633
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
@@ -0,0 +1,48 @@
+From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001
+From: Matt Fleming <matt.fleming@intel.com>
+Date: Fri, 27 Jun 2014 11:12:18 +0100
+Subject: [PATCH] BaseTools: Force tools variables to host toolchain
+
+Signed-off-by: Matt Fleming <matt.fleming@intel.com>
+---
+ BaseTools/Source/C/Makefiles/app.makefile | 7 +++++++
+ BaseTools/Source/C/VfrCompile/GNUmakefile | 5 +++++
+ 2 files changed, 12 insertions(+)
+
+diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile
+index 19269a1..62aad0f 100644
+--- a/BaseTools/Source/C/Makefiles/app.makefile
++++ b/BaseTools/Source/C/Makefiles/app.makefile
+@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile
+ 
+ APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
+ 
++CC = gcc
++CXX = g++
++AS = gcc
++AR = ar
++LD = ld
++LINKER = $(CC)
++
+ .PHONY:all
+ all: $(MAKEROOT)/bin $(APPLICATION) 
+ 
+diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile
+index 82005e1..5ac5f7e 100644
+--- a/BaseTools/Source/C/VfrCompile/GNUmakefile
++++ b/BaseTools/Source/C/VfrCompile/GNUmakefile
+@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn
+ 
+ VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS)
+ 
++CC = gcc
++CXX = g++
++AS = gcc
++AR = ar
++LD = ld
+ LINKER = $(CXX)
+ 
+ EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h
+-- 
+1.9.0
+
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
new file mode 100644
index 0000000..ce7e4f8
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -0,0 +1,61 @@
+DESCRIPTION = "OVMF - UEFI firmware for Qemu and KVM"
+HOMEPAGE = "http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=ffd52cf9a8e0e036b9a61a0de2dc87ed"
+
+SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
+	file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch"
+
+SRCREV="dc4ad1532e59fd1a185d6b90d1c2a92cf8713f40"
+
+S = "${WORKDIR}/git"
+
+DEPENDS_class-native="util-linux-native iasl-native"
+
+# OVMF has trouble building with the default optimization of -O2.
+BUILD_OPTIMIZATION="-pipe"
+
+# OVMF supports IA only, although it could conceivably support ARM someday.
+COMPATIBLE_HOST='(i.86|x86_64).*'
+
+do_patch_append() {
+    bb.build.exec_func('do_fix_iasl', d)
+    bb.build.exec_func('do_fix_toolchain', d)
+}
+
+do_fix_iasl() {
+    sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
+}
+
+do_fix_toolchain(){
+    sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
+    sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' ${S}/BaseTools/Conf/tools_def.template
+    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
+    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/Makefiles/app.makefile
+    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+    sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" ${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+}
+
+GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}' | awk -F. '{print $1$2}')"
+
+do_compile() {
+    export LFLAGS="${LDFLAGS}"
+    OVMF_ARCH="X64"
+    if [ "${TARGET_ARCH}" != "x86_64" ] ; then
+        OVMF_ARCH="IA32"
+    fi
+    ${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t GCC${GCC_VER}
+}
+
+do_install() {
+    OVMF_DIR_SUFFIX="X64"
+    if [ "${TARGET_ARCH}" != "x86_64" ] ; then
+        OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
+    fi
+    install -d ${D}${datadir}/ovmf
+    build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_GCC${GCC_VER}"
+    install -m 0755 ${build_dir}/FV/OVMF.fd \
+	${D}${datadir}/ovmf/bios.bin
+}
+
+BBCLASSEXTEND = "native"
-- 
1.8.4.5

[PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[leonardo.sandoval.gonzalez]

From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>

At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS
under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT.
The latter is used when searching BIOS, VGA BIOS and keymaps. As a example,
to boot a OVFM BIOS, one can run the following command:

$ runqemu qemux86-64 core-image-minimal \
    biosdir=usr/share/ovmf  \
    biosfilename=bios.bin \
    nographic

Note the bios* parameters: these two are needed to specify the subfolder
(parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it,
it picks a BIOS named bios-256k.bin).

[YOCTO #5654]

Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
---
 scripts/runqemu | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 09c507d..f68dba1 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -397,6 +397,13 @@ setup_sysroot() {
 
         OECORE_NATIVE_SYSROOT=$OE_TMPDIR/sysroots/$BUILD_SYS
     fi 
+
+    # Some recipes store the BIOS under $OE_TMPDIR/sysroots/$MACHINE,
+    # now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching
+    # BIOS, VGA BIOS and keymaps.
+    if [ -z "$OECORE_MACHINE_SYSROOT" ]; then
+        OECORE_MACHINE_SYSROOT=$OE_TMPDIR/sysroots/$MACHINE
+    fi
 }
 
 # Locate a rootfs image to boot which matches our expected
@@ -486,7 +493,7 @@ fi
 echo "FSTYPE: [$FSTYPE]"
 
 setup_sysroot
-# OECORE_NATIVE_SYSROOT is now set for all cases
+# OECORE_NATIVE_SYSROOT and OECORE_MACHINE_SYSROOT are now set for all cases
 
 INTERNAL_SCRIPT="$0-internal"
 if [ ! -f "$INTERNAL_SCRIPT" -o ! -r "$INTERNAL_SCRIPT" ]; then
@@ -498,10 +505,14 @@ if [ ! -z "$CUSTOMBIOSDIR" ]; then
     if [ -d "$OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" ]; then
         echo "Assuming biosdir is $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
         SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
+    elif [ -d "$OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" ]; then
+        echo "Assuming biosdir is $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR"
+        SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR"
     else
         if [ ! -d "$CUSTOMBIOSDIR" ]; then
             echo "Custom BIOS directory not found. Tried: $CUSTOMBIOSDIR"
             echo "and $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR"
+            echo "and $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR"
             exit 1;
         fi
         echo "Assuming biosdir is $CUSTOMBIOSDIR"
-- 
1.8.4.5

Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Patrick Ohly]

On Tue, 2015-07-14 at 20:07 +0000,
leonardo.sandoval.gonzalez@linux.intel.com wrote:
> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> 
> At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS
> under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT.
> The latter is used when searching BIOS, VGA BIOS and keymaps. As a example,
> to boot a OVFM BIOS, one can run the following command:
> 
> $ runqemu qemux86-64 core-image-minimal \
>     biosdir=usr/share/ovmf  \
>     biosfilename=bios.bin \
>     nographic
> 
> Note the bios* parameters: these two are needed to specify the subfolder
> (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it,
> it picks a BIOS named bios-256k.bin).

While researching the nvram support question I came across the ovmf
whitepaper [1] showing how to use OVMF via "-drive
if=pflash,format=raw,file=fedora.flash" (where fedora.flash is a per-vm
copy of OVMF.fd = bios.bin in the sysroot).

I kept wondering why you were using "-bios bios.bin" instead of the
-drive method, and how that would affect nvram support. Then I found a
pretty clear statement by Laszlo Ersek, one of the OVMF co-maintainers,
saying [2] that -bios and the nvram support possible with it (storing in
an NvRam file in the EFI boot partition) are a kludge that should not be
used anymore.

So in other words, this particular patch needs further work. Perhaps add
an "ovmf" keyword (selecting the bios.bin as pflash drive), file name
handling (treat anything ending in .bin or .fd as pflash, supporting
more than one) and a OVMF env variable with a corresponding colon
separated list of pflash files?

I also wonder about the "bios.bin" name and the ".bin" suffix. I think
it would be better to stick with the upstream convention and just
install the file in the sysroot as OVMF.fd. This simplifies the file
name handling such that only .fd is special.

Note that the upstream discussion was about per-vm nvram storage. I
think in the context of runqemu it is okay to have a single file per
build configuration, because effectively we are creating a single
machine with one OS image. What's less nice is that the sysroot will get
modified when using bios.bin as pflash drive. Resetting the nvram needs
to be done with "bitbake -c clean ovmf && bitbake ovmf". Both is not
obvious.

Perhaps if runqemu picks up the file automatically from the sysroot (the
"ovmf" keyword usage), it should make a copy in tmp (on first run) and
then use that copy instead?

[1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Leonardo Sandoval]

Hi Patrick,

I do not have much time for a V4 set of patches, but now with all your 
input I can rework V3 patches on 2.1. Copying Matt and Ricardo, they 
helped me when porting these patches into poky. They may have other 
comments.



On 08/28/2015 02:29 AM, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 20:07 +0000,
> leonardo.sandoval.gonzalez@linux.intel.com wrote:
>> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>>
>> At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS
>> under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT.
>> The latter is used when searching BIOS, VGA BIOS and keymaps. As a example,
>> to boot a OVFM BIOS, one can run the following command:
>>
>> $ runqemu qemux86-64 core-image-minimal \
>>      biosdir=usr/share/ovmf  \
>>      biosfilename=bios.bin \
>>      nographic
>>
>> Note the bios* parameters: these two are needed to specify the subfolder
>> (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it,
>> it picks a BIOS named bios-256k.bin).
>
> While researching the nvram support question I came across the ovmf
> whitepaper [1] showing how to use OVMF via "-drive
> if=pflash,format=raw,file=fedora.flash" (where fedora.flash is a per-vm
> copy of OVMF.fd = bios.bin in the sysroot).
>
> I kept wondering why you were using "-bios bios.bin" instead of the
> -drive method, and how that would affect nvram support. Then I found a
> pretty clear statement by Laszlo Ersek, one of the OVMF co-maintainers,
> saying [2] that -bios and the nvram support possible with it (storing in
> an NvRam file in the EFI boot partition) are a kludge that should not be
> used anymore.
>
> So in other words, this particular patch needs further work. Perhaps add
> an "ovmf" keyword (selecting the bios.bin as pflash drive), file name
> handling (treat anything ending in .bin or .fd as pflash, supporting
> more than one) and a OVMF env variable with a corresponding colon
> separated list of pflash files?
>
> I also wonder about the "bios.bin" name and the ".bin" suffix. I think
> it would be better to stick with the upstream convention and just
> install the file in the sysroot as OVMF.fd. This simplifies the file
> name handling such that only .fd is special.
>
> Note that the upstream discussion was about per-vm nvram storage. I
> think in the context of runqemu it is okay to have a single file per
> build configuration, because effectively we are creating a single
> machine with one OS image. What's less nice is that the sysroot will get
> modified when using bios.bin as pflash drive. Resetting the nvram needs
> to be done with "bitbake -c clean ovmf && bitbake ovmf". Both is not
> obvious.
>
> Perhaps if runqemu picks up the file automatically from the sysroot (the
> "ovmf" keyword usage), it should make a copy in tmp (on first run) and
> then use that copy instead?
>
> [1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47
>

Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Patrick Ohly]

On Fri, 2015-08-28 at 08:34 -0500, Leonardo Sandoval wrote:
> Hi Patrick,
> 
> I do not have much time for a V4 set of patches, but now with all your 
> input I can rework V3 patches on 2.1.

What do you mean with "rework on on 2.1"?

I have some other runqemu changes pending locally (support booting
hddimg), so runqemu internals are still kinda fresh in my mind. If you
don't have time, then I can rework the patch series. However, it's a
side project for me, too.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Leonardo Sandoval]

Patrick

these set of patches should be merged into master(next). I do not see 
any heavy objection doing it. As you mentioned, there are some points to 
improve but I think the latter can be done before 2.1 release.

Let me know if you have any objections, otherwise the merge is pending.

On 08/28/2015 01:08 PM, Patrick Ohly wrote:
> On Fri, 2015-08-28 at 08:34 -0500, Leonardo Sandoval wrote:
>> Hi Patrick,
>>
>> I do not have much time for a V4 set of patches, but now with all your
>> input I can rework V3 patches on 2.1.
>
> What do you mean with "rework on on 2.1"?
>
> I have some other runqemu changes pending locally (support booting
> hddimg), so runqemu internals are still kinda fresh in my mind. If you
> don't have time, then I can rework the patch series. However, it's a
> side project for me, too.
>

Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Patrick Ohly]

On Wed, 2015-09-02 at 14:40 -0500, Leonardo Sandoval wrote:
> these set of patches should be merged into master(next). I do not see 
> any heavy objection doing it. As you mentioned, there are some points to 
> improve but I think the latter can be done before 2.1 release.
> 
> Let me know if you have any objections, otherwise the merge is pending.

No objections from me.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH V3 0/3] Add UEFI firmware for qemux86*

[Patrick Ohly]

On Tue, 2015-07-14 at 20:07 +0000,
leonardo.sandoval.gonzalez@linux.intel.com wrote:
> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> 
> These patches include:
> 
>     1. iasl recipe taken from luv-yocto repository into OE-Core (the only 
>        change done was the LICENSE, from Intel-ACPI to BSD | GPLv2)
>     2. OVMF recipe (taken from luv-yocto repository) into OE-Core
>     3. Boot script: Instrumenting runqemu to include OECORE_MACHINE_SYSROOT, 
>     so the OVMF BIOS can be found.

I've tried out these patches. Mostly it worked as advertised and I'd
love to use EFI with qemu, so I'd like to see this merged.

I noticed that "git format-patches" from your branch followed by "git
am" mangles the
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch because it is a mixture of Unix line ends (patch boiler plate) and DOS line ends (actual patches). The file ended up with all Unix line ends, which then failed during do_patch. I solved that by checking out your branch and copying the file. Whoever merges needs to be careful here. This might also be a problem for combo-layer, so perhaps a solution not based on patching the makefiles may be needed.

When I use runqemu, it ends up invoking qemu with "-vga vmware". With
that, I don't see any output from TianoCore and booting hangs. It boots
when disabling graphical output ("serial nographic" as parameter of
runqemu) or when explicitly selecting a different graphics
("'qemuparams=-vga std'"). Might be worthwhile adding to the commit
message.

It wasn't clear from the description whether one had to build "ovmf" or
"ovmf-native" - it's the former (obvious after thinking about it some
more, because the code runs on the target).

Do you happen to know how non-volatile EFI variables are handled? There
are several posts from around 2012 saying that qemu does not support
storing nvram persistently (for example, [1]). I've not seen anything
more recent directly contradicting that, but there seems to be
something, at least in Fedora [2]. That patch mentions that "OVMF [...]
works in two
modes: 1) Code and UEFI variable store is mixed in one file. ...".

I'm probably doing something wrong (haven't tried this before), but when
I do a "setvar foobar ="foobar" in the EFI shell, I just get a "unable
to set: Invalid Parameter" error, with and without -nv.

[1] http://blog.hansenpartnership.com/uefi-secure-boot/
[2] http://www.redhat.com/archives/libvir-list/2014-August/msg00960.html


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH V3 0/3] Add UEFI firmware for qemux86*

[Paul Eggleton]

On Thursday 27 August 2015 15:19:57 Patrick Ohly wrote:
> On Tue, 2015-07-14 at 20:07 +0000,
> 
> leonardo.sandoval.gonzalez@linux.intel.com wrote:
> > From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> > 
> > These patches include:
> >     1. iasl recipe taken from luv-yocto repository into OE-Core (the only
> >     
> >        change done was the LICENSE, from Intel-ACPI to BSD | GPLv2)
> >     
> >     2. OVMF recipe (taken from luv-yocto repository) into OE-Core
> >     3. Boot script: Instrumenting runqemu to include
> >     OECORE_MACHINE_SYSROOT,
> >     so the OVMF BIOS can be found.
> 
> I've tried out these patches. Mostly it worked as advertised and I'd
> love to use EFI with qemu, so I'd like to see this merged.
> 
> I noticed that "git format-patches" from your branch followed by "git
> am" mangles the
> meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-too
> lchain.patch because it is a mixture of Unix line ends (patch boiler plate)
> and DOS line ends (actual patches). The file ended up with all Unix line
> ends, which then failed during do_patch. I solved that by checking out your
> branch and copying the file. Whoever merges needs to be careful here. This
> might also be a problem for combo-layer, so perhaps a solution not based on
> patching the makefiles may be needed.

Good to note this - FYI the --keep-cr option is what you need to add to your 
"git am" command line in order to avoid this problem. combo-layer does this 
already (we hit this same problem with patches to files with DOS line endings a 
while back).

This is one reason why using the branch is usually a lot easier and safer than 
applying emails as patches (assuming the submitter sends a pull request with a 
branch - I'd encourage everyone sending series of more than a couple of 
patches to do this using the create-pull-request/send-pull-request scripts if 
they aren't already).

Cheers,
Paul
-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH V3 0/3] Add UEFI firmware for qemux86*

[Leonardo Sandoval]

On 08/27/2015 08:19 AM, Patrick Ohly wrote:
> On Tue, 2015-07-14 at 20:07 +0000,
> leonardo.sandoval.gonzalez@linux.intel.com wrote:
>> From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
>>
>> These patches include:
>>
>>      1. iasl recipe taken from luv-yocto repository into OE-Core (the only
>>         change done was the LICENSE, from Intel-ACPI to BSD | GPLv2)
>>      2. OVMF recipe (taken from luv-yocto repository) into OE-Core
>>      3. Boot script: Instrumenting runqemu to include OECORE_MACHINE_SYSROOT,
>>      so the OVMF BIOS can be found.
>
> I've tried out these patches. Mostly it worked as advertised and I'd
> love to use EFI with qemu, so I'd like to see this merged.
>
> I noticed that "git format-patches" from your branch followed by "git
> am" mangles the
> meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch because it is a mixture of Unix line ends (patch boiler plate) and DOS line ends (actual patches). The file ended up with all Unix line ends, which then failed during do_patch. I solved that by checking out your branch and copying the file. Whoever merges needs to be careful here. This might also be a problem for combo-layer, so perhaps a solution not based on patching the makefiles may be needed.
>

I believe Paul has answered this. I also got some trouble, in fact the 
reason I sent V3 was because I patch incorrectly V2. it is a pain these 
line endings.

> When I use runqemu, it ends up invoking qemu with "-vga vmware". With
> that, I don't see any output from TianoCore and booting hangs. It boots
> when disabling graphical output ("serial nographic" as parameter of
> runqemu) or when explicitly selecting a different graphics
> ("'qemuparams=-vga std'"). Might be worthwhile adding to the commit
> message.

In the 3/3 commit's description, there is a command line with the 
nographic parameter. I did not test with any other kernel command line.

>
> It wasn't clear from the description whether one had to build "ovmf" or
> "ovmf-native" - it's the former (obvious after thinking about it some
> more, because the code runs on the target).
>

you are right. It is not obvious.

> Do you happen to know how non-volatile EFI variables are handled? There
> are several posts from around 2012 saying that qemu does not support
> storing nvram persistently (for example, [1]). I've not seen anything
> more recent directly contradicting that, but there seems to be
> something, at least in Fedora [2]. That patch mentions that "OVMF [...]
> works in two
> modes: 1) Code and UEFI variable store is mixed in one file. ...".
>

sorry, I do not know.

> I'm probably doing something wrong (haven't tried this before), but when
> I do a "setvar foobar ="foobar" in the EFI shell, I just get a "unable
> to set: Invalid Parameter" error, with and without -nv.
>
> [1] http://blog.hansenpartnership.com/uefi-secure-boot/
> [2] http://www.redhat.com/archives/libvir-list/2014-August/msg00960.html
>
>

Re: [PATCH V3 0/3] Add UEFI firmware for qemux86*

[Patrick Ohly]

On Thu, 2015-08-27 at 14:50 -0500, Leonardo Sandoval wrote:
> On 08/27/2015 08:19 AM, Patrick Ohly wrote:
> > When I use runqemu, it ends up invoking qemu with "-vga vmware". With
> > that, I don't see any output from TianoCore and booting hangs. It boots
> > when disabling graphical output ("serial nographic" as parameter of
> > runqemu) or when explicitly selecting a different graphics
> > ("'qemuparams=-vga std'"). Might be worthwhile adding to the commit
> > message.
> 
> In the 3/3 commit's description, there is a command line with the 
> nographic parameter. I did not test with any other kernel command line.

True, that example works. But it is not clear that the "nographic" is
important. Being explicit about it and adding the graphical case would
be useful.

> > Do you happen to know how non-volatile EFI variables are handled? There
> > are several posts from around 2012 saying that qemu does not support
> > storing nvram persistently (for example, [1]). I've not seen anything
> > more recent directly contradicting that, but there seems to be
> > something, at least in Fedora [2]. That patch mentions that "OVMF [...]
> > works in two
> > modes: 1) Code and UEFI variable store is mixed in one file. ...".
> >
> 
> sorry, I do not know.

I think this will require further work - see my comment on the runqemu
patch.

Do you have time for a forth revision?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.