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 <nitin.a.kamble@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <stefanx.stanacar@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

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 <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

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 <joaohf@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

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 <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices.  This patch adds the same concept to
the grub-efi menu.  That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.

[YOCTO #4100]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.

1) PCBIOS Only ISO
   - This option remains unchanged by this commit
   - Uses syslinux menus
   - Can be directly copied with dd to a USB device
   - Can be burned to optical media

2) EFI Only ISO
   - Uses grub 2 menus
   - Can be burned to optical media
   - If you want to use this image on a USB device
     extra steps must be taken in order to format the USB
     device with fat32, and copy an EFI loader which will
     in turn load the iso image

3) PCBIOS / EFI ISO
   - This is a hybrid image ISO that will work for case 1 or 2
     as above with the same restrictions and boot menu types
     depending on what type of firmware is installed on
     the hardware or depending on if EFI or "Legacy Boot" is
     enabled on some UEFI firmwares.

The syslinux.bbclass is now always required because that is where the
isohybrid dependencies come from as well as the configuration data for
the isohybrid.  The isohybrid is the secret sauce which allows the ISO
to work as optical media or as a disk image on USB or a HDD/SSD.

[YOCTO #4100]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

"ERROR: Nothing PROVIDES 'grub-efi-x86_64-native'" is returned when
trying to build meta-intel/meta-cedartrail with DEFAULTTUNE = "core2-64"
Used TRANSLATED_TARGET_ARCH instead of TARGET_ARCH in grub-efi.bbclass

[YOCTO #3013]

Signed-off-by: Mihai Lindner <mihaix.lindner@linux.intel.com>