openembedded-core.git/meta/classes/bootimg.bbclass, branch daisy Mirror of openembedded-core bootimg/grub-efi.bbclass: allow using a different class for EFI images 2014-03-11T16:29:40+00:00 Stefan Stanacar stefanx.stanacar@intel.com 2014-03-06T17:57:25+00:00 14e5de3b8f4d5902d0ac683ff45fb878e88b40ef 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> 
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>
image*.bbclass, bootimg.bbclass: add image type dependencies 2014-02-20T14:28:04+00:00 Laurentiu Palcu laurentiu.palcu@intel.com 2014-02-18T13:49:43+00:00 5e2796aa28e02ae3a076c6593c6533753720b13d The following dependencies were manually added in the image creation code. However, in order to have an image dependency mechanism in place, use a new variable, IMAGE_TYPEDEP, to declare that an image type depends on another being already created. The following dependencies are added by this commit: elf -> cpio.gz live -> ext3 vmdk -> ext3 iso -> ext3 hddimg -> ext3 This commit adds also another new variable: IMAGE_TYPES_MASKED. Currently, masking out certain types from IMAGE_FSTYPES was hardcoded in the image creation code. [YOCTO #5830] Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> 
The following dependencies were manually added in the image creation
code. However, in order to have an image dependency mechanism in place,
use a new variable, IMAGE_TYPEDEP, to declare that an image type depends
on another being already created.

The following dependencies are added by this commit:

elf -> cpio.gz
live -> ext3
vmdk -> ext3
iso -> ext3
hddimg -> ext3

This commit adds also another new variable: IMAGE_TYPES_MASKED. Currently,
masking out certain types from IMAGE_FSTYPES was hardcoded in the image
creation code.

[YOCTO #5830]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
boot-directdisk.bbclass: Fix media generation problems with vmdk 2013-09-26T16:27:23+00:00 Jason Wessel jason.wessel@windriver.com 2013-09-17T13:32:17+00:00 63d164b755b984021f7e3cdba7280918ded6e821 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 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>
bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images 2013-09-26T16:27:23+00:00 Jason Wessel jason.wessel@windriver.com 2013-09-17T13:32:18+00:00 808d4371939ec48ed62e0c0b6614b96d61b1f7b8 The mkzftree is needed to allow ISO images to be compressed with minimal runtime overhead. Below is an example of the savings on a core-image-minimal. Before ls -l: 24117248 core-image-minimal-qemux86-64.iso Using the mkzftree ls -l: 16777216 core-image-minimal-qemux86-64.iso Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead.  Below is an example of the savings on a
core-image-minimal.

Before ls -l:
24117248 core-image-minimal-qemux86-64.iso

Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bootimage.bbclass, grub-efi.bbclass: Improve EFI & PCBIOS+EFI ISO support 2013-09-26T16:27:22+00:00 Jason Wessel jason.wessel@windriver.com 2013-09-17T13:32:14+00:00 a4baf911ab9d306ce5200e7d794ed6a9ccb25f30 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> 
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>
bootimage.bbclass: Move fat image creation into a function 2013-09-17T13:26:21+00:00 Jason Wessel jason.wessel@windriver.com 2013-09-14T00:08:57+00:00 6d5181dc68766f42416a41f4988e8400d37fd7fa In order to call the fat image creation multiple times it needs to be in its own function. A future commit will make use of the new function to additionally create EFI image files for use with an ISO. [YOCTO #4100] [YOCTO #1913] 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> 
In order to call the fat image creation multiple times it needs to be
in its own function.  A future commit will make use of the new
function to additionally create EFI image files for use with an ISO.

[YOCTO #4100]
[YOCTO #1913]

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>
boot-directdisk/bootimg/image-vmdk: remove more nostamps for image generation 2013-05-10T09:25:01+00:00 Robert Yang liezhi.yang@windriver.com 2013-05-10T02:31:45+00:00 45c7dab5d51065c7b24ab5292f8e9d3104eb0626 We have removed the nostamps for do_rootfs and do_build, so it seems reasonable to remove the stamps for do_bootimg, do_bootdirectdisk and do_vmdkimg. The current problem is that the do_vmdkimg always re-run, but the do_rootfs may not, so the code like below in the do_rootfs function doesn't re-run and cause problems (the symlink exists when the do_vmdkimg creates the symlink again): if d.getVar('IMAGE_LINK_NAME', True): cmds += "\trm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*" Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
We have removed the nostamps for do_rootfs and do_build, so it seems
reasonable to remove the stamps for do_bootimg, do_bootdirectdisk and
do_vmdkimg.

The current problem is that the do_vmdkimg always re-run, but the
do_rootfs may not, so the code like below in the do_rootfs function
doesn't re-run and cause problems (the symlink exists when the
do_vmdkimg creates the symlink again):

    if d.getVar('IMAGE_LINK_NAME', True):
        cmds += "\trm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*"

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bootimg.bbclass: add comment for NOHDD 2013-05-09T07:48:32+00:00 Robert Yang liezhi.yang@windriver.com 2013-05-08T08:13:58+00:00 9843ad9d783f68b97fedfe5b435528538bb26c1c Add comment for NOHDD which is used for skipping building the HDDIMG if set to 1 Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add comment for NOHDD which is used for skipping building the HDDIMG if
set to 1

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bootimg: Use FAT 32 for images larger than 512MB 2012-12-13T14:41:47+00:00 Darren Hart dvhart@linux.intel.com 2012-12-12T22:39:15+00:00 de808c552d445502bd99f78bb8159d21149f87c1 Fixes [YOCTO #2138] Commit 217584211625b1c496fe5b78aa4765ccf605d2b9 dropped the forced use of FAT32 for the hddimg generation as it broke with very small images (< 32MB). Unfortunately, left to its own devices, mkdosfs appears to select FAT16 even for very large images, resulting in 2.2GB images being generated as FAT16: $ ls -lah core-image-lsb-sdk-atom-pc-20121010233936.hddimg -rw-rw-r-- 1 dvhart dvhart 2.2G 2012-10-17 08:00 core-image-lsb-sdk-atom-pc-20121010233936.hddimg $ file !$ file core-image-lsb-sdk-atom-pc-20121010233936.hddimg core-image-lsb-sdk-atom-pc-20121010233936.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 128, root entries 512, Media descriptor 0xf8, sectors/FAT 138, heads 64, sectors 4502496 (volumes > 32 MB) , serial number 0x50761926, label: "boot ", FAT (16 bit) The result was a runtime boot error from SYSLINUX and a failure to boot live images greater than 1GB in size. While strictly speaking it is the cluster count that determines which FAT size is used, that calculation requires more information than we have readily available (such as sectors per cluster). If we let mkdosfs determine sectors per cluster and just set a sane threshold above which FAT32 is used, we get correct bootable images. With this patch the 2.2GB core-image-lsb-sdk uses FAT32 and the 21 MB core-image-minimal uses FAT16, and both boot in qemu successfully: $ ls -lah tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg -rw-r--r-- 1 dvhart dvhart 2.2G 2012-12-12 14:18 tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg $ file !$ file tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, heads 64, sectors 4470304 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 4357, reserved3 0x800000, serial number 0x50c902b7, label: "boot " $ ls -lah tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg -rw-r--r-- 1 dvhart dvhart 21M 2012-12-12 14:06 tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg $ file !$ file tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 4, root entries 512, sectors 41408 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 41, heads 64, serial number 0x50c8ffec, label: "boot ", FAT (16 bit) I have tested and booted core-image-minimal and core-image-lsb-sdk for atom-pc with qemu-system-i386 using this patch. Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Steve Sakoman <steve@sakoman.com> Cc: Joshua Immanuel <josh@hipro.co.in> Cc: Przemek Czesnowicz <przemyslawx.czesnowicz@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Fixes [YOCTO #2138]

Commit 217584211625b1c496fe5b78aa4765ccf605d2b9 dropped the forced use
of FAT32 for the hddimg generation as it broke with very small images
(< 32MB). Unfortunately, left to its own devices, mkdosfs appears to select
FAT16 even for very large images, resulting in 2.2GB images being
generated as FAT16:

$ ls -lah core-image-lsb-sdk-atom-pc-20121010233936.hddimg
-rw-rw-r-- 1 dvhart dvhart 2.2G 2012-10-17 08:00 core-image-lsb-sdk-atom-pc-20121010233936.hddimg

$ file !$
file core-image-lsb-sdk-atom-pc-20121010233936.hddimg
core-image-lsb-sdk-atom-pc-20121010233936.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 128, root entries 512, Media descriptor 0xf8, sectors/FAT 138, heads 64, sectors 4502496 (volumes > 32 MB) , serial number 0x50761926, label: "boot       ", FAT (16 bit)

The result was a runtime boot error from SYSLINUX and a failure to boot
live images greater than 1GB in size.

While strictly speaking it is the cluster count that determines which
FAT size is used, that calculation requires more information than we
have readily available (such as sectors per cluster). If we let mkdosfs
determine sectors per cluster and just set a sane threshold above which
FAT32 is used, we get correct bootable images. With this patch the 2.2GB
core-image-lsb-sdk uses FAT32 and the 21 MB core-image-minimal uses
FAT16, and both boot in qemu successfully:

$ ls -lah tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg
-rw-r--r-- 1 dvhart dvhart 2.2G 2012-12-12 14:18 tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg

$ file !$
file tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg
tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, heads 64, sectors 4470304 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 4357, reserved3 0x800000, serial number 0x50c902b7, label: "boot       "

$ ls -lah tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg
-rw-r--r-- 1 dvhart dvhart 21M 2012-12-12 14:06 tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg

$ file !$
file tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg
tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 4, root entries 512, sectors 41408 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 41, heads 64, serial number 0x50c8ffec, label: "boot       ", FAT (16 bit)

I have tested and booted core-image-minimal and core-image-lsb-sdk for
atom-pc with qemu-system-i386 using this patch.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Steve Sakoman <steve@sakoman.com>
Cc: Joshua Immanuel <josh@hipro.co.in>
Cc: Przemek Czesnowicz <przemyslawx.czesnowicz@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bootimg: Remove now unnecessary dummy inherit usage 2012-12-07T17:09:23+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2012-12-06T11:36:39+00:00 77cd2ef06bdf701b047c4f8c817b364b8b4b8837 bitbake now supports empty expansions for inherit usage so we can simplify these statements. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
bitbake now supports empty expansions for inherit usage so we can simplify
these statements.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>