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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
