[OE-core] RFC: grub-efi native tools

[Koen Kooi]

Op 23 nov. 2011, om 08:01 heeft Darren Hart het volgende geschreven:

> 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.

One way:

DEPENDS = "grub-efi-native"
DEPENDS_virtclass-native = ""

But the proper way is IMAGE_DEPENDS = "grub-efi-native" in the image classes that need it.


>   - 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...

BBCLASSEXTEND is quite cheap.

> 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.

Have a look at u-boot-mkimage, there's a native and target version available.

regards,

Koen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111123/8bba8e97/attachment-0002.sig>