linux/meta-intel.git/classes, branch master

classes: add oneapi-vendor-compat bbclass

2026-04-29T13:15:11+00:00

The Intel oneAPI DPC++/C++ compiler binaries (icx, icpx) shipped by meta-intel as prebuilt installers have a fixed default -target triple baked into the LLVM driver. As of the 2025.3.x bundle the triple is 'x86_64-unknown-linux-gnu' (LLVM's portable default); prior 2024.x bundles used 'x86_64-oe-linux' (matching the OpenEmbedded nodistro default of TARGET_VENDOR=oe). icx also emits 'x86_64-linux-gnu' (the Debian/Ubuntu host triple) in some search paths. Yocto distros set TARGET_VENDOR differently: poky uses 'poky' (TARGET_SYS=x86_64-poky-linux), nodistro uses 'oe', etc. The result is a vendor-triple mismatch: icx looks for crtbeginS.o / bits/c++config.h and similar files under one triple while they are installed at another. Until Intel either ships per-vendor variants or the meta-intel oneAPI recipes patch the prebuilt binaries, install a set of compatibility symlinks at rootfs time so every spelling of the multilib vendor triple resolves to the same files on the image. The alias set is configurable via ONEAPI_VENDOR_TRIPLE_ALIASES; entries that already match the native target triple are skipped, so the class is a no-op on images whose native vendor matches every alias. Usage: add to IMAGE_CLASSES in a distro / local config that consumes the Intel oneAPI compiler: IMAGE_CLASSES += "oneapi-vendor-compat" Signed-off-by: Yogesh Tyagi

recipes: remove secureboot selftest and images

2024-05-30T02:27:20+00:00

This no longer works and is not maintained and tested. Signed-off-by: Anuj Mittal

icc: drop Intel C++ classic compiler support

2022-11-23T02:49:13+00:00

Support for Intel(R) oneAPI DPC++/C++ (icx) compiler is being added. So remove the support for the classic compiler. Signed-off-by: Naveen Saini Signed-off-by: Anuj Mittal

icc: add Intel(R) C++ Compiler Classic (ICC) support

2022-10-12T05:57:11+00:00

Using the Intel® C++ Compiler Classic, you can compile and generate applications that can run on Intel® 64 architecture. Signed-off-by: Naveen Saini Signed-off-by: Anuj Mittal

Convert to new override syntax

2021-07-31T09:47:03+00:00

Use the convert-overrides.py to convert to new syntax and manually fix some additional changes. Signed-off-by: Anuj Mittal

rmc: remove

2018-07-16T08:53:00+00:00

It's not being maintained anymore and the scripts have not been kept in sync with upstream for quite some time. Signed-off-by: Anuj Mittal

uefi-comboapp.bbclass: install files under pseudo

2017-11-17T18:54:21+00:00

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 Signed-off-by: Saul Wold

uefi-comboapp.bbclass: Split signing functionality into its own bbclass

2017-07-19T15:30:08+00:00

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 Signed-off-by: Saul Wold

uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes

2017-07-19T15:30:08+00:00

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 Signed-off-by: Saul Wold

classes: Add uefi-comboapp bbclass

2017-07-10T19:08:20+00:00

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 Signed-off-by: Saul Wold