summaryrefslogtreecommitdiffstats
path: root/classes
Commit message (Collapse)AuthorAgeFilesLines
* uefi-comboapp.bbclass: install files under pseudoPatrick Ohly2017-11-171-2/+2
| | | | | | | | | | | | | | | | | do_uefiapp_deploy copies files into the /boot directory of the rootfs and thus, like do_rootfs, should run under pseudo so that the files end up being owned by root. This did not trigger the uid leak check, perhaps because the task runs later. For some (still unknown reason), sometimes the installed files did end up being owned by root, which tripped up a swupd test because the system update randomly included unexpected changes to bootx64.efi or rmc.db. With this change, they are owned by root consistently. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* uefi-comboapp.bbclass: Split signing functionality into its own bbclassCalifornia Sullivan2017-07-192-34/+55
| | | | | | | | | In the future more secure boot implementations will be offered, with each one needing the signing method. Instead of repeating a forty line block of code across several recipes, just use a configurable bbclass. Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* uefi-comboapp.bbclass: support multiple UEFI combo apps + fixesPatrick Ohly2017-07-191-23/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original code in intel-iot-refkit allows to create more than one UEFI combo app and uses that to create one for removable media and one for fixed media (after installation), with different boot=PARTUUID=xxx parameters. This way, an installed image never ended up booting from the install media. uefi-comboapp.bbclass now supports the same feature, with create_uefiapp() as the API function that can be used to create additional UEFI apps and create_uefiapps as the method where the call can be added. In addition, several shortcomings are getting addressed: - A UEFI combo app must be stored under a name that is specific to the image for which it gets created, otherwise different image recipes end up overwriting (or using) files from other images. - Signing must be done after creating the apps and before deploying them, otherwise the unsigned apps get copied to the image when using do_uefiapp_deploy. - The common code for deployment is now in uefiapp_deploy_at. - $dest is used instead of ${DEST} because the latter might get expanded by bitbake. - Because do_uefiapp always had to run anew to produce the clean, unsigned input for do_uefiapp_sign, having two different tasks just added unnecessary complexity. Now all code is in do_uefiapp. - Old files matching the output pattern get removed explicitly, because they might not get overwritten when the optional app suffix changes between builds, or when the task fails in the middle. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* classes: Add uefi-comboapp bbclassCalifornia Sullivan2017-07-101-0/+155
| | | | | | | | | | | | | | This bbclass pulls in the portion of code that builds a UEFI combo application from meta-refkit to meta-intel. The combo app contains an EFI stub from systemd, which allows you to boot a kernel directly, a kernel, an initramfs, and a command line. This class is compatible as either an EFI_PROVIDER or IMAGE_CLASSES target, and does not include the entire _dsk type image creation seen in meta-refkit. Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* rmc-db: allow multiple fingerprint per board directoryTodor Minchev2017-06-071-7/+7
| | | | | | | | | | Different firmware revisions often result in different fingerprints for the same hardware platform. This change allows multiple fingerprints to be stored in the same board directory to avoid having to duplicate the data for each record. Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* rmc: Extend usages of RMC_BOARD_DATA_DIRS to specify board dataJianxun Zhang2017-01-091-1/+5
| | | | | | | | | | | | | | | | | | | Use the variable RMC_BOARD_DATA_DIRS, to disable, append to, or override the default board data in meta-intel with boards' data provided by users. Ideally, users should get the updated database in the new built image after an incremental build. Examples of RMC database output (db): RMC_BOARD_DATA_DIRS = "" (disable db generation) RMC_BOARD_DATA_DIRS_append = " top_dir" (db of defaults & user's) RMC_BOARD_DATA_DIRS = "top_dir" (db for user's , no defaults) RMC_BOARD_DATA_DIRS = " " (same as "") Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com> Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
* rmc: add support for alternative EFI bootloadersTodor Minchev2016-12-151-2/+3
| | | | | | | | | | RMC was previously configured to work only with the systemd-boot EFI bootloader. With this commit we can specify alternative bootloaders by setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is not set systemd-boot will be used by default. Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com> Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
* rmc: Add recipe and bbclass for RMC featureJianxun Zhang2016-08-031-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RMC Feature is based on RMC project, systemd-boot, EFI installer to enable a single generic image, built for multiple platforms, automatically applies customization and quirks specific to a type of boards at runtime. In another word, you will see a single image behaves differently and intelligently according to the type of board it is running on. To Enable this feature: add the two lines in conf file: DISTRO_FEATURES_append = " rmc" EFI_PROVIDER = "rmc-systemd-boot" Based on Saul Wold's initial work on a feature switch, RMC patches in systemd-boot, installer and gnu-efi aren't built unless the feature is enabled. For a supported board, this feature can : () show and boot with board-specific boot entries in boot menu in live-boot and post-installation. () apply a kernel cmdline fragment to the end of cmdline to boot Linux kernel. This is effective for any boot entry user chooses in boot menu. () create directory and deploy files only for the type of the running board to target's file systems. What left on target after installation is just same as the result from installing a conventional image customized for a single type of hardware. To add support of new boards, a new variable RMC_BOARD_DATA_DIRS is the interface to developers. How-to information will be provided with examples in following patches. Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com> Reviewed-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
* rmc: Add Runtime Machine Configuration (RMC) projectJianxun Zhang2016-08-031-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RMC recipe fetch RMC project and build it more than once in build time: RMC tool is built for host architecture (native). The tool for host is used to generate RMC database in build time. RMC tool is also built for target architecture, so that scripts in user space can call RMC tool on a running target. Developers can also boot a target and run rmc tool to obtain fingerprint for a new board type. RMC libraries are compiled for both of UEFI context and user space. They are always linked in RMC tool and can be linked into an EFI bootloader. The recipes don't install libraries for target's user space until we have a new client needs it. The rmc-db.bbclass provides functions to generate rmc database file for other software components to reuse. We absorb a patch from Tom Zanussi to update source location with the public link. We could put this change in another commit, but leaving the replaced internal link in this commit could cause trouble when people bisect the project but don't have access to the internal location: ---------------------- rmc: Update to use public repo The repo the rmc recipe was pointing to was private - it's now public Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com> common/recipes-bsp/rmc/rmc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc index c046e2e..bdf930d 100644 --- a/common/recipes-bsp/rmc/rmc.inc +++ b/common/recipes-bsp/rmc/rmc.inc @@ -15,7 +15,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07" -SRC_URI = "git://git@git.yoctoproject.org/rmc;protocol=ssh" +SRC_URI = "git://git.yoctoproject.org/rmc" ... ---------------------- Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com> Reviewed-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
* Remove all the changes related to the proprietary EMGD graphics driverNitin A Kamble2014-09-161-11/+0
| | | | | | | | As all the EMGD based BSPs have been retired, there is no need for the proprietary EMGD support in the meta-intel layer. Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
* Separate packagedir for GL components of EMGD BSPsRichard Purdie2013-09-181-0/+11
When multiple BSPs of the same arch are built in a build directory, the differences in GL providers such as emgd-driver and mesa causes rebuild of large set of recipes, as they collide on each other's space for multiple BSPs. Although this does not impact correctness, it impacts build performance negatively. Richard had an idea of providing separate PACKAGE_DIR to the colliding recipes to avoid the build area collision. And this approach significantly reduces the negative impact on the build performance. Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>