Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: RFC: grub-efi native tools
Date: Tue, 22 Nov 2011 23:01:56 -0800	[thread overview]
Message-ID: <4ECC9A64.4080009@linux.intel.com> (raw)

While working towards supporting efi boot in live images, I have been
refactoring bootimg.bbclass, syslinux.bbclass, and adding recipes and
classes for grub-efi.

I'd like the seasoned OE experts' opinions on a question of
implementation. grub-efi seems to require a final step after the normal
build to assemble the efi image, specifically:

grub-mkimage -p / -d ./grub-core/ -O i386-efi -o ./bootia32.efi \
             boot linux fat serial part_msdos normal

grub-mkimage is a tool built during the grub-efi do_compile step, so it
needs to be native in order to run the above command. So I'm left with a
few options:

1) Use BBCLASSEXTEND="native" and make grub-efi depend on
   grub-efi-native so the native grub-mkimage is available.
   - I'm not sure how to avoid a circular dependency there,
     other than making an explicit grub-efi-native_1.99.bb.
   - No component of the grub-efi build needs to be installed
     on the target rootfs - so perhaps the the target arch version
     isn't needed at all...

2) Only build grub-efi-native.
   - The above grub-mkimage command fails with some incorrect elf format
     error messages on the grub kernel.img file. A similar error was
     reported on the grub mailing list when compiling with cygwin.
     Some work may be required to fix GRUB here.
   - Installing output of -native recipes onto the target seems to be a
     bit at odds with the existing mechanisms (it doesn't find
     bootia32.efi when placed in ${STAGING_LIBDIR}/grub by a -native
     build, for example).

3) Tweak the build so that only the grub-* utilities are built natively.
   - The Linux kernel build does this for some of the internal
     tooling required for the build (Kconfig, etc.).
   - If we did want to install the tools on the target, we wouldn't have
     the target arch binaries available. Perhaps both could be built.

So there are a number of ways to go about this. If someone can leverage
some experience with OE to indicate which of these would be met with the
least resistance, both in terms of implementation as well as upstream
acceptance, I would appreciate it.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



             reply	other threads:[~2011-11-23  7:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23  7:01 Darren Hart [this message]
2011-11-23  7:36 ` RFC: grub-efi native tools Koen Kooi
2011-11-23  8:01   ` Darren Hart
2011-11-23  8:10     ` Paul Eggleton
2011-11-23  8:14       ` Darren Hart
2011-11-23  7:44 ` Darren Hart

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=4ECC9A64.4080009@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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