From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 4/9] ovmf: deploy firmware in image directory
Date: Wed, 28 Dec 2016 13:38:44 -0800 [thread overview]
Message-ID: <1482961124.106950.55.camel@ranerica-desktop> (raw)
In-Reply-To: <ce57b729e9ac830d808040b7e3ff1fc128475420.1482324587.git.patrick.ohly@intel.com>
On Wed, 2016-12-21 at 14:11 +0100, Patrick Ohly wrote:
> When used with '-drive if=pflash', qemu will store UEFI variables
> inside the firmware image file. That is unexpected for a file located in
> the sysroot, which should be read-only, while it is normal for image
> files in the deploy/images directory. Therefore that directory is a
> better place for use with runqemu.
>
> The name was chose so that "runqemu ovmf" can be used as shorthand for
> "runqemu <full path>/ovmf.qcow2" by treating "ovmf" as the base name
> of the BIOS file. "ovmf_secboot.qcow2" is meant to be used for the
> Secure Boot enabled BIOS. qcow2 is used because it is needed for
> "savevm" snapshots of a virtual machine.
>
> Alternatively, OVMF_CODE.fd (read-only) and OVMF_VARS.fd (read/write)
> could be used. That would then allow updating the firmware of an
> existing machine without wiping out the variables set
> earlier. Configuring that in qemu would be more complicated, so for
> now the simpler approach with combined code and variable store is
> used.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> ---
> meta/recipes-core/ovmf/ovmf_git.bb | 33 +++++++++++++++++++++++----------
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
> index 13b583b..d0441d1 100644
> --- a/meta/recipes-core/ovmf/ovmf_git.bb
> +++ b/meta/recipes-core/ovmf/ovmf_git.bb
> @@ -16,7 +16,7 @@ PARALLEL_MAKE = ""
>
> S = "${WORKDIR}/git"
>
> -DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native"
> +DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native qemu-native"
>
> DEPENDS_class-target="ovmf-native"
>
> @@ -97,9 +97,20 @@ do_compile_class-target() {
> OVMF_ARCH="IA32"
> fi
>
> + # ${WORKDIR}/ovmf is a well-known location where do_install and
> + # do_deploy will be able to find the files.
> + rm -rf ${WORKDIR}/ovmf
> + mkdir ${WORKDIR}/ovmf
> + OVMF_DIR_SUFFIX="X64"
> + if [ "${TARGET_ARCH}" != "x86_64" ] ; then
> + OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
> + fi
> FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
> - echo FIXED_GCCVER is ${FIXED_GCCVER}
> + bbnote FIXED_GCCVER is ${FIXED_GCCVER}
> + build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
> +
> ${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER}
> + ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.fd
> }
>
> do_install_class-native() {
> @@ -108,16 +119,18 @@ do_install_class-native() {
> }
>
> do_install_class-target() {
> - OVMF_DIR_SUFFIX="X64"
> - if [ "${TARGET_ARCH}" != "x86_64" ] ; then
> - OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
> - fi
> + # Traditional location.
> install -d ${D}${datadir}/ovmf
> + install -m 0755 ${WORKDIR}/ovmf/OVMF.fd ${D}${datadir}/ovmf/bios.bin
Now that I think about it. Installing here does not sever any purpose.
Thus, I think this can be removed by perhaps doing do_install[noexec] =
"1"
> +}
>
> - FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
> - build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
> - install -m 0755 ${build_dir}/FV/OVMF.fd \
> - ${D}${datadir}/ovmf/bios.bin
> +inherit deploy
I am not sure if there is a right way for inheriting in bitbake.
However, a quick grep -n inherit reveals that the majority of the
recipes put their inheritances towards the top of the recipe.
Thanks and BR,
Ricardo
> +do_deploy() {
> +}
> +do_deploy_class-target() {
> + # For use with "runqemu ovmf".
> + qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/OVMF.fd ${DEPLOYDIR}/ovmf.qcow2
> }
> +addtask do_deploy after do_compile before do_build
>
> BBCLASSEXTEND = "native"
next prev parent reply other threads:[~2016-12-28 21:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-21 13:11 [PATCH 0/9] UEFI + Secure Boot + qemu Patrick Ohly
2016-12-21 13:11 ` [PATCH 1/9] ovmf: move from meta-luv to OE-core Patrick Ohly
2016-12-28 2:58 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 2/9] iasl: " Patrick Ohly
2016-12-21 14:11 ` Fathi Boudra
2016-12-21 15:38 ` Patrick Ohly
2016-12-21 18:17 ` Fathi Boudra
2016-12-28 3:08 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 3/9] ovmf: explicitly depend on nasm-native Patrick Ohly
[not found] ` <1482893989.106950.45.camel@ranerica-desktop>
2017-01-04 12:56 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 4/9] ovmf: deploy firmware in image directory Patrick Ohly
2016-12-28 3:12 ` Ricardo Neri
2016-12-28 21:38 ` Ricardo Neri [this message]
2016-12-28 23:25 ` Ricardo Neri
2017-01-04 10:01 ` Patrick Ohly
2017-01-10 3:50 ` Ricardo Neri
2017-01-10 7:32 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 5/9] ovmf_git.bb: enable parallel compilation Patrick Ohly
2016-12-28 3:17 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 6/9] ovmf_git.bb: enable Secure Boot Patrick Ohly
2016-12-28 22:54 ` Ricardo Neri
2017-01-04 10:10 ` Patrick Ohly
2017-01-10 3:51 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 7/9] runqemu: let command line parameters override defaults Patrick Ohly
2016-12-21 13:11 ` [PATCH 8/9] runqemu: support UEFI with OVMF firmware Patrick Ohly
2016-12-28 23:33 ` Ricardo Neri
2017-01-04 9:43 ` Patrick Ohly
2017-01-10 3:50 ` Ricardo Neri
2017-01-10 7:29 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 9/9] ovmf: build image which enrolls standard keys Patrick Ohly
2016-12-21 14:19 ` [PATCH 0/9] UEFI + Secure Boot + qemu Fathi Boudra
2016-12-28 2:56 ` Ricardo Neri
2016-12-28 19:27 ` Patrick Ohly
2016-12-28 23:26 ` Ricardo Neri
2016-12-28 2:55 ` Ricardo Neri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1482961124.106950.55.camel@ranerica-desktop \
--to=ricardo.neri-calderon@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox