1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
meta-intel
==========
This is the location for Intel maintained BSPs.
Please see the README files contained in the individual BSP layers for
BSP-specific information. For details on the intel-common BSPs, see the
conf/machine/README file.
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.
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 'How to Submit a
Change' secion 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.
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.
Building for Intel Quark X1000 microprocessor
---------------------------------------------
To target the Intel Quark X1000.
1. In conf/local.conf set the MACHINE type to be intel-quark.
MACHINE ??= "intel-quark"
2. Build a target image of your choice.
$ bitbake core-image-minimal
3. Use the provided wic script to create an SD card image.
$ wic list images
mkgalileodisk Create an Galileo Gen 1/2 disk image
mkgummidisk Create an EFI disk image
...
$ wic create mkgalileodisk -e core-image-minimal
4. Write the output image to an SD Card
$ sudo dd if=~/mkgalileodisk-*-mmcblk0.direct of=/dev/mmcblk0
5. Insert the SD Card into the reference platform and power on.
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.
|