brl/citadel
1
0
Fork 2
Code Issues Pull Requests 2 Packages Projects Releases Wiki Activity

Merge commit '5789f1b122ac5b32dce85e80a36dafe049c757cd' as 'meta-intel'

Browse Source
This commit is contained in:
brl 2017-12-04 16:35:46 -05:00
commit f3c6426196
185 changed files with 8596 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
meta-intel/.gitignore vendored Normal file
View File

@ -0,0 +1,6 @@
*.pyc
*.pyo
*.swp
*.orig
*.rej
*~

87
meta-intel/CHANGELOG Normal file
View File

@ -0,0 +1,87 @@
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"

17
meta-intel/COPYING.MIT Normal file
View File

@ -0,0 +1,17 @@
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.

5
meta-intel/LICENSE Normal file
View File

@ -0,0 +1,5 @@
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.

32
meta-intel/MAINTAINERS Normal file
View File

@ -0,0 +1,32 @@
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: *

481
meta-intel/README Normal file
View File

@ -0,0 +1,481 @@
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.

17
meta-intel/README.sources Normal file
View File

@ -0,0 +1,17 @@
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

17
meta-intel/classes/rmc-boot.bbclass Normal file
View File

@ -0,0 +1,17 @@
# 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
}

92
meta-intel/classes/rmc-db.bbclass Normal file
View File

@ -0,0 +1,92 @@
# 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
}

151
meta-intel/classes/uefi-comboapp.bbclass Normal file
View File

@ -0,0 +1,151 @@
# 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"

50
meta-intel/classes/uefi-sign.bbclass Normal file
View File

@ -0,0 +1,50 @@
# 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 \
"

23
meta-intel/conf/include/maintainers.inc Normal file
View File

@ -0,0 +1,23 @@
# 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>"

24
meta-intel/conf/layer.conf Normal file
View File

@ -0,0 +1,24 @@
# 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

15
meta-intel/conf/machine/include/intel-common-pkgarch.inc Normal file
View File

@ -0,0 +1,15 @@
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}:"

7
meta-intel/conf/machine/include/intel-core2-32-common.inc Normal file
View File

@ -0,0 +1,7 @@
#
# 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

7
meta-intel/conf/machine/include/intel-corei7-64-common.inc Normal file
View File

@ -0,0 +1,7 @@
#
# 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

12
meta-intel/conf/machine/include/intel-quark-common.inc Normal file
View File

@ -0,0 +1,12 @@
#
# 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"

53
meta-intel/conf/machine/include/meta-intel.inc Normal file
View File

@ -0,0 +1,53 @@
#
# 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

19
meta-intel/conf/machine/include/qemu-intel.inc Normal file
View File

@ -0,0 +1,19 @@
# 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"

19
meta-intel/conf/machine/include/qemuboot-intel.inc Normal file
View File

@ -0,0 +1,19 @@
# 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"

35
meta-intel/conf/machine/intel-core2-32.conf Normal file
View File

@ -0,0 +1,35 @@
#@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"

46
meta-intel/conf/machine/intel-corei7-64.conf Normal file
View File

@ -0,0 +1,46 @@
#@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"

33
meta-intel/conf/machine/intel-quark.conf Normal file
View File

@ -0,0 +1,33 @@
#@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"

30
meta-intel/custom-licenses/BSD_LMS Executable file
View File

@ -0,0 +1,30 @@
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.

123
meta-intel/custom-licenses/Intel-Microcode-License Normal file
View File

@ -0,0 +1,123 @@
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.

382
meta-intel/documentation/rmc/README Normal file
View File

@ -0,0 +1,382 @@
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>

38
meta-intel/documentation/secureboot/README Normal file
View File

@ -0,0 +1,38 @@
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

176
meta-intel/lib/oeqa/selftest/cases/secureboot.py Normal file
View File

@ -0,0 +1,176 @@
#!/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)

20
meta-intel/recipes-bsp/amt/files/atnetworktool-printf-fix.patch Normal file
View File

@ -0,0 +1,20 @@
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) {

18
meta-intel/recipes-bsp/amt/files/readlink-declaration.patch Normal file
View File

@ -0,0 +1,18 @@
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

28
meta-intel/recipes-bsp/amt/lms/0001-Include-sys-select.h-for-fd_set.patch Normal file
View File

@ -0,0 +1,28 @@
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

31
meta-intel/recipes-bsp/amt/lms/0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-error.patch Normal file
View File

@ -0,0 +1,31 @@
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

31
meta-intel/recipes-bsp/amt/lms/0002-Use-proper-netinet-in.h-API.patch Normal file
View File

@ -0,0 +1,31 @@
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

91
meta-intel/recipes-bsp/amt/lms/0003-Fix-device-file-referance-to-dev-mei0-remove-select.patch Normal file
View File

@ -0,0 +1,91 @@
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

2647
meta-intel/recipes-bsp/amt/lms/0004-Intel-AMT-ME-real-time-notification-infra.patch Normal file
View File

File diff suppressed because it is too large Load Diff

58
meta-intel/recipes-bsp/amt/lms7_7.1.20.bb Normal file
View File

@ -0,0 +1,58 @@
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} || :
}

46
meta-intel/recipes-bsp/amt/lms8_8.0.0-7.bb Normal file
View File

@ -0,0 +1,46 @@
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} || :
}

33
meta-intel/recipes-bsp/efilinux/efilinux/0001-Disable-address-of-packed-member-warning.patch Normal file
View File

@ -0,0 +1,33 @@
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

33
meta-intel/recipes-bsp/efilinux/efilinux/0002-initialize-char-pointers.patch Normal file
View File

@ -0,0 +1,33 @@
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

38
meta-intel/recipes-bsp/efilinux/efilinux_1.1.bb Normal file
View File

@ -0,0 +1,38 @@
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))
}

39
meta-intel/recipes-bsp/formfactor/formfactor/machconfig Normal file
View File

@ -0,0 +1,39 @@
# 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
meta-intel/recipes-bsp/formfactor/formfactor_0.0.bbappend Normal file
View File

@ -0,0 +1 @@
FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"

2
meta-intel/recipes-bsp/gma500-gfx-check/gma500-gfx-check/gma500-gfx-check.conf Normal file
View File

@ -0,0 +1,2 @@
# 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; }

15
meta-intel/recipes-bsp/gma500-gfx-check/gma500-gfx-check/gma500-gfx-check.sh Normal file
View File

@ -0,0 +1,15 @@
#!/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

18
meta-intel/recipes-bsp/gma500-gfx-check/gma500-gfx-check_1.0.bb Normal file
View File

@ -0,0 +1,18 @@
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"

3
meta-intel/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,3 @@
boot.conf
install.conf

4
meta-intel/recipes-bsp/rmc/boards/Galileo2/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title Galileo Gen 2 boot
linux /vmlinuz
initrd /initrd
options LABEL=boot rootwait console=ttyS1,115200

BIN
meta-intel/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp Executable file
View File

Binary file not shown.

4
meta-intel/recipes-bsp/rmc/boards/Galileo2/install.conf Normal file
View File

@ -0,0 +1,4 @@
title Galileo Gen 2 install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi rootwait console=ttyS1,115200

1
meta-intel/recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
console=ttyS0,115200

BIN
meta-intel/recipes-bsp/rmc/boards/MinnowboardTurbot/minnowboardturbot.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

2
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG Normal file
View File

@ -0,0 +1,2 @@
efi_entry_dir:root:disk:770:/boot/loader/entries/
boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf

2
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh Normal file
View File

@ -0,0 +1,2 @@
# There is no tty device on this board.
sed -i '/start_getty.\+ttyS.*/d' /tgt_root/etc/inittab

4
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title NUC5i5RYB boot
linux /vmlinuz
initrd /initrd
options LABEL=boot rootwait

4
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf Normal file
View File

@ -0,0 +1,4 @@
title NUC5i5RYB install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi rootwait

BIN
meta-intel/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

BIN
meta-intel/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp Normal file
View File

Binary file not shown.

4
meta-intel/recipes-bsp/rmc/boards/T100-32bit/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title T100T(32bit) boot
linux /vmlinuz
initrd /initrd
options LABEL=boot loglevel=8

4
meta-intel/recipes-bsp/rmc/boards/T100-32bit/install.conf Normal file
View File

@ -0,0 +1,4 @@
title T100T(32bit) install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi

2
meta-intel/recipes-bsp/rmc/boards/broxton-m/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

3
meta-intel/recipes-bsp/rmc/boards/broxton-m/INSTALLER.CONFIG Normal file
View File

@ -0,0 +1,3 @@
# 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
meta-intel/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
video=efifb maxcpus=4 reboot=efi kmemleak=off console=tty0 console=ttyS2,115200

2
meta-intel/recipes-bsp/rmc/boards/broxton-m/POSTINSTALL.sh Normal file
View File

@ -0,0 +1,2 @@
# Joule uses only S2 for serial, so remove S0
sed -i '/start_getty.\+ttyS0/d' /tgt_root/etc/inittab

BIN
meta-intel/recipes-bsp/rmc/boards/broxton-m/bm-1F1.fp Executable file
View File

Binary file not shown.

BIN
meta-intel/recipes-bsp/rmc/boards/broxton-m/bm.fp Executable file
View File

Binary file not shown.

4
meta-intel/recipes-bsp/rmc/boards/broxton-m/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title Joule / Broxton-m
linux /vmlinuz
initrd /initrd
options LABEL=boot

4
meta-intel/recipes-bsp/rmc/boards/broxton-m/install.conf Normal file
View File

@ -0,0 +1,4 @@
title Joule / Broxton-m Install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi rootwait

BIN
meta-intel/recipes-bsp/rmc/boards/broxton-m/joule-1F1.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

4
meta-intel/recipes-bsp/rmc/boards/minnowmax/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title Minnow Max boot
linux /vmlinuz
initrd /initrd
options LABEL=boot console=ttyS0,115200n8

4
meta-intel/recipes-bsp/rmc/boards/minnowmax/install.conf Normal file
View File

@ -0,0 +1,4 @@
title Minnow Max install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi console=ttyS0,115200n8

BIN
meta-intel/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

4
meta-intel/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title Minnow Max B3 boot
linux /vmlinuz
initrd /initrd
options LABEL=boot console=ttyS0,115200n8

4
meta-intel/recipes-bsp/rmc/boards/minnowmaxB3/install.conf Normal file
View File

@ -0,0 +1,4 @@
title Minnow Max B3 install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi console=ttyS0,115200n8

BIN
meta-intel/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/mohonpeak/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

3
meta-intel/recipes-bsp/rmc/boards/mohonpeak/INSTALLER.CONFIG Normal file
View File

@ -0,0 +1,3 @@
# 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
meta-intel/recipes-bsp/rmc/boards/mohonpeak/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
console=ttyS1,115200 console=tty1

3
meta-intel/recipes-bsp/rmc/boards/mohonpeak/POSTINSTALL.sh Normal file
View File

@ -0,0 +1,3 @@
# 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

4
meta-intel/recipes-bsp/rmc/boards/mohonpeak/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title Mohon Peak boot
linux /vmlinuz
initrd /initrd
options LABEL=boot

4
meta-intel/recipes-bsp/rmc/boards/mohonpeak/install.conf Normal file
View File

@ -0,0 +1,4 @@
title Mohon Peak Install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi rootwait

BIN
meta-intel/recipes-bsp/rmc/boards/mohonpeak/mohonpeak.fp Normal file
View File

Binary file not shown.

2
meta-intel/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG Normal file
View File

@ -0,0 +1,2 @@
boot.conf
install.conf

6
meta-intel/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG Normal file
View File

@ -0,0 +1,6 @@
# 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
meta-intel/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
i915.preliminary_hw_support=1

7
meta-intel/recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh Normal file
View File

@ -0,0 +1,7 @@
# 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

4
meta-intel/recipes-bsp/rmc/boards/nucgen6/boot.conf Normal file
View File

@ -0,0 +1,4 @@
title NUC Gen6 boot
linux /vmlinuz
initrd /initrd
options LABEL=boot

4
meta-intel/recipes-bsp/rmc/boards/nucgen6/install.conf Normal file
View File

@ -0,0 +1,4 @@
title NUC Gen6 install
linux /vmlinuz
initrd /initrd
options LABEL=install-efi

7
meta-intel/recipes-bsp/rmc/boards/nucgen6/mylib.conf Normal file
View File

@ -0,0 +1,7 @@
# 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"

BIN
meta-intel/recipes-bsp/rmc/boards/nucgen6/nuc6.fp Normal file
View File

Binary file not shown.

1
meta-intel/recipes-bsp/rmc/boards/qemu-2.6/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
console=ttyS0,115200

BIN
meta-intel/recipes-bsp/rmc/boards/qemu-2.6/qemu-2.6.fp Normal file
View File

Binary file not shown.

1
meta-intel/recipes-bsp/rmc/boards/qemu-2.8/KBOOTPARAM Normal file
View File

@ -0,0 +1 @@
console=ttyS0,115200

BIN
meta-intel/recipes-bsp/rmc/boards/qemu-2.8/qemu-2.8.fp Normal file
View File

Binary file not shown.

49
meta-intel/recipes-bsp/rmc/rmc-db.bb Normal file
View File

@ -0,0 +1,49 @@
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

40
meta-intel/recipes-bsp/rmc/rmc-efi.bb Normal file
View File

@ -0,0 +1,40 @@
SUMMARY = "RMC (Runtime Machine Configuration) EFI library"
DESCRIPTION = "The RMC EFI library adds RMC support to existing EFI bootloaders"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=ade413c694d3aaefc9554b24a8814ee8"
SRC_URI = "git://git.yoctoproject.org/rmc"
SRCREV = "027ac76f642dcab1a9f237a00f03a3a714bd04b9"
S = "${WORKDIR}/git"
COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
TARGET_CFLAGS +="-Wl,--hash-style=both"
EXTRA_OEMAKE = "RMC_INSTALL_PREFIX=${D}/${prefix} \
RMC_INSTALL_LIB_PATH=${D}${libdir} \
RMC_INSTALL_HEADER_PATH=${D}${includedir}/rmc"
SECURITY_CFLAGS_remove_class-target = "-fstack-protector-strong"
SECURITY_CFLAGS_append_class-target = " -fno-stack-protector"
python () {
ccargs = d.getVar('TUNE_CCARGS').split()
if '-mx32' in ccargs:
ccargs.remove('-mx32')
ccargs.append('-m64')
d.setVar('TUNE_CCARGS', ' '.join(ccargs))
}
do_compile() {
oe_runmake -f Makefile.efi
}
do_install() {
oe_runmake -f Makefile.efi install
}

46
meta-intel/recipes-bsp/rmc/rmc.bb Normal file
View File

@ -0,0 +1,46 @@
SUMMARY = "RMC (Runtime Machine Configuration)"
DESCRIPTION = "RMC project provides a tool and libraries to identify types \
of hardware boards and access any file-based data specific to the board's \
type at runtime in a centralized way. Software (clients) can have a generic \
logic to query board-specific data from RMC without knowing the type of board. \
This make it possible to have a generic software work running on boards which \
require any quirks or customizations at a board or product level. \
"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=ade413c694d3aaefc9554b24a8814ee8"
SRC_URI = "git://git.yoctoproject.org/rmc"
SRCREV = "027ac76f642dcab1a9f237a00f03a3a714bd04b9"
S = "${WORKDIR}/git"
COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
TARGET_CFLAGS +="-Wl,--hash-style=both"
EXTRA_OEMAKE = "RMC_INSTALL_PREFIX=${D}/${prefix} \
RMC_INSTALL_BIN_PATH=${D}${bindir} \
RMC_INSTALL_LIB_PATH=${D}${libdir} \
RMC_INSTALL_HEADER_PATH=${D}${includedir}/rmc"
SECURITY_CFLAGS_remove_class-target = "-fstack-protector-strong"
SECURITY_CFLAGS_append_class-target = " -fno-stack-protector"
do_compile_class-target() {
oe_runmake
}
do_install() {
oe_runmake install
}
do_install_class-native() {
install -d ${D}${STAGING_BINDIR_NATIVE}
install -m 0755 ${S}/src/rmc ${D}${STAGING_BINDIR_NATIVE}
}
BBCLASSEXTEND = "native"

Some files were not shown because too many files have changed in this diff Show More