Openembedded Core Discussions
 help / color / mirror / Atom feed
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"




  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