summaryrefslogtreecommitdiffstats
path: root/meta-fri2/README
blob: a86617443f06819b599f870d326eeef925139d71 (plain)
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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
This README file contains information on building the meta-fri2 BSP
layer, and booting the images contained in the /binary directory.
Please see the corresponding sections below for details.

The Fish River Island II BSP supports the Kontron M2M Smart Services
Developer Kit, as described here:

http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

The platform consists of the Intel Atom E640T processor plus the Intel
EG20T Platform Controller Hub (Tunnel Creek + Topcliff), along with a
variety of communications options and other machine-to-machine (m2m)
capabilities.

It also supports the E6xx embedded on-chip graphics via the Intel
Embedded Media and Graphics Driver (EMGD) 1.10 Driver.


Dependencies
============

This layer depends on:

  URI: git://git.openembedded.org/bitbake
  branch: master

  URI: git://git.openembedded.org/openembedded-core
  layers: meta
  branch: master

  URI: git://git.yoctoproject.org/meta-intel
  layers: intel
  branch: master


Patches
=======

Please submit any patches against this BSP to the Yocto mailing list
(yocto@yoctoproject.org) and cc: the maintainer:

Maintainer: Darren Hart <dvhart@linux.intel.com>

Please see the meta-intel/MAINTAINERS file for more details.


Table of Contents
=================

  I. Building the meta-fri2 BSP layer
 II. Booting the images in /binary
III. Device Notes
     a. Serial Port
     b. HDMI
     c. Power Reset
     d. Accelerometer
     e. GPIO
     f. MMC
     g. 802.11
     h. 802.15.4
     i. Audio
     j. Optional devices
 IV. Known Issues
     a. EFI boot fails
     b. Client USB is disabled
     c. Audio over secondary HDMI port only


I. Building the meta-fri2 BSP layer
===================================

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.

Having done that, and assuming you extracted the BSP tarball contents
at the top-level of your yocto build tree, you can build an fri2 image
by adding the location of the meta-intel and meta-fri2 layers to
bblayers.conf, e.g.:

  yocto/meta-intel \
  yocto/meta-intel/meta-fri2 \

The meta-fri2 layer contains support for two different machine
configurations. These configurations are identical except for the fact
that the one prefixed with 'fri2' makes use of the Intel-proprietary
EMGD 1.10 graphics driver, while the one prefixed with 'fri2-noemgd'
does not.

If you want to enable the layer that supports EMGD graphics add the
following to the local.conf file:

  MACHINE ?= "fri2"

The 'fri2' machine includes the emgd-driver-bin package, which has a
proprietary license that must be whitelisted by adding the string
"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable
in your local.conf.  For example:

  LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

If you want to enable the layer that does not support EMGD graphics
add the following to the local.conf file:

  MACHINE ?= "fri2-noemgd"

You should then be able to build an fri2 image as such:

  $ source oe-init-build-env
  $ bitbake core-image-sato

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
that below, in the section 'Booting the images from /binary').

NOTE: The 'fri2' machine will include support for hardware video
acceleration via gstreamer if and only if the "commercial" string is
added to the the LICENSE_FLAGS_WHITELIST variable in your local.conf.

For example:

  LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10 commercial"

The reason this is needed is to prevent the image from including
anything that might violate the license terms of the packages used to
implement the the video acceleration feature, such as gst-ffmpeg and
ffmpeg.  As always, please consult the licenses included in the
specific packages for details if you use packages that require
particular LICENSE_FLAGS.

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.


II. Booting the images in /binary
=================================

This BSP 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 live image to it.  For
example:

# dd if=core-image-sato-fri2-20101207053738.hddimg 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


III. Device Notes
================================
a. Serial Port
--------------
The FRI2 has an optional serial daughter card providing a serial
console via the micro-USB port on the top of the device adjascent the
SIM card slot.

The UART from the EG20T is connected to a TI UART-to-USB device
(TUSB3410) which appears as a serial port on the host computer. From a
Linux host, load the driver with the following options:

# modprobe ti_usb_3410_5052 vendor_3410=0x0451 product_3410=0x5053

In future versions of the Linux kernel (3.4 and later), the
vendor and product codes are detected automatically.

When you power on your FRI2, your host will discover a serial device
and name it /dev/ttyUSB0 (or similar). You can communicate with this
device at 115200 8N1 using your preferred terminal emulator.

In order to redirect the BIOS console to the serial port, you may need
to set up console redirection in the BIOS menu. The serial port is
referred to as COM2 in the BIOS.

  Advanced
    Serial Port Console Redirection
      COM2
      Console Redirection [Enabled]
      Console Redirection Settings
        Terminal Type         [ANSI]
        Bits per second       [115200]
        Data Bits             [8]
        Parity                [None]
        Stop Bits             [1]
        Flow Control          [None]
        Recorder Mode         [Disabled]
        Resolution 100x31     [Disabled]
        Legacy OS Redirection [80x24]

Note that the UART clock is configured at 48MHz in the firmware. This
will cause problems with software assuming a typical 1.8 MHz clock.
The Linux kernel pch-uart driver is aware of the clock, but Syslinux,
for example, is not. For software expecting a typical clock, directing
them to use a BAUD of 3318 (rather than 115200) can work around the
problem.

b. HDMI
-------
The FRI2 has two micro HDMI ports. The one closest to the 1/8" audio
jacks is the primary display.

c. Power Reset
--------------
The recessed button adjacent the LEDs on the top of the device is a
power reset button.

d. Accelerometer
----------------
The LIS331DLH accelerometer is connected to the I2C bus on the CPLD on
the compute module. The driver for this chip is under active
development and will be included in the BSP once completed.

e. GPIO
-------
The FRI2 has two I2C PCA555x GPIO devices used for internal control
signals. These have not been exposed in the current release of the
BSP, but may be in the future. Regardless, these do would not provide
general purpose IO with which to read or drive additional signals.

f. MMC
------
The FRI2 provides two microSD card MMC devices. One is located
adjacent the 1/8" audio jacks, another is located on the board inside
the chassis. These devices can be used to boot the device, or as
secondary storage.

g. 802.11
---------
The Intel Corporation Centrino Advanced-N 6205 that ships with the
FRI2 is supported. You can use connman-gnome to configures the
interface.

h. 802.15.4
-----------
The TI CC2531 802.15.4 radio is a USB ACM modem. The MAC is enabled by
issuing the following command:

# echo J > /dev/ttyACM0

The bank of 3 LEDs nearest the power reset button will change if this
command is executed successfully. If you have a 3G modem installed,
the 802.15.4 device may appear as /dev/ttyACM3 instead.

No further testing or integration has been done.

i. Audio
--------------------
The FRI2 has an 1/8" analog output (nearest the antennae), a line-in
input below that, as well as SPDIF over HDMI. These can be tested
using the alsa-utils package. aplay -l will list both playback
devices:

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: MID [HDA Intel MID], device 0: ALC262 Analog [ALC262 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: MID [HDA Intel MID], device 3: ALC262 Digital [ALC262 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Using a sample WAV file, you can use aplay to play to either device:

Over analog:
# aplay -D plughw:0,0 sample.wav

Over HDMI:
# aplay -D plughw:0,3 sample.wav


j. Optional Devices
-------------------
The FRI2 has two mini-PCIe slots internally. The device ships with a
half-length wireless card installed. This can be replaced with a
wireless + bluetooth card. The other slot is available for use with
cellular cards or mSATA SSDs.

The Ericsson F5521gw 3G modem has been verifed with the FRI2 images.
Note that the connman-gnome UI does not allow for configuring the
cellular interface. The ofono-tests package can be used to configure
the modem and bring up an interface.


IV. Known Issues
----------------
a. EFI
------
The FRI2 firmware can boot to an EFI shell. It does not yet boot the
EFI payload provided on the FRI2 live image. This is a known issue
under investigation.

b. Client USB is disabled
-------------------------
The micro-USB port adjacent the primary HDMI port is intended for
Client USB functionality, but is not supported on current revisions of
the device.

c. Audio over secondary HDMI port only
--------------------------------------
While audio over HDMI has been shown to work, it seems to only work over
the secondary (bottom-most) HDMI port. There does not appear to be a
deterministic way of getting the device to output the signal (video and audio)
over the secondary port.