linux/poky.git/meta/classes/bootimg.bbclass, branch dylan

bootimg.bbclass: add comment for NOHDD

2013-05-22T16:14:03+00:00

Add comment for NOHDD which is used for skipping building the HDDIMG if set to 1 (From OE-Core master rev: 9843ad9d783f68b97fedfe5b435528538bb26c1c) (From OE-Core rev: 3c5145670cff69828e7adbce6bde2ec8ddc60e84) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bootimg: Use FAT 32 for images larger than 512MB

2012-12-13T15:18:46+00:00

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. (From OE-Core rev: de808c552d445502bd99f78bb8159d21149f87c1) Signed-off-by: Darren Hart Cc: Steve Sakoman Cc: Joshua Immanuel Cc: Przemek Czesnowicz Signed-off-by: Richard Purdie

bootimg: Remove now unnecessary dummy inherit usage

2012-12-07T17:13:12+00:00

bitbake now supports empty expansions for inherit usage so we can simplify these statements. (From OE-Core rev: 77cd2ef06bdf701b047c4f8c817b364b8b4b8837) Signed-off-by: Richard Purdie

Convert tab indentation in python functions into four-space

2012-07-19T09:24:50+00:00

(From OE-Core rev: 604d46c686d06d62d5a07b9c7f4fa170f99307d8) Signed-off-by: Richard Purdie

bootimg: Use STAGING_KERNEL_DIR

2012-07-06T08:39:23+00:00

bootimg.bbclass using STAGING_DIR_HOST/kernel instead of STAGING_KERNEL_DIR, resulting in build failure of live images. | install: cannot stat `/usr/local/dev/yocto/fishriver-test/build/tmp/sysroots/fishriver/kernel/bzImage': No such file or directory Replace it with STAGING_KERNEL_DIR. (From OE-Core rev: 8f16811a8d51982a8b3d70e6087aef4a41926840) Signed-off-by: Darren Hart Tested-by: Tom Zanussi Signed-off-by: Richard Purdie

bootimg.bbclass: Tweak iso images to become hybrid images

2012-04-26T09:05:12+00:00

This allows iso images to be written to usb keys and booted on systems which have a BIOS which support this. There is no real down side to tweaking the iso images in this way. [YOCTO #1763 partial] (From OE-Core rev: 9a946554e4843841c2ec3cbb2575e80d0ccdc29f) Signed-off-by: Damien Lespiau Signed-off-by: Richard Purdie

bootimg: Fix Quoting

2012-02-28T17:51:51+00:00

(From OE-Core rev: 18ad7e003e36510ff0097d71bad0378a77fabbdd) Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

bootimg: Use the same OS files for each boot method

2012-02-08T00:50:22+00:00

Fixes [YOCTO #1951] The do_bootimg code can generate hybrid efi+pcbios images (syslinux and grub-efi) to boot on platforms with both EFI and legacy BIOS options. The current implementation copies the kernel, initrd, and rootfs twice, unnecessarily bloating the image size. This is an especially egregious bug on -sato images. Update the classes to use a common install of the kernel, initrd, and rootfs to the root of the boot media. Grub-efi, syslinux, and isolinux can all reference this location explicitly with a leading slash. Tested with an EFI+PCBIOS image in both EFI and PCBIOS boot modes on two platforms. No ISO image testing was performed. (From OE-Core rev: 5209016cf4c4c8f649e37dc8857b3fbcfe8dd8c8) Signed-off-by: Darren Hart Signed-off-by: Richard Purdie

bootimg: Do not force FAT32 on all images, it violates the FAT specification

2012-02-01T15:15:14+00:00

Fixes [YOCTO #1940] do_bootimg was performing the FAT overhead calculations assuming FAT32 and then forcing the use of FAT32 with "-F 32" to mkdosfs. The FAT specification is clear on cluster count being the determining factor for FAT size (even if the fs string is set to FAT32, go figure). Syslinux follows this spec, and rightly so, resulting in a failure on core-image-minimal: syslinux: zero FAT sectors (FAT12/16) Drop the "-F 32" from mkdosfs to allow it to select the appropriate FAT size based on cluster count. Leave the FAT overhead calculation in FAT32. This will result in a little extra padding for really small images, but not enough extra to justify recalculating for FAT12 and FAT16. Tested with a core-image-minimal build for atom-pc. do_bootimg completed successfully, and the resulting image was FAT16. (From OE-Core rev: 634137704dd1a205e377a1131ef708f1c981f6b2) Signed-off-by: Darren Hart Signed-off-by: Richard Purdie

bootimg: Fix a math thinko in the block count calculation

2012-01-25T14:30:56+00:00

Fixes [YOCTO #1852] ... again. The conversion from sectors to blocks was multiplying by 2 instead of dividing by 2. Blocks are 1024 bytes, sectors are 512 bytes. The result was images being much larger than intended. Reported-by: Tom Zanussi (From OE-Core rev: b35384fa3ca96b31c63d764322215abced2066e4) Signed-off-by: Darren Hart CC: Joshua Lock Signed-off-by: Richard Purdie