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]
(From OE-Core rev: 63d164b755b984021f7e3cdba7280918ded6e821)
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 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
(From OE-Core rev: 808d4371939ec48ed62e0c0b6614b96d61b1f7b8)
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>
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]
(From OE-Core rev: a4baf911ab9d306ce5200e7d794ed6a9ccb25f30)
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]
(From OE-Core rev: 6d5181dc68766f42416a41f4988e8400d37fd7fa)
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>
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}.*"
(From OE-Core rev: 45c7dab5d51065c7b24ab5292f8e9d3104eb0626)
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
(From OE-Core rev: 9843ad9d783f68b97fedfe5b435528538bb26c1c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #2138]
Commit 2175842116 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 <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>
bitbake now supports empty expansions for inherit usage so we can simplify
these statements.
(From OE-Core rev: 77cd2ef06bdf701b047c4f8c817b364b8b4b8837)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <dvhart@linux.intel.com>
Tested-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <damien.lespiau@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <tom.zanussi@intel.com>
(From OE-Core rev: b35384fa3ca96b31c63d764322215abced2066e4)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #1852]
The bootimg class wasn't accounting for non-trivial amount of space
required by the directory entries and FATs for the FAT filesystem.
This patch attempts to make an accurate prediction of FAT overhead and
adjusts the image size accordingly. It assumes no more than 16 directory
entries per directory (which fit in a single sector). It also assumes
8.3 filenames. With the ceiling functions rounding up to full sectors
and tracks, these assumptions seem reasonable.
In order to ensure the calculations are accurate, this patch forces the
FAT size to 32, rather than allowing mkdosfs to automatically select 12,
16, or 32 depending on the image being built.
Tested by setting BOOTIMG_EXTRA_SPACE=0 and building core-image-minimal
and core-image-sato for fri2-noemgd from meta-intel.
(From OE-Core rev: 68aa18609c10a3ae2f738930c933fa2a95ce8959)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The initial directory support (-d) added to mkdosfs has proven to be incomplete
and non-compliant with FAT. Rather than continue to maintain this feature and
work around the various issues, we can use mcopy to construct the image.
bootimg.bbclass already depends on mtools-native (although it may not have
needed to previously). No new dependencies are introduced. The image created
passes dosfsck cleanly. Remove the call to dosfsck.
mcopy reported an error with the image we were creating:
Total number of sectors (107574) not a multiple of sectors per track (32)!
Add some logic to ensure the total sector count is an integral number of sectors
per track, including forcing the logical sector size to 512 in the mkdosfs
command.
The du -bks arguments are contradictory, -b is equivalent to "--apparent-size
--block-size=1" and -k is --block-size=1K. If reordered, -kbs will report the
disk usage in bytes insteadk of 1k blocks. Eliminate the ambiguity by using:
du --apparent-size -ks
(From OE-Core rev: 92d2ea1a306354c6565a1b05b51b5719e481840f)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Nitin A. Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Condition building PCBIOS legacy images on MACHINE_FEATURES containing "pcbios"
or not containing "efi". This ensures existing BSPs will continue to get the
old PCBIOS legacy-only images. New BSPs can add "efi", "pcbios", or both. The
images created likewise support one or the other or both.
EFI-only ISO images are untested.
(From OE-Core rev: be3fc8c07e84c654f55c5d09934dfbdc7ff7e2b6)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a new grub-efi.bbclass and integrate it into bootimg alongside the
syslinux support. This new class uses the output from the grub-efi-native
recipe. Thanks goes to Josef Ahmad <josef.ahmad@intel.com> for the original
build_grub_cfg() routine.
The EFI features are only added to the image if MACHINE_FEATURES contains
"efi". The resulting images are therefor either legacy boot only (like they
were originally) or legacy boot and EFI boot.
A new "dummy.bbclass" was added to allow for the conditional include
of grub-efi. This makes it so if efi support is not to be built in, we
don't spend time building grub-efi-native just because the include adds
the dependency.
There is a bug in the mkdosfs tool from the dosfstools package which causes
it to crash when the directory passed with the -d parameter contains
sub-directories. An /EFI/BOOT directory is required for a proper EFI
installation. Until it is fixed, we install to the top level directory
for the hddimg.
(From OE-Core rev: be95f54495bf9e03062f86b929c66cab6e385a03)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Josef Ahmad <josef.ahmad@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Working towards a more generic bootimg.bbclass, pull out all
syslinux specific bits and let syslinux.bbclass manage them
directly. This introduces no functional changes to the images
constructed and the behavior remains unchanged.
(From OE-Core rev: 1915293688d348a765aa0bcdf01168c9fecd9842)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Separate the construction of the ISO image from that of the hddimg.
This is part of the groundwork for creating a much more flexible
live image builder.
(From OE-Core rev: 2da25c7c6649757350782a939bcc7553c5c86570)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible to create an "hybrid" iso image that you can both burn
to a CD-Rom and dd to a USB key. isohybrid will create a valid boot
sector for the USB key case.
[YOCTO #1763]
(From OE-Core rev: 321a7dc9d934f31aae27828ff8c56d6c69ecc665)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If an image sets NOHDD = "1" the HDD image won't be build.
(From OE-Core rev: 23c5a83e877efe6d86618898dd181bb75f44aa71)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit changes the sysroots path to be machine specific.
Changes includes:
1) STAGING_DIR_TARGET and STRAGING_DIR_HOST points to machine specific
paths.
2) task stamp files. Adding ${MACHINE} info into stamp files for
do_populate_sysroots and do_package tasks. Add a BB_STAMPTASK_BLACKLIST
to keep native, nativesdk, crosssdk, and cross-canadian stamp unchanged.
3) siteconfig path. Separate the site config path for different machines
to avoid one machine adopting the cache file of another machine.
4) sstate. Add machine name to sstate manifest file.
Change relocation code for sstate paths since sysroot is machine.
Keep native, nativesdk, crosssdk, and cross-canadian unchanged.
5) toolchain scripts. Change the environment path to point to machine
specific sysroots in toolchain scripts bbclass.
6) Relocate la files when populating to a different machine of the same
architecture.
7) Exclude STAGING_DIR_TARGET and STAGING_DIR_HOST parameter from sstate
siginfo since they contain ${MACHINE} information.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
This change makes the purpose of the staging directory more obvious and
the taskname more true to what it now actually does.
The layout version number is increased due to the change in layout
but code to convert existing directories and insert a symlink for
backwards compatibility is included.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We only had one package for building both the bootloader and the installer,
i.e. target and host code. It used always the host compiler. Split the
package into syslinux and syslinux-installer-native, require both for a
cd bootable image.
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@5539 311d38ba-8fff-0310-9ca6-ca027cbcb966
bootimg.bbclass supported creation of FAT filesystem images for usage with
syslinux (kernel and initrd in /boot/) and creation of ISO images with kernel
and initrd on it. ISO images contained also not needed /boot/ directory from
FAT image.
Now still two files are created as result but both contain only needed files.
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@1899 311d38ba-8fff-0310-9ca6-ca027cbcb966
Jason Wessel
Robert Yang
Darren Hart
Richard Purdie
Damien Lespiau
Saul Wold
Otavio Salvador
Dongxiao Xu
Richard Purdie
Samuel Ortiz
Andrzej Zaborowski
Samuel Ortiz
Richard Purdie
Marcin Juszkiewicz