openembedded-core.git/meta/classes/gummiboot.bbclass, branch master Mirror of openembedded-core gummiboot: Remove old gummiboot recipe, related class and wks file 2017-01-16T18:01:49+00:00 Alejandro Hernandez alejandro.hernandez@linux.intel.com 2016-11-23T23:00:31+00:00 65eb3f51b70baaf24de871301a7247d5baed00ed Since the gummiboot project is no longer being maintained and we are using systemd-boot as a replacement instead, we can now clean up all remaining gummiboot files. [YOCTO #10332] Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Since the gummiboot project is no longer being maintained
and we are using systemd-boot as a replacement instead,
we can now clean up all remaining gummiboot files.

[YOCTO #10332]

Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta/scripts: Various getVar/getVarFlag expansion parameter fixes 2017-01-06T11:46:14+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-01-05T21:15:08+00:00 688f7a64917a5ce5cbe12f8e5da4d47e265d240f There were a few straggling expansion parameter removals left for getVar/getVarFlag where the odd whitespace meant they were missed on previous passes. There were also some plain broken ussages such as: d.getVar('ALTERNATIVE_TARGET', old_name, True) path = d.getVar('PATH', d, True) d.getVar('IMAGE_ROOTFS', 'True') which I've corrected (they happend to work by luck). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:

d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')

which I've corrected (they happend to work by luck).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gummiboot.bbclass: Use bb.fatal() instead of raising FuncFailed 2016-10-03T14:46:21+00:00 Ulf Magnusson ulfalizer@gmail.com 2016-10-01T02:46:58+00:00 f7c82acbac583c7838550175796a7aa697a5c7e0 This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.

Motivating quote below:

< kergoth> the *original* intent was for the function/task to error via
           whatever appropriate means, bb.fatal, whatever, and
           funcfailed was what you'd catch if you were calling
           exec_func/exec_task. that is, it's what those functions
           raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself

FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/classes: fix bb.build.FuncFailed typos 2016-08-07T21:18:21+00:00 Jonathan Liu net147@gmail.com 2016-08-07T08:34:28+00:00 6a8b9599945f3f57bd86a205bc107b8490518d29 Signed-off-by: Jonathan Liu <net147@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gummiboot.bbclass: also write startup.nsh for non-iso 2016-05-30T08:30:31+00:00 Christopher Larson chris_larson@mentor.com 2016-05-25T20:31:51+00:00 43ca968c5af129a990625923bc28131b8701386d wic will be needing this for its bootimg-efi plugin. [YOCTO #9556] Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
wic will be needing this for its bootimg-efi plugin.

[YOCTO #9556]

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
bootimg.bbclass: merge it into image-live.bbclass 2016-03-31T12:22:50+00:00 Robert Yang liezhi.yang@windriver.com 2016-03-30T07:23:10+00:00 bfd4d95210b3f841aa2e7c5a06ac89667523438d They are doing the same things: create live images, merge them into one bbclass makes it easy to understand. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
They are doing the same things: create live images, merge them into one
bbclass makes it easy to understand.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
grub-efi, gummiboot: Emit correct path in startup.nsh 2015-10-19T16:47:45+00:00 Khem Raj raj.khem@gmail.com 2015-10-10T01:53:25+00:00 38fe481911e7c4e9f674ded8f66878dff9e12ce3 when we generate hddimage and use it to prepare SD card using scripts/contrib/mkefidisk.sh as described here http://elinux.org/Minnowboard:MinnowMaxYoctoProject The content of startup.nsh contains bootx64.efi but this file is actually not in same dir as startup.nsh its in /EFI/BOOT so for this to work entry in startup.nsh should be fs0:\EFI\BOOT\bootx64.efi Otherwise the image is D-O-A Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
when we generate hddimage and use it to prepare SD card
using scripts/contrib/mkefidisk.sh as described here

http://elinux.org/Minnowboard:MinnowMaxYoctoProject

The content of startup.nsh contains

bootx64.efi

but this file is actually not in same dir as startup.nsh
its in /EFI/BOOT so for this to work entry in startup.nsh
should be

fs0:\EFI\BOOT\bootx64.efi

Otherwise the image is D-O-A

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
boot loader: support root=UUID 2015-09-06T14:24:26+00:00 Patrick Ohly patrick.ohly@intel.com 2015-09-03T18:42:32+00:00 1e29d77d0d33ee216b43022439876863f0db39bb As mentioned when introducing the VM images (https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the resulting images only work when the image is mounted as a disk that results in the hard-coded path (/dev/sda in the current default). Using the file system UUID to find the rootfs is more flexible. To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT = "root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file system. The special string will get replaced in the APPEND line with the actual UUID when the boot loader (grub-efi, syslinux or gummiboot) writes the boot loader configuration files. At that time, the rootfs image has already been created and its UUID can be extracted using "tune2fs -l", which also should be available because the e2fsprogs-native tools were needed to create the image in the first place. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.

To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.

The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gummiboot.bbclass: Ensure MLPREFIX is applied to depends flag 2014-06-24T18:53:02+00:00 Ming Liu ming.liu@windriver.com 2014-06-19T08:43:00+00:00 9ed2b77aafe5bcd57da56377e6e58dae0c1fcfaf Add MLPREFIX to depends flag to ensure the correct gummiboot is dependended upon. Signed-off-by: Ming Liu <ming.liu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Add MLPREFIX to depends flag to ensure the correct gummiboot is
dependended upon.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
classes: Add gummiboot class 2014-03-11T16:29:56+00:00 Stefan Stanacar stefanx.stanacar@intel.com 2014-03-06T17:59:07+00:00 b457e40fc69cc6503dc566f16495f03606e5333b Adds a gummiboot class similar to grub-efi class and makes the necessary changes so it can be used for live/hddimg images as well. One can set EFI_PROVIDER = "gummiboot" in local.conf to use gummiboot instead of grub-efi. Gummiboot requires some kernel options that are not enabled by default, so one has to build with KERNEL_FEATURES_append = " cfg/efi-ext". The install scripts have been updated too, keeping the old behaviour around, but accounting for the new boot loader config files (if they exist). It can be argued that the installer and bootimg are a bit wierd and not necessarily correct, but I wanted to have the exact same behviour with gummiboot. With the default EFI_PROVIDER = "grub-efi" nothing changes, everthing should be just as before. I've tested live boot, install and normal boot on: - FRI2 - genericx86-64 on NUC with: EFI_PROVIDER = "gummiboot" KERNEL_FEATURES_append = " cfg/efi-ext" in local.conf. 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> 
Adds a gummiboot class similar to grub-efi class and makes the necessary
changes so it can be used for live/hddimg images as well.

One can set EFI_PROVIDER = "gummiboot" in local.conf to use gummiboot instead of grub-efi.
Gummiboot requires some kernel options that are not enabled by default, so one has to build
with KERNEL_FEATURES_append = " cfg/efi-ext".

The install scripts have been updated too, keeping the old behaviour around,
but accounting for the new boot loader config files (if they exist).
It can be argued that the installer and bootimg are a bit wierd and not necessarily correct,
but I wanted to have the exact same behviour with gummiboot.
With the default EFI_PROVIDER = "grub-efi" nothing changes, everthing should be just as before.

I've tested live boot, install and normal boot on:
    - FRI2
    - genericx86-64 on NUC
with:
  EFI_PROVIDER = "gummiboot"
  KERNEL_FEATURES_append = " cfg/efi-ext"
in local.conf.

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>