Patchwork [RFC,1/5] grub-efi-native: New recipe to build GRUB EFI images

login
register
mail settings
Submitter Darren Hart
Date Nov. 24, 2011, 8:05 a.m.
Message ID <d5ab9354f38a3cdecfedaf734ffb48aa969a8541.1322120651.git.dvhart@linux.intel.com>
Download mbox | patch
Permalink /patch/15365/
State Accepted
Commit f9518a368f041ceccb4a36061d91ae64cd4dabd4
Headers show

Comments

Darren Hart - Nov. 24, 2011, 8:05 a.m.
Add a recipe to build the GRUB efi images. This recipe is written as
a native recipe as the resulting GRUB utils are required to assemble
the final image. Rather than build a native and a target recipe (and
increase build times), this recipe builds the utils for the host and
passes an appropriate --target argument to the GRUB configure script
to build the modules for the target arch. The only output of this
recipe is an EFI image in the deploy directory.

Care is taken to ensure changing targets will force a rebuild of this
native recipe by including the target arch in the PN.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
---
 meta/recipes-bsp/grub/grub-efi-native_1.99.bb |   74 +++++++++++++++++++++++++
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-bsp/grub/grub-efi-native_1.99.bb
Koen Kooi - Nov. 24, 2011, 8:59 a.m.
Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:

> Add a recipe to build the GRUB efi images. This recipe is written as
> a native recipe as the resulting GRUB utils are required to assemble
> the final image. Rather than build a native and a target recipe (and
> increase build times), 

That's a false dilemma. If you write it as a regular recipe with BBCLASSEXTEND=native your buildtime doesn't increase and you leave open the option of adding more BBCLASSEXTENDS if someone wants to ship it in an SDK.
Richard Purdie - Nov. 24, 2011, 11:26 a.m.
On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
> Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
> 
> > Add a recipe to build the GRUB efi images. This recipe is written as
> > a native recipe as the resulting GRUB utils are required to assemble
> > the final image. Rather than build a native and a target recipe (and
> > increase build times), 
> 
> That's a false dilemma. If you write it as a regular recipe with
> BBCLASSEXTEND=native your buildtime doesn't increase

That isn't true, if you build a target and a native version your build
time does increase. Using BBCLASSEXTEND does improve parsing time over
having two separate recipes though.

>  and you leave open the option of adding more BBCLASSEXTENDS if
> someone wants to ship it in an SDK.

I did talk with Darren about why the recipe is the way it is and there
are some pretty nasty issues with the way grub builds itself. I'm
therefore ok with this as a version 1 and we can see whether there are
any issues that result which need us to rethink the way the recipe is
constructed. 

Its currently behaving very like the way the binutils/gcc cross recipes
will end up (see the separate thread with Matthew) Perhaps it should be
called grub-efi-cross even if it uses native.bbclass.

Cheers,

Richard
Darren Hart - Nov. 24, 2011, 4:21 p.m.
On 11/24/2011 03:26 AM, Richard Purdie wrote:
> On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
>> Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
>>
>>> Add a recipe to build the GRUB efi images. This recipe is written as
>>> a native recipe as the resulting GRUB utils are required to assemble
>>> the final image. Rather than build a native and a target recipe (and
>>> increase build times), 
>>
>> That's a false dilemma. If you write it as a regular recipe with
>> BBCLASSEXTEND=native your buildtime doesn't increase
> 
> That isn't true, if you build a target and a native version your build
> time does increase. Using BBCLASSEXTEND does improve parsing time over
> having two separate recipes though.

Right, while it isn't a huge project to build, I didn't want to
contribute to the expanding build time unnecessarily.

> 
>>  and you leave open the option of adding more BBCLASSEXTENDS if
>> someone wants to ship it in an SDK.

I think the right thing to do here is to modify the origin grub recipe
to build with the efi platform enabled if we want to ship the binaries
on the TARGET. This recipe doesn't build the grub tools for deployment,
it builds the target bootloader binary image for the boot media. That's
the distinction I'm going with anyway.

> 
> I did talk with Darren about why the recipe is the way it is and there
> are some pretty nasty issues with the way grub builds itself. I'm
> therefore ok with this as a version 1 and we can see whether there are
> any issues that result which need us to rethink the way the recipe is
> constructed. 
> 
> Its currently behaving very like the way the binutils/gcc cross recipes
> will end up (see the separate thread with Matthew) Perhaps it should be
> called grub-efi-cross even if it uses native.bbclass.

If you prefer I can change it, I don't have a strong preference for the
name. That would end up as "grub-efi-${TRANSLATED_TARGET_ARCH}-cross"
after the PN adjustment then?
Koen Kooi - Nov. 24, 2011, 4:51 p.m.
Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
>> Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende geschreven:
>> 
>>> Add a recipe to build the GRUB efi images. This recipe is written as
>>> a native recipe as the resulting GRUB utils are required to assemble
>>> the final image. Rather than build a native and a target recipe (and
>>> increase build times), 
>> 
>> That's a false dilemma. If you write it as a regular recipe with
>> BBCLASSEXTEND=native your buildtime doesn't increase
> 
> That isn't true, if you build a target and a native version your build
> time does increase. Using BBCLASSEXTEND does improve parsing time over
> having two separate recipes though.

Are you really saying that 'bitbake grub-native' will build both versions if you use BBCLASSEXTEND!?!?! If not, it remains a false dilemma.
Darren Hart - Nov. 24, 2011, 5:14 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 11/24/2011 08:51 AM, Koen Kooi wrote:
> 
> Op 24 nov. 2011, om 12:26 heeft Richard Purdie het volgende 
> geschreven:
> 
>> On Thu, 2011-11-24 at 09:59 +0100, Koen Kooi wrote:
>>> Op 24 nov. 2011, om 09:05 heeft Darren Hart het volgende 
>>> geschreven:
>>> 
>>>> Add a recipe to build the GRUB efi images. This recipe is 
>>>> written as a native recipe as the resulting GRUB utils are 
>>>> required to assemble the final image. Rather than build a 
>>>> native and a target recipe (and increase build times),
>>> 
>>> That's a false dilemma. If you write it as a regular recipe
>>> with BBCLASSEXTEND=native your buildtime doesn't increase
>> 
>> That isn't true, if you build a target and a native version your 
>> build time does increase. Using BBCLASSEXTEND does improve
>> parsing time over having two separate recipes though.
> 
> Are you really saying that 'bitbake grub-native' will build both 
> versions if you use BBCLASSEXTEND!?!?! If not, it remains a false 
> dilemma.

No, that isn't it. Because of the way grub builds, you need the utils
in HOST_ARCH and the grub modules in TARGET_ARCH. Grub has a
monolithic build system, so in order to do this with BBCLASSEXTEND, we
would need to have grub-efi depend on grub-efi-native so that the
final do_mkimage task could use the -native version of grub-mkimage to
assemble the target-built modules into a final binary.

This approach builds grub natively and sets the --target to the
TARGET_ARCH so the modules are built for the target. This is why I'm
making the distinction between build the grub tools for deployment and
building the grub efi boot image. The approach to each is different,
and this recipe generates the boot image for the target.


- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOznttAAoJEKbMaAwKp364dG0H/0tScwNt0pc9gHDXDELdhCvp
JGJ8soO+yWgksG9o/p077oysd7HMm24Tq//m7FuRzgm0D2JymYwPwdLe06mA1ARs
BpwtvltUW5SLaWzJVeamxeNn5cDpdIcyaa904BdS2Ink/alZgTdoV60qh9LvElIh
P70Pb/GeV/Po5OLALmnYuEV39JPnRxz7RfaXr7qU/0e0JVGKxXa/hrBp8ZgzpYI4
WvGns2LrZRPi/Fp93Vc312NfZYa2y/s9H8ji+B2Nvdza99Zo9y4xtWSf9bDRn+4J
04Kw/CFUe4GqXrIoBATLvm8LmcS/fLaqtVY5Ewz5bSnPFRvXyYApmmNvWpy5hGs=
=LaXk
-----END PGP SIGNATURE-----
Darren Hart - Nov. 25, 2011, 10:57 p.m.
On 11/24/2011 12:05 AM, Darren Hart wrote:
> Add a recipe to build the GRUB efi images. This recipe is written as
> a native recipe as the resulting GRUB utils are required to assemble
> the final image. Rather than build a native and a target recipe (and
> increase build times), this recipe builds the utils for the host and
> passes an appropriate --target argument to the GRUB configure script
> to build the modules for the target arch. The only output of this
> recipe is an EFI image in the deploy directory.

The grub-help list came through with an alternative approach:

"./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386
--with-platform=pc TARGET_CC=i386-linux-gcc"

This would allow for building on a host of arch ppc for a target of arch
i386.

Would it be preferable then to build this as a target package and
manipuate the configure flags to use the BUILD_CC ? I presume a similar
PN rename would be desirable to account for the HOST component of the
build as I used here for the TARGET on the -native version?

--
Darren

> 
> Care is taken to ensure changing targets will force a rebuild of this
> native recipe by including the target arch in the PN.
> 
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> ---
>  meta/recipes-bsp/grub/grub-efi-native_1.99.bb |   74 +++++++++++++++++++++++++
>  1 files changed, 74 insertions(+), 0 deletions(-)
>  create mode 100644 meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> 
> diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> new file mode 100644
> index 0000000..3c52ec9
> --- /dev/null
> +++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> @@ -0,0 +1,74 @@
> +SUMMARY = "GRUB2 is the next-generation GRand Unified Bootloader"
> +
> +DESCRIPTION = "GRUB2 is the next generaion of a GPLed bootloader \
> +intended to unify bootloading across x86 operating systems. In \
> +addition to loading the Linux kernel, it implements the Multiboot \
> +standard, which allows for flexible loading of multiple boot images. \
> +This recipe builds an EFI binary for the target. It does not install \
> +or package anything, it only deploys a target-arch GRUB EFI image."
> +
> +HOMEPAGE = "http://www.gnu.org/software/grub/"
> +SECTION = "bootloaders"
> +PRIORITY = "optional"
> +
> +LICENSE = "GPLv3"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> +
> +# FIXME: We should be able to optionally drop freetype as a dependency
> +DEPENDS = "help2man-native"
> +RDEPENDS_${PN} = "diffutils freetype"
> +PR = "r1"
> +
> +# Native packages do not normally rebuild when the target changes.
> +# Ensure this is built once per HOST-TARGET pair.
> +PN := "grub-efi-${TRANSLATED_TARGET_ARCH}-native"
> +
> +SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz"
> +
> +SRC_URI[md5sum] = "ca9f2a2d571b57fc5c53212d1d22e2b5"
> +SRC_URI[sha256sum] = "b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff"
> +
> +COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
> +
> +S = "${WORKDIR}/grub-${PV}"
> +
> +# Determine the target arch for the grub modules before the native class
> +# clobbers TARGET_ARCH.
> +ORIG_TARGET_ARCH := ${TARGET_ARCH}
> +python __anonymous () {
> +    import re
> +    target = d.getVar('ORIG_TARGET_ARCH', True)
> +    if target == "x86_64":
> +        grubtarget = 'x86_64'
> +        grubimage = "bootx64.efi"
> +    elif re.match('i.86', target):
> +        grubtarget = 'i386'
> +        grubimage = "bootia32.efi"
> +    else:
> +        raise bb.parse.SkipPackage("grub-efi is incompatible with target %s" % target)
> +    d.setVar("GRUB_TARGET", grubtarget)
> +    d.setVar("GRUB_IMAGE", grubimage)
> +}
> +
> +inherit autotools
> +inherit gettext
> +inherit native
> +inherit deploy
> +
> +EXTRA_OECONF = "--with-platform=efi --disable-grub-mkfont \
> +                --target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''"
> +
> +do_mkimage() {
> +	./grub-mkimage -p / -d ./grub-core/ \
> +		       -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
> +	               boot linux fat serial part_msdos normal
> +}
> +addtask mkimage after do_compile before do_install
> +
> +do_deploy() {
> +	install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
> +}
> +addtask deploy after do_install before do_build
> +
> +do_install[noexec] = "1"
> +do_populate_sysroot[noexec] = "1"
Darren Hart - Nov. 29, 2011, 8:03 a.m.
On 11/25/2011 02:57 PM, Darren Hart wrote:
> 
> 
> On 11/24/2011 12:05 AM, Darren Hart wrote:
>> Add a recipe to build the GRUB efi images. This recipe is written as
>> a native recipe as the resulting GRUB utils are required to assemble
>> the final image. Rather than build a native and a target recipe (and
>> increase build times), this recipe builds the utils for the host and
>> passes an appropriate --target argument to the GRUB configure script
>> to build the modules for the target arch. The only output of this
>> recipe is an EFI image in the deploy directory.
> 
> The grub-help list came through with an alternative approach:
> 
> "./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386
> --with-platform=pc TARGET_CC=i386-linux-gcc"
> 
> This would allow for building on a host of arch ppc for a target of arch
> i386.
> 
> Would it be preferable then to build this as a target package and
> manipuate the configure flags to use the BUILD_CC ? I presume a similar
> PN rename would be desirable to account for the HOST component of the
> build as I used here for the TARGET on the -native version?

I have been working on trying to get this working as a target recipe. I've
resolved a number of issues, but something is still biting me and I haven't been
able to sort out what. I would really appreciate a few more sets of eyes on
this.

I have pushed my dvhart/efi/dev branch to poky-contrib for reference:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev

When building this recipe, the mkimage task fails with the grub-mkimage command
segfaulting. I can build with the same ./configure command and using the Yocto
1.1 x86_64-i586 toolchain for the TARGET_CC and the mkimage succeeds. The
configure command is:

./configure --build=x86_64-linux --host=x86_64-linux --target=i586-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --with-libtool-sysroot=/build/poky/n450/tmp/sysroots/n450 CC=gcc TARGET_CC=i586-poky-linux-gcc --with-platform=efi --enable-efiemu=no --disable-grub-mkfont --program-prefix='' --enable-nls 

The make output from building manually vs. within bitbake is nearly identical
with a couple minor path changes for the cross toolchain. The bitbake make also
prints more errors, including the following for the grub-mkimage target (which
is the one that segfaults).

gcc -DHAVE_CONFIG_H -I.  -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\"/usr/lib/grub\" -DLOCALEDIR=\"/usr/share/locale\"  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=I386_EFI -DGRUB_FILE=\"util/grub-mkimage.c\" -I. -I. -I. -I. -I./include -I./include -I./grub-core/gnulib -I./grub-core/gnulib -DGRUB_PKGLIBROOTDIR=\"/usr/lib/''grub\"    -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter   -MT util/grub_mkimage-grub-mkimage.o -MD -MP -MF util/.deps-util/grub_mkimage-grub-mkimage.Tpo -c -o util/grub_mkimage-grub-mkimage.o `test -f 'util/grub-mkimage.c' || echo './'`util/grub-mkimage.c
util/grub-mkimage.c: In function 'generate_image':
util/grub-mkimage.c:665:11: warning: passing argument 2 of 'load_image32' from incompatible pointer type [enabled by default]
util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *'
util/grub-mkimage.c:665:11: warning: passing argument 3 of 'load_image32' from incompatible pointer type [enabled by default]
util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *'
util/grub-mkimage.c:669:11: warning: passing argument 2 of 'load_image64' from incompatible pointer type [enabled by default]
util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *'
util/grub-mkimage.c:669:11: warning: passing argument 3 of 'load_image64' from incompatible pointer type [enabled by default]
util/grub-mkimagexx.c:601:1: note: expected 'grub_size_t *' but argument is of type 'size_t *'

The recipe follows for your reference and for inline comments. Any thoughts on
why this might be failing? Is there are better way to go about trying to build
this as a target recipe?

grub-efi_1.99.bb
----------------
SUMMARY = "GRUB2 is the next-generation GRand Unified Bootloader"

DESCRIPTION = "GRUB2 is the next generaion of a GPLed bootloader \
intended to unify bootloading across x86 operating systems. In \
addition to loading the Linux kernel, it implements the Multiboot \
standard, which allows for flexible loading of multiple boot images. \
This recipe builds an EFI binary for the target. It does not install \
or package anything, it only deploys a target-arch GRUB EFI image."

HOMEPAGE = "http://www.gnu.org/software/grub/"
SECTION = "bootloaders"
PRIORITY = "optional"

LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

# FIXME: We should be able to optionally drop freetype as a dependency
DEPENDS = "help2man-native"
RDEPENDS_${PN} = "diffutils freetype"
PR = "r1"

# FIXME: make this use build arch too?
# Native packages do not normally rebuild when the target changes.
# Ensure this is built once per HOST-TARGET pair.
PN := "grub-efi"

SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz"

SRC_URI[md5sum] = "ca9f2a2d571b57fc5c53212d1d22e2b5"
SRC_URI[sha256sum] = "b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff"

COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'

S = "${WORKDIR}/grub-${PV}"

inherit autotools
inherit gettext
inherit deploy
#inherit cross

# Translate machine arches to grub arch values
python __anonymous () {
    import re
    target = d.getVar("TARGET_ARCH", True)
    if target == "x86_64":
        grubtarget = "x86_64"
        grubimage = "bootx64.efi"
    elif re.match("i.86", target):
        grubtarget = "i386"
        grubimage = "bootia32.efi"
    else:
        raise bb.parse.SkipPackage("grub-efi is incompatible with target %s" % target)
    d.setVar("GRUB_TARGET", grubtarget)
    d.setVar("GRUB_IMAGE", grubimage)

    host = d.getVar("BUILD_ARCH", True)
    if re.match("x86_64", host):
        hostarch = "x86_64"
    elif re.match("i.86", host):
        hostarch = "i386"
    else:
        # This should have been caught by COMPATIBLE_HOST above
        bb.error("grub-efi is incompatible with host %s" % host)
    d.setVar("GRUB_HOST", host)


}

# Build utils for the host and modules and images for the target:
# ./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386 \
# --with-platform=efi TARGET_CC=i386-linux-gcc
#EXTRA_OECONF = "CC=${BUILD_PREFIX}gcc --host=${GRUB_HOST} RANLIB=${BUILD_RANLIB} \
#                TARGET_CC=${TARGET_PREFIX}gcc --target=${GRUB_TARGET} \
#                --with-platform=efi --enable-efiemu=no \
#		--disable-grub-mkfont --program-prefix=''"

#HOST_ARCH = "${BUILD_ARCH}"
#HOST_VENDOR = "${BUILD_VENDOR}"
#HOST_OS = "${BUILD_OS}"
#HOST_PREFIX = "${BUILD_PREFIX}"
#HOST_CC_ARCH = "${BUILD_CC_ARCH}"
#HOST_LD_ARCH = "${BUILD_LD_ARCH}"
#HOST_AS_ARCH = "${BUILD_AS_ARCH}"
SELECTED_OPTIMIZATION=""
FULL_OPTIMIZATION=""
CPP="${BUILD_PREFIX}gcc -E"
HOST_SYS="${BUILD_SYS}"
RANLIB="${BUILD_PREFIX}ranlib"
#LDFLAGS=""
ASNEEDED=""
TARGET_LINK_HASH_STYLE=""
TARGET_LDFLAGS=""
EXTRA_OECONF = "CC=${BUILD_PREFIX}gcc \
                TARGET_CC=${TARGET_PREFIX}gcc \
                --with-platform=efi --enable-efiemu=no \
		--disable-grub-mkfont --program-prefix=''"

do_mkimage() {
	./grub-mkimage -p / -d ./grub-core/ \
		       -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
	               boot linux fat serial part_msdos normal
}
do_compile(){
#	export CFLAGS="-Os"
#	export TARGET_CFLAGS="-Os"
#	export CC="${BUILD_PREFIX}gcc"
	bbnote "CC=${CC}"
	bbnote "CFLAGS=${CFLAGS}"
	bbnote "TARGET_CFLAGS=${TARGET_CFLAGS}"
	bbnote "RANLIB=${RANLIB}"
	bbnote "gcc=$(which gcc)"
	oe_runmake
}
addtask mkimage after do_compile before do_install

do_deploy() {
	install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
}
addtask deploy after do_install before do_build

do_install[noexec] = "1"
do_populate_sysroot[noexec] = "1"

--
Thanks,
Koen Kooi - Nov. 29, 2011, 8:22 a.m.
Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende geschreven:

> On 11/25/2011 02:57 PM, Darren Hart wrote:
>> 
>> 
>> On 11/24/2011 12:05 AM, Darren Hart wrote:
>>> Add a recipe to build the GRUB efi images. This recipe is written as
>>> a native recipe as the resulting GRUB utils are required to assemble
>>> the final image. Rather than build a native and a target recipe (and
>>> increase build times), this recipe builds the utils for the host and
>>> passes an appropriate --target argument to the GRUB configure script
>>> to build the modules for the target arch. The only output of this
>>> recipe is an EFI image in the deploy directory.
>> 
>> The grub-help list came through with an alternative approach:
>> 
>> "./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386
>> --with-platform=pc TARGET_CC=i386-linux-gcc"
>> 
>> This would allow for building on a host of arch ppc for a target of arch
>> i386.
>> 
>> Would it be preferable then to build this as a target package and
>> manipuate the configure flags to use the BUILD_CC ? I presume a similar
>> PN rename would be desirable to account for the HOST component of the
>> build as I used here for the TARGET on the -native version?
> 
> I have been working on trying to get this working as a target recipe. I've
> resolved a number of issues, but something is still biting me and I haven't been
> able to sort out what. I would really appreciate a few more sets of eyes on
> this.
> 
> I have pushed my dvhart/efi/dev branch to poky-contrib for reference:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev
> 
> When building this recipe

This is against poky, so I can't build it. If it was against OE-core, like one would expect on the OE-core mailing list, I could build it.
Darren Hart - Nov. 29, 2011, 8:58 a.m.
On 11/29/2011 12:22 AM, Koen Kooi wrote:
> 
> Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende geschreven:
> 
>> On 11/25/2011 02:57 PM, Darren Hart wrote:
>>>
>>>
>>> On 11/24/2011 12:05 AM, Darren Hart wrote:
>>>> Add a recipe to build the GRUB efi images. This recipe is written as
>>>> a native recipe as the resulting GRUB utils are required to assemble
>>>> the final image. Rather than build a native and a target recipe (and
>>>> increase build times), this recipe builds the utils for the host and
>>>> passes an appropriate --target argument to the GRUB configure script
>>>> to build the modules for the target arch. The only output of this
>>>> recipe is an EFI image in the deploy directory.
>>>
>>> The grub-help list came through with an alternative approach:
>>>
>>> "./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386
>>> --with-platform=pc TARGET_CC=i386-linux-gcc"
>>>
>>> This would allow for building on a host of arch ppc for a target of arch
>>> i386.
>>>
>>> Would it be preferable then to build this as a target package and
>>> manipuate the configure flags to use the BUILD_CC ? I presume a similar
>>> PN rename would be desirable to account for the HOST component of the
>>> build as I used here for the TARGET on the -native version?
>>
>> I have been working on trying to get this working as a target recipe. I've
>> resolved a number of issues, but something is still biting me and I haven't been
>> able to sort out what. I would really appreciate a few more sets of eyes on
>> this.
>>
>> I have pushed my dvhart/efi/dev branch to poky-contrib for reference:
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev
>>
>> When building this recipe
> 
> This is against poky, so I can't build it. If it was against
> OE-core, like one would expect on the OE-core mailing list,
> I could build it.

OK, fair enough.

git://git.infradead.org/srv/git/users/dvhart/oe-core.git dvhart/efi/dev

I just fixed up the patch series - untested.
Koen Kooi - Nov. 29, 2011, 9:16 a.m.
Op 29 nov. 2011, om 09:58 heeft Darren Hart het volgende geschreven:

> 
> 
> On 11/29/2011 12:22 AM, Koen Kooi wrote:
>> 
>> Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende geschreven:
>> 
>>> On 11/25/2011 02:57 PM, Darren Hart wrote:
>>>> 
>>>> 
>>>> On 11/24/2011 12:05 AM, Darren Hart wrote:
>>>>> Add a recipe to build the GRUB efi images. This recipe is written as
>>>>> a native recipe as the resulting GRUB utils are required to assemble
>>>>> the final image. Rather than build a native and a target recipe (and
>>>>> increase build times), this recipe builds the utils for the host and
>>>>> passes an appropriate --target argument to the GRUB configure script
>>>>> to build the modules for the target arch. The only output of this
>>>>> recipe is an EFI image in the deploy directory.
>>>> 
>>>> The grub-help list came through with an alternative approach:
>>>> 
>>>> "./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu --target=i386
>>>> --with-platform=pc TARGET_CC=i386-linux-gcc"
>>>> 
>>>> This would allow for building on a host of arch ppc for a target of arch
>>>> i386.
>>>> 
>>>> Would it be preferable then to build this as a target package and
>>>> manipuate the configure flags to use the BUILD_CC ? I presume a similar
>>>> PN rename would be desirable to account for the HOST component of the
>>>> build as I used here for the TARGET on the -native version?
>>> 
>>> I have been working on trying to get this working as a target recipe. I've
>>> resolved a number of issues, but something is still biting me and I haven't been
>>> able to sort out what. I would really appreciate a few more sets of eyes on
>>> this.
>>> 
>>> I have pushed my dvhart/efi/dev branch to poky-contrib for reference:
>>> 
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev
>>> 
>>> When building this recipe
>> 
>> This is against poky, so I can't build it. If it was against
>> OE-core, like one would expect on the OE-core mailing list,
>> I could build it.
> 
> OK, fair enough.
> 
> git://git.infradead.org/srv/git/users/dvhart/oe-core.git dvhart/efi/dev

I get:

$ git fetch git://git.infradead.org/srv/git/users/dvhart/oe-core.git
fatal: The remote end hung up unexpectedly

regards,

Koen
Darren Hart - Nov. 29, 2011, 9:19 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 11/29/2011 01:16 AM, Koen Kooi wrote:
> 
> Op 29 nov. 2011, om 09:58 heeft Darren Hart het volgende
> geschreven:
> 
>> 
>> 
>> On 11/29/2011 12:22 AM, Koen Kooi wrote:
>>> 
>>> Op 29 nov. 2011, om 09:03 heeft Darren Hart het volgende
>>> geschreven:
>>> 
>>>> On 11/25/2011 02:57 PM, Darren Hart wrote:
>>>>> 
>>>>> 
>>>>> On 11/24/2011 12:05 AM, Darren Hart wrote:
>>>>>> Add a recipe to build the GRUB efi images. This recipe is
>>>>>> written as a native recipe as the resulting GRUB utils
>>>>>> are required to assemble the final image. Rather than
>>>>>> build a native and a target recipe (and increase build
>>>>>> times), this recipe builds the utils for the host and 
>>>>>> passes an appropriate --target argument to the GRUB
>>>>>> configure script to build the modules for the target
>>>>>> arch. The only output of this recipe is an EFI image in
>>>>>> the deploy directory.
>>>>> 
>>>>> The grub-help list came through with an alternative
>>>>> approach:
>>>>> 
>>>>> "./configure CC=powerpc-linux-gcc  --host=ppc-linux-gnu
>>>>> --target=i386 --with-platform=pc TARGET_CC=i386-linux-gcc"
>>>>> 
>>>>> This would allow for building on a host of arch ppc for a
>>>>> target of arch i386.
>>>>> 
>>>>> Would it be preferable then to build this as a target
>>>>> package and manipuate the configure flags to use the
>>>>> BUILD_CC ? I presume a similar PN rename would be desirable
>>>>> to account for the HOST component of the build as I used
>>>>> here for the TARGET on the -native version?
>>>> 
>>>> I have been working on trying to get this working as a target
>>>> recipe. I've resolved a number of issues, but something is
>>>> still biting me and I haven't been able to sort out what. I
>>>> would really appreciate a few more sets of eyes on this.
>>>> 
>>>> I have pushed my dvhart/efi/dev branch to poky-contrib for
>>>> reference:
>>>> 
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dvhart/efi/dev
>>>>
>>>>
>>>> 
When building this recipe
>>> 
>>> This is against poky, so I can't build it. If it was against 
>>> OE-core, like one would expect on the OE-core mailing list, I
>>> could build it.
>> 
>> OK, fair enough.
>> 
>> git://git.infradead.org/srv/git/users/dvhart/oe-core.git
>> dvhart/efi/dev
> 
> I get:
> 
> $ git fetch
> git://git.infradead.org/srv/git/users/dvhart/oe-core.git fatal: The
> remote end hung up unexpectedly
> 

Grmble... too late... too rushed... too many copy buffers. Sorry about
that:

git://git.infradead.org/users/dvhart/oe-core.git dvhart/efi/dev

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO1KO/AAoJEKbMaAwKp364F3QH/iwqj6yfAuMfX1XNWFmvC+Pr
yreEjQMz6n7LjN47svDZb0vTjiUTufdE6peIez1j2WZV5riXA4qePwXHa562zN1e
bsBYH3pjJ87CYZ9Hyg2jdGX7VSeJGpX+dkKggucg0VwzU5MJOM1E0cwKIhfyG3Ja
ytqDhQQXlTQfwHqFkKI1yp7usXDjLZc/OS/nOgNan5x2RVBnfXug33E02Y7yhldW
yRIa0aoCk8LdKGj+PdOVAiHMjXA67KxO16P0Moqk4K3lSV34GBZmSNYT9Mmpk9AV
nFoaxIKYZdaBqLg7i6wyM/g8U0qVajdE3koAj2Hy/KPHXaU/nhiUx9vYg09yyw8=
=e2h9
-----END PGP SIGNATURE-----

Patch

diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
new file mode 100644
index 0000000..3c52ec9
--- /dev/null
+++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
@@ -0,0 +1,74 @@ 
+SUMMARY = "GRUB2 is the next-generation GRand Unified Bootloader"
+
+DESCRIPTION = "GRUB2 is the next generaion of a GPLed bootloader \
+intended to unify bootloading across x86 operating systems. In \
+addition to loading the Linux kernel, it implements the Multiboot \
+standard, which allows for flexible loading of multiple boot images. \
+This recipe builds an EFI binary for the target. It does not install \
+or package anything, it only deploys a target-arch GRUB EFI image."
+
+HOMEPAGE = "http://www.gnu.org/software/grub/"
+SECTION = "bootloaders"
+PRIORITY = "optional"
+
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+
+# FIXME: We should be able to optionally drop freetype as a dependency
+DEPENDS = "help2man-native"
+RDEPENDS_${PN} = "diffutils freetype"
+PR = "r1"
+
+# Native packages do not normally rebuild when the target changes.
+# Ensure this is built once per HOST-TARGET pair.
+PN := "grub-efi-${TRANSLATED_TARGET_ARCH}-native"
+
+SRC_URI = "ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz"
+
+SRC_URI[md5sum] = "ca9f2a2d571b57fc5c53212d1d22e2b5"
+SRC_URI[sha256sum] = "b91f420f2c51f6155e088e34ff99bea09cc1fb89585cf7c0179644e57abd28ff"
+
+COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
+
+S = "${WORKDIR}/grub-${PV}"
+
+# Determine the target arch for the grub modules before the native class
+# clobbers TARGET_ARCH.
+ORIG_TARGET_ARCH := ${TARGET_ARCH}
+python __anonymous () {
+    import re
+    target = d.getVar('ORIG_TARGET_ARCH', True)
+    if target == "x86_64":
+        grubtarget = 'x86_64'
+        grubimage = "bootx64.efi"
+    elif re.match('i.86', target):
+        grubtarget = 'i386'
+        grubimage = "bootia32.efi"
+    else:
+        raise bb.parse.SkipPackage("grub-efi is incompatible with target %s" % target)
+    d.setVar("GRUB_TARGET", grubtarget)
+    d.setVar("GRUB_IMAGE", grubimage)
+}
+
+inherit autotools
+inherit gettext
+inherit native
+inherit deploy
+
+EXTRA_OECONF = "--with-platform=efi --disable-grub-mkfont \
+                --target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''"
+
+do_mkimage() {
+	./grub-mkimage -p / -d ./grub-core/ \
+		       -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
+	               boot linux fat serial part_msdos normal
+}
+addtask mkimage after do_compile before do_install
+
+do_deploy() {
+	install -m 644 ${S}/${GRUB_IMAGE} ${DEPLOYDIR}
+}
+addtask deploy after do_install before do_build
+
+do_install[noexec] = "1"
+do_populate_sysroot[noexec] = "1"