Add UEFI firmware for qemux86*
v3 cover Add UEFI firmware for qemux86*
From: Leonardo Sandoval <[email protected]>
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
Signature · 1 line
1.8.4.5
PATCH v3 1/3 iasl: Recipe taken from the luv-yocto repository
From: Leonardo Sandoval <[email protected]>
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
--- meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bb
meta/recipes-extended/iasl/iasl_20150515.bb new file +27 -0
@@ -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 +}
Signature · 1 line
1.8.4.5
Re: [PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository
Quoted 6 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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.
Quoted 7 lines
[1] https://github.com/01org/luv-yocto/tree/master/meta-luv/recipes-extended/iasl
Signed-off-by Leonardo Sandoval <[email protected]>--- 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
Quoted 9 lines · Richard Purdie
Quoted 7 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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
Quoted 21 lines
Quoted 5 lines
Signed-off-by Leonardo Sandoval <[email protected]>--- meta/recipes-extended/iasl/iasl_20150515.bb | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 meta/recipes-extended/iasl/iasl_20150515.bbSadly 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/213Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH V3 1/3] iasl: Recipe taken from the luv-yocto repository
In reply to Richard PurdieQuoted 10 lines · Richard Purdie
Quoted 8 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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
Quoted 8 lines
Quoted 5 lines
Signed-off-by Leonardo Sandoval <[email protected]>--- 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.
PATCH v3 2/3 ovmf: Recipe taken from luv-yocto repository
In reply to [email protected]From: Leonardo Sandoval <[email protected]>
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]
--- ...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
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch new file +48 -0
@@ -0,0 +1,48 @@ +From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001 +From: Matt Fleming <[email protected]> +Date: Fri, 27 Jun 2014 11:12:18 +0100 +Subject: [PATCH] BaseTools: Force tools variables to host toolchain + +Signed-off-by: Matt Fleming <[email protected]> +--- + 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 +
meta/recipes-core/ovmf/ovmf_git.bb new file +61 -0
61 lines not on this page · raw message
Signature · 1 line
1.8.4.5
PATCH v3 3/3 runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot
In reply to [email protected]From: Leonardo Sandoval <[email protected]>
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 \
nographicNote 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]
--- scripts/runqemu | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
scripts/runqemu +12 -1
@@ -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"
Signature · 1 line
1.8.4.5
Re: [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot
Quoted 7 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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:
Quoted 8 lines
$ runqemu qemux86-64 core-image-minimal \ biosdir=usr/share/ovmf \ biosfilename=bios.bin \ nographicNote 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
Signature · 6 lines
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
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.
Quoted 56 lines · Patrick Ohly
Quoted 7 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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:Quoted 8 lines
$ runqemu qemux86-64 core-image-minimal \ biosdir=usr/share/ovmf \ biosfilename=bios.bin \ nographicNote 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
Quoted 4 lines · 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.
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.
Signature · 6 lines
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
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.
Quoted 13 lines · Patrick Ohly
Quoted 4 lines · 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.
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
Quoted 5 lines · Leonardo Sandoval
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.
Signature · 6 lines
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.
Quoted 9 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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 includeOECORE_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 themeta/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
Signature · 6 lines
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.
Quoted 18 lines · On Thursday 27 August 2015 15:19:57 Patrick Ohly wrote:
On Tue, 2015-07-14 at 20:07 +0000,
Quoted 11 lines · [email protected] wrote:
From: Leonardo Sandoval <[email protected]>
These patches include:
1. iasl recipe taken from luv-yocto repository into OE-Core (the onlychange 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 includeOECORE_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.
Quoted 9 lines
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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 12 lines · Patrick Ohly
Quoted 9 lines · On Tue, 2015-07-14 at 20:07 +0000, [email protected]…
From: Leonardo Sandoval <[email protected]>
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 includeOECORE_MACHINE_SYSROOT, so the OVMF BIOS can be found.
Quoted 7 lines
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 themeta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patchbecause 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 duringdo_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.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
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
Quoted 10 lines · Leonardo Sandoval
Quoted 6 lines · Patrick Ohly
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.
Quoted 10 lines
Quoted 8 lines
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?
Signature · 6 lines
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.