<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openembedded-core.git/meta/classes/grub-efi.bbclass, branch dora</title>
<subtitle>Mirror of openembedded-core</subtitle>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/'/>
<entry>
<title>grub-efi.bbclass: Fix startup.nsh to work on more EFI revs</title>
<updated>2013-12-12T16:53:03+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2013-10-30T17:35:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=a65db42d4b0c6636ee6538a28930e4d19e170d18'/>
<id>a65db42d4b0c6636ee6538a28930e4d19e170d18</id>
<content type='text'>
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&gt; EFI\BOOT\bootx64.efi
'EFI\BOOT\bootx64.efi' is not recognized as an internal or external command, operable program, or batch file
Shell&gt;

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

(From OE-Core master rev: 754b52ea7a3cdf8e7e939a314525d16c4dfb52cb)

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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&gt; EFI\BOOT\bootx64.efi
'EFI\BOOT\bootx64.efi' is not recognized as an internal or external command, operable program, or batch file
Shell&gt;

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

(From OE-Core master rev: 754b52ea7a3cdf8e7e939a314525d16c4dfb52cb)

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>grub-efi.bbclass: Fixes GRUB_IMAGE when using boot-directdisk class</title>
<updated>2013-12-12T16:53:03+00:00</updated>
<author>
<name>Joao Henrique Ferreira de Freitas</name>
<email>joaohf@gmail.com</email>
</author>
<published>2013-10-30T10:37:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=b14ba80d22f4892a4d9269dbf982b2f88109da98'/>
<id>b14ba80d22f4892a4d9269dbf982b2f88109da98</id>
<content type='text'>
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.

(From OE-Core master rev: b9778975db410b8cd01ef6854c7cd3ea22a0b5b7)

Signed-off-by: Joao Henrique Ferreira de Freitas &lt;joaohf@gmail.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

(From OE-Core master rev: b9778975db410b8cd01ef6854c7cd3ea22a0b5b7)

Signed-off-by: Joao Henrique Ferreira de Freitas &lt;joaohf@gmail.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>boot-directdisk.bbclass: Fix media generation problems with vmdk</title>
<updated>2013-09-26T16:27:23+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2013-09-17T13:32:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=63d164b755b984021f7e3cdba7280918ded6e821'/>
<id>63d164b755b984021f7e3cdba7280918ded6e821</id>
<content type='text'>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>grub-efi.bbclass: Add serial and graphics menu options</title>
<updated>2013-09-26T16:27:22+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2013-09-17T13:32:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=8444199fb598012f54853b010b5e5cce750db89d'/>
<id>8444199fb598012f54853b010b5e5cce750db89d</id>
<content type='text'>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bootimage.bbclass, grub-efi.bbclass: Improve EFI &amp; PCBIOS+EFI ISO support</title>
<updated>2013-09-26T16:27:22+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2013-09-17T13:32:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=a4baf911ab9d306ce5200e7d794ed6a9ccb25f30'/>
<id>a4baf911ab9d306ce5200e7d794ed6a9ccb25f30</id>
<content type='text'>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Saul Wold &lt;sgw@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>grub-efi: fix Nothing PROVIDES 'grub-efi-x86_64-native'</title>
<updated>2012-08-25T13:44:00+00:00</updated>
<author>
<name>Mihai Lindner</name>
<email>mihaix.lindner@linux.intel.com</email>
</author>
<published>2012-08-24T18:06:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=20e2aaacb36113604c4ea7c40dd0bbbf224b8360'/>
<id>20e2aaacb36113604c4ea7c40dd0bbbf224b8360</id>
<content type='text'>
"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 &lt;mihaix.lindner@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
"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 &lt;mihaix.lindner@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>meta/classes: Various python whitespace fixes</title>
<updated>2012-08-21T10:37:01+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2012-08-20T16:52:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=8385d6d74624000d68814f4e3266d47bc8885942'/>
<id>8385d6d74624000d68814f4e3266d47bc8885942</id>
<content type='text'>
It was pointed out we have a number of weird indentations in the python functions.
This patch cleans up 3, 7 and other weird indentations for the core bbclass files.

It also fixes some wierd (odd) shell function indentation which my searches picked up.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It was pointed out we have a number of weird indentations in the python functions.
This patch cleans up 3, 7 and other weird indentations for the core bbclass files.

It also fixes some wierd (odd) shell function indentation which my searches picked up.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>EFI: Make installer EFI aware</title>
<updated>2012-07-19T16:48:53+00:00</updated>
<author>
<name>Darren Hart</name>
<email>dvhart@linux.intel.com</email>
</author>
<published>2012-07-04T04:05:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=4bce3417917a3e88ba6529db394525fba82e0699'/>
<id>4bce3417917a3e88ba6529db394525fba82e0699</id>
<content type='text'>
[YOCTO #1919]

Create a basic EFI installer script modeled after the existing installer
and add it to a new initramfs-live-install-efi recipe. Update the
init-live.sh script to distinguish between LABEL=install and
LABEL=install-efi and select the appropriate script. Add the efi
installer to core-image-minimal-initramfs.

Update grub-efi.bbclass to use "LABEL=install-efi" when it detects a
label of "install". This is clearly not ideal, but a proper fix would
involve decoupling the LABELS assignment from the image-live.bbclass
usage of SYSLINUX_LABELS. We should be able to address that in a
follow-on clean-up series.

V2: Include missing initramfs-live-install-efi_1.0.bb
V3: Rebase after Radu's console_params fix

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[YOCTO #1919]

Create a basic EFI installer script modeled after the existing installer
and add it to a new initramfs-live-install-efi recipe. Update the
init-live.sh script to distinguish between LABEL=install and
LABEL=install-efi and select the appropriate script. Add the efi
installer to core-image-minimal-initramfs.

Update grub-efi.bbclass to use "LABEL=install-efi" when it detects a
label of "install". This is clearly not ideal, but a proper fix would
involve decoupling the LABELS assignment from the image-live.bbclass
usage of SYSLINUX_LABELS. We should be able to address that in a
follow-on clean-up series.

V2: Include missing initramfs-live-install-efi_1.0.bb
V3: Rebase after Radu's console_params fix

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bootimg: Use the same OS files for each boot method</title>
<updated>2012-02-07T22:37:12+00:00</updated>
<author>
<name>Darren Hart</name>
<email>dvhart@linux.intel.com</email>
</author>
<published>2012-02-02T00:15:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=5209016cf4c4c8f649e37dc8857b3fbcfe8dd8c8'/>
<id>5209016cf4c4c8f649e37dc8857b3fbcfe8dd8c8</id>
<content type='text'>
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.

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>grub-efi: Use /EFI/BOOT now that mkdosfs -d works with directories</title>
<updated>2011-12-16T15:33:34+00:00</updated>
<author>
<name>Darren Hart</name>
<email>dvhart@linux.intel.com</email>
</author>
<published>2011-12-16T06:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=badf0504f5ed4c5e48607922ac15c56463ad09ef'/>
<id>badf0504f5ed4c5e48607922ac15c56463ad09ef</id>
<content type='text'>
[Yocto 1783] prevented us from using a proper /EFI/BOOT path in the live
images due to a bug in the -d patch for mkdosfs in dosfstools. With this
now fixed, we can place the efi payload where it belongs per spec and
the images will autoboot to the grub menu on EFI platforms.

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[Yocto 1783] prevented us from using a proper /EFI/BOOT path in the live
images due to a bug in the -d patch for mkdosfs in dosfstools. With this
now fixed, we can place the efi payload where it belongs per spec and
the images will autoboot to the grub menu on EFI platforms.

Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
