openembedded-core.git/meta/classes/grub-efi.bbclass, branch jethro

grub-efi, gummiboot: Emit correct path in startup.nsh

2015-10-19T16:47:45+00:00

when we generate hddimage and use it to prepare SD card
using scripts/contrib/mkefidisk.sh as described here

http://elinux.org/Minnowboard:MinnowMaxYoctoProject

The content of startup.nsh contains

bootx64.efi

but this file is actually not in same dir as startup.nsh
its in /EFI/BOOT so for this to work entry in startup.nsh
should be

fs0:\EFI\BOOT\bootx64.efi

Otherwise the image is D-O-A

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton

boot loader: support root=UUID

2015-09-06T14:24:26+00:00

As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.

To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<>". The rootfs image must use an ext file
system.

The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

grub-efi: Allow to use file name different from grub.cfg in GRUBCFG

2015-07-07T22:56:23+00:00

To generate a same image both in live image type and boot-directdisk image type
and make boot-direct image boot directly on the rootfs partition without using
an initramfs we need to have the ability to generate several grub.cfg files.

Signed-off-by: Nicolas Guyomard 
Signed-off-by: Ross Burton

INITRD var: make it a list of filesystem images

2014-08-02T08:21:14+00:00

The initrd image used by the Linux kernel is list of file system images
concatenated together and presented as a single initrd file at boot time.

So far the initrd is a single filesystem image. But in cases like to support
early microcode loading, the initrd image need to have multiple filesystem
images concatenated together.

This commit is extending the INITRD variable from a single filesystem image
to a list of filesystem images to satisfy the need mentioned above.

Signed-off-by: Nitin A Kamble 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

grub-efi.bbclass: Ensure MLPREFIX is applied to depends flag

2014-06-24T18:53:02+00:00

Add MLPREFIX to depends flag to ensure the correct grub-efi is
dependended upon.

Signed-off-by: Ming Liu 
Signed-off-by: Richard Purdie

bootimg/grub-efi.bbclass: allow using a different class for EFI images

2014-03-11T16:29:40+00:00

Abstract away some names so one can select using EFI_PROVIDER a different
class than grub-efi for populating live images, basically allowing the use
of a different bootloader than grub-efi.

Signed-off-by: Stefan Stanacar 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

grub-efi: change to generate EFI image in target package

2013-12-14T07:08:02+00:00

To generate the target EFI image in a native package, it requires
the host gcc have the ability to do -m32/-m64 compiling, but gcc
doesn't have that support on the 32bit version of some distributions
(e.g. rehl, suse), it would fail when build a 64bit target on these
32bit hosts.

In fact, all we need from grub-efi-native is the grub-mkimage binary,
so change the solution to:
 * grub-efi-native only install grub-mkimage
 * grub-efi compiles target modules, generates EFI image
   with grub-mkimage and deploy, but install nothing.

Signed-off-by: Jackie Huang 
Signed-off-by: Saul Wold

grub-efi.bbclass: Fix startup.nsh to work on more EFI revs

2013-11-01T06:57:04+00:00

Some revs of the EFI firmware + shell do not automatically setup the
path in a such a way as to execute a binary without an absolute
reference like "FS0:\EFI\BOOT\bootx64.efi".  All the versions that I
have tested work properly by simply calling the binary which is in the
EFI\BOOT directory by name like "bootx64.efi".

The error you see on the console looks like the following:

startup.nsh> EFI\BOOT\bootx64.efi
'EFI\BOOT\bootx64.efi' is not recognized as an internal or external command, operable program, or batch file
Shell>

This patch simply drops the EFI\BOOT for greater compatibility.

Signed-off-by: Jason Wessel 
Signed-off-by: Saul Wold

grub-efi.bbclass: Fixes GRUB_IMAGE when using boot-directdisk class

2013-11-01T06:57:04+00:00

When boot-directdisk class is used and EFI boot is set the
grub-efi-${TRANSLATED_TARGET_ARCH}-native need to be dependent.
Allowing GRUB_IMAGE to be created and bootia32.efi got from the
image directory.

Signed-off-by: Joao Henrique Ferreira de Freitas 
Signed-off-by: Saul Wold

boot-directdisk.bbclass: Fix media generation problems with vmdk

2013-09-26T16:27:23+00:00

The various populate methods need to accept a path as an argument vs
using hard expanded variables.  In the case of the boot-directdisk
class it uses a different path for HDDDIR but it gets eclipsed by the
the class definition at the point in time ${HDDDIR} gets expanded.

The logical fix is to pass the arguments to the functions as opposed
to using globally expanded variables from the class definitions.

This patch changes 3 things:
1) syslinux_hddimg_populate takes an argument for the destination
2) syslinux_iso_populate takes an argument for the destination
3) populate is changed to boot_direct_populate because there
   was a conflict with it overriding the populate in bootimg.bbclass

[YOCTO #3994]

Signed-off-by: Jason Wessel 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie