| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Using the Intel® C++ Compiler Classic, you can compile and generate
applications that can run on Intel® 64 architecture.
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
| |
Use the convert-overrides.py to convert to new syntax and manually
fix some additional changes.
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
| |
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 <anuj.mittal@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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 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 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>
|
| |
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
