forked from brl/citadel
meta-intel moved to submodule
This commit is contained in:
parent
a50a095f38
commit
13f7e03e8a
3
.gitmodules
vendored
3
.gitmodules
vendored
@ -4,3 +4,6 @@
|
||||
[submodule "poky"]
|
||||
path = poky
|
||||
url = https://git.yoctoproject.org/git/poky
|
||||
[submodule "meta-intel"]
|
||||
path = meta-intel
|
||||
url = https://git.yoctoproject.org/git/meta-intel
|
||||
|
||||
1
meta-intel
Submodule
1
meta-intel
Submodule
@ -0,0 +1 @@
|
||||
Subproject commit 9a4d583c7de4634a22104ca4c88ddf0d560494b6
|
||||
6
meta-intel/.gitignore
vendored
6
meta-intel/.gitignore
vendored
@ -1,6 +0,0 @@
|
||||
*.pyc
|
||||
*.pyo
|
||||
*.swp
|
||||
*.orig
|
||||
*.rej
|
||||
*~
|
||||
@ -1,87 +0,0 @@
|
||||
This file will only list major changes that occur within a release.
|
||||
For a full list of changes, view the git log of the repository.
|
||||
|
||||
Rocko Release 11/2017
|
||||
=====================
|
||||
|
||||
Moved qat support to separate layer
|
||||
-----------------------------------
|
||||
Quick Assist Technology (QAT) is more middleware and should not be part of the
|
||||
core BSP. The new layer can be found here:
|
||||
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-qat/
|
||||
|
||||
Moved dpdk support to separate layer
|
||||
------------------------------------
|
||||
We had some requests to make DPDK standalone so that it could be included
|
||||
without bringing in anything else from meta-intel, as it is not specific to
|
||||
Intel(R) hardware. The new layer is located here:
|
||||
https://git.yoctoproject.org/cgit/cgit.cgi/meta-dpdk/
|
||||
|
||||
Added support for out-of-tree iwlwifi drivers
|
||||
---------------------------------------------
|
||||
Backport-iwlwifi out-of-tree wifi modules are now available via meta-intel.
|
||||
Backport-iwlwifi brings the latest iwlwifi drivers to almost any kernel
|
||||
Note that mac80211 and cfg80211 backports are also necessary, which will most
|
||||
likely cause incompatibility with other in-tree wifi drivers.
|
||||
See https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi for more info.
|
||||
|
||||
Added support for out-of-tree ixgbe drivers
|
||||
-------------------------------------------
|
||||
The out-of-tree ixgbe drivers bring ixgbe support to nearly any kernel. See
|
||||
here: http://www.intel.com/network/connectivity/products/server_adapters.htm
|
||||
|
||||
Added an implementation of Secure Boot
|
||||
--------------------------------------
|
||||
meta-intel now supports a simple Secure Boot implementation. This implementation
|
||||
consists of a single binary consisting of an EFI stub, the kernel, an
|
||||
initrd, and a kernel command line. The binary is then signed via keys defined by
|
||||
the variables SECUREBOOT_SIGNING_KEY and SECUREBOOT_SIGNING_CERT. These keys
|
||||
should match the keys embedded in your hardware's firmware.
|
||||
See documentation/secureboot/README for more information on this feature.
|
||||
|
||||
Improved Yocto Project Compatibility status
|
||||
-------------------------------------------
|
||||
The common layer should now be considered Yocto Project compatible - it should
|
||||
no longer modify OE-core values when adding the layer to your bblayers.conf.
|
||||
The meta-tlk layer is still not Yocto Project compatible, however.
|
||||
|
||||
Pyro Release 5/2017
|
||||
===================
|
||||
|
||||
Changed default kernel provider from linux-yocto to linux-intel.
|
||||
----------------------------------------------------------------
|
||||
Linux-intel is an Intel(R)-maintained kernel based on the latest stable
|
||||
branch, along with backports from upstream to better support Intel(R)
|
||||
hardware. The intel-linux kernel also has a branch with the preempt-rt
|
||||
patches applied, providing a preempt-rt kernel with no additional work.
|
||||
|
||||
Added QEMU support.
|
||||
-------------------
|
||||
We now build several virtio drivers into the kernel by default, and
|
||||
have qemuboot.conf files for intel-corei7-64 and intel-core2-32
|
||||
targets. This allows one to do basic testing on meta-intel images
|
||||
without having to use hardware. The virtio drivers are added via
|
||||
KERNEL_FEATURES_INTEL_COMMON. This prevents them from being added to
|
||||
custom kernels by default. They can be removed by adding the
|
||||
following to a conf or kernel bbappend file:
|
||||
KERNEL_FEATURES_INTEL_COMMON_remove = “cfg/virtio.scc”
|
||||
OVMF firmware is also built and can be used in order to emulate a UEFI
|
||||
environment. A full runqemu command line for intel-corei7-64 could look
|
||||
like this:
|
||||
runqemu core-image-minimal intel-corei7-64 wic ovmf
|
||||
|
||||
Musl support
|
||||
------------
|
||||
Meta-intel is now compatible with the musl C library. You can specify musl
|
||||
As your C library by adding the following to your local.conf:
|
||||
TCLIBC = “musl”
|
||||
Note: there is a known failure with DPDK.
|
||||
|
||||
X32 support
|
||||
-----------
|
||||
The meta-intel layer can now build with the x32 tune settings in a multi-lib
|
||||
setting, it will not work in as the primary MACHINE tune as the bootloader needs
|
||||
to be built as a 64bit binary. The setup for this would be as follows:
|
||||
require conf/multilib.conf
|
||||
MULTILIBS = "multilib:libx32
|
||||
DEFAULTTUNE_virtclass-multilib-libx32 = "corei7-64-x32"
|
||||
@ -1,17 +0,0 @@
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in
|
||||
all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
||||
THE SOFTWARE.
|
||||
@ -1,5 +0,0 @@
|
||||
All metadata files (including, but not limited to bb, bbappend,
|
||||
bbclass, inc and conf files) are MIT licensed unless otherwise stated.
|
||||
Source code included in tree for individual recipes is under the
|
||||
LICENSE stated in the associated recipe (.bb file) unless otherwise
|
||||
stated.
|
||||
@ -1,32 +0,0 @@
|
||||
This file contains a list of BSP maintainers for the BSPs contained in
|
||||
the meta-intel repository.
|
||||
|
||||
The purpose of this file is to provide contact information for
|
||||
specific BSPs and other code contained within meta-intel. You should
|
||||
address questions and patches for a particular BSP or other code to
|
||||
the appropriate maintainer listed in this file, cc'ing the meta-intel
|
||||
mailing list. This ensures that your question or patch will be
|
||||
addressed by the appropriate person, and that it will be seen by other
|
||||
users who may be facing similar problems or questions.
|
||||
|
||||
Please see the top-level README file for guidelines relating to the
|
||||
details of submitting patches, reporting problems, or asking questions
|
||||
about any of the BSPs or other recipes contained within meta-intel.
|
||||
|
||||
Descriptions of section entries:
|
||||
|
||||
M: Mail patches to: FullName <address@domain>
|
||||
F: Files and directories with wildcard patterns.
|
||||
A trailing slash includes all files and subdirectory files.
|
||||
F: common/ all files in and below common
|
||||
F: common/* all files in common, but not below
|
||||
One pattern per line. Multiple F: lines acceptable.
|
||||
|
||||
Please keep this list in alphabetical order.
|
||||
|
||||
Maintainers List (try to look for most precise areas first)
|
||||
|
||||
-----------------------------------
|
||||
|
||||
M: Saul Wold <sgw@linux.intel.com>
|
||||
F: *
|
||||
@ -1,481 +0,0 @@
|
||||
meta-intel
|
||||
==========
|
||||
|
||||
This README file contains information on building and booting
|
||||
meta-intel BSP layers. Please see the corresponding sections below
|
||||
for details.
|
||||
|
||||
|
||||
Yocto Project Compatible
|
||||
========================
|
||||
|
||||
The BSPs contained in this layer are compatible with the Yocto Project
|
||||
as per the requirements listed here:
|
||||
|
||||
https://www.yoctoproject.org/webform/yocto-project-compatible-registration
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This layer depends on:
|
||||
|
||||
URI: git://git.openembedded.org/bitbake
|
||||
branch: 1.34
|
||||
|
||||
URI: git://git.openembedded.org/openembedded-core
|
||||
layers: meta
|
||||
branch: rocko
|
||||
|
||||
|
||||
Table of Contents
|
||||
=================
|
||||
|
||||
I. Overview
|
||||
II. Building and booting meta-intel BSP layers
|
||||
a. Building the intel-common and quark BSP layers
|
||||
b. Booting the intel-common BSP images
|
||||
c. Booting the intel-quark BSP image on a Galileo board
|
||||
III. Technical Miscellany
|
||||
Benefits of using meta-intel
|
||||
The intel-common kernel package architecture
|
||||
Intel-specific machine features
|
||||
IV. Tested Hardware
|
||||
V. Guidelines for submitting patches
|
||||
|
||||
|
||||
I. Overview
|
||||
===========
|
||||
|
||||
This is the location for Intel-maintained BSPs.
|
||||
|
||||
For details on the intel-common and intel-quark BSPs, see the
|
||||
information below.
|
||||
|
||||
For all others, please see the README files contained in the
|
||||
individual BSP layers for BSP-specific information.
|
||||
|
||||
If you have problems with or questions about a particular BSP, please
|
||||
contact the maintainer listed in the MAINTAINERS file directly (cc:ing
|
||||
the Yocto mailing list puts it in the archive and helps other people
|
||||
who might have the same questions in the future), but please try to do
|
||||
the following first:
|
||||
|
||||
- look in the Yocto Project Bugzilla
|
||||
(http://bugzilla.yoctoproject.org/) to see if a problem has
|
||||
already been reported
|
||||
|
||||
- look through recent entries of the meta-intel
|
||||
(https://lists.yoctoproject.org/pipermail/meta-intel/) and Yocto
|
||||
(https://lists.yoctoproject.org/pipermail/yocto/) mailing list
|
||||
archives to see if other people have run into similar problems or
|
||||
had similar questions answered.
|
||||
|
||||
If you believe you have encountered a bug, you can open a new bug and
|
||||
enter the details in the Yocto Project Bugzilla
|
||||
(http://bugzilla.yoctoproject.org/). If you're relatively certain
|
||||
that it's a bug against the BSP itself, please use the 'Yocto Project
|
||||
Components: BSPs | meta-intel' category for the bug; otherwise, please
|
||||
submit the bug against the most likely category for the problem - if
|
||||
you're wrong, it's not a big deal and the bug will be recategorized
|
||||
upon triage.
|
||||
|
||||
|
||||
II. Building and booting meta-intel BSP layers
|
||||
==============================================
|
||||
|
||||
The following sections contain information on building and booting the
|
||||
BSPs contained in the meta-intel layer.
|
||||
|
||||
Note that these instructions specifically cover the intel-common and
|
||||
quark BSPs, which may or may not be applicable to other BSPs contained
|
||||
in this layer - if a given BSP contains its own README, that version
|
||||
should be used instead, and these instructions can be ignored.
|
||||
|
||||
a. Building the intel-common and quark BSP layers
|
||||
-------------------------------------------------
|
||||
|
||||
In order to build an image with BSP support for a given release, you
|
||||
need to download the corresponding BSP tarball from the 'Board Support
|
||||
Package (BSP) Downloads' page of the Yocto Project website (or
|
||||
equivalently, check out the appropriate branch from the meta-intel git
|
||||
repository, see below). For the intel-common and quark BSPs, those
|
||||
tarballs would correspond to the following choices in the BSP
|
||||
downloads section:
|
||||
|
||||
- Intel-core2-32 Intel® Common Core BSP (Intel-core2-32)
|
||||
- Intel-core2-32 Intel® Common Core BSP (Intel-quark)
|
||||
- Intel-corei7-64 Intel® Common Core BSP (Intel-corei7-64)
|
||||
|
||||
The intel-* BSPs, also known as the intel-common BSPs, provide a few
|
||||
carefully selected tune options and generic hardware support to cover
|
||||
the majority of current Intel CPUs and devices. The naming follows the
|
||||
convention of intel-<TUNE>-<BITS>, where TUNE is the gcc cpu-type
|
||||
(used with mtune and march typically) and BITS is either 32 bit or 64
|
||||
bit.
|
||||
|
||||
Having done that, and assuming you extracted the BSP tarball contents
|
||||
at the top-level of your yocto build tree, you can build a BSP image
|
||||
by adding the location of the meta-intel layer to bblayers.conf e.g.:
|
||||
|
||||
yocto/meta-intel \
|
||||
|
||||
To enable a particular machine, you need to add a MACHINE line naming
|
||||
the BSP to the local.conf file:
|
||||
|
||||
MACHINE ?= "xxx"
|
||||
|
||||
where 'xxx' is replaced by one of the following BSP names:
|
||||
|
||||
- intel-core2-32
|
||||
|
||||
This BSP is optimized for the Core2 family of CPUs as well as all
|
||||
Atom CPUs prior to the Silvermont core.
|
||||
|
||||
- intel-corei7-64
|
||||
|
||||
This BSP is optimized for Nehalem and later Core and Xeon CPUs as
|
||||
well as Silvermont and later Atom CPUs, such as the Baytrail SoCs.
|
||||
|
||||
- intel-quark
|
||||
|
||||
This BSP is optimized for Quark-based systems.
|
||||
|
||||
You should then be able to build an image as such:
|
||||
|
||||
$ source oe-init-build-env
|
||||
$ bitbake core-image-sato
|
||||
|
||||
At the end of a successful build, you should have an image that
|
||||
you can boot from a USB flash drive (see instructions on how to do
|
||||
that below, in the section 'Booting the intel-common BSP images').
|
||||
|
||||
As an alternative to downloading the BSP tarball, you can also work
|
||||
directly from the meta-intel git repository. For each BSP in the
|
||||
'meta-intel' repository, there are multiple branches, one
|
||||
corresponding to each major release starting with 'laverne' (0.90), in
|
||||
addition to the latest code which tracks the current master (note that
|
||||
not all BSPs are present in every release). Instead of extracting
|
||||
a BSP tarball at the top level of your yocto build tree, you can
|
||||
equivalently check out the appropriate branch from the meta-intel
|
||||
repository at the same location.
|
||||
|
||||
b. Booting the intel-common BSP images
|
||||
--------------------------------------
|
||||
|
||||
If you downloaded the BSP tarball, you will find bootable images in
|
||||
the /binary directory. If you've built your own image, either from
|
||||
the downloaded BSP layer or from the meta-intel git repository, you'll
|
||||
find the bootable image in the build/tmp/deploy/images/xxx directory,
|
||||
where again 'xxx' refers to the machine name used in the build.
|
||||
|
||||
The BSP /binary directory or build contains bootable live images,
|
||||
which can be used to directly boot Yocto off of a USB flash drive.
|
||||
|
||||
Under Linux, insert a USB flash drive. Assuming the USB flash drive
|
||||
takes device /dev/sdf, use dd to copy the image to it. For example:
|
||||
|
||||
$ dd if=core-image-sato-intel-corei7-64.wic of=/dev/sdf
|
||||
$ sync
|
||||
$ eject /dev/sdf
|
||||
|
||||
This should give you a bootable USB flash device. Insert the device
|
||||
into a bootable USB socket on the target, and power on. This should
|
||||
result in a system booted to the Sato graphical desktop.
|
||||
|
||||
If you want a terminal, use the arrows at the top of the UI to move to
|
||||
different pages of available applications, one of which is named
|
||||
'Terminal'. Clicking that should give you a root terminal.
|
||||
|
||||
If you want to ssh into the system, you can use the root terminal to
|
||||
ifconfig the IP address and use that to ssh in. The root password is
|
||||
empty, so to log in type 'root' for the user name and hit 'Enter' at
|
||||
the Password prompt: and you should be in.
|
||||
|
||||
If you find you're getting corrupt images on the USB (it doesn't show
|
||||
the syslinux boot: prompt, or the boot: prompt contains strange
|
||||
characters), try doing this first:
|
||||
|
||||
$ dd if=/dev/zero of=/dev/sdf bs=1M count=512
|
||||
|
||||
c. Booting the intel-quark BSP image on a Galileo board
|
||||
-------------------------------------------------------
|
||||
|
||||
If you downloaded the BSP tarball, you will find bootable images in
|
||||
the /binary directory. If you've built your own image, either from
|
||||
the downloaded BSP layer or from the meta-intel git repository, you'll
|
||||
find the bootable image in the build/tmp/deploy/images/xxx directory,
|
||||
where again 'xxx' refers to the machine name used in the build.
|
||||
|
||||
The Galileo board can boot off of either an SD card or USB storage
|
||||
media that has a special disk layout. The 'wic' tool can be used to
|
||||
create directly bootable images for either of the two formats via the
|
||||
following steps. As of meta-intel 6.0-morty-2.2 or newer, wic images are
|
||||
created automatically during build time, and the manual use of wic is
|
||||
not necessary. By default, the galileodisk-sd wic kickstart file is used,
|
||||
which targets SD cards. This can be changed by setting the WKS_FILE to
|
||||
something else in local.conf, such as the following:
|
||||
|
||||
WKS_FILE = “galileodisk-usb”
|
||||
|
||||
If your build is successful, a .wic image will be created in the usual
|
||||
deploy directory. Write this image to an SD card:
|
||||
|
||||
$ sudo dd if=/path/to/image/image-name.wic of=/dev/your_sd_dev
|
||||
$ sync
|
||||
$ sudo eject /dev/your_sd_dev
|
||||
|
||||
Insert the SD card into the Galileo and power on.
|
||||
|
||||
The Galileo board can boot from an hddimg formatted USB drive as well,
|
||||
but currently only live-boot, and not installation, is supported.
|
||||
An image in hddimg format is generated when you build the quark BSP.
|
||||
You can follow the procedure in II.b to use dd command to prepare your USB
|
||||
drive, then press F7 key during startup to bring up the boot option menu.
|
||||
Choose the UEFI USB boot option for the drive to boot the system. If the board
|
||||
already passes this stage and show a grub boot menu, you can press 'c'
|
||||
key and then type "quit" in grub shell. The board should come back to
|
||||
the UEFI boot menu.
|
||||
|
||||
III. Technical Miscellany
|
||||
=========================
|
||||
|
||||
Benefits of using meta-intel
|
||||
----------------------------
|
||||
|
||||
Using meta-intel has the following benefits over a generic BSP:
|
||||
|
||||
tune flags
|
||||
++++++++++
|
||||
intel-* MACHINEs each have different compilation flags appropriate for their
|
||||
targeted hardware sets. intel-corei7-64 has tune flags appropriate for modern
|
||||
64-bit Intel Core i microarchitecture, and includes instruction sets up to
|
||||
SSE4.2. intel-core2-32 has tune flags appropriate for legacy 32-bit Intel Core2
|
||||
microarchitecture, and includes instruction sets up to SSE3. intel-quark
|
||||
contains a subset of the intel-core2-32 instruction set, as quark does not
|
||||
support prefix locking instructions.
|
||||
|
||||
linux-intel kernel
|
||||
++++++++++++++++++
|
||||
The linux-intel kernel is an initiative to bring better Intel(R) hardware
|
||||
support to the current LTS linux kernel. It contains a base LTS kernel with
|
||||
additional backports from upstream Intel drivers. In addition, a default kernel
|
||||
config containing most features found on Intel boards is supplied via the
|
||||
yocto-kernel-cache.
|
||||
|
||||
graphics stack
|
||||
++++++++++++++
|
||||
Meta-intel provides the latest Intel Graphics Linux Stack drivers to support
|
||||
Intel hardware as defined by the https://01.org/linuxgraphics.
|
||||
|
||||
Other software
|
||||
++++++++++++++
|
||||
* intel ucode - provides the latest microcode updates for Intel processors
|
||||
|
||||
* thermald - which proactively controls thermal, using P-states, T-states, and
|
||||
the Intel power clamp driver.
|
||||
(https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon)
|
||||
|
||||
* RMC - Runtime Machine Configuration, which allows the bootload to determine
|
||||
board and CPU information in order to set specific kernel command line
|
||||
information at startup.
|
||||
|
||||
The intel-common kernel package architecture
|
||||
--------------------------------------------
|
||||
|
||||
These BSPs use what we call the intel-common Linux kernel package
|
||||
architecture. This includes core2-32-intel-common and
|
||||
corei7-64-intel-common. These kernel packages can also be used by any
|
||||
of the BSPs in meta-intel that choose to include the
|
||||
intel-common-pkgarch.inc file.
|
||||
|
||||
To minimize the proliferation of vendor trees, reduce the sources we
|
||||
must support, and consolidate QA efforts, all BSP maintainers are
|
||||
encouraged to make use of the intel-common Linux kernel package
|
||||
architecture.
|
||||
|
||||
Intel-specific machine features
|
||||
-------------------------------
|
||||
|
||||
The meta-intel layer makes some additional machine features available
|
||||
to BSPs. These machine features can be used in a BSP layer in the
|
||||
same way that machine features are used in other layers based on
|
||||
oe-core, via the MACHINE_FEATURES variable.
|
||||
|
||||
Requirements
|
||||
++++++++++++
|
||||
|
||||
The meta-intel-specific machine features are only available to a BSP
|
||||
when the meta-intel layer is included in the build configuration, and
|
||||
the meta-intel.inc file is included in the machine configuration of
|
||||
that BSP.
|
||||
|
||||
To make these features available for your machine, you will need to:
|
||||
|
||||
1. include a configuration line such as the below in bblayers.conf
|
||||
BBLAYERS += "<local path>/meta-intel"
|
||||
2. include the following line in the machine configuration file
|
||||
require conf/machine/include/meta-intel.inc
|
||||
|
||||
Once the above requirements are met, the machine features provided by
|
||||
the meta-intel layer will be available for the BSP to use.
|
||||
|
||||
Available machine features
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
Currently, the meta-intel layer makes the following set of
|
||||
Intel-specific machine features available:
|
||||
|
||||
* intel-ucode
|
||||
|
||||
These machine features can be included by listing them in the
|
||||
MACHINE_FEATURES variable in the machine configuration file. For
|
||||
example:
|
||||
|
||||
MACHINE_FEATURES += "intel-ucode"
|
||||
|
||||
Machine feature details
|
||||
+++++++++++++++++++++++
|
||||
|
||||
* intel-ucode
|
||||
|
||||
This feature provides support for microcode updates to Intel
|
||||
processors. The intel-ucode feature runs at early boot and uses
|
||||
the microcode data file added by the feature into the BSP's
|
||||
initrd. It also puts the userland microcode-updating tool,
|
||||
iucode_tool, into the target images along with the microcode data
|
||||
file.
|
||||
|
||||
Q. Why might a user want to enable the intel-ucode feature?
|
||||
|
||||
A. Intel releases microcode updates to correct processor behavior
|
||||
as documented in the respective processor specification
|
||||
updates. While the normal approach to getting such microcode
|
||||
updates is via a BIOS upgrade, this can be an administrative
|
||||
hassle and not always possible in the field. The intel-ucode
|
||||
feature enables the microcode update capability present in the
|
||||
Linux kernel. It provides an easy path for upgrading processor
|
||||
microcode without the need to change the BIOS. If the feature
|
||||
is enabled, it is also possible to update the existing target
|
||||
images with a newer microcode update in the future.
|
||||
|
||||
Q. How would a user bundle only target-specific microcode in the
|
||||
target image?
|
||||
|
||||
A. The Intel microcode data file released by Intel contains
|
||||
microcode updates for multiple processors. If the BSP image is
|
||||
meant to run on only a certain subset of processor types, a
|
||||
processor-specific subset of microcode can be bundled into the
|
||||
target image via the UCODE_FILTER_PARAMETERS variable. This
|
||||
works by listing a sequence of iucode-tool parameters in the
|
||||
UCODE_FILTER_PARAMETERS variable, which in this case will
|
||||
select only the specific microcode relevant to the BSP. For
|
||||
more information on the underlying parameters refer to the
|
||||
iucode-tool manual page at http://manned.org/iucode-tool
|
||||
|
||||
To define a set of parameters for microcode-filtering via the
|
||||
UCODE_FILTER_PARAMETERS variable, one needs to identify the
|
||||
cpuid signatures of all the processors the BSP is meant to run
|
||||
on. One way to determine the cpuid signature for a specific
|
||||
processor is to build and run an intel-ucode-feature-enabled
|
||||
image on the target hardware, without first assigning any value
|
||||
to the UCODE_FILTER_PARAMETERS variable, and then once the
|
||||
image is booted, run the "ucode_tool -S" command to have the
|
||||
ucode tool scan the system for processor signatures. These
|
||||
signatures can then be used in the UCODE_FILTER_PARAMETERS
|
||||
variable in conjunction with -s parameter. For example, for
|
||||
the fri2 BSP, the cpuid can be determined as such:
|
||||
|
||||
[root@fri2 ~]# iucode_tool -S
|
||||
iucode_tool: system has processor(s) with signature 0x00020661
|
||||
|
||||
Given that output, a suitable UCODE_FILTER_PARAMETERS variable
|
||||
definition could be specified in the machine configuration as
|
||||
such:
|
||||
|
||||
UCODE_FILTER_PARAMETERS = "-s 0x00020661"
|
||||
|
||||
Q. Are there any reasons a user might want to disable the
|
||||
intel-ucode feature?
|
||||
|
||||
A. The microcode data file and associated tools occupy a small
|
||||
amount of space (a few KB) on the target image. BSPs which are
|
||||
highly sensitive to target image size and which are not
|
||||
experiencing microcode-related issues might consider not
|
||||
enabling this feature.
|
||||
|
||||
|
||||
IV. Tested Hardware
|
||||
===================
|
||||
|
||||
The following undergo regular basic testing with their respective MACHINE types.
|
||||
Note that both 64-bit and 32-bit firmware is available for the MinnowBoard
|
||||
Turbot, so it is tested against both intel-corei7-64 and intel-core2-32.
|
||||
|
||||
intel-corei7-64:
|
||||
NUC6i5SYH
|
||||
MinnowBoard Turbot
|
||||
Braswell RVP
|
||||
|
||||
intel-core2-32:
|
||||
MinnowBoard Turbot
|
||||
|
||||
Intel-quark:
|
||||
Galileo 2
|
||||
|
||||
|
||||
V. Guidelines for submitting patches
|
||||
====================================
|
||||
|
||||
Please submit any patches against meta-intel BSPs to the meta-intel
|
||||
mailing list (meta-intel@yoctoproject.org). Also, if your patches are
|
||||
available via a public git repository, please also include a URL to
|
||||
the repo and branch containing your patches as that makes it easier
|
||||
for maintainers to grab and test your patches.
|
||||
|
||||
There are patch submission scripts available that will, among other
|
||||
things, automatically include the repo URL and branch as mentioned.
|
||||
Please see the Yocto Project Development Manual sections entitled
|
||||
'Using Scripts to Push a Change Upstream and Request a Pull' and
|
||||
'Using Email to Submit a Patch' for details.
|
||||
|
||||
Regardless of how you submit a patch or patchset, the patches should
|
||||
at minimum follow the suggestions outlined in the 'Submitting a Change
|
||||
to the Yocto Project' section in the Yocto Project Development Manual.
|
||||
Specifically, they should:
|
||||
|
||||
- Include a 'Signed-off-by:' line. A commit can't legally be pulled
|
||||
in without this.
|
||||
|
||||
- Provide a single-line, short summary of the change. This short
|
||||
description should be prefixed by the BSP or recipe name, as
|
||||
appropriate, followed by a colon. Capitalize the first character
|
||||
of the summary (following the colon).
|
||||
|
||||
- For the body of the commit message, provide detailed information
|
||||
that describes what you changed, why you made the change, and the
|
||||
approach you used.
|
||||
|
||||
- If the change addresses a specific bug or issue that is associated
|
||||
with a bug-tracking ID, include a reference to that ID in your
|
||||
detailed description in the following format: [YOCTO #<bug-id>].
|
||||
|
||||
- Pay attention to line length - please don't allow any particular
|
||||
line in the commit message to stretch past 72 characters.
|
||||
|
||||
- For any non-trivial patch, provide information about how you
|
||||
tested the patch, and for any non-trivial or non-obvious testing
|
||||
setup, provide details of that setup.
|
||||
|
||||
Doing a quick 'git log' in meta-intel will provide you with many
|
||||
examples of good example commits if you have questions about any
|
||||
aspect of the preferred format.
|
||||
|
||||
The meta-intel maintainers will do their best to review and/or pull in
|
||||
a patch or patchset within 24 hours of the time it was posted. For
|
||||
larger and/or more involved patches and patchsets, the review process
|
||||
may take longer.
|
||||
|
||||
Please see the meta-intel/MAINTAINERS file for the list of maintainers
|
||||
and their specific areas; it's also a good idea to cc: the specific
|
||||
maintainer, if applicable.
|
||||
@ -1,17 +0,0 @@
|
||||
The sources for the packages comprising the images shipped with this
|
||||
BSP can be found at the following location:
|
||||
|
||||
http://downloads.yoctoproject.org/mirror/sources/
|
||||
|
||||
The metadata used to generate the images shipped with this BSP, in
|
||||
addition to the code contained in this BSP, can be found at the
|
||||
following location:
|
||||
|
||||
http://downloads.yoctoproject.org/releases/yocto/yocto-2.1/poky-krogoth-15.0.tar.bz2
|
||||
|
||||
The metadata used to generate the images shipped with this BSP, in
|
||||
addition to the code contained in this BSP, can also be found at the
|
||||
following locations:
|
||||
|
||||
git://git.yoctoproject.org/poky.git
|
||||
git://git.yoctoproject.org/meta-intel
|
||||
@ -1,17 +0,0 @@
|
||||
# rmc-boot bbclass
|
||||
# Deploy central RMC database file to ESP
|
||||
|
||||
IMAGE_INSTALL_append = " rmc"
|
||||
RMC_BOOTLOADER ?= "systemd-boot"
|
||||
|
||||
inherit ${RMC_BOOTLOADER}
|
||||
|
||||
do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
|
||||
|
||||
efi_populate_append() {
|
||||
if [ -f ${DEPLOY_DIR_IMAGE}/rmc.db ]; then
|
||||
install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
|
||||
else
|
||||
rm -f ${DEST}/rmc.db
|
||||
fi
|
||||
}
|
||||
@ -1,92 +0,0 @@
|
||||
# RMC database bbclass
|
||||
# provide functions to generate RMC database file on build host (native)
|
||||
|
||||
DEPENDS += "rmc-native"
|
||||
|
||||
# rmc_generate_db()
|
||||
# $1: a list of directories. Each directory holds directories for a group of
|
||||
# boards.
|
||||
# $2: path_name of rmc generates database file and records
|
||||
#
|
||||
# WARNING: content of directory of database file will be removed.
|
||||
#
|
||||
# Each board directory shall contain a fingerprint file (*.fp) at least, with
|
||||
# optional file blob(s) associated to the type of board. If a board directory
|
||||
# has no file blob, no record is created for that board.
|
||||
#
|
||||
# An example of two directories each of which contains two boards for RMC:
|
||||
# (All file and directory names are for illustration purpose.)
|
||||
#
|
||||
# dir_1/
|
||||
# board_1/
|
||||
# board_1_fingerprint.fp
|
||||
# file_1.blob
|
||||
# board_2/
|
||||
# board_2.fp
|
||||
# dir_2/
|
||||
# board_3/
|
||||
# b3.fp
|
||||
# file_1.blob
|
||||
# file_2.conf
|
||||
# board_4/
|
||||
# board_foo.fp
|
||||
# mylib.config
|
||||
#
|
||||
# To generate a RMC database "rmc.db" with data of all (actually 3) of boards in
|
||||
# a directory "deploy_dir":
|
||||
#
|
||||
# rmc_generate_db "dir_1 dir_2" "deploy_dir/rmc.db"
|
||||
#
|
||||
# The board_2 will be skipped. No record or any data for it is packed in
|
||||
# generated database because it only contains a fingerprint file.
|
||||
#
|
||||
|
||||
rmc_generate_db () {
|
||||
RMC_BOARD_DIRS=$1
|
||||
|
||||
if [ "$#" -ne 2 ]; then
|
||||
echo "rmc_generate_db(): Wrong number of arguments: $#"
|
||||
return 1
|
||||
fi
|
||||
|
||||
RMC_DB_DIR=$(dirname "$2")
|
||||
RMC_RECORDS=""
|
||||
|
||||
rm -rf ${RMC_DB_DIR}
|
||||
mkdir -p ${RMC_DB_DIR}
|
||||
|
||||
# generate rmc database
|
||||
for topdir in ${RMC_BOARD_DIRS}; do
|
||||
# For all board dirs in a topdir:
|
||||
CUR_BOARD_DIRS=$(find ${topdir}/* -type d)
|
||||
for board_dir in ${CUR_BOARD_DIRS}; do
|
||||
CUR_FINGERPRINT=$(find ${board_dir}/ -name "*.fp")
|
||||
|
||||
# disallow a board directory without any fingerprint file in it.
|
||||
if [ -z "${CUR_FINGERPRINT}" ]; then
|
||||
echo "Cannot find RMC fingerprint file in ${board_dir}"
|
||||
return 1
|
||||
fi
|
||||
|
||||
CUR_FILES=$(find ${board_dir}/ -type f |grep -v '\.fp$' || true)
|
||||
|
||||
# allow a directory only with fingerprint file. Developer may
|
||||
# check in fingerprint for future use.
|
||||
if [ -z "${CUR_FILES}" ]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
for fp in ${CUR_FINGERPRINT}; do
|
||||
fullname=$(basename ${fp})
|
||||
CUR_TAG="${fullname%.*}"
|
||||
CUR_RECORD=${RMC_DB_DIR}/${CUR_TAG}.rec
|
||||
rmc -R -f ${fp} -b ${CUR_FILES} -o ${CUR_RECORD}
|
||||
RMC_RECORDS="${RMC_RECORDS} ${CUR_RECORD}"
|
||||
done
|
||||
done
|
||||
done
|
||||
|
||||
if [ ! -z "${RMC_RECORDS}" ]; then
|
||||
rmc -D ${RMC_RECORDS} -o "$2"
|
||||
fi
|
||||
}
|
||||
@ -1,151 +0,0 @@
|
||||
# This class brings a more generic version of the UEFI combo app from refkit to meta-intel.
|
||||
# It uses a combo file, containing kernel, initramfs and
|
||||
# command line, presented to the BIOS as UEFI application, by prepending
|
||||
# it with the efi stub obtained from systemd-boot.
|
||||
|
||||
# Don't add syslinux or build an ISO
|
||||
PCBIOS_forcevariable = "0"
|
||||
NOISO_forcevariable = "1"
|
||||
|
||||
# image-live.bbclass will default INITRD_LIVE to the image INITRD_IMAGE creates.
|
||||
# We want behavior to be consistent whether or not "live" is in IMAGE_FSTYPES, so
|
||||
# we default INITRD_LIVE to the INITRD_IMAGE as well.
|
||||
INITRD_IMAGE ?= "core-image-minimal-initramfs"
|
||||
INITRD_LIVE ?= " ${@ ('${DEPLOY_DIR_IMAGE}/' + d.getVar('INITRD_IMAGE', expand=True) + '-${MACHINE}.cpio.gz') if d.getVar('INITRD_IMAGE', True) else ''}"
|
||||
|
||||
do_uefiapp[depends] += " \
|
||||
intel-microcode:do_deploy \
|
||||
systemd-boot:do_deploy \
|
||||
virtual/kernel:do_deploy \
|
||||
"
|
||||
|
||||
# INITRD_IMAGE is added to INITRD_LIVE, which we use to create our initrd, so depend on it if it is set
|
||||
do_uefiapp[depends] += "${@ '${INITRD_IMAGE}:do_image_complete' if d.getVar('INITRD_IMAGE') else ''}"
|
||||
|
||||
# The image does without traditional bootloader.
|
||||
# In its place, instead, it uses a single UEFI executable binary, which is
|
||||
# composed by:
|
||||
# - an UEFI stub
|
||||
# The linux kernel can generate a UEFI stub, however the one from systemd-boot can fetch
|
||||
# the command line from a separate section of the EFI application, avoiding the need to
|
||||
# rebuild the kernel.
|
||||
# - the kernel
|
||||
# - an initramfs (optional)
|
||||
|
||||
def create_uefiapp(d, uuid=None, app_suffix=''):
|
||||
import glob, re
|
||||
from subprocess import check_call
|
||||
|
||||
build_dir = d.getVar('B')
|
||||
deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
|
||||
image_link_name = d.getVar('IMAGE_LINK_NAME')
|
||||
|
||||
cmdline = '%s/cmdline.txt' % build_dir
|
||||
linux = '%s/%s' % (deploy_dir_image, d.getVar('KERNEL_IMAGETYPE'))
|
||||
initrd = '%s/initrd' % build_dir
|
||||
|
||||
stub_path = '%s/linux*.efi.stub' % deploy_dir_image
|
||||
stub = glob.glob(stub_path)[0]
|
||||
m = re.match(r"\S*(ia32|x64)(.efi)\S*", os.path.basename(stub))
|
||||
app = "boot%s%s%s" % (m.group(1), app_suffix, m.group(2))
|
||||
executable = '%s/%s.%s' % (deploy_dir_image, image_link_name, app)
|
||||
|
||||
if d.getVar('INITRD_LIVE'):
|
||||
with open(initrd, 'wb') as dst:
|
||||
for cpio in d.getVar('INITRD_LIVE').split():
|
||||
with open(cpio, 'rb') as src:
|
||||
dst.write(src.read())
|
||||
initrd_cmd = "--add-section .initrd=%s --change-section-vma .initrd=0x3000000 " % initrd
|
||||
else:
|
||||
initrd_cmd = ""
|
||||
|
||||
root = 'root=PARTUUID=%s' % uuid if uuid else ''
|
||||
|
||||
with open(cmdline, 'w') as f:
|
||||
f.write('%s %s' % (d.getVar('APPEND'), root))
|
||||
|
||||
objcopy_cmd = ("objcopy "
|
||||
"--add-section .cmdline=%s --change-section-vma .cmdline=0x30000 "
|
||||
"--add-section .linux=%s --change-section-vma .linux=0x40000 "
|
||||
"%s %s %s") % \
|
||||
(cmdline, linux, initrd_cmd, stub, executable)
|
||||
|
||||
check_call(objcopy_cmd, shell=True)
|
||||
|
||||
python create_uefiapps () {
|
||||
# We must clean up anything that matches the expected output pattern, to ensure that
|
||||
# the next steps do not accidentally use old files.
|
||||
import glob
|
||||
pattern = d.expand('${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.boot*.efi')
|
||||
for old_efi in glob.glob(pattern):
|
||||
os.unlink(old_efi)
|
||||
uuid = d.getVar('DISK_SIGNATURE_UUID')
|
||||
create_uefiapp(d, uuid=uuid)
|
||||
}
|
||||
|
||||
# This is intentionally split into different parts. This way, derived
|
||||
# classes or images can extend the individual parts. We can also use
|
||||
# whatever language (shell script or Python) is more suitable.
|
||||
python do_uefiapp() {
|
||||
bb.build.exec_func('create_uefiapps', d)
|
||||
}
|
||||
|
||||
do_uefiapp[vardeps] += "APPEND DISK_SIGNATURE_UUID INITRD_LIVE KERNEL_IMAGETYPE IMAGE_LINK_NAME"
|
||||
|
||||
uefiapp_deploy_at() {
|
||||
dest=$1
|
||||
for i in ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.boot*.efi; do
|
||||
target=`basename $i`
|
||||
target=`echo $target | sed -e 's/${IMAGE_LINK_NAME}.//'`
|
||||
cp --preserve=timestamps -r $i $dest/$target
|
||||
done
|
||||
}
|
||||
|
||||
fakeroot do_uefiapp_deploy() {
|
||||
rm -rf ${IMAGE_ROOTFS}/boot/*
|
||||
dest=${IMAGE_ROOTFS}/boot/EFI/BOOT
|
||||
mkdir -p $dest
|
||||
uefiapp_deploy_at $dest
|
||||
}
|
||||
|
||||
do_uefiapp_deploy[depends] += "${PN}:do_uefiapp virtual/fakeroot-native:do_populate_sysroot"
|
||||
|
||||
|
||||
# This decides when/how we add our tasks to the image
|
||||
python () {
|
||||
image_fstypes = d.getVar('IMAGE_FSTYPES', True)
|
||||
initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES', True)
|
||||
|
||||
# Don't add any of these tasks to initramfs images
|
||||
if initramfs_fstypes not in image_fstypes:
|
||||
bb.build.addtask('uefiapp', 'do_image', 'do_rootfs', d)
|
||||
bb.build.addtask('uefiapp_deploy', 'do_image', 'do_rootfs', d)
|
||||
}
|
||||
|
||||
SIGN_AFTER ?= "do_uefiapp"
|
||||
SIGN_BEFORE ?= "do_uefiapp_deploy"
|
||||
SIGNING_DIR ?= "${DEPLOY_DIR_IMAGE}"
|
||||
SIGNING_BINARIES ?= "${IMAGE_LINK_NAME}.boot*.efi"
|
||||
inherit uefi-sign
|
||||
|
||||
# Legacy hddimg support below this line
|
||||
efi_hddimg_populate() {
|
||||
uefiapp_deploy_at "$1"
|
||||
}
|
||||
|
||||
build_efi_cfg() {
|
||||
# The command line is built into the combo app, so this is a null op
|
||||
:
|
||||
}
|
||||
|
||||
populate_kernel_append() {
|
||||
# The kernel and initrd are built into the app, so we don't need these
|
||||
if [ -f $dest/initrd ]; then
|
||||
rm $dest/initrd
|
||||
fi
|
||||
if [ -f $dest/vmlinuz ]; then
|
||||
rm $dest/vmlinuz
|
||||
fi
|
||||
}
|
||||
|
||||
IMAGE_FEATURES[validitems] += "secureboot"
|
||||
@ -1,50 +0,0 @@
|
||||
# By default, sign all .efi binaries in ${B} after compiling and before deploying
|
||||
SIGNING_DIR ?= "${B}"
|
||||
SIGNING_BINARIES ?= "*.efi"
|
||||
SIGN_AFTER ?= "do_compile"
|
||||
SIGN_BEFORE ?= "do_deploy"
|
||||
|
||||
python () {
|
||||
import os
|
||||
import hashlib
|
||||
|
||||
# Ensure that if the signing key or cert change, we rerun the uefiapp process
|
||||
if bb.utils.contains('IMAGE_FEATURES', 'secureboot', True, False, d):
|
||||
for varname in ('SECURE_BOOT_SIGNING_CERT', 'SECURE_BOOT_SIGNING_KEY'):
|
||||
filename = d.getVar(varname)
|
||||
if filename is None:
|
||||
bb.fatal('%s is not set.' % varname)
|
||||
if not os.path.isfile(filename):
|
||||
bb.fatal('%s=%s is not a file.' % (varname, filename))
|
||||
with open(filename, 'rb') as f:
|
||||
data = f.read()
|
||||
hash = hashlib.sha256(data).hexdigest()
|
||||
d.setVar('%s_HASH' % varname, hash)
|
||||
|
||||
# Must reparse and thus rehash on file changes.
|
||||
bb.parse.mark_dependency(d, filename)
|
||||
|
||||
bb.build.addtask('uefi_sign', d.getVar('SIGN_BEFORE'), d.getVar('SIGN_AFTER'), d)
|
||||
|
||||
# Original binary needs to be regenerated if the hash changes since we overwrite it
|
||||
# SIGN_AFTER isn't necessarily when it gets generated, but its our best guess
|
||||
d.appendVarFlag(d.getVar('SIGN_AFTER'), 'vardeps', 'SECURE_BOOT_SIGNING_CERT_HASH SECURE_BOOT_SIGNING_KEY_HASH')
|
||||
}
|
||||
|
||||
do_uefi_sign() {
|
||||
if [ -f ${SECURE_BOOT_SIGNING_KEY} ] && [ -f ${SECURE_BOOT_SIGNING_CERT} ]; then
|
||||
for i in `find ${SIGNING_DIR}/ -name '${SIGNING_BINARIES}'`; do
|
||||
sbsign --key ${SECURE_BOOT_SIGNING_KEY} --cert ${SECURE_BOOT_SIGNING_CERT} $i
|
||||
sbverify --cert ${SECURE_BOOT_SIGNING_CERT} $i.signed
|
||||
mv $i.signed $i
|
||||
done
|
||||
fi
|
||||
}
|
||||
|
||||
do_uefi_sign[depends] += "sbsigntool-native:do_populate_sysroot"
|
||||
|
||||
do_uefi_sign[vardeps] += "SECURE_BOOT_SIGNING_CERT_HASH \
|
||||
SECURE_BOOT_SIGNING_KEY_HASH \
|
||||
SIGNING_BINARIES SIGNING_DIR \
|
||||
SIGN_BEFORE SIGN_AFTER \
|
||||
"
|
||||
@ -1,23 +0,0 @@
|
||||
# This file contains a list of recipe maintainers for meta-intel
|
||||
|
||||
RECIPE_MAINTAINER_pn-core-image-rt = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-core-image-rt-sdk = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-efilinux = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-gma500-gfx-check = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-intel-gpu-tools = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-intel-microcode = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-intel-minimal-initramfs = "California Sullivan <california.l.sullivan@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-iucode-tool = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-libva-intel-driver = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-libyami = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-libyami-utils = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-linux-intel = "California Sullivan <california.l.sullivan@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-linux-intel-rt = "California Sullivan <california.l.sullivan@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-lms7 = "TBD"
|
||||
RECIPE_MAINTAINER_pn-lms8 = "TBD"
|
||||
RECIPE_MAINTAINER_pn-rmc = "Todor Minchev <todor.minchev@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-rmc-db = "Todor Minchev <todor.minchev@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-thermald = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-va-intel = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-xf86-video-ast = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
RECIPE_MAINTAINER_pn-xf86-video-mga = "Alejandro Hernandez <alejandro.hernandez@intel.com>"
|
||||
@ -1,24 +0,0 @@
|
||||
# We have a conf and classes directory, add to BBPATH
|
||||
BBPATH .= ":${LAYERDIR}"
|
||||
|
||||
# We have recipes-* directories, add to BBFILES
|
||||
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
|
||||
${LAYERDIR}/recipes-*/*/*.bbappend"
|
||||
|
||||
BBFILE_COLLECTIONS += "intel"
|
||||
BBFILE_PATTERN_intel := "^${LAYERDIR}/"
|
||||
BBFILE_PRIORITY_intel = "5"
|
||||
|
||||
# Additional license directories.
|
||||
LICENSE_PATH += "${LAYERDIR}/custom-licenses"
|
||||
|
||||
LAYERDEPENDS_intel = "core"
|
||||
LAYERRECOMMENDS_intel = "dpdk intel-qat"
|
||||
|
||||
# This should only be incremented on significant changes that will
|
||||
# cause compatibility issues with other layers
|
||||
LAYERVERSION_intel = "5"
|
||||
LAYERSERIES_COMPAT_intel = "rocko"
|
||||
|
||||
|
||||
require ${LAYERDIR}/conf/include/maintainers.inc
|
||||
@ -1,15 +0,0 @@
|
||||
INTEL_COMMON_PACKAGE_ARCH ?= "${TUNE_PKGARCH}-intel-common"
|
||||
PACKAGE_ARCH_pn-linux-intel = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-intel-rt = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-intel-tiny = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-intel-dev = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-yocto = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-yocto-rt = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-yocto-tiny = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-linux-yocto-dev = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-intel-microcode = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-backport-iwlwifi = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-ixgbe = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_ARCH_pn-ixgbevf = "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
PACKAGE_EXTRA_ARCHS_append += "${INTEL_COMMON_PACKAGE_ARCH}"
|
||||
MACHINEOVERRIDES =. "${INTEL_COMMON_PACKAGE_ARCH}:"
|
||||
@ -1,7 +0,0 @@
|
||||
#
|
||||
# Common configuration for all MACHINEs of the intel-core2 type
|
||||
#
|
||||
|
||||
DEFAULTTUNE ?= "core2-32"
|
||||
require conf/machine/include/tune-core2.inc
|
||||
require conf/machine/include/x86-base.inc
|
||||
@ -1,7 +0,0 @@
|
||||
#
|
||||
# Common configuration for all MACHINES of the intel-corei7-64 type
|
||||
#
|
||||
|
||||
DEFAULTTUNE ?= "corei7-64"
|
||||
require conf/machine/include/tune-corei7.inc
|
||||
require conf/machine/include/x86-base.inc
|
||||
@ -1,12 +0,0 @@
|
||||
#
|
||||
# Common configuration for all MACHINES of the intel-quark type
|
||||
#
|
||||
|
||||
DEFAULTTUNE ?= "i586-nlp-32"
|
||||
require conf/machine/include/tune-i586-nlp.inc
|
||||
require conf/machine/include/x86-base.inc
|
||||
|
||||
# gnutls padlock code uses CMOV instruction in assembly which
|
||||
# is not valid for Quark.
|
||||
EXTRA_OECONF_append_pn-gnutls_intel-quark = " --disable-padlock"
|
||||
EXTRA_OECONF_append_pn-openssl_intel-quark = " no-asm"
|
||||
@ -1,53 +0,0 @@
|
||||
#
|
||||
# BSP variables and settings specific to the meta-intel layer.
|
||||
# You must include the meta-intel layer in your bblayers.conf
|
||||
# to use them.
|
||||
#
|
||||
|
||||
#
|
||||
# XSERVER subcomponents, used to build the XSERVER variable
|
||||
#
|
||||
|
||||
# Soft set linux-yocto as preferred kernel like x86-base.inc
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-intel"
|
||||
PREFERRED_PROVIDER_virtual/kernel_poky-tiny ?= "linux-intel"
|
||||
PREFERRED_PROVIDER_virtual/kernel_linuxstdbase ?= "linux-yocto"
|
||||
PREFERRED_VERSION_linux-intel ?= "4.9%"
|
||||
|
||||
# for Xserver older than 1.13.0
|
||||
OLD_XSERVER_X86_EXT = "xserver-xorg-extension-dri \
|
||||
xserver-xorg-extension-dri2 \
|
||||
xserver-xorg-extension-extmod \
|
||||
xserver-xorg-extension-dbe \
|
||||
"
|
||||
|
||||
XSERVER_X86_MATROX_MGA = "xf86-video-mga \
|
||||
"
|
||||
|
||||
XSERVER_X86_ASPEED_AST = "xf86-video-ast \
|
||||
"
|
||||
|
||||
# include the user space intel microcode loading support in the generated images.
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', ' intel-microcode', '', d)} thermald"
|
||||
|
||||
# recommended extra packages common to all intel machines
|
||||
MACHINE_EXTRA_RRECOMMENDS_append = " kernel-modules linux-firmware"
|
||||
|
||||
# for the early boot time kernel microcode loading support,
|
||||
# merge the microcode data in the final initrd image.
|
||||
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
|
||||
|
||||
DISK_SIGNATURE_UUID ??= "deadbeef-dead-beef-dead-beefdeadbeef"
|
||||
|
||||
EFI_PROVIDER ?= "rmc-boot"
|
||||
EFI_PROVIDER_x86-x32 = "grub-efi"
|
||||
|
||||
# Add general MACHINEOVERRIDE for meta-intel
|
||||
MACHINEOVERRIDES =. "intel-x86-common:"
|
||||
|
||||
# Definition of (more or less) suitable virtual machines.
|
||||
require conf/machine/include/qemuboot-intel.inc
|
||||
|
||||
# Ensure that the extra tools needed by qemu are built when building images
|
||||
# and tweak machine definition to make the result more usable under qemu.
|
||||
require conf/machine/include/qemu-intel.inc
|
||||
@ -1,19 +0,0 @@
|
||||
# Similar to meta/conf/machine/include/qemu.inc but influences the
|
||||
# distro content (in particular the kernel) less than qemu.inc.
|
||||
|
||||
# Ensure that qemu gets built when building images.
|
||||
EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
|
||||
|
||||
# Build ovmf firmware for uefi support in qemu.
|
||||
EXTRA_IMAGEDEPENDS += "ovmf"
|
||||
|
||||
# runqemu uses virtio, so we have to enable the corresponding
|
||||
# kernel drivers.
|
||||
KERNEL_FEATURES_INTEL_COMMON += "cfg/virtio.scc"
|
||||
|
||||
# Other useful extensions which are not enabled by default:
|
||||
# rng-tools to take advantage of qemu's virtio-rng-pci device.
|
||||
# MACHINE_EXTRA_RRECOMMENDS += "rng-tools"
|
||||
|
||||
# Creates the necessary .qemuboot.conf file for each image.
|
||||
IMAGE_CLASSES += "qemuboot"
|
||||
@ -1,19 +0,0 @@
|
||||
# For runqemu
|
||||
IMAGE_CLASSES += "qemuboot"
|
||||
QB_SYSTEM_NAME_intel-core2-32 = "qemu-system-i386"
|
||||
QB_CPU_intel-core2-32 = "-cpu coreduo"
|
||||
QB_CPU_KVM_intel-core2-32 = "-cpu kvm32"
|
||||
|
||||
QB_SYSTEM_NAME_intel-corei7-64 = "qemu-system-x86_64"
|
||||
QB_CPU_intel-corei7-64 = "-cpu Nehalem"
|
||||
QB_CPU_KVM_intel-corei7-64 = "-cpu kvm64"
|
||||
|
||||
QB_SYSTEM_NAME_intel-quark = "qemu-system-i386"
|
||||
QB_CPU_intel-quark = "-cpu coreduo"
|
||||
QB_CPU_KVM_intel-quark = "-cpu kvm32"
|
||||
|
||||
QB_AUDIO_DRV = "alsa"
|
||||
QB_AUDIO_OPT = "-soundhw ac97,es1370"
|
||||
QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
|
||||
# Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
|
||||
QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
|
||||
@ -1,35 +0,0 @@
|
||||
#@TYPE: Machine
|
||||
#@NAME: intel-core2-32
|
||||
|
||||
#@DESCRIPTION: Machine configuration for 32 bit Intel Core 2 CPU (and later) with MMX, SSE, SSE2, SSE3, and SSSE3 instruction set support. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware.
|
||||
|
||||
require conf/machine/include/meta-intel.inc
|
||||
require conf/machine/include/intel-core2-32-common.inc
|
||||
require conf/machine/include/intel-common-pkgarch.inc
|
||||
|
||||
MACHINE_FEATURES += "pcbios efi"
|
||||
MACHINE_FEATURES += "va-impl-intel"
|
||||
MACHINE_FEATURES += "wifi 3g nfc"
|
||||
MACHINE_FEATURES += "intel-ucode"
|
||||
|
||||
MACHINE_HWCODECS ?= "va-intel gstreamer1.0-vaapi"
|
||||
|
||||
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "gma500-gfx-check"
|
||||
|
||||
XSERVER ?= "${XSERVER_X86_BASE} \
|
||||
${XSERVER_X86_EXT} \
|
||||
${XSERVER_X86_FBDEV} \
|
||||
${XSERVER_X86_I915} \
|
||||
${XSERVER_X86_I965} \
|
||||
${XSERVER_X86_MODESETTING} \
|
||||
${XSERVER_X86_VESA} \
|
||||
${XSERVER_X86_ASPEED_AST} \
|
||||
"
|
||||
|
||||
SYSLINUX_OPTS = "serial 0 115200"
|
||||
SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyPCH0"
|
||||
APPEND += "rootwait console=ttyS0,115200 console=ttyPCH0,115200 console=tty0"
|
||||
|
||||
IMAGE_FSTYPES += "wic"
|
||||
WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", "systemd-bootdisk.wks", "mkefidisk.wks", d)}"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
|
||||
@ -1,46 +0,0 @@
|
||||
#@TYPE: Machine
|
||||
#@NAME: intel-corei7-64
|
||||
|
||||
#@DESCRIPTION: Machine configuration for 64 bit Intel Core i7 CPU (and later) with MMX, SSE, SSE2, SSE3, and SSSE3 instruction set support. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware.
|
||||
|
||||
require conf/machine/include/meta-intel.inc
|
||||
require conf/machine/include/intel-corei7-64-common.inc
|
||||
require conf/machine/include/intel-common-pkgarch.inc
|
||||
|
||||
MACHINE_FEATURES += "pcbios efi"
|
||||
MACHINE_FEATURES += "va-impl-intel"
|
||||
MACHINE_FEATURES += "wifi 3g nfc"
|
||||
MACHINE_FEATURES += "intel-ucode"
|
||||
|
||||
MACHINE_HWCODECS ?= "va-intel gstreamer1.0-vaapi"
|
||||
|
||||
MACHINE_EXTRA_RRECOMMENDS += "lms8"
|
||||
|
||||
# Enable optional dpdk:
|
||||
COMPATIBLE_MACHINE_pn-dpdk = "intel-corei7-64"
|
||||
COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = "intel-corei7-64"
|
||||
DPDK_TARGET_MACHINE ?= "atm"
|
||||
|
||||
# Enable optional QAT items:
|
||||
COMPATIBLE_MACHINE_pn-openssl-qat = "intel-corei7-64"
|
||||
COMPATIBLE_MACHINE_pn-qat16 = "intel-corei7-64"
|
||||
COMPATIBLE_MACHINE_pn-zlib-qat = "intel-corei7-64"
|
||||
|
||||
XSERVER ?= "${XSERVER_X86_BASE} \
|
||||
${XSERVER_X86_EXT} \
|
||||
${XSERVER_X86_FBDEV} \
|
||||
${XSERVER_X86_I915} \
|
||||
${XSERVER_X86_I965} \
|
||||
${XSERVER_X86_MATROX_MGA} \
|
||||
${XSERVER_X86_MODESETTING} \
|
||||
${XSERVER_X86_VESA} \
|
||||
${XSERVER_X86_ASPEED_AST} \
|
||||
"
|
||||
|
||||
SYSLINUX_OPTS = "serial 0 115200"
|
||||
SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2"
|
||||
APPEND += "rootwait console=ttyS0,115200 console=tty0"
|
||||
|
||||
IMAGE_FSTYPES += "wic"
|
||||
WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", "systemd-bootdisk.wks", "mkefidisk.wks", d)}"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
|
||||
@ -1,33 +0,0 @@
|
||||
#@TYPE: Machine
|
||||
#@NAME: quark
|
||||
|
||||
#@DESCRIPTION: Machine configuration for Quark systems
|
||||
|
||||
require conf/machine/include/meta-intel.inc
|
||||
require conf/machine/include/intel-quark-common.inc
|
||||
require conf/machine/include/intel-common-pkgarch.inc
|
||||
|
||||
#Avoid pulling in GRUB
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
|
||||
|
||||
MACHINE_FEATURES = "efi usb"
|
||||
MACHINE_FEATURES += "intel-ucode"
|
||||
|
||||
SERIAL_CONSOLE = "115200 ttyS1"
|
||||
APPEND += "rootwait console=ttyS1,115200 console=tty0"
|
||||
|
||||
# Bypass the default labels which also has "install" option in OE.
|
||||
#
|
||||
# We don't need to do this when constructing direct-boot image with
|
||||
# wic. But EFI installer in hddimg image doesn't work on quark now,
|
||||
# so we only provide a live-boot entry in boot menu for images in
|
||||
# hddimg format.
|
||||
|
||||
LABELS_LIVE = "boot"
|
||||
|
||||
# Ensure that the Lock prefix is omitted for the kernel"
|
||||
KERNEL_EXTRA_ARGS = "EXTRA_CFLAGS=-Wa,-momit-lock-prefix=yes"
|
||||
|
||||
IMAGE_FSTYPES += "wic"
|
||||
WKS_FILE ?= "galileodisk-sd.wks"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
|
||||
@ -1,30 +0,0 @@
|
||||
Copyright (C) 2004-2012 Intel Corporation. All rights reserved.
|
||||
|
||||
• This license covers the sources of the Local Manageability Service (LMS).
|
||||
For licensing information for the LMS build scripts, please refer to the file build_script_license.txt.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions are met:
|
||||
|
||||
- Redistributions of source code must retain the above copyright notice,
|
||||
this list of conditions and the following disclaimer.
|
||||
|
||||
- Redistributions in binary form must reproduce the above copyright notice,
|
||||
this list of conditions and the following disclaimer in the documentation
|
||||
and/or other materials provided with the distribution.
|
||||
|
||||
- Neither the name of Intel Corporation. nor the names of its
|
||||
contributors may be used to endorse or promote products derived from this
|
||||
software without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''
|
||||
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
ARE DISCLAIMED. IN NO EVENT SHALL Intel Corporation. OR THE CONTRIBUTORS
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
||||
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
||||
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
||||
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
||||
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
||||
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
@ -1,123 +0,0 @@
|
||||
INTEL SOFTWARE LICENSE AGREEMENT
|
||||
|
||||
IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING.
|
||||
Do not use or load this software and any associated materials (collectively,
|
||||
the "Software") until you have carefully read the following terms and
|
||||
conditions. By loading or using the Software, you agree to the terms of this
|
||||
Agreement. If you do not wish to so agree, do not install or use the Software.
|
||||
|
||||
LICENSES: Please Note:
|
||||
- If you are a network administrator, the "Site License" below shall
|
||||
apply to you.
|
||||
- If you are an end user, the "Single User License" shall apply to you.
|
||||
- If you are an original equipment manufacturer (OEM), the "OEM License"
|
||||
shall apply to you.
|
||||
|
||||
SITE LICENSE. You may copy the Software onto your organization's computers
|
||||
for your organization's use, and you may make a reasonable number of
|
||||
back-up copies of the Software, subject to these conditions:
|
||||
|
||||
1. This Software is licensed for use only in conjunction with Intel
|
||||
component products. Use of the Software in conjunction with non-Intel
|
||||
component products is not licensed hereunder.
|
||||
2. You may not copy, modify, rent, sell, distribute or transfer any part
|
||||
of the Software except as provided in this Agreement, and you agree to
|
||||
prevent unauthorized copying of the Software.
|
||||
3. You may not reverse engineer, decompile, or disassemble the Software.
|
||||
4. You may not sublicense or permit simultaneous use of the Software by
|
||||
more than one user.
|
||||
5. The Software may include portions offered on terms in addition to those
|
||||
set out here, as set out in a license accompanying those portions.
|
||||
|
||||
SINGLE USER LICENSE. You may copy the Software onto a single computer for
|
||||
your personal, noncommercial use, and you may make one back-up copy of the
|
||||
Software, subject to these conditions:
|
||||
|
||||
1. This Software is licensed for use only in conjunction with Intel
|
||||
component products. Use of the Software in conjunction with non-Intel
|
||||
component products is not licensed hereunder.
|
||||
2. You may not copy, modify, rent, sell, distribute or transfer any part
|
||||
of the Software except as provided in this Agreement, and you agree to
|
||||
prevent unauthorized copying of the Software.
|
||||
3. You may not reverse engineer, decompile, or disassemble the Software.
|
||||
4. You may not sublicense or permit simultaneous use of the Software by
|
||||
more than one user.
|
||||
5. The Software may include portions offered on terms in addition to those
|
||||
set out here, as set out in a license accompanying those portions.
|
||||
|
||||
OEM LICENSE: You may reproduce and distribute the Software only as an
|
||||
integral part of or incorporated in Your product or as a standalone
|
||||
Software maintenance update for existing end users of Your products,
|
||||
excluding any other standalone products, subject to these conditions:
|
||||
|
||||
1. This Software is licensed for use only in conjunction with Intel
|
||||
component products. Use of the Software in conjunction with non-Intel
|
||||
component products is not licensed hereunder.
|
||||
2. You may not copy, modify, rent, sell, distribute or transfer any part
|
||||
of the Software except as provided in this Agreement, and you agree to
|
||||
prevent unauthorized copying of the Software.
|
||||
3. You may not reverse engineer, decompile, or disassemble the Software.
|
||||
4. You may only distribute the Software to your customers pursuant to a
|
||||
written license agreement. Such license agreement may be a "break-the-
|
||||
seal" license agreement. At a minimum such license shall safeguard
|
||||
Intel's ownership rights to the Software.
|
||||
5. The Software may include portions offered on terms in addition to those
|
||||
set out here, as set out in a license accompanying those portions.
|
||||
|
||||
NO OTHER RIGHTS. No rights or licenses are granted by Intel to You, expressly
|
||||
or by implication, with respect to any proprietary information or patent,
|
||||
copyright, mask work, trademark, trade secret, or other intellectual property
|
||||
right owned or controlled by Intel, except as expressly provided in this
|
||||
Agreement.
|
||||
|
||||
OWNERSHIP OF SOFTWARE AND COPYRIGHTS. Title to all copies of the Software
|
||||
remains with Intel or its suppliers. The Software is copyrighted and
|
||||
protected by the laws of the United States and other countries, and
|
||||
international treaty provisions. You may not remove any copyright notices
|
||||
from the Software. Intel may make changes to the Software, or to items
|
||||
referenced therein, at any time without notice, but is not obligated to
|
||||
support or update the Software. Except as otherwise expressly provided, Intel
|
||||
grants no express or implied right under Intel patents, copyrights,
|
||||
trademarks, or other intellectual property rights. You may transfer the
|
||||
Software only if the recipient agrees to be fully bound by these terms and if
|
||||
you retain no copies of the Software.
|
||||
|
||||
LIMITED MEDIA WARRANTY. If the Software has been delivered by Intel on
|
||||
physical media, Intel warrants the media to be free from material physical
|
||||
defects for a period of ninety days after delivery by Intel. If such a defect
|
||||
is found, return the media to Intel for replacement or alternate delivery of
|
||||
the Software as Intel may select.
|
||||
|
||||
EXCLUSION OF OTHER WARRANTIES. EXCEPT AS PROVIDED ABOVE, THE SOFTWARE IS
|
||||
PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND
|
||||
INCLUDING WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, OR FITNESS FOR A
|
||||
PARTICULAR PURPOSE. Intel does not warrant or assume responsibility for the
|
||||
accuracy or completeness of any information, text, graphics, links or other
|
||||
items contained within the Software.
|
||||
|
||||
LIMITATION OF LIABILITY. IN NO EVENT SHALL INTEL OR ITS SUPPLIERS BE LIABLE
|
||||
FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, LOST PROFITS,
|
||||
BUSINESS INTERRUPTION, OR LOST INFORMATION) ARISING OUT OF THE USE OF OR
|
||||
INABILITY TO USE THE SOFTWARE, EVEN IF INTEL HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES. SOME JURISDICTIONS PROHIBIT EXCLUSION OR
|
||||
LIMITATION OF LIABILITY FOR IMPLIED WARRANTIES OR CONSEQUENTIAL OR INCIDENTAL
|
||||
DAMAGES, SO THE ABOVE LIMITATION MAY NOT APPLY TO YOU. YOU MAY ALSO HAVE
|
||||
OTHER LEGAL RIGHTS THAT VARY FROM JURISDICTION TO JURISDICTION.
|
||||
|
||||
TERMINATION OF THIS AGREEMENT. Intel may terminate this Agreement at any time
|
||||
if you violate its terms. Upon termination, you will immediately destroy the
|
||||
Software or return all copies of the Software to Intel.
|
||||
|
||||
APPLICABLE LAWS. Claims arising under this Agreement shall be governed by the
|
||||
laws of California, excluding its principles of conflict of laws and the
|
||||
United Nations Convention on Contracts for the Sale of Goods. You may not
|
||||
export the Software in violation of applicable export laws and regulations.
|
||||
Intel is not obligated under any other agreements unless they are in writing
|
||||
and signed by an authorized representative of Intel.
|
||||
|
||||
GOVERNMENT RESTRICTED RIGHTS. The Software is provided with "RESTRICTED
|
||||
RIGHTS." Use, duplication, or disclosure by the Government is subject to
|
||||
restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its
|
||||
successor. Use of the Software by the Government constitutes acknowledgment
|
||||
of Intel's proprietary rights therein. Contractor or Manufacturer is Intel
|
||||
2200 Mission College Blvd., Santa Clara, CA 95052.
|
||||
@ -1,382 +0,0 @@
|
||||
Runtime Machine Configuration (RMC)
|
||||
--------------------------------------------------------------------------------
|
||||
Table of Contents
|
||||
|
||||
Introduction
|
||||
Usage
|
||||
Enable RMC Feature
|
||||
Examples
|
||||
Troubleshooting
|
||||
When you (don't) need RMC feature
|
||||
|
||||
|
||||
Introduction:
|
||||
--------------------------------------------------------------------------------
|
||||
RMC Project - a light-weight project provide developers a mechanism to keep
|
||||
their software implementation board-type agnostic, yet still able to customize
|
||||
software behavior according to the type of a running board at runtime. Recipes
|
||||
and bbclasses are available for other components to reuse to construct their own
|
||||
RMC database.
|
||||
|
||||
RMC Feature - An end-to-end solution based on RMC project to have a generic
|
||||
image capable to apply board-type-specific quirks and configurations for a board
|
||||
at runtime. It consists of a modified bootloader (systemd-boot), an updated EFI
|
||||
installer, recipes, bbclass and RMC project.
|
||||
|
||||
RMC feature supports special customizations cannot be covered by conventional
|
||||
auto-detection features based on probing a hardware module because they happen
|
||||
at a board or a product level. For example:
|
||||
- tty console for kernel log output in kernel cmdline
|
||||
- default audio route configuration
|
||||
- network configuration
|
||||
- UI layout
|
||||
- requirement to software driven by a mechanical design
|
||||
- or static configuration bits for a physical bus that doesn't support to
|
||||
identify devices or their presence at runtime
|
||||
|
||||
An image with the feature has ability to configure supported boards with data
|
||||
associated only to a type of board to get full functionality of the target at
|
||||
runtime, yet still with a single image.
|
||||
|
||||
Effect after installation is identical to what a conventional image specially
|
||||
customized for a type of board (depending on the way to deploy image).
|
||||
|
||||
Main functions of RMC Feature:
|
||||
|
||||
Show board-specific boot entries in boot menu and boot system with configuration
|
||||
(boot title, boot options, etc) in a selected boot entry.
|
||||
|
||||
Support a "global" kernel boot command line fragment which is effective for all
|
||||
boot entries.
|
||||
|
||||
Deploy file blobs and create directories specific to the type of running board.
|
||||
|
||||
Beside from this document, you can also find several built-in examples in
|
||||
common/recipes-bsp/rmc/boards/. Refer to "Examples" section.
|
||||
|
||||
You can also add new board types in your layer via a simple variable.
|
||||
|
||||
|
||||
|
||||
Usage
|
||||
--------------------------------------------------------------------------------
|
||||
Developers are suggested to organize all board-specific files in their own layer
|
||||
following this example, so that RMC recipes can pick up them correctly in build.
|
||||
|
||||
- my_top_dir/ Top directory of your board (Note 0)
|
||||
|- rmc-db.bbappend bbappend file to rmc-db recipe at a lower level
|
||||
|- rmc/
|
||||
|- target_board_1/ subdirectory of a board.
|
||||
| |- board1.fp fingerprint file must be provided (NOTE 1)
|
||||
| |- BOOTENTRY.CONFIG optional config file for boot entries. (NOTE 2)
|
||||
| |- INSTALLER.CONFIG optional config file for installer. (NOTE 3)
|
||||
| |- POSTINSTALL.sh optional script hook for installer (NOTE 4)
|
||||
| |- board_file_1 A file blob specific to the type of board
|
||||
| |- board_file_2 An another file specific to the type of board
|
||||
| |- ...more files
|
||||
|- target_board_2/ subdirectory of another board.
|
||||
|- board_2_v2.fp fingerprint file for board 2.
|
||||
|- BOOTENTRY.CONFIG
|
||||
|- INSTALLER.CONFIG
|
||||
|- board_file_1
|
||||
|- ...more files
|
||||
|
||||
Note 0:
|
||||
Developers are expected to use variable RMC_BOARD_DATA_DIRS to specify data of
|
||||
boards packed into RMC database file generated in a build. The default value of
|
||||
the variable in meta-intel specifies a group of boards. They work as examples
|
||||
and necessary quirks for these boards to function properly. Developers can
|
||||
override, append to the default boards with data of their own boards in the
|
||||
database file, or even disable the generation of the database file.
|
||||
|
||||
For example, in your local.conf file:
|
||||
|
||||
This line adds your boards along with the default boards into RMC database file,
|
||||
assuming you have a directory named "rmc" which has a subdirectory for each
|
||||
board:
|
||||
|
||||
RMC_BOARD_DATA_DIRS_append = " /path_of/rmc"
|
||||
|
||||
This line directs RMC to pack data of your boards only, without data of the
|
||||
default boards in meta-intel:
|
||||
|
||||
RMC_BOARD_DATA_DIRS = "/path_of/rmc"
|
||||
|
||||
And this line disables database generation:
|
||||
|
||||
RMC_BOARD_DATA_DIRS = ""
|
||||
|
||||
Please also refer to the "Example 1" in this document.
|
||||
|
||||
Subdirectory is not supported in a board's directory.
|
||||
|
||||
Note 1:
|
||||
Fingerprint files must be provided and with ".fp" at the end of their names.
|
||||
Fingerprint can be obtained by running RMC tool on your board. An easy way is to
|
||||
live-boot USB stick flashed with any image enabled this feature on your board,
|
||||
then run this command:
|
||||
|
||||
# rmc -F -o my_board.fp
|
||||
|
||||
Or you will need to build RMC tool for the architecture of your board, 32 or
|
||||
64 bit x86, from RMC project.
|
||||
|
||||
You can run RMC tool without any argument to get usage and examples.
|
||||
|
||||
DO NOT NAME ANY FILE ENDING WITH '.fp' IF IT IS NOT A RMC FINGERPRINT FILE.
|
||||
|
||||
If you do need a .fp file deployed onto target, please rename it in source and
|
||||
specify the real name of file on target in INSTALLER.CONFIG.
|
||||
|
||||
Note 2:
|
||||
At runtime, RMC bootloader tries to fetch this file specific to the board at run
|
||||
time, then tries to fetch each boot entry file specified in BOOTENTRY.CONFIG and
|
||||
show them in boot menu options. The format of this file is very simple. Each
|
||||
line is the name of a boot entry file:
|
||||
|
||||
boot.conf
|
||||
Install.conf
|
||||
myrmcboot.conf
|
||||
|
||||
Name of a boot entry file is defined by developer so it can be anything. But the
|
||||
name of config file is what RMC bootloader looks up in RMC database, so it must
|
||||
be named BOOTENTRY.CONFIG.
|
||||
|
||||
Bootloader skips loading entry conf files from disk once any entry is loaded
|
||||
from RMC database.
|
||||
|
||||
Note 3:
|
||||
At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to the
|
||||
board, then tries to fetch each file specified in this config file, and then
|
||||
deploy the file onto target with its permissions, UID, GID and other attributes
|
||||
also specified in this config file if file for the board can be retrieved from
|
||||
RMC database. The format of this file is (# is for comment line)
|
||||
|
||||
# name:uid:gid:mode:path_on_target
|
||||
# to create a directory, add a “/” at the end of path_on_target:
|
||||
audio_policy:0:0:600:/etc/audio/
|
||||
audio_def_policy:0:0:600:/etc/audio/audio_policy
|
||||
|
||||
The above example creates /etc/audio directory first, then fetch a file named
|
||||
“audio_def_policy” from RMC database for the board, then copy it to /etc/audio/
|
||||
with a new name “audio_policy”.
|
||||
|
||||
If this config file is not provided, No data in RMC database is deployed to the
|
||||
target.
|
||||
|
||||
Some steps defined by developers could not be supported on a filesystem.
|
||||
Installer simply ignores any errors in RMC deployment stage.
|
||||
|
||||
The name of this config file is what installer looks up first, so it must be
|
||||
INSTALLER.CONFIG.
|
||||
|
||||
Note 4:
|
||||
At the end of RMC deployment during installation, RMC installer queries a script
|
||||
file POSTINSTALL.sh from RMC database file, and execute it when query is
|
||||
successful on the running board. This hook provides developers almost ultimate
|
||||
flexibility to retouch what have been deployed on the target. There are some
|
||||
steps still can override results from this hook for boot entries and KBOOTPARAM.
|
||||
|
||||
|
||||
|
||||
Enable RMC Feature
|
||||
--------------------------------------------------------------------------------
|
||||
To enable the RMC feature please add the following variables to your local.conf.
|
||||
|
||||
DISTRO_FEATURES_append = " rmc"
|
||||
EFI_PROVIDER = "rmc-boot"
|
||||
|
||||
The default EFI bootloader used with RMC is systemd-boot. To change the default
|
||||
bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
|
||||
|
||||
Note:
|
||||
Image could be still bootable if you only have either of two lines, but RMC
|
||||
feature could not be fully functional, depending on the availability of the
|
||||
database file, installer and the rmc tool.
|
||||
|
||||
Examples
|
||||
--------------------------------------------------------------------------------
|
||||
We checked in configuration data in common/recipes-bsp/rmc/boards/ for several
|
||||
boards, to help users to understand the RMC feature. These examples are also for
|
||||
validation. For any example you find not working as what this section depicts,
|
||||
it should be treated as a bug to be fixed.
|
||||
|
||||
To test this feature with examples, enable it and build an image first, then
|
||||
boot the built image on supported boards. Examples are always built in when the
|
||||
feature is enabled, except for the EXAMPLE 1.
|
||||
|
||||
EXAMPLE 1: Support a new board type:
|
||||
(1) enable the feature and do a build to get a live-boot image by adding these
|
||||
lines in conf/local.conf:
|
||||
DISTRO_FEATURES_append = " rmc"
|
||||
EFI_PROVIDER = "rmc-boot"
|
||||
|
||||
(2) flash the image to a USB stick and boot it on your board
|
||||
|
||||
(3) in super user mode, run "rmc -F -o my_board.fp"
|
||||
|
||||
(4) create directories in your host "mkdir -p my_top_dir/my_rmc/my_board"
|
||||
|
||||
(5) copy my_board.fp from target to my_top_dir/my_rmc/my_board/ on host
|
||||
|
||||
(6) create a file my_top_dir/my_rmc/my_board/KBOOTPARAM, put some fake
|
||||
and harmless options in a single line, say, "loglevel=7"
|
||||
|
||||
(7) create a file my_top_dir/rmc-db.bbappend, put this single line in it:
|
||||
RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/my_rmc"
|
||||
From parent directory of my_top_dir, the tree should look like:
|
||||
my_top_dir/
|
||||
my_rmc/
|
||||
my_board/
|
||||
KBOOTPARAM
|
||||
my_board.fp
|
||||
rmc-db.bbappend
|
||||
Later, you can add more board directories in my_rmc directory.
|
||||
|
||||
(8) modify build configuration to add my_top_dir into build, for example, put
|
||||
this line in a bblayers.conf:
|
||||
BBFILES += "/full/path/of/my_top_dir/rmc-db.bbappend"
|
||||
|
||||
(9) build image again then boot it on your board
|
||||
|
||||
(10) Once you login to shell, new options should be effective, run this command
|
||||
"cat /proc/cmdline" to verify the result.
|
||||
|
||||
EXAMPLE 2: Board-specific boot entry
|
||||
MinnowBoard MAX and B3 version:
|
||||
common/recipes-bsp/rmc/boards/minnowmax
|
||||
common/recipes-bsp/rmc/boards/minnowmaxB3
|
||||
|
||||
We have found two identities (type of board) exist for the "same" Minnow Max
|
||||
hardware, so they have to be treated as two different types of hardware. The two
|
||||
examples show you a boot entry specific to a type of board. Titles shown in boot
|
||||
menu have different names according to the type of running board, "Minnow Max
|
||||
boot" or "Minnow Max B3 boot". in /proc/cmdline, "console=ttyS0,115200n8" shall
|
||||
be there. Kernel prints logs from 6-pin FTDI serial port on Minnow Max(s). This
|
||||
console setting is in board-specific entries, so you won't see it effective if
|
||||
you select default "boot" entry to boot the device.
|
||||
|
||||
EXAMPLE 3: Board-specific boot entry, global kernel cmdline and installer
|
||||
NUC Gen 6:
|
||||
common/recipes-bsp/rmc/boards/nucgen6
|
||||
This is a combo example with all supported configuration data for NUC Gen 6
|
||||
product. It shows two boot entries in bootloader menu when you boot image on NUC
|
||||
Gen 6 product, with "NUC Gen6" in entry titles. There shall no any "console=" in
|
||||
/proc/cmdline when you boot with either of two "NUC Gen6"entries. We designed it
|
||||
this way because there is no accessible tty port on NUC Gen 6 with housing. The
|
||||
post-install hook is also provided in this example.
|
||||
|
||||
This example also includes a global kernel cmdline fragment KBOOTPARAM. Content
|
||||
of KBOOTPARAM shall be at the end of /proc/cmdline no matter which boot entry
|
||||
you selected to boot NUC Gen6.
|
||||
|
||||
INSTALLER.CONFIG directs installer to create a directory and deploy a file in it
|
||||
when install the image on NUC Gen6.
|
||||
|
||||
Choose "NUC Gen6 install" boot entry to boot shall start installation. Once
|
||||
the device reboots after installation, we can verify the configurations.
|
||||
|
||||
The boot entry "NUC Gen6 boot" shall be shown in boot menu.
|
||||
|
||||
The content of KBOOTPARAM shall be in /proc/cmdline too.
|
||||
|
||||
A directory /etc/mylib/ is created and a file "mylib.conf" is there. The content
|
||||
of that file shall be what we put in mylib.conf in
|
||||
common/recipes-bsp/rmc/boards/nucgen6
|
||||
|
||||
POSTINSTALL.sh shows how we get rid of an error message caused by no serial
|
||||
console available on NUC Gen 6, without creating another static board
|
||||
configuration.
|
||||
|
||||
EXAMPLE 4: For validation only
|
||||
T100 (32bit):
|
||||
common/recipes-bsp/rmc/boards/T100-32bit
|
||||
This example is provided for validation on 32 bit X86 architecture. It doesn't
|
||||
provide any new function not mentioned in above examples.
|
||||
|
||||
EXAMPLE 5: RMC for quark
|
||||
Galileo Gen 2
|
||||
common/recipes-bsp/rmc/boards/Galileo2
|
||||
This example doesn't show any feature not covered in the above examples. Note
|
||||
RMC only supports hddimg image format so far. Please refer to the section II.c
|
||||
in README in meta-intel for how to boot Galileo with images in hddimg format.
|
||||
Bootloader should show a board-specific boot option "Galileo Gen 2 boot" when
|
||||
the board boots off.
|
||||
|
||||
Troubleshooting
|
||||
--------------------------------------------------------------------------------
|
||||
Issue: Cannot obtain RMC fingerprint for a board
|
||||
|
||||
RMC tool requires UEFI BIOS and SMBIOS support in firmware. It doesn't support
|
||||
other type of firmware, e.g. legacy BIOS. It also requires EFI driver enabled
|
||||
in Linux kernel.
|
||||
|
||||
Issue: Configuration for a board seems not effective at runtime.
|
||||
|
||||
Check if board is booted from the storage where the image or installation lives
|
||||
when you have multiple boot options in BIOS. On some old hardwares it is not
|
||||
that obvious as you assume. A build image can support boot from both of legacy
|
||||
and UEFI mode, but RMC only works with UEFI boot so far.
|
||||
|
||||
Make sure configuration files (BOOTENTRY.CONFIG, INSTALLER.CONFIG and,
|
||||
KBOOTPARAM ...) are properly named in the board directory.
|
||||
|
||||
Make sure configuration files have correct contents.
|
||||
|
||||
Some file attributes could not be supported by targeted file system. Installer
|
||||
cannot setup file blobs as you wish. It simply move to the next step if a step
|
||||
fails.
|
||||
|
||||
Kernel command line can be customized globally with KBOOTPARAM or just in a boot
|
||||
entry for the type of board. They have different effective scopes.
|
||||
|
||||
If no any board-specific configuration becomes effective on your board but it
|
||||
works on other boards of same product, you can run rmc tool to obtain
|
||||
fingerprint file on your board and compare it with fingerprint of a working
|
||||
board. It is possible they have different firmware versions and unluckily, some
|
||||
information for fingerprint changes between two versions. You can update BIOS
|
||||
on every board to the same BIOS version if it is feasible. Otherwise you have
|
||||
to treat them as two different type of boards. We could extend rmc design to
|
||||
allow multiple fingerprints in a board directory as a workaround.
|
||||
|
||||
Issue: RMC reports error because it cannot find fingerprint when building image.
|
||||
|
||||
Make sure you have a fingerprint file. Its name must be ended with '.fp'. You
|
||||
can put a fingerprint file in a board directory and provide data later.
|
||||
|
||||
Issue: Any problems the above troubleshooting cannot help
|
||||
|
||||
Please report it to us. Extra information like the type of your board or a dump
|
||||
file from dmidecode tool is helpful. We will investigate the problem and keep
|
||||
improving this feature.
|
||||
|
||||
|
||||
|
||||
|
||||
When you (don't) need RMC feature
|
||||
--------------------------------------------------------------------------------
|
||||
RMC feature is designed to as generic as possible, in order to support a large
|
||||
number of types of boards. And it shall be designed not to break things when it
|
||||
is disabled. These considerations help users to decide if they really need or
|
||||
enable it.
|
||||
|
||||
If you are satisfied with a dedicated build target and image for each board in
|
||||
your development cycle (source, build, validation, release, etc), you don't need
|
||||
this feature.
|
||||
|
||||
If you have a generic build for multiple type of boards and features supported
|
||||
by that build meet your needs to functionality on all of boards, you don't need
|
||||
to have this feature or you can disable it until you need to check in the first
|
||||
board's data, in order to apply a quirk or customization only for that board.
|
||||
|
||||
If you want this feature but have concerns to see more and more boards' finger-
|
||||
prints and data in a generic project, you can have another layer to hold all of
|
||||
board-specific data to split them from a generic layer at source level. Another
|
||||
suggestion is always seeking chances not to clone or copy a common configuration
|
||||
to each board's directory.
|
||||
|
||||
|
||||
|
||||
Thanks
|
||||
|
||||
Jianxun Zhang <jianxun.zhang@linux.intel.com>
|
||||
@ -1,38 +0,0 @@
|
||||
Currently, only one implementation of Secure Boot is available out of the box,
|
||||
which is using a single signed EFI application to directly boot the kernel with
|
||||
an optional initramfs.
|
||||
|
||||
This can be added to your build either through local.conf, or via your own
|
||||
custom image recipe.
|
||||
|
||||
If you are adding it via local.conf, set the following variables:
|
||||
|
||||
IMAGE_FEATURES += "secureboot"
|
||||
WKS_FILE = "generic-bootdisk.wks.in"
|
||||
SECURE_BOOT_SIGNING_KEY = "/path/to/your/signing/key"
|
||||
SECURE_BOOT_SIGNING_CERT = "/path/to/your/signing/cert"
|
||||
IMAGE_CLASSES += "uefi-comboapp"
|
||||
|
||||
If working with an image recipe, you can inherit uefi-comboapp directly instead
|
||||
of using the IMAGE_CLASSES variable.
|
||||
|
||||
The signing keys and certs can be created via openssl commands. Here's an
|
||||
example:
|
||||
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=your-subject/" -keyout \
|
||||
your-key.key -out your-key.crt -days 365 -nodes -sha256
|
||||
openssl x509 -in your-key.crt -out your-key.cer -outform DER
|
||||
|
||||
The .crt file is your SECURE_BOOT_SIGNING_CERT, and the .key file is your
|
||||
SECURE_BOOT_SIGNING_KEY.
|
||||
|
||||
You should enroll the .crt key in your firmware under the PK, KEK, and DB
|
||||
options (methods are different depending on your firmware). If a key should ever
|
||||
become invalid, enroll it under DBX to blacklist it.
|
||||
|
||||
The comboapp can be further manipulated in a number of ways. You can modify the
|
||||
kernel command line via the APPEND variable, you can change the default UUID via
|
||||
the DISK_SIGNATURE_UUID variable, and you can modify the contents of the
|
||||
initramfs via the INITRD_IMAGE or INITRD_LIVE variables.
|
||||
|
||||
A simple Secure Boot enabled image used for testing can be viewed at:
|
||||
common/recipes-selftest/images/secureboot-selftest-image-signed.bb
|
||||
@ -1,176 +0,0 @@
|
||||
#!/usr/bin/env python
|
||||
# ex:ts=4:sw=4:sts=4:et
|
||||
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
||||
#
|
||||
# Copyright (c) 2017, Intel Corporation.
|
||||
# All rights reserved.
|
||||
#
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License version 2 as
|
||||
# published by the Free Software Foundation.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License along
|
||||
# with this program; if not, write to the Free Software Foundation, Inc.,
|
||||
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
#
|
||||
# AUTHORS
|
||||
# Mikko Ylinen <mikko.ylinen@linux.intel.com>
|
||||
#
|
||||
# Based on meta/lib/oeqa/selftest/* and meta-refkit/lib/oeqa/selftest/*
|
||||
|
||||
"""Test cases for secure boot with QEMU running OVMF."""
|
||||
|
||||
import os
|
||||
import unittest
|
||||
import re
|
||||
import glob
|
||||
from shutil import rmtree, copy
|
||||
|
||||
from oeqa.core.decorator.depends import OETestDepends
|
||||
from oeqa.selftest.case import OESelftestTestCase
|
||||
from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars, runqemu
|
||||
|
||||
class SecureBootTests(OESelftestTestCase):
|
||||
"""Secure Boot test class."""
|
||||
|
||||
ovmf_keys_enrolled = False
|
||||
ovmf_qemuparams = ''
|
||||
ovmf_dir = ''
|
||||
test_image_unsigned = 'secureboot-selftest-image-unsigned'
|
||||
test_image_signed = 'secureboot-selftest-image-signed'
|
||||
correct_key = 'refkit-db'
|
||||
incorrect_key = 'incorrect'
|
||||
|
||||
@classmethod
|
||||
def setUpLocal(self):
|
||||
|
||||
if not SecureBootTests.ovmf_keys_enrolled:
|
||||
bitbake('ovmf ovmf-shell-image-enrollkeys', output_log=self.logger)
|
||||
|
||||
bb_vars = get_bb_vars(['TMPDIR', 'DEPLOY_DIR_IMAGE'])
|
||||
|
||||
SecureBootTests.ovmf_dir = os.path.join(bb_vars['TMPDIR'], 'oeselftest', 'secureboot', 'ovmf')
|
||||
bb.utils.mkdirhier(SecureBootTests.ovmf_dir)
|
||||
|
||||
# Copy (all) OVMF in a temporary location
|
||||
for src in glob.glob('%s/ovmf.*' % bb_vars['DEPLOY_DIR_IMAGE']):
|
||||
copy(src, SecureBootTests.ovmf_dir)
|
||||
|
||||
SecureBootTests.ovmf_qemuparams = '-drive if=pflash,format=qcow2,file=%s/ovmf.secboot.qcow2' % SecureBootTests.ovmf_dir
|
||||
|
||||
cmd = ("runqemu "
|
||||
"qemuparams='%s' "
|
||||
"ovmf-shell-image-enrollkeys wic intel-corei7-64 "
|
||||
"nographic slirp") % SecureBootTests.ovmf_qemuparams
|
||||
print('Running "%s"' % cmd)
|
||||
status = runCmd(cmd)
|
||||
|
||||
if not re.search('info: success', status.output, re.M):
|
||||
self.fail('Failed to enroll keys. EFI shell log:\n%s' % status.output)
|
||||
else:
|
||||
# keys enrolled in ovmf.secboot.vars
|
||||
SecureBootTests.ovmf_keys_enrolled = True
|
||||
|
||||
@classmethod
|
||||
def tearDownLocal(self):
|
||||
# Seems this is mandatory between the tests (a signed image is booted
|
||||
# when running test_boot_unsigned_image after test_boot_signed_image).
|
||||
# bitbake('-c clean %s' % test_image, output_log=self.logger)
|
||||
#
|
||||
# Whatever the problem was, it no longer seems to be necessary, so
|
||||
# we can skip the time-consuming clean + full rebuild (5:04 min instead
|
||||
# of 6:55min here).
|
||||
pass
|
||||
|
||||
@classmethod
|
||||
def tearDownClass(self):
|
||||
bitbake('ovmf-shell-image-enrollkeys:do_cleanall', output_log=self.logger)
|
||||
rmtree(self.ovmf_dir, ignore_errors=True)
|
||||
|
||||
def secureboot_with_image(self, boot_timeout=300, signing_key=None):
|
||||
"""Boot the image with UEFI SecureBoot enabled and see the result. """
|
||||
|
||||
config = ""
|
||||
|
||||
if signing_key:
|
||||
test_image = self.test_image_signed
|
||||
config += 'SECURE_BOOT_SIGNING_KEY = "${THISDIR}/files/%s.key"\n' % signing_key
|
||||
config += 'SECURE_BOOT_SIGNING_CERT = "${THISDIR}/files/%s.crt"\n' % signing_key
|
||||
else:
|
||||
test_image = self.test_image_unsigned
|
||||
|
||||
self.write_config(config)
|
||||
bitbake(test_image, output_log=self.logger)
|
||||
self.remove_config(config)
|
||||
|
||||
# Some of the cases depend on the timeout to expire. Allow overrides
|
||||
# so that we don't have to wait 1000s which is the default.
|
||||
overrides = {
|
||||
'TEST_QEMUBOOT_TIMEOUT': boot_timeout,
|
||||
}
|
||||
|
||||
print('Booting %s' % test_image)
|
||||
|
||||
try:
|
||||
with runqemu(test_image, ssh=False,
|
||||
runqemuparams='nographic slirp',
|
||||
qemuparams=self.ovmf_qemuparams,
|
||||
overrides=overrides,
|
||||
image_fstype='wic') as qemu:
|
||||
|
||||
cmd = 'uname -a'
|
||||
|
||||
status, output = qemu.run_serial(cmd)
|
||||
|
||||
self.assertTrue(status, 'Could not run \'uname -a\' (status=%s):\n%s' % (status, output))
|
||||
|
||||
# if we got this far without a correctly signed image, something went wrong
|
||||
if signing_key != self.correct_key:
|
||||
self.fail('The image not give a Security violation when expected. Boot log:\n%s' % output)
|
||||
|
||||
|
||||
except Exception:
|
||||
|
||||
# Currently runqemu() fails if 'login:' prompt is not seen and it's
|
||||
# not possible to login as 'root'. Those conditions aren't met when
|
||||
# booting to EFI shell (See [YOCTO #11438]). We catch the failure
|
||||
# and parse the boot log to determine the success. Note: the
|
||||
# timeout triggers verbose bb.error() but that's normal with some
|
||||
# of the test cases.
|
||||
|
||||
workdir = get_bb_var('WORKDIR', test_image)
|
||||
bootlog = "%s/testimage/qemu_boot_log" % workdir
|
||||
|
||||
with open(bootlog, "r") as log:
|
||||
|
||||
# This isn't right but all we can do at this point. The right
|
||||
# approach would run commands in the EFI shell to determine
|
||||
# the BIOS rejects unsigned and/or images signed with keys in
|
||||
# dbx key store but that needs changes in oeqa framework.
|
||||
|
||||
output = log.read()
|
||||
|
||||
# PASS if we see a security violation on unsigned or incorrectly signed images, otherwise fail
|
||||
if signing_key == self.correct_key:
|
||||
self.fail('Correctly signed image failed to boot. Boot log:\n%s' % output)
|
||||
elif not re.search('Security Violation', output):
|
||||
self.fail('The image not give a Security violation when expected. Boot log:\n%s' % output)
|
||||
|
||||
def test_boot_unsigned_image(self):
|
||||
""" Boot unsigned image with secureboot enabled in UEFI."""
|
||||
self.secureboot_with_image(boot_timeout=120, signing_key=None)
|
||||
|
||||
@OETestDepends(['secureboot.SecureBootTests.test_boot_unsigned_image'])
|
||||
def test_boot_incorrectly_signed_image(self):
|
||||
""" Boot (correctly) signed image with secureboot enabled in UEFI."""
|
||||
self.secureboot_with_image(boot_timeout=120, signing_key=self.incorrect_key)
|
||||
|
||||
@OETestDepends(['secureboot.SecureBootTests.test_boot_incorrectly_signed_image'])
|
||||
def test_boot_correctly_signed_image(self):
|
||||
""" Boot (correctly) signed image with secureboot enabled in UEFI."""
|
||||
self.secureboot_with_image(boot_timeout=150, signing_key=self.correct_key)
|
||||
@ -1,20 +0,0 @@
|
||||
Add a missing debug ifdef causing compilation problems.
|
||||
|
||||
Upstream-Status: Submitted
|
||||
|
||||
Signed-off-by: Tom Zanussi <tom.zanussi (a] intel.com>
|
||||
|
||||
Index: lms-7.1.20/src/tools/ATNetworkTool.cpp
|
||||
===================================================================
|
||||
--- lms-7.1.20.orig/src/tools/ATNetworkTool.cpp 2012-04-30 23:24:56.693879920 -0500
|
||||
+++ lms-7.1.20/src/tools/ATNetworkTool.cpp 2012-04-30 23:25:32.363473948 -0500
|
||||
@@ -302,7 +302,9 @@
|
||||
close(s);
|
||||
return -1;
|
||||
}
|
||||
+#ifdef LMS_NET_DEBUG
|
||||
printf("successfully binded local\n");
|
||||
+#endif
|
||||
|
||||
}
|
||||
if (bind(s, addr, addrlen) == -1) {
|
||||
@ -1,18 +0,0 @@
|
||||
Add a missing include causing compilation (missing declaration) problems.
|
||||
|
||||
Upstream-Status: Submitted
|
||||
|
||||
Signed-off-by: Tom Zanussi <tom.zanussi (a] intel.com>
|
||||
|
||||
Index: lms-7.1.20/src/tools/ATVersion.cpp
|
||||
===================================================================
|
||||
--- lms-7.1.20.orig/src/tools/ATVersion.cpp 2012-05-29 20:34:34.061997035 -0500
|
||||
+++ lms-7.1.20/src/tools/ATVersion.cpp 2012-05-29 20:35:22.671412948 -0500
|
||||
@@ -40,6 +40,7 @@
|
||||
#include <cerrno>
|
||||
#include <fstream>
|
||||
#include <dirent.h>
|
||||
+#include <unistd.h>
|
||||
|
||||
#define AT_VERSION_ARGUMENT "--version"
|
||||
#define AT_VERSION_MAXSIZE 40
|
||||
@ -1,28 +0,0 @@
|
||||
From 518a3a277c89a3d6b0a9d3ee552cfa33a1dbd5c6 Mon Sep 17 00:00:00 2001
|
||||
From: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
||||
Date: Mon, 23 Jan 2017 20:45:08 +0200
|
||||
Subject: [PATCH 1/2] Include sys/select.h for fd_set()
|
||||
|
||||
This is needed at least on musl.
|
||||
|
||||
Upstream-Status: Pending
|
||||
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
||||
---
|
||||
src/mei/MEILinux.cpp | 1 +
|
||||
1 file changed, 1 insertion(+)
|
||||
|
||||
diff --git a/src/mei/MEILinux.cpp b/src/mei/MEILinux.cpp
|
||||
index 1e9d28f..631270e 100755
|
||||
--- a/src/mei/MEILinux.cpp
|
||||
+++ b/src/mei/MEILinux.cpp
|
||||
@@ -37,6 +37,7 @@
|
||||
#include <cerrno>
|
||||
#include <fcntl.h>
|
||||
#include <sys/ioctl.h>
|
||||
+#include <sys/select.h>
|
||||
#include <unistd.h>
|
||||
#include <stdint.h>
|
||||
#include <aio.h>
|
||||
--
|
||||
2.1.4
|
||||
|
||||
@ -1,31 +0,0 @@
|
||||
From 8d737ba9745bef223c3d3b96899f11c26102ea04 Mon Sep 17 00:00:00 2001
|
||||
From: Saul Wold <sgw@linux.intel.com>
|
||||
Date: Mon, 16 May 2016 09:01:05 -0700
|
||||
Subject: [PATCH] Protocol.cpp: Add whitespace for gcc6 compile error
|
||||
|
||||
When moving from C++-3 -> C++11 additiona white space is required between
|
||||
User-defined literals.
|
||||
|
||||
Upstream-Status: Pending
|
||||
|
||||
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
||||
---
|
||||
src/Protocol.cpp | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/src/Protocol.cpp b/src/Protocol.cpp
|
||||
index 1c21a0f..3a4a9bb 100755
|
||||
--- a/src/Protocol.cpp
|
||||
+++ b/src/Protocol.cpp
|
||||
@@ -1428,7 +1428,7 @@ int Protocol::_handleFQDNChange(const char *fqdn)
|
||||
char host[FQDN_MAX_SIZE + 1];
|
||||
#define LMS_MAX_LINE_LEN 1023
|
||||
char line[LMS_MAX_LINE_LEN + 1];
|
||||
-#define LMS_LINE_SIG_FIRST_WORDS(a) "# LMS GENERATED "a" "
|
||||
+#define LMS_LINE_SIG_FIRST_WORDS(a) "# LMS GENERATED " a " "
|
||||
#define LMS_LINE_SIG_LAST_WORD "LINE"
|
||||
#define LMS_LINE_SIG_LAST_WORD_LEN 4
|
||||
#define LMS_LINE_SIG(a) LMS_LINE_SIG_FIRST_WORDS(a) LMS_LINE_SIG_LAST_WORD
|
||||
--
|
||||
2.5.0
|
||||
|
||||
@ -1,31 +0,0 @@
|
||||
From 0adc925ca9e005f93d77f373ccda2a6c6cc3ff2f Mon Sep 17 00:00:00 2001
|
||||
From: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
||||
Date: Mon, 23 Jan 2017 20:46:50 +0200
|
||||
Subject: [PATCH 2/2] Use proper netinet/in.h API
|
||||
|
||||
in6addr is only guaranteed to contain this member:
|
||||
uint8_t s6_addr[16]
|
||||
Use that instead of the glibc implementation detail __in6_u.
|
||||
|
||||
Upstream-Status: Pending
|
||||
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
||||
---
|
||||
src/tools/ATNetworkTool.cpp | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/src/tools/ATNetworkTool.cpp b/src/tools/ATNetworkTool.cpp
|
||||
index 66e27df..0789c79 100755
|
||||
--- a/src/tools/ATNetworkTool.cpp
|
||||
+++ b/src/tools/ATNetworkTool.cpp
|
||||
@@ -207,7 +207,7 @@ int ATNetworkTool::GetSockPeerIP(int sock, ATAddressList & peerAddresses, int &e
|
||||
if(sa->sa_family == AF_INET6 && IN6_IS_ADDR_V4MAPPED(&addr)) //if(IN6_IS_ADDR_V4COMPAT(&addr))
|
||||
{
|
||||
struct in_addr demapped_addr;
|
||||
- memcpy(&demapped_addr.s_addr, &addr.__in6_u.__u6_addr8[12], 4);
|
||||
+ memcpy(&demapped_addr.s_addr, &addr.s6_addr[12], 4);
|
||||
|
||||
struct sockaddr_in sa_in;
|
||||
sa_in.sin_family = AF_INET;
|
||||
--
|
||||
2.1.4
|
||||
|
||||
@ -1,91 +0,0 @@
|
||||
Fix device file referance to /dev/mei0, remove select post write.
|
||||
|
||||
LMS uses /dev/mei character device which is absent on current kernel versions causing LMS fail to initialize. LMS sends messages to MEI with a post select timeout. Select timeout causes SendMessage to fail causing LMS to not to communicate properly with MEI.
|
||||
|
||||
Adding /dev/mei0 device file reference to check first and then /dev/mei sucessfully initializes LMS. Rely on write return length and remove select with timeout to fix communication with MEI.
|
||||
|
||||
Upstream-Status: Pending
|
||||
|
||||
Signed-off-by: Anand Vastrad <anand.vastrad@intel.com>
|
||||
---
|
||||
src/mei/MEILinux.cpp | 43 +++++++------------------------------------
|
||||
1 file changed, 7 insertions(+), 36 deletions(-)
|
||||
|
||||
diff --git a/src/mei/MEILinux.cpp b/src/mei/MEILinux.cpp
|
||||
index 1e9d28f..6d23f54 100755
|
||||
--- a/src/mei/MEILinux.cpp
|
||||
+++ b/src/mei/MEILinux.cpp
|
||||
@@ -94,13 +94,17 @@ bool MEILinux::Init(unsigned char reqProtocolVersion)
|
||||
Deinit();
|
||||
}
|
||||
|
||||
- _fd = open("/dev/mei", O_RDWR);
|
||||
+ _fd = open("/dev/mei0", O_RDWR);
|
||||
|
||||
if (_fd == -1 ) {
|
||||
if (_verbose) {
|
||||
- fprintf(stderr, "Error: Cannot establish a handle to the MEI driver\n");
|
||||
+ fprintf(stderr, "Warning: Cannot establish a handle to the MEI driver mei0, retrying with mei \n");
|
||||
+ }
|
||||
+ _fd = open("/dev/mei", O_RDWR);
|
||||
+ if (_fd == -1 ) {
|
||||
+ fprintf(stderr, "Error: Cannot establish a handle to the MEI driver mei\n");
|
||||
+ return false;
|
||||
}
|
||||
- return false;
|
||||
}
|
||||
_initialized = true;
|
||||
|
||||
@@ -181,13 +185,7 @@ int MEILinux::ReceiveMessage(unsigned char *buffer, int len, unsigned long timeo
|
||||
int MEILinux::SendMessage(const unsigned char *buffer, int len, unsigned long timeout)
|
||||
{
|
||||
int rv = 0;
|
||||
- int return_length =0;
|
||||
int error = 0;
|
||||
- fd_set set;
|
||||
- struct timeval tv;
|
||||
-
|
||||
- tv.tv_sec = timeout / 1000;
|
||||
- tv.tv_usec =(timeout % 1000) * 1000000;
|
||||
|
||||
if (_verbose) {
|
||||
fprintf(stdout, "call write length = %d\n", len);
|
||||
@@ -198,35 +196,8 @@ int MEILinux::SendMessage(const unsigned char *buffer, int len, unsigned long ti
|
||||
if (_verbose) {
|
||||
fprintf(stderr,"write failed with status %d %d\n", rv, error);
|
||||
}
|
||||
- goto out;
|
||||
- }
|
||||
-
|
||||
- return_length = rv;
|
||||
-
|
||||
- FD_ZERO(&set);
|
||||
- FD_SET(_fd, &set);
|
||||
- rv = select(_fd+1 ,&set, NULL, NULL, &tv);
|
||||
- if (rv > 0 && FD_ISSET(_fd, &set)) {
|
||||
- if (_verbose) {
|
||||
- fprintf(stderr, "write success\n");
|
||||
- }
|
||||
}
|
||||
- else if (rv == 0) {
|
||||
- if (_verbose) {
|
||||
- fprintf(stderr, "write failed on timeout with status\n");
|
||||
- }
|
||||
- goto out;
|
||||
- }
|
||||
- else { //rv<0
|
||||
- if (_verbose) {
|
||||
- fprintf(stderr, "write failed on select with status %d\n", rv);
|
||||
- }
|
||||
- goto out;
|
||||
- }
|
||||
-
|
||||
- rv = return_length;
|
||||
|
||||
-out:
|
||||
if (rv < 0) {
|
||||
Deinit();
|
||||
}
|
||||
--
|
||||
2.7.4
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,58 +0,0 @@
|
||||
DESCRIPTION = "Intel Local Manageability Service allows applications \
|
||||
to access the Intel Active Management Technology (AMT) firmware via \
|
||||
the Intel Management Engine Interface (MEI)."
|
||||
HOMEPAGE = "http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers"
|
||||
|
||||
LICENSE = "BSD_LMS"
|
||||
|
||||
PR = "r0"
|
||||
BPN="lms"
|
||||
PV_SUB = "25"
|
||||
SRC_URI = "http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-${BPN}_${PV}.${PV_SUB}.zip \
|
||||
file://atnetworktool-printf-fix.patch \
|
||||
file://readlink-declaration.patch \
|
||||
file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-error.patch \
|
||||
file://0001-Include-sys-select.h-for-fd_set.patch \
|
||||
file://0002-Use-proper-netinet-in.h-API.patch \
|
||||
"
|
||||
|
||||
LOCALSRC = "file://${WORKDIR}/outputdir/${BPN}-${PV}-${PV_SUB}.tar.gz"
|
||||
|
||||
COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
|
||||
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=7264184cf88d9f27b719a9656255b47b"
|
||||
|
||||
SRC_URI[md5sum] = "687b76e78bfdbcf567c0e842c1fe240a"
|
||||
SRC_URI[sha256sum] = "cc0457f0044e924794bb1aeae9a72c28666a525cd8a963d0d92970222946e75b"
|
||||
|
||||
inherit autotools update-rc.d
|
||||
|
||||
INITSCRIPT_NAME = "lms7"
|
||||
INITSCRIPT_PARAMS = "defaults"
|
||||
|
||||
python do_unpack() {
|
||||
s = d.getVar('S', True)
|
||||
d.setVar('S', '${WORKDIR}/outputdir')
|
||||
bb.build.exec_func('base_do_unpack', d)
|
||||
# temorarily change SRC_URI for unpack
|
||||
src_uri = d.getVar('SRC_URI', True)
|
||||
d.setVar('SRC_URI', '${LOCALSRC}')
|
||||
d.setVar('S', s)
|
||||
bb.build.exec_func('base_do_unpack', d)
|
||||
d.setVar('SRC_URI', src_uri)
|
||||
}
|
||||
|
||||
|
||||
do_install_append () {
|
||||
mv ${D}/${sbindir}/lms ${D}/${sbindir}/lms7
|
||||
install -d ${D}${sysconfdir}/init.d
|
||||
# The configure script looks at the host to decide where to put init
|
||||
# scripts, so move it at the same time as renaming it.
|
||||
if test -f ${D}${sysconfdir}/rc.d/init.d/lms ; then
|
||||
mv ${D}${sysconfdir}/rc.d/init.d/lms ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
else
|
||||
mv ${D}${sysconfdir}/init.d/lms ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
fi
|
||||
sed -i 's/^NAME=lms/NAME=lms7/' ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
rmdir ${D}${datadir} || :
|
||||
}
|
||||
@ -1,46 +0,0 @@
|
||||
DESCRIPTION = "Intel Local Manageability Service allows applications \
|
||||
to access the Intel Active Management Technology (AMT) firmware via \
|
||||
the Intel Management Engine Interface (MEI)."
|
||||
HOMEPAGE = "http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers"
|
||||
|
||||
LICENSE = "BSD_LMS"
|
||||
|
||||
PR = "r0"
|
||||
BPN="lms"
|
||||
SRC_URI = "http://software.intel.com/sites/default/files/${BPN}-${PV}.tar.gz \
|
||||
file://readlink-declaration.patch \
|
||||
file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-error.patch \
|
||||
file://0001-Include-sys-select.h-for-fd_set.patch \
|
||||
file://0002-Use-proper-netinet-in.h-API.patch \
|
||||
file://0003-Fix-device-file-referance-to-dev-mei0-remove-select.patch \
|
||||
file://0004-Intel-AMT-ME-real-time-notification-infra.patch \
|
||||
"
|
||||
|
||||
FILES_${PN} += "${datadir}/xml/AMTAlerts.xml"
|
||||
|
||||
COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
|
||||
|
||||
LIC_FILES_CHKSUM = "file://COPYING;md5=ec77c894e8a1a89fa07aed2c76680ab8"
|
||||
|
||||
SRC_URI[md5sum] = "3cbd027a0e6e9ced8238478b24cde3c6"
|
||||
SRC_URI[sha256sum] = "7077db6f2f381e67cb37565b20c40ff0c7d3f98f014e65622a4b4b66c2b1d637"
|
||||
|
||||
inherit autotools update-rc.d
|
||||
|
||||
INITSCRIPT_NAME = "lms8"
|
||||
INITSCRIPT_PARAMS = "defaults"
|
||||
|
||||
|
||||
do_install_append () {
|
||||
mv ${D}/${sbindir}/lms ${D}/${sbindir}/lms8
|
||||
install -d ${D}${sysconfdir}/init.d
|
||||
# The configure script looks at the host to decide where to put init
|
||||
# scripts, so move it at the same time as renaming it.
|
||||
if test -f ${D}${sysconfdir}/rc.d/init.d/lms ; then
|
||||
mv ${D}${sysconfdir}/rc.d/init.d/lms ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
else
|
||||
mv ${D}${sysconfdir}/init.d/lms ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
fi
|
||||
sed -i 's/^NAME=lms/NAME=lms8/' ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
|
||||
rmdir ${D}${datadir} || :
|
||||
}
|
||||
@ -1,33 +0,0 @@
|
||||
From 7c171c1813651a3a02ad2cda361b42ebc7ce324d Mon Sep 17 00:00:00 2001
|
||||
From: Khem Raj <raj.khem@gmail.com>
|
||||
Date: Sat, 12 Aug 2017 10:34:19 -0700
|
||||
Subject: [PATCH 1/2] Disable address-of-packed-member warning
|
||||
|
||||
Clang complains so make it happy
|
||||
|
||||
loaders/bzimage/bzimage.c:346:55: error: taking address of packed member 'base' of class or structure 'dt_addr_t' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
|
||||
err = emalloc(gdt.limit, 8, (EFI_PHYSICAL_ADDRESS *)&gdt.base);
|
||||
|
||||
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
||||
---
|
||||
Upstream-Status: Pending
|
||||
|
||||
Makefile | 2 +-
|
||||
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||
|
||||
diff --git a/Makefile b/Makefile
|
||||
index a955e34..ff1b79b 100644
|
||||
--- a/Makefile
|
||||
+++ b/Makefile
|
||||
@@ -61,7 +61,7 @@ ifeq ($(ARCH),ia32)
|
||||
endif
|
||||
endif
|
||||
ifeq ($(ARCH),x86_64)
|
||||
- CFLAGS += -mno-red-zone
|
||||
+ CFLAGS += -mno-red-zone -Wno-address-of-packed-member
|
||||
endif
|
||||
|
||||
LDFLAGS=-T $(LDSCRIPT) -Bsymbolic -shared -nostdlib -znocombreloc \
|
||||
--
|
||||
2.14.1
|
||||
|
||||
@ -1,33 +0,0 @@
|
||||
From 49053e4ff0f3550d019cdad8a93677c18fc69791 Mon Sep 17 00:00:00 2001
|
||||
From: Khem Raj <raj.khem@gmail.com>
|
||||
Date: Sat, 12 Aug 2017 10:35:09 -0700
|
||||
Subject: [PATCH 2/2] initialize char pointers
|
||||
|
||||
Clang complains about using them without initializing
|
||||
|
||||
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
||||
---
|
||||
Upstream-Status: Pending
|
||||
|
||||
entry.c | 4 ++--
|
||||
1 file changed, 2 insertions(+), 2 deletions(-)
|
||||
|
||||
diff --git a/entry.c b/entry.c
|
||||
index 0aa6cdd..23ba51e 100644
|
||||
--- a/entry.c
|
||||
+++ b/entry.c
|
||||
@@ -402,9 +402,9 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *_table)
|
||||
WCHAR *error_buf;
|
||||
EFI_STATUS err;
|
||||
EFI_LOADED_IMAGE *info;
|
||||
- CHAR16 *name, *options;
|
||||
+ CHAR16 *name = NULL, *options;
|
||||
UINT32 options_size;
|
||||
- char *cmdline;
|
||||
+ char *cmdline = NULL;
|
||||
|
||||
InitializeLib(image, _table);
|
||||
sys_table = _table;
|
||||
--
|
||||
2.14.1
|
||||
|
||||
@ -1,38 +0,0 @@
|
||||
DESCRIPTION = "A UEFI OS loader"
|
||||
LICENSE = "BSD-2-Clause"
|
||||
LIC_FILES_CHKSUM = "file://efilinux.h;beginline=5;endline=27;md5=f8d56e644672ac63fd81b55c205283ad"
|
||||
|
||||
DEPENDS = "gnu-efi"
|
||||
|
||||
inherit deploy
|
||||
|
||||
SRCREV = "a995826f9e43f1134baea61610eafd8c173bb776"
|
||||
PV = "1.1+git${SRCPV}"
|
||||
|
||||
SRC_URI = "git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git \
|
||||
file://0001-Disable-address-of-packed-member-warning.patch \
|
||||
file://0002-initialize-char-pointers.patch \
|
||||
"
|
||||
|
||||
S = "${WORKDIR}/git"
|
||||
|
||||
COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
|
||||
|
||||
EXTRA_OEMAKE = "INCDIR=${STAGING_INCDIR} LIBDIR=${STAGING_LIBDIR}"
|
||||
|
||||
# syslinux uses $LD for linking, strip `-Wl,' so it can work
|
||||
export LDFLAGS = "`echo $LDFLAGS | sed 's/-Wl,//g'`"
|
||||
|
||||
do_deploy () {
|
||||
install ${S}/efilinux.efi ${DEPLOYDIR}/efilinux.efi
|
||||
}
|
||||
addtask deploy before do_build after do_compile
|
||||
|
||||
python () {
|
||||
ccargs = d.getVar('TUNE_CCARGS').split()
|
||||
if '-mx32' in ccargs:
|
||||
# use x86_64 EFI ABI
|
||||
ccargs.remove('-mx32')
|
||||
ccargs.append('-m64')
|
||||
d.setVar('TUNE_CCARGS', ' '.join(ccargs))
|
||||
}
|
||||
@ -1,39 +0,0 @@
|
||||
# Note: superuser permission is required to run usbhid-dump
|
||||
# successfully.
|
||||
|
||||
# HEX keys are according to the USB HID spec and USB HID usage table
|
||||
# We can add more keys as needed in the future.
|
||||
|
||||
# This test may not be very accurate, as we only look for the first
|
||||
# two lines of a descriptor section. Example:
|
||||
#
|
||||
# 001:003:000:DESCRIPTOR 1460501386.337809
|
||||
# 05 01 09 02 A1 01 09 01 A1 00 05 09 19 01 29 03
|
||||
# 15 00 25 01 95 03 75 01 81 02 .. .. .. .. .. ..
|
||||
# .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
|
||||
#
|
||||
# By doing so we eliminate false matches when HEX keys are in the lines
|
||||
# in the middle of the whole descriptor section.
|
||||
|
||||
if type usbhid-dump &>/dev/null; then
|
||||
if USBHID_DUMP_OUTPUT=$(usbhid-dump -e descriptor 2>/dev/null|grep -A1 DESCRIPTOR); then
|
||||
# checker for generic USB HID keyboard
|
||||
USBHID_KBD_CMD="grep -E '^ 05 01 09 06'"
|
||||
|
||||
# checker for touch screen
|
||||
USBHID_TS_CMD="grep -E '^ 05 0D 09 04'"
|
||||
|
||||
if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_TS_CMD &>/dev/null; then
|
||||
HAVE_TOUCHSCREEN=1
|
||||
fi
|
||||
|
||||
if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_KBD_CMD &>/dev/null; then
|
||||
HAVE_KEYBOARD=1
|
||||
else
|
||||
# config script in OE will set HAVE_KEYBOARD=1
|
||||
# if we don't set any value. We have to explicitly
|
||||
# tell it when keyboard is not detected.
|
||||
HAVE_KEYBOARD=0
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
@ -1 +0,0 @@
|
||||
FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"
|
||||
@ -1,2 +0,0 @@
|
||||
# Mimic modprobe's install funcitonality with busybox's modprobe
|
||||
install gma500_gfx dmesg | grep gma500_gfx_checked || { /etc/modprobe.d/gma500-gfx-check.sh || modprobe gma500_gfx; }
|
||||
@ -1,15 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
# Check for devices we wish to avoid gma500_gfx for
|
||||
DEVICES="0x8119 0x4108"
|
||||
|
||||
# Checked flag to avoid infinite modprobe
|
||||
echo "gma500_gfx_checked" >> /dev/kmsg;
|
||||
|
||||
for DEVICE in $DEVICES; do
|
||||
if udevadm trigger --subsystem-match=pci --verbose --attr-match=device=$DEVICE | grep "pci" >> /dev/null ; then
|
||||
echo "Found $DEVICE, avoiding gma500_gfx module" >> /dev/kmsg;
|
||||
exit 0
|
||||
fi
|
||||
done
|
||||
exit 1
|
||||
@ -1,18 +0,0 @@
|
||||
SUMMARY = "Intel gma500_gfx fix for certain hardware"
|
||||
DESCRIPTION = "Avoid inserting gma500_gfx module for certain hardware devices."
|
||||
LICENSE="GPLv2"
|
||||
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
|
||||
|
||||
SRC_URI = "file://gma500-gfx-check.conf \
|
||||
file://gma500-gfx-check.sh "
|
||||
|
||||
do_install(){
|
||||
install -d ${D}${sysconfdir}/modprobe.d/
|
||||
install -m 755 ${WORKDIR}/gma500-gfx-check.sh ${D}${sysconfdir}/modprobe.d/gma500-gfx-check.sh
|
||||
install -m 644 ${WORKDIR}/gma500-gfx-check.conf ${D}${sysconfdir}/modprobe.d/gma500-gfx-check.conf
|
||||
}
|
||||
|
||||
FILES_${PN}="${sysconfdir}/modprobe.d/gma500-gfx-check.conf \
|
||||
${sysconfdir}/modprobe.d/gma500-gfx-check.sh"
|
||||
|
||||
COMPATIBLE_MACHINE = "intel-core2-32"
|
||||
@ -1,3 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
|
||||
@ -1,4 +0,0 @@
|
||||
title Galileo Gen 2 boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot rootwait console=ttyS1,115200
|
||||
Binary file not shown.
@ -1,4 +0,0 @@
|
||||
title Galileo Gen 2 install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi rootwait console=ttyS1,115200
|
||||
@ -1 +0,0 @@
|
||||
console=ttyS0,115200
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,2 +0,0 @@
|
||||
efi_entry_dir:root:disk:770:/boot/loader/entries/
|
||||
boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
|
||||
@ -1,2 +0,0 @@
|
||||
# There is no tty device on this board.
|
||||
sed -i '/start_getty.\+ttyS.*/d' /tgt_root/etc/inittab
|
||||
@ -1,4 +0,0 @@
|
||||
title NUC5i5RYB boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot rootwait
|
||||
@ -1,4 +0,0 @@
|
||||
title NUC5i5RYB install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi rootwait
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
Binary file not shown.
@ -1,4 +0,0 @@
|
||||
title T100T(32bit) boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot loglevel=8
|
||||
@ -1,4 +0,0 @@
|
||||
title T100T(32bit) install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi
|
||||
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,3 +0,0 @@
|
||||
# Keep rmc Joule boot.conf instead of meta-intel default
|
||||
efi_entry_dir:root:disk:770:/boot/loader/entries/
|
||||
boot.conf:root:disk:770:/boot/loader/entries/boot.conf
|
||||
@ -1 +0,0 @@
|
||||
video=efifb maxcpus=4 reboot=efi kmemleak=off console=tty0 console=ttyS2,115200
|
||||
@ -1,2 +0,0 @@
|
||||
# Joule uses only S2 for serial, so remove S0
|
||||
sed -i '/start_getty.\+ttyS0/d' /tgt_root/etc/inittab
|
||||
Binary file not shown.
Binary file not shown.
@ -1,4 +0,0 @@
|
||||
title Joule / Broxton-m
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot
|
||||
@ -1,4 +0,0 @@
|
||||
title Joule / Broxton-m Install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi rootwait
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,4 +0,0 @@
|
||||
title Minnow Max boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot console=ttyS0,115200n8
|
||||
@ -1,4 +0,0 @@
|
||||
title Minnow Max install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi console=ttyS0,115200n8
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,4 +0,0 @@
|
||||
title Minnow Max B3 boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot console=ttyS0,115200n8
|
||||
@ -1,4 +0,0 @@
|
||||
title Minnow Max B3 install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi console=ttyS0,115200n8
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,3 +0,0 @@
|
||||
# Keep rmc Mohonpeak boot.conf instead of meta-intel default
|
||||
efi_entry_dir:root:disk:770:/boot/loader/entries/
|
||||
boot.conf:root:disk:770:/boot/loader/entries/boot.conf
|
||||
@ -1 +0,0 @@
|
||||
console=ttyS1,115200 console=tty1
|
||||
@ -1,3 +0,0 @@
|
||||
# Mohonpeak uses only S1 for serial, so remove S0 and S2
|
||||
sed -i '/start_getty.\+ttyS0/d' /tgt_root/etc/inittab
|
||||
sed -i '/start_getty.\+ttyS2/d' /tgt_root/etc/inittab
|
||||
@ -1,4 +0,0 @@
|
||||
title Mohon Peak boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot
|
||||
@ -1,4 +0,0 @@
|
||||
title Mohon Peak Install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi rootwait
|
||||
Binary file not shown.
@ -1,2 +0,0 @@
|
||||
boot.conf
|
||||
install.conf
|
||||
@ -1,6 +0,0 @@
|
||||
# This file specifies which file or dir RMC will install onto target.
|
||||
# Note the absolute path is referred from mount points in installation.
|
||||
efi_entry_dir:root:disk:770:/boot/loader/entries/
|
||||
boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
|
||||
mylibdir:root:root:770:/tgt_root/etc/mylib/
|
||||
mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
|
||||
@ -1 +0,0 @@
|
||||
i915.preliminary_hw_support=1
|
||||
@ -1,7 +0,0 @@
|
||||
# NUC Gen 6 specific retouch after RMC deployment
|
||||
|
||||
# The generated inittab from OE build causes error messages:
|
||||
# "auth.err getty[615]: tcgetattr: Input/output error"
|
||||
# in /var/log/messages because NUC Gen 6 doesn't have any
|
||||
# serial tty. We delete line(s) here on target.
|
||||
sed -i '/start_getty.\+ttyS.*/d' /tgt_root/etc/inittab
|
||||
@ -1,4 +0,0 @@
|
||||
title NUC Gen6 boot
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=boot
|
||||
@ -1,4 +0,0 @@
|
||||
title NUC Gen6 install
|
||||
linux /vmlinuz
|
||||
initrd /initrd
|
||||
options LABEL=install-efi
|
||||
@ -1,7 +0,0 @@
|
||||
# This is a demo conf file read by an imagined program or library
|
||||
# which reads this file at runtime to customize its behavior.
|
||||
# rmc will deploy it to the location specified in INSTALLER.CONFIG.
|
||||
|
||||
lib.info = "V1.0 for rmc demo"
|
||||
lib.board = "NUC gen 6"
|
||||
prog.ui.layout = "minimal"
|
||||
Binary file not shown.
@ -1 +0,0 @@
|
||||
console=ttyS0,115200
|
||||
Binary file not shown.
@ -1 +0,0 @@
|
||||
console=ttyS0,115200
|
||||
Binary file not shown.
@ -1,49 +0,0 @@
|
||||
SUMMARY = "Central RMC Database"
|
||||
DESCRIPTION = "Generate a centralized RMC database for RMC feature. \
|
||||
Fingerprints and data for all boards supported are specified by variable \
|
||||
RMC_BOARD_DATA_DIRS which is a list of top directories that contains \
|
||||
subdirectories for boards. Developers can add their top directories by appending \
|
||||
them to this variable in a rmc-db.bbappend.Refer to rmc-db bbclass for more \
|
||||
information."
|
||||
|
||||
LICENSE = "MIT"
|
||||
|
||||
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
|
||||
|
||||
S = "${WORKDIR}"
|
||||
|
||||
inherit rmc-db
|
||||
|
||||
RMC_BOARD_DATA_DIRS ?= "${THISDIR}/boards/"
|
||||
RMC_DB_DIR = "${WORKDIR}/db"
|
||||
|
||||
# Let sstate be aware of change in any added board directories
|
||||
do_generate_rmc_db[file-checksums] = "${@get_rmc_top_dirs_list(d)}"
|
||||
|
||||
# derived from get_lic_checksum_file_list(d) in base.bbclass in OE
|
||||
def get_rmc_top_dirs_list(d):
|
||||
dirlist = []
|
||||
dirs = d.getVar("RMC_BOARD_DATA_DIRS", True) or ''
|
||||
topdirs = dirs.split()
|
||||
for each in topdirs:
|
||||
dirlist.append(each + ":" + str(os.path.exists(each)))
|
||||
return " ".join(dirlist)
|
||||
|
||||
do_generate_rmc_db () {
|
||||
rmc_generate_db "${RMC_BOARD_DATA_DIRS}" "${RMC_DB_DIR}"/rmc.db
|
||||
}
|
||||
|
||||
addtask generate_rmc_db after do_compile
|
||||
|
||||
inherit deploy
|
||||
|
||||
do_deploy () {
|
||||
if [ -f ${RMC_DB_DIR}/rmc.db ]; then
|
||||
install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR}
|
||||
else
|
||||
rm -f ${DEPLOYDIR}/rmc.db
|
||||
echo "Warning: no RMC central database found, skip deployment."
|
||||
fi
|
||||
}
|
||||
|
||||
addtask deploy after do_generate_rmc_db
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user