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